Determining Which Service Logon Account to Use

Q: What's the best practice for using service logon accounts? Should I use one of the built-in Windows service logon accounts or should I create a custom service account?

A: A service’s logon account determines the security context it runs in. Let's take a look at the differences between the three built-in service logon accounts (i.e., Local System, Local Service, Network Service) and a custom service account.

The Local System account (SID S-1-5-18) is the highest-privilege account on a Windows system. When a service is configured to run in the security context of the Local System account, the service has full access to a computer’s local resources and will leverage the identity of the local computer account when authenticating to and accessing remote resources. In Windows NT 4.0 and earlier, almost all built-in Windows services run in the security context of the Local System account by default. Giving services such high privileges creates significant security risks and doesn't honor the principle of least privilege.

In Windows Server 2003 and Windows XP, Microsoft introduced two more-restricted built-in service accounts: Local Service (SID S-1-5-19) and Network Service (SID S-1-5-20). The Local Service account is tailored to services that access only local resources and don't need access to network resources. The Network Service account is tailored to services or applications that need access to network resources.

A service that runs using either the Local Service account or the Network Service account has fewer privileges for accessing local computer resources than it would have if it ran using the Local System account. When accessing remote resources, a service that runs using the Local Service account will authenticate as an anonymous user and a service that runs using the Network Service account will authenticate using the local computer account (which is similar to the way services using the Local System account access remote resources). An advantage of using one of the three built-in service accounts is that you can use the automatic password maintenance feature in Windows, which automatically changes a built-in service account's password.

An alternative to using one of the built-in service accounts is to create a custom service account and manually give the account the permissions it needs to access its resources. A major disadvantage of using a custom service account is that you must periodically (depending on the local or domain password policy) change a custom service account’s password—it can't leverage the automatic password maintenance that's available for the built-in service accounts. One potential advantage of running a service as a custom account is that you can control the account’s privileges (i.e., its access permissions and user rights), which you can't control if you use one of the built-in accounts.

A best practice for selecting a service account is to choose the least-privileged account that works for your service. If your service runs smoothly using one of the built-in least-privilege accounts (i.e., the Local Service account or the Network Service account), I recommend using one of those accounts. If a service needs slightly more privileges, create a custom service account with only the access permissions and privileges that the service needs to do its job.

Try to limit the use of the Local System account or the use of a custom service account that's a member of the local administrators, domain administrators, or enterprise administrators groups. Adding a service account to one of these groups is really the worst (i.e., least secure) thing you can do. Doing so will automatically give the service access to all the resources in your Windows domain or even forest.