The Hazards of Running a Service under the Local System Account

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 AUTHORITY\System. 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". . . .