Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan



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. (This account appears as name LOCAL 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 NETWORK 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.

The NETWORK SERVICE account by rakhesh is licensed under a Creative Commons Attribution 4.0 International License.