The difference between the 'Local System' account and the 'Network Service' account?

Question

I have written a Windows service that spawns a separate process. This process creates a COM object. If the service runs under the 'Local System' account everything works fine, but if the service runs under the 'Network Service' account, the external process starts up but it fails to create the COM object. The error returned from the COM object creation is not a standard COM error (I think it's specific to the COM object being created).

So, how do I determine how the two accounts, 'Local System' and 'Network Service' differ? These built-in accounts seem very mysterious and nobody seems to know much about them.

Boohoo

Answer 1

Since there is so much confusion about functionality of standard service accounts, I'll try to give a quick run down.

First the actual accounts:

• LocalService account (preferred)

  A limited service account that is very similar to Network Service and meant to run standard least-privileged services. However, unlike Network Service it accesses the network as an Anonymous user.

  • Name: NT AUTHORITY\LocalService
  • the account has no password (any password information you provide is ignored)
  • HKCU represents the LocalService user account
  • has minimal privileges on the local computer
  • presents anonymous credentials on the network
  • SID: S-1-5-19
  • has its own profile under the HKEY_USERS registry key (HKEY_USERS\S-1-5-19)

   

• NetworkService account

  Limited service account that is meant to run standard privileged services. This account is far more limited than Local System (or even Administrator) but still has the right to access the network as the machine (see caveat above).

  • NT AUTHORITY\NetworkService
  • the account has no password (any password information you provide is ignored)
  • HKCU represents the NetworkService user account
  • has minimal privileges on the local computer
  • presents the computer's credentials (e.g. MANGO$) to remote servers
  • SID: S-1-5-20
  • has its own profile under the HKEY_USERS registry key (HKEY_USERS\S-1-5-20)
  • If trying to schedule a task using it, enter NETWORK SERVICE into the Select User or Group dialog

   

• LocalSystem account (dangerous, don't use!)

  Completely trusted account, more so than the administrator account. There is nothing on a single box that this account cannot do, and it has the right to access the network as the machine (this requires Active Directory and granting the machine account permissions to something)

  • Name: .\LocalSystem (can also use LocalSystem or ComputerName\LocalSystem)
  • the account has no password (any password information you provide is ignored)
  • SID: S-1-5-18
  • does not have any profile of its own (HKCU represents the default user)
  • has extensive privileges on the local computer
  • presents the computer's credentials (e.g. MANGO$) to remote servers

   

Above when talking about accessing the network, this refers solely to SPNEGO (Negotiate), NTLM and Kerberos and not to any other authentication mechanism. For example, processing running as LocalService can still access the internet.

The general issue with running as a standard out of the box account is that if you modify any of the default permissions you're expanding the set of things everything running as that account can do. So if you grant DBO to a database, not only can your service running as Local Service or Network Service access that database but everything else running as those accounts can too. If every developer does this the computer will have a service account that has permissions to do practically anything (more specifically the superset of all of the different additional privileges granted to that account).

It is always preferable from a security perspective to run as your own service account that has precisely the permissions you need to do what your service does and nothing else. However, the cost of this approach is setting up your service account, and managing the password. It's a balancing act that each application needs to manage.

In your specific case, the issue that you are probably seeing is that the the DCOM or COM+ activation is limited to a given set of accounts. In Windows XP SP2, Windows Server 2003, and above the Activation permission was restricted significantly. You should use the Component Services MMC snapin to examine your specific COM object and see the activation permissions. If you're not accessing anything on the network as the machine account you should seriously consider using Local Service (not Local System which is basically the operating system).

---

In Windows Server 2003 you cannot run a scheduled task as

• NT_AUTHORITY\LocalService (aka the Local Service account), or
• NT AUTHORITY\NetworkService (aka the Network Service account).

That capability only was added with Task Scheduler 2.0, which only exists in Windows Vista/Windows Server 2008 and newer.

A service running as NetworkService presents the machine credentials on the network. This means that if your computer was called mango, it would present as the machine account MANGO$:

Sulfaguanidine

I think that Managed Service Accounts remove some of the pain of setting up the account and managing the password (or rather pass it off to a domain admin or delegate.) – Hose

Hi, thanks for the explanation. I have one question though - using local system/network service account is it possible to add/remove entries to containers in the active directory (provided the container in active directory has granted full permissions to the computer on which these windows services are running). Please note that everything is working, when I ran the service as one of the domain users, but not as local system/network service (for details #20943936 ) Regards – Cellulosic

Yea, it should. I'll answer your question directly as this question is more abstract and that is a specific implementation. – Sulfaguanidine

Hi, thanks for your answer. i have two questions: 1). what does the computer credential mean if the NetworkService has no password? 2). Can we run desktop applicaiton(e.g. IE) under NetworkService account? – Flintlock

@PeterOehlert thank you for helpful information, can you please provide the complete reference (book or chapter for example) – E

Is it possible to retrieve the name programmatically? E.g. getting NT_AUTHORITY\LocalService from LocalService... – Orthopedics

Note that "anonymous" user is not only, not a member of "authenticated users", it's not a member of "everyone" on Windows. On Windows networks, 'anonymous' only has access to resources that have been explicitly granted to 'anonymous' - by default, nothing. – Puff

@PeterOehlert - In a recent article published by SANS ISC (isc.sans.edu/forums/diary/…), it suggests that the use of service accounts provides an avenue for privileges to be compromised. If the recommendation is to run distinct service accounts, how does one cater for privileged accounts associated with service accounts? – Santamaria

Though this answer is more than 10 years old, I'd say that with the help of more than a few editors it mostly stands the test of time. The SANS article argues that organizations' capacity to implement individual service accounts and manage credential rotation is suspect and unless you do it well it's a bigger risk than using the shared machine credentials from above. I agree, and even as noted in the article, "it's a balancing act apps need to manage." Perhaps it could be more explicitly said, it has to be done well or better not done at all. Also as noted in above, MSAs make this much better! – Sulfaguanidine

@DingxinXu maybe 5 years late but 1) the nomenclature is less than accurate in some spots. By credential I mean identity. You're right that networkservice has no password and no credential as commonly used in identity systems.2) I think if you do some programming against the windows API directly you could get some desktop applications running under NS but no idea why you'd want to or what you'd get. I've done that with system before for certain reasons, but never networkservice but I can't think of why you can't. There may be some unexpected behavior in desktop as it would be unsupported. – Sulfaguanidine

@HakamFostok I don't have a lot of reference. If I recall correctly, Dan Brown covered some of it in his book Programming Windows Security. There's a lot in the windows help and MSDN docs but I have no specific reference. Jeff Richter's book(s) on programming windows, as well as Inside Windows (3rd or 4th Ed) by Soloman & Russinovich also has some. – Sulfaguanidine

@Orthopedics I'm pretty sure there are some APIs that will map back and forth between them but in some cases they are actually returned as special constants from wrappers. At this point I couldn't cite them and would have to go investigate each one to know which does which. – Sulfaguanidine

@Puff My best recollection is that anonymous was removed from the everyone group on windows somewhere around Windows XP SP1 or SP2 around 2003'ish. But I'm not really certain about that at this point. I actually could be wrong and that might go right back to the start of NT but I want to say that changed. – Sulfaguanidine

Hello @PeterOehlert What could be the reason for the NT AUTHORITY\NETWORK SERVICE doesn't appear to me in english ? I was having some issues while running some powershell scripts that was searching by the english name. I was only able to find out by the sid. $objSID = New-Object System.Security.Principal.SecurityIdentifier ("S-1-5-20") $objSID $objUser = $objSID.Translate( [System.Security.Principal.NTAccount]) $objUser.Value this returns to me NT AUTHORITY\Serviço de rede (network service in portuguese) How can I change that to english ? Thanks. – Tamarin

Additional privileges for these accounts may be found at learn.microsoft.com/en-us/windows/win32/services/…, but these appear to change depending on the version of Windows. – Kashmir

Can we all admit that WIndows Security is severely broken? It's so incredibly convoluted that most users and even veteran administrators will turn it off or elevate permissions to get things to work properly. Even Microsoft personnel are clueless about it and often will tell you to just "Run as Administrator." I wish Microsoft would completely overhaul it, but they consistently fail at simplifying things. – Mondragon

in Windows 10 21H1 LocalSystem account has its profile in C:\Windows\System32\config\systemprofile, though it still has no dedicated registry hive – Perlis