About Service Logon Accounts

When a Win32®-based service starts up, it logs on to the local computer. It can log on using one of the following:

• The credentials of a local or domain user account
• The LocalSystem account

The logon account determines the security identity of the service at run time, that is, the service's primary security context. And the security context determines the service's ability to access local and network resources. For example, a service running in the security context of a local user account would have no access to network resources. At the other extreme, a service running in the security context of the LocalSystem account on a Microsoft® Windows® 2000 domain controller, would have unrestricted access to Microsoft® Active Directory™. For a discussion of the tradeoffs between user accounts and LocalSystem, see Security Contexts and Active Directoyr.

Ultimately, administrators on the system where the service is installed have control over the service's logon account. For security reasons, many administrators will not allow you to install your service under the LocalSystem account (unless you can present convincing documentation why they should). This means that your service must be able to run under a domain user account. As a programmer, you can exercise some control over your service's logon account. Your service installation program specifies the service's logon account when it calls the CreateService function to install the service on a host computer. Your installation program can suggest a default logon account, but it should allow an administrator to specify the actual account.

Your installation program can also perform the following tasks relating to your service's logon account:

• If you are installing your service to run under a user account, the account must exist before you call CreateService. You can use an existing account or create one as part of the host-computer installation program. See Setting up a Service's User Account.
• If you want clients to use Active Directory support for Kerberos mutual authentication, you need to register the SPNs on the service's logon account. If the service runs under the LocalSystem account, the service's logon account is the computer account of the host computer. See Service Principal Names.
• Ensure that the service at run time has the access rights and privileges that it needs to perform its tasks. This can require setting ACEs in the security descriptors of various resources (directory objects, file shares, and so on) to allow the necessary access rights to the user or computer account. See Granting Access Rights to the Service Logon Account.
• Assign privileges to the specified logon account, such as the right to logon as a service to the host computer. See Granting Logon as Service Right on the Host Computer.

After a service is installed, there are maintenance tasks relating to your service's logon account. See Logon Account Maintenance Tasks.

• Password maintenance. For a service that runs under a user account, you need to periodically change the password and keep the password in sync with the password used by one or more local service control managers to start the service.
• SPN maintenance. If a service's logon account changes, you need to remove the SPNs registered on the old account and register them on the new account. Note that once a service is installed, a domain administrator can change the account under which your service runs (using Win32 functions or the user interface of the Computer Management administrative tool).
• ACE maintenance. If a service's logon account changes, you need to update ACEs and group memberships to ensure that the service can still access the necessary resources.