How can you prevent an administrator from harming your computer environment by using his or her rights inappropriately? That's a tough challenge, to be sure. Not long ago, I attended a Microsoft-sponsored technical roundtable on Disaster Recovery. Microsoft noted that one of the top reasons customers ask for disaster recovery help is because of the "accidental bulk deletion of objects." For instance, such a call comes in when an administrator accidentally deletes an Organizational Unit (OU) that has 5,000 users.
Of course, there are procedures to recover those objects, such as the Authoritative Restore tool, but we are interested in preventing it. At that roundtable, one of Microsoft's recommendations to prevent such a disaster was to be careful who you give administration Administrator rights to.
So exactly how would you protect your environment from a rogue administrator? Of course, the easy answer is delegation. Windows 2000 and 2003 permits a granular delegation model that allows fairly restrictive admin rights. An admin can have rights to control objects in an OU or to perform a specific task like modifying the Schema, or editing Group Policy. However, everything can't be delegated. At some point, you have to trust the administrator to simply do the right thing or follow company policy.
Recently, I was asked to come up with a way to prevent an administrator from using the Authoritative Restore tool. Authoritative restore forces a restored Active Directory database to replicate to other servers after restoring from a backup. It ensures that your restored data gets replicated to all of your servers. In this case it was a college environment which had an empty root domain and about 30 child domains. Each educational department had its own domain with an employee of that department as the domain administrator. The college's IT department held the enterprise admin accounts. Apparently one administrator mistakenly performed an authoritative restore that reinstated a number of Domain Controllers (DCs) that had been removed from the domain.
The staff had fixed the Active Directory (AD), and the guilty administrator was no longer employed there, but my client wanted to know how to prevent this from happening again.
Specifically, they wanted to be able to prevent domain administrators from performing functions like authoritative restore that affects the entire forest. They, of course, pointed to documents that state that the domain is a security boundary. So how can a domain admin modify objects in the forest partition? Whether or not the domain is a security boundary has been argued for a long time. It is a boundary in some instances, but it's not an absolute boundary.
I explained that this is not a technical problem but a management issue, and the solution relies on the physical security of a DC. Authoritative restore is performed by booting into Directory Service Restore Mode (DSRM), which allows the DC to boot without loading Active Directory. You must log in to the DSRM administrator account -– essentially a local account on the DC. Thus, even if you did perform some sort of delegation in AD, it would not apply to this account. All you need is the password to the DSRM administrator account and you have access to the data on the DC. The DSRM password can be changed in the NTDSUtil program by any domain administrator who is logged into the domain on the DC, so even if an administrator does not know the password, he or she could change it. When administrators have physical access, there is no way to lock them out and stop them from performing the authoritative restore. In fact, if the cleaning lady found the DSRM administrator password stuck to the manager's monitor and used her pass key to gain physical access to the data center, she could do the same thing.
So this institution was between a rock and a hard place. Management had given domain admin rights to employees of the various departments but couldn't prevent them from modifying objects that affect the forest. Ultimately you have to trust the administrator. If you don't trust an individual's judgment and skills, then you should not grant them the rights.
In this case, they had a couple of options. They could have revoked domain admin rights from all the departmental admins and given them more restrictive rights -– and had the IT department administer the domains. Of course, the downside to that decision is that the IT staff has to administer 30 domains causing personnel issues. The other option, which should have been done in the first place, would be to collapse the forest to a single domain and grant the departments an OU and give OU admin rights to the department.
The point here is that you must understand that physical access to a DC, combined with domain administrator privileges, puts all AD objects within the realm of authority to those individuals with that access.
The NTDS.DIT file holds the entire AD on the disk. Anyone with the DSRM administrator account password and physical access to the server can access it. Any domain administrator can easily reset the DSRM password in the NTDSUtil program. In planning your security model, be sure to consider physical access and the power of the DSRM administrator account when you grant administrator rights to individuals. If you can't trust their judgment and skills, don't give them the rights and then try to get technology to fix it.
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.