The Hazards of Running a Service under the Local System Account

Q: What are the security disadvantages of using the local system account for running a service? Does Microsoft offer local system account alternatives that are more secure for running a service?

A: On Windows 2000 and earlier Windows versions, Windows services and third-party applications often run in the security context of the local system security principal. This built-in Windows security principal is also referred to as the LocalSystem account (LSA). In Active Directory (AD), it shows up as Well-Known-Security-ID-System. The LSA acts as the host computer account when it communicates with other entities on the network; as such it appears as $ to these other entities. The actual name of the account is NT AUTHORITYSystem. The LSA doesn't have a password and has a predefined SID: S-1-5-18.

Running a service or application in the security context of the LSA gives the service almost unlimited privileges on a Windows system. The LSA’s powers are comparable to those of the root account on UNIX systems. If a service logs on using the LSA on a domain controller (DC), for example, it obtains local system access on the domain controller (DC) and its resources. This could, if the service was compromised, allow malicious users to change anything they wanted in the AD database. Using the LSA is definitely a bad security practice for organizations that want to honor the principle of least privilege (i.e., give a service the rights it needs to do its job and nothing more or less). For a complete overview of the LSA’s privilege, consult the MSDN article "LocalSystem Account".

To better honor the principle of least privilege when configuring application service accounts, Microsoft provides two new predefined security principals in Windows Server 2003 and Windows XP SP2 and later Windows OSs: the Local Service (S-1-5-19) and the Network Service (S-1-5-20) security principals. Both have significantly fewer privileges than the LSA. A service that runs as Local Service accesses network resources as a null session. This means it uses anonymous credentials. The actual account name of the Local Service account is NT AUTHORITYLocalService and--similar to the LSA--it does not have a password. The Local Service principal is tailored to services that only access local resources and don't need access to other network resources.

The Network Service account, on the other hand, is tailored to services or applications that do need access to network resources. A service that runs using the Network Service account accesses network resources using the credentials of the computer account - similar to how a service does when it uses the LSA. The actual account name of the Network Service account is NT AUTHORITYNetworkService, and --similar to the other two accounts--it doesn't have a password.

Examples of Windows 2003 and XP SP2 services that are using the Local Service account by default are the Smart Card, Remote Registry, and Telnet services. Examples of services using the Network Service account by default are the DNS Client and the Remote Procedure Call (RPC) services. When you want to configure a service to use one of these new accounts as its service account, you must enter the service accounts’ names manually--you can't simply select them from a list. To configure the local service account, type NT AuthorityLocalService (as illustrated in Figure 1 ). To configure the network service account, type NT AuthorityNetworkService. You don't need to provide a password.