Managing Service Accounts and Service Account Passwords

Microsoft® Windows® 2000 Scripting Guide

Services must run under a user account. When the SCM starts a service, it logs on to the account that is associated with the service. If the logon is successful, the service process is given an access token. This token identifies the service in any subsequent interactions with securable objects (objects that have a security descriptor attached to them). For example, if the service attempts to access a remote computer, the token is used for authentication. If authentication fails, the service is denied access to the resource.

In Windows 2000, most operating system services run under the LocalSystem account, a special account that is granted all possible privileges to the local computer on which it resides. (Even administrators do not have all privileges granted to them by default.) LocalSystem is often used as a service account because it already has all privileges and does not require special privileges to ensure that the service runs.

Although the LocalSystem account has full access to the local computer, it is never validated by Active Directory. In fact, no password is associated with the LocalSystem account, and you cannot interactively log on as LocalSystem. Because it has no domain credentials, the LocalSystem account has limited access to resources outside the local computer.

Although most services use the LocalSystem account by default, it is recommended that you not run services under this account, especially on domain controllers.


  • The LocalSystem account has access to all resources on the local computer. If the local computer is a domain controller, this means the account has access to everything in Active Directory as well. If someone compromises a service running under LocalSystem, that person then has full Administrator access to every resource on the computer. To avoid this potential security problem, run services under an account other than LocalSystem whenever possible.