Someone asked me why a certain service worked when run as the NETWORK SERVICE account but not as a service account. Was there anything inherently powerful about the NETWORK SERVICE account?

The short answer is “No”. The long answer is “It depends”. :)

The NETWORK SERVICE is a special account that presents the credentials of the computer it is running on to the remote services it connects to. Thus, for example, if you have an SQL Service (which was the case here) running on a computer COMPUTER1 connecting to a file share on COMPUTER2, and this SQL Service runs as NETWORK SERVICE, when it connects to COMPUTER2 it will connect with the computer account COMPUTER1$. So the question then becomes does the COMPUTER1$ account have any additional rights to the service on COMPUTER2 over the service account? In this case – yes, the COMPUTER1$ account did have additional rights and that’s why the service worked when running as NETWORK SERVICE. Once I gave the service account the additional rights, the SQL service worked as expected under that context too.

For info – there are three such service accounts.

  • NT AUTHORITY\NetworkService – the NETWORK SERVICE account I mentioned above. It has minimum privileges on the local computer. (This account appears as name NETWORK SERVICE).
  • NT AUTHORITY\LocalService – an account with minimum privileges on the local computer, presents anonymous credentials to remote services – meant for running services locally with minimum privileges and no network access. (This account appears as name LOCAL SERVICE).
  • .\LocalSystem – an all powerful local account, even more powerful than the Administrator account; presents the computer credentials to remote services like the NETWORK SERVICE account. (This account appears as name SYSTEM). 

See this StackOverflow answer for more.


Server 2008 R2 introduces Virtual Accounts. Think of these as per-app “NETWORK SERVICE” accounts. Quoting from this link:

Virtual accounts (beginning with Windows Server 2008 R2 and Windows 7) are managed local accounts that provide the following features to simplify service administration. The virtual account is auto-managed, and the virtual account can access the network in a domain environment. If the default value is used for the service accounts during SQL Server setup, a virtual account using the instance name as the service name is used, in the format NT SERVICE\<SERVICENAME>. Services that run as virtual accounts access network resources by using the credentials of the computer account in the format \$. When specifying a virtual account to start SQL Server, leave the password blank. If the virtual account fails to register the Service Principal Name (SPN), register the SPN manually.

So Virtual Accounts present the computer credentials when accessing remote services. Locally, however, they have minimum rights but you can assign them additional rights as required by the application they belong to. Since they are associated with an app, you are able to fine-tune permissions.

This is a good link on service accounts and such.