LocalSystem Account
The LocalSystem account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has extensive privileges on the local computer, and acts as the computer on the network. Its token includes the NT AUTHORITYSYSTEM and BUILTINAdministrators SIDs; these accounts have access to most system objects. The name of the account in all locales is .LocalSystem. The name, LocalSystem or ComputerNameLocalSystem can also be used. This account does not have a password. If you specify the LocalSystem account in a call to the CreateService or ChangeServiceConfig function, any password information you provide is ignored.
A service that runs in the context of the LocalSystem account inherits the security context of the SCM. The user SID is created from the SECURITY_LOCAL_SYSTEM_RID value. The account is not associated with any logged-on user account. This has several implications:
- The registry key HKEY_CURRENT_USER is associated with the default user, not the current user. To access another user's profile, impersonate the user, then access HKEY_CURRENT_USER.
- The service can open the registry key HKEY_LOCAL_MACHINESECURITY.
- The service presents the computer's credentials to remote servers.
- If the service opens a command window and runs a batch file, the user could hit CTRL+C to terminate the batch file and gain access to a command window with LocalSystem permissions.
The LocalSystem account has the following privileges:
- SE_ASSIGNPRIMARYTOKEN_NAME (disabled)
- SE_AUDIT_NAME (enabled)
- SE_BACKUP_NAME (disabled)
- SE_CHANGE_NOTIFY_NAME (enabled)
- SE_CREATE_GLOBAL_NAME (enabled)
- SE_CREATE_PAGEFILE_NAME (enabled)
- SE_CREATE_PERMANENT_NAME (enabled)
- SE_CREATE_TOKEN_NAME (disabled)
- SE_DEBUG_NAME (enabled)
- SE_IMPERSONATE_NAME (enabled)
- SE_INC_BASE_PRIORITY_NAME (enabled)
- SE_INCREASE_QUOTA_NAME (disabled)
- SE_LOAD_DRIVER_NAME (disabled)
- SE_LOCK_MEMORY_NAME (enabled)
- SE_MANAGE_VOLUME_NAME (disabled)
- SE_PROF_SINGLE_PROCESS_NAME (enabled)
- SE_RESTORE_NAME (disabled)
- SE_SECURITY_NAME (disabled)
- SE_SHUTDOWN_NAME (disabled)
- SE_SYSTEM_ENVIRONMENT_NAME (disabled)
- SE_SYSTEMTIME_NAME (disabled)
- SE_TAKE_OWNERSHIP_NAME (disabled)
- SE_TCB_NAME (enabled)
- SE_UNDOCK_NAME (disabled)
Most services do not need such a high privilege level. If your service does not need these privileges, and it is not an interactive service, consider using the LocalService account or the NetworkService account. For more information, see Service Security and Access Rights.
Using the LocalSystem Account as a Service Logon Account
One advantage of running under the LocalSystem account is that the service has complete unrestricted access to local resources. This is also the disadvantage of LocalSystem because a LocalSystem service can do things that would bring down the entire system. In particular, a service running as LocalSystem on a domain controller (DC) has unrestricted access to Active Directory Domain Services. This means that bugs in the service, or security attacks on the service, can damage the system or, if the service is on a DC, damage the entire enterprise network.
For these reasons, domain administrators at sensitive installations will be cautious about allowing services to run as LocalSystem. In fact, they may have policies against it, especially on DCs. If your service must run as LocalSystem, the documentation for your service should justify to domain administrators the reasons for granting the service the right to run at elevated privileges. Services should never run as LocalSystem on a domain controller. For more information and a code example that shows how a service or service installer can determine if it is running on a domain controller, see Testing Whether Running on a Domain Controller.
When a service runs under the LocalSystem account on a computer that is a domain member, the service has whatever network access is granted to the computer account, or to any groups of which the computer account is a member. Be aware that in Windows 2000, a domain computer account is a service principal, similar to a user account. This means that a computer account can be in a security group, and an ACE in a security descriptor can grant access to a computer account. Be aware that adding computer accounts to groups is not recommended for two reasons:
- Computer accounts are subject to deletion and re-creation if the computer leaves and then rejoins the domain.
- If you add a computer account to a group, all services running as LocalSystem on that computer are permitted the access rights of the group. This is because all LocalSystem services share the computer account of their host server. For this reason, it is particularly important that computer accounts not be made members of any domain administrator groups.
Computer accounts typically have few privileges and do not belong to groups. The default ACL protection in Active Directory Domain Services permits minimal access for computer accounts. Consequently, services running as LocalSystem, on computers other than DCs, have only minimal access to Active Directory Domain Services.
If your service runs under LocalSystem, you must test your service on a member server to ensure that your service has sufficient rights to read/write to Active Directory Domain Controllers. A domain controller should not be the only Windows computer on which you test your service. Be aware that a service running under LocalSystem on a Windows domain controller has complete access to Active Directory Domain Services and that a member server runs in the context of the computer account which has substantially实质上 fewer rights.
About Service Logon Accounts
When a Win32-based service starts, it logs on to the local computer. It can log on as:
- 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. 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 cannot access network resources. Conversely, a service running in the security context of the LocalSystem account on a Windows 2000 domain controller (DC), would have unrestricted access to the DC. For more information, and a discussion of the benefits and limitations between user accounts and LocalSystem, see Security Contexts and Active Directory Domain Services.
Ultimately, administrators on the system where the service is installed have control over the service's logon account. For security reasons, some administrators may not allow you to install your service under the LocalSystem account. 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 installer specifies the service's logon account when it calls the CreateService function to install the service on a host computer. Your installer can suggest a default logon account, but it should allow an administrator to specify the actual account.
Your installer can also perform the following tasks relating to your service's logon account:
- Installation. If 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 installrt. For more information, see Setting up a Service's User Account.
- Authentication. If you want clients to use Kerberos mutual authentication, 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. For more information, see Service Principal Names.
- Grant Access. Ensure that the service at run time has the access rights and privileges that it requires to perform its tasks. This can require setting access-control entries (ACEs) in the security descriptors of various resources, that is directory objects, file shares, and so on, to allow the necessary access rights to the user or computer account. For more information, see Granting Access Rights to the Service Logon Account.
- Set Privileges. Assign privileges to the specified logon account, such as the right to logon as a service to the host computer. For more information, see Granting Logon as Service Right on the Host Computer.
After a service is installed, there are maintenance tasks that relate to your service logon account. For more information, see Logon Account Maintenance Tasks.
- Password maintenance. For a service that runs under a user account, you must 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 logon account changes, remove the SPNs registered on the old account and register them on the new account. Be aware that when a service is installed, a domain administrator can change the account under which your service runs; use Win32 functions or the user interface of the Computer Management administrative tool.
- ACE maintenance. If a service logon account changes, you need to update ACEs and group memberships to ensure that the service can still access the necessary resources.