In this article you will learn the fundamentals of Windows service accounts. Specifically, we discover the options and best practices concerning the selection of a service account for a particular service application.

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

It is a common mistake for entry-level Windows systems administrators to associate a local or domain Administrator account with Windows services and applications. I hope that you can see how dangerous a practice this is. If a malicious user were to compromise a service account, then that malicious user accesses your domain up to and including all level of privilege of the associated service account.

It is my goal in this mini-series on Windows service accounts to teach you exactly what these accounts are, what options we have in using them, and what specific best practices Microsoft recommends for their use. Let’s get to work.

What is a Service? ^

A service is compiled code that is typically long-running and executes with no user interaction. By “long-running” we mean that many services are configured to start automatically with Windows. By “no user interaction” we mean that the service typically runs in the background with no visible front-end user interface.

As you know, we can view and modify services by using the Service Control Manager (services.msc) MMC console. We can also view active services by using Task Manager or Sysinternals Process Explorer.

NOTE: Process Explorer is a far superior choice for viewing live processes because we can “drill into” the svchost.exe generic host processes to see individual service names.

Viewing services in Sysinternals Process Explorer

Viewing services in Sysinternals Process Explorer

The IT security principle of least service means, simply, that if we don’t need a particular service on a system, we should disable said service. Note that I said disable the service and not simply set its startup type to Manual.

By applying the least service principle, we not only conserve system resources but we also minimize the attack surface of the system.

What is a Service Account? ^

A service account is a Windows user identity that is associated with a service executable for the purpose of providing a security context for that service.

More broadly, we can say that service accounts are used not only for Windows services, but also for many enterprise applications. For instance, SharePoint 2010 requires service accounts not only for its registered Windows services, but also for its internal application components.

Microsoft introduced managed service accounts (MSAs) in Windows Server 2008 R2 as a way to ease our administrative burden in managing service account passwords. The great thing about MSAs is that we don’t have to worry about our domain password policy messing up our service accounts and breaking our line-of-business (LOB) applications.

The bad thing about MSAs is that because they are still so new, their use is not supported universally, even among Microsoft’s own enterprise application portfolio.

NOTE: Surprisingly, MSAs are supported in SharePoint 2010 but not in SQL Server 2008, which is the data store used by SharePoint.

Because of this compatibility problem, we will not include the use of MSAs in this discussion of service account best practices.

Options for Service Accounts ^

In terms of selecting a user account for a service or application, our choices fall along two lines:

  • A built-in operating system identity
  • A local or domain user account

The following table summarizes the major aspects of the built-in OS identities that are used as default service accounts in Windows.

Account NameACL NameVisibilityDefault Privilege Level
Local SystemNT AUTHORITY\SystemLocal and Network (network access uses computer account credentials)High
Local ServiceNT AUTHORITY\LocalServiceLocal and Network (network access uses anonymous credentials)Low (as authenticated user)
Network ServiceNT AUTHORITY\NetworkServiceNetwork (uses computer account credentials)Low (as authenticated user)

I would like to point out some additional facts concerning the account identities in the previously given table:

You don’t have to manage their passwords. Because these built-in identities are created by Windows itself, the operating system manages their account passwords. In this respect these accounts function like MSAs.

The System account is very highly privileged. The Local System identity is granted system privileges that make this account in many ways more powerful than the built-in Administrator account. Although Local System was designed for access on a local computer only, this account can be associated with services and applications that move across your network. In this case, the credential that is presented to remote processes is Domainname\machinename$.

Be wary of Local Service and Network Service account group membership. Again, the ‘Local’ and ‘Network’ parts of these account names inform us that the Local Service and Network Service accounts are targeted at local and network use, respectively.

However, you should always keep in mind that the Local Service account runs locally as a member of the computer’s Local Users group (Domain Users on domain controllers) and runs remotely as an anonymous connection.

By contrast, the Network Service account runs locally as a member of the local Users or Domain Users groups, and runs remotely as a member of the Authenticated Users group. In addition, Network Service inherits any permissions that have been granted to the source computer account in Active Directory.

User Accounts as Service Accounts ^

You can sidestep some of the complexities of running services with the built-in service accounts by instead using a local or domain user account. One “gotcha” to keep in mind is that Windows automatically grants additional privileges (most notable the Log on as a Service user right) to user accounts we associate with services.

Service account privilege escalation

Service account privilege escalation

In addition, applications that leverage service accounts may grant additional permissions on top of the OS system privileges.

For this reason, it is imperative that you never use a service account for interactive logon. In other words, a human being should never log on to a system by using a service account identity.

We can again use the wonderful Sysinternals Process Explorer tool to retrieve “at a glance” data concerning specifically which system privileges have been granted a service account-driven process.

Sysinternals Process Explorer - System privileges service account

Sysinternals Process Explorer - System privileges service account

So Which Account Should I Choose? ^

According to Microsoft, Windows administrators should choose service accounts based upon the following hierarchy. This hierarchy is ordered from least privilege to greatest privilege:

  1. Local Service
  2. Network Service
  3. Unique domain user account
  4. Local System
  5. Local Administrator account
  6. Domain Administrator account

Obviously, options 5 and 6 in the list represent “worst-case scenarios” in which a given service or application simply will not run with a service account containing lesser privilege and permissions.

Conclusion ^

In this lesson we learned the basic terminology governing service accounts in Windows. We also examined the options available to us in service account use. In the next installment of this series, we will cover the practical application of service accounts in a multi-tier network application context.

Win the monthly 4sysops member prize for IT pros


Related Posts

  1. John 4 years ago

    Thanks for a really good introduction to service accounts. Written at just the right level for me.

    One nagging question I have is if I have selected a Unique domain user account to run a service, how do I then go about determining what file system permissions a need to give to that account.

    For instance, if I was to install a third-party tool (such as Jenkins or JIRA), I am guessing that I would first perform the installation (double clicking an exe or whatever) using my own account, and then assign an Unique domain user account (say JIRA-service-user) to run the service.

    How can I then confidently assign the correct file system permissions to the JIRA-service-user to ensure that it functions correctly? Am I purely dependent on the documentation supplied by the third party tool, or is there some other means of determining correct permissions? Trial and error perhaps?


  2. Michael Pietroforte 4 years ago

    John, I posted your question in the forum.


  3. kanishka 2 years ago

    This is really a good article. I want to gain knowledge in more depth. I hope the author is going to share the same very soon.


  4. Peter B. 9 months ago

    If SYSTEM account "is more powerful than the built-in Administrator account", why the proposed hierarchy is:

    4. Local System,

    5. Local Administrator account



    • TesfayeH 8 months ago

      Peter B.

      Because you can't logon interactively as Local System.


  5. root@localhost 2 months ago

    Do these built-in operating system accounts have any related SID? i.e.


  6. root@localhost 2 months ago

    Oops, they do  😉


Leave a reply

Your email address will not be published. Required fields are marked *



Please ask IT administration questions in the forum. Any other messages are welcome.

© 4sysops 2006 - 2017

Log in with your credentials


Forgot your details?

Create Account