Subscribe via e-mail: 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
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 Name | ACL Name | Visibility | Default Privilege Level |
| Local System | NT AUTHORITY\System | Local and Network (network access uses computer account credentials) | High |
| Local Service | NT AUTHORITY\LocalService | Local and Network (network access uses anonymous credentials) | Low (as authenticated user) |
| Network Service | NT AUTHORITY\NetworkService | Network (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
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
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:
- Local Service
- Network Service
- Unique domain user account
- Local System
- Local Administrator account
- 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.
