The LocalSystem account has been around since Windows NT, yet few administrators really understand it.
Although it is a powerful account, it is often used as a crutch for application developers who don't want to deal with figuring out what security they require. The LocalSystem account has some interesting characteristics that create security risks, especially in multiple domain forests.
First, let's look at a few basic concepts of the LocalSystem account. The account exists on every Windows computer -- whether it is a client workstation, domain controller or server. This account has total control over the computer and cannot be locked out or denied of any privilege.
The characteristics of this account include:
On a domain controller, the LocalSystem account has full access to Active Directory because a replica exists on the local computer's file system and is, therefore, considered a local resource.
In Windows NT, there was only a single writable copy of the SAM database, and there was no concept of a forest linking domains and domain security together, other than by external trusts. The domain was the security boundary.
This made the LocalSystem account pretty safe. Windows 2000 introduced the concept of a forest and two additional naming contexts or directory partitions: the schema and configuration partitions. These partitions contain information about every DC, every domain and other forest-wide information like replication topology.
Two specific groups in Active Directory have access to this information. The Enterprise Administrators group has access to domain and configuration information, while the Schema Administrators group has access to schema data. The Domain Administrators group has rights to the resources in a specific domain.
Accounts are appropriately given permissions required for domain and forest administration using these groups. However, the LocalSystem account is a bit of a wild
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
card. As previously mentioned, one of the characteristics of the LocalSystem account is that it has full access to Active Directory because replicas of the AD exist on each DC.
The dangers posed by this account on a domain controller are somewhat frightening because they transcend normal delegation design, where we attempt to limit certain accounts in scope of access. For instance, we usually assume that a domain administrator has no access to the schema or configuration partitions.
Note that a domain administrator account runs in the context of the LocalSystem account. That means that the domain admin has control over all resources on a domain controller. Furthermore, the domain, configuration and schema configurations all exist on each DC and the LocalSystem account has access to every resource on a computer. Therefore, it follows that the domain administrator has access to not only domain resources but also resources in the forest, including other domains. What is even more frightening is that any service running in the context of the LocalSystem would have that same access.
There are a number of ways this exploitation can be accomplished. You just have to run a command or process that runs in the LocalSystem context and do your work through this process.
For instance, the task scheduler service, accessed by the AT command, runs under this account. So any domain admin on a DC could schedule tasks such as the Schema Manager and get access to modify the schema.
In addition, this account could be used to access Exchange information because routing groups, public folder configuration, organization name and other data exists in the configuration naming context and must be available across domains. It is also possible for a domain admin to gain access to mailbox data for Exchange recipients. Note that a DC has about 30 services that run in this context, all of which are vulnerable to the domain administrator.
The case of the DSRM with zero AD security
Several years ago, a client called me and complained that a domain administrator had "corrupted" his organization's forest. It ran a multiple domain configuration in a single forest. The domain admin had decided to do an authoritative restore. Unfortunately, he restored some parts of the configuration partition in addition to his domain. That had the effect of reanimating several DCs that had been decommissioned and broke replication.
My client wanted to know how a domain admin could have access to the forest resources. It's fairly simple. Note that to do an authoritative restore, you boot to Directory Services Restore Mode (DSRM), which has no Active Directory access. The security is the DSRM administrator account. Once you boot into DSRM, there is no AD security, which gives the domain admin a free pass to do whatever he or she wants to do.
There is no way to prevent this other than through physical security or removal of the person as a domain admin. Because the domain admin can run the Ntdsutil when logged in, he or she can change the DSRM admin password, so you can't keep the password secret either.
There are two important points to be made here to protect your forest from an attack using this account:
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Olsen is a Microsoft MVP for Directory Services and formerly for Windows File Systems.
