Protect AD from Administrative Errors

Imagine that you're the enterprise administrator of a multidomain Active Directory (AD) environment. You're attending a presentation by your new CIO Steve Johanson justifying the sizable IT budget to the shareholders. The meeting is supposed to start in 5 minutes and your CIO can't access his presentation on the company SAN. When you look up his account to make sure he has the necessary access permissions, you find that his account is missing. You look at the change log and see that your junior administrator was supposed to remove the account for Steve Johnson, who just retired. Then it dawns on you—the wrong user was removed. Now it's panic time. Fortunately, the CIO knows a few good jokes and can entertain the shareholders while you reanimate his user account, give him a new password, and add him back to all the groups in the other domains so he can access the presentation as well as the rest of his reference material. Fortunately, the CIO understands that mistakes happen, but you wish it could all have been avoided.

Most administrators have been in situations in which a mistake has led to users being accidentally deleted or removed from groups or users being granted access they shouldn't have. Although you can purchase expensive AD backup utilities or set up complicated scripts that let you recover an account in only a few minutes, wouldn't it be great if you could avoid these types of mistakes all together?

Protecting AD objects from administrative errors is challenging. One way to meet this challenge is to have administrators check each other's changes before implementing them. Another way is to use third-party tools to automate changes. One solution that not many people are aware of is to use selective authentication, which was introduced in Windows Server 2003, in an external trust.

The selective authentication solution takes some work to set up initially, but it provides an effective way to audit AD changes. When selective authentication is enabled, users (in this case, administrators) in a trusted domain are explicitly granted rights on specific computers in the trusting domain, so you can control what resources they can access.

Here's how to set up an AD environment for selective authentication:

1. On the production side of the AD forest, set up a lag site that contains one domain controller (DC) but no associated subnets. Set up a strict replication schedule in which you either allow replication at very limited times or require all replication to be manually triggered. (Turning off all scheduled replication on a site link will generate spanning tree error events on other DCs.) The replication limitation is controlled through the site link schedule.
2. Set up a second forest (aka the Admin Forest) that contains two or more DCs for redundancy. Place all the administrator accounts for which you want to validate changes in this forest.
3. et up an external trust between the two forests. Although the trust can be domain based or forest based, you need to set it up as a one-way trust, where the outgoing or trusted domain is the admin domain and the trusting side is the production AD. Instead of using the default authentication method, choose the selective authentication method.
4. Grant authentication permission. You now have a group of administrator accounts in the Admin Forest that can see the trust to the production forest but can't authenticate to any of the resources in it. So, you need to grant the Allowed to Authenticate permission to the administrator group on the DC in the lag site (aka lag DC).
5. Grant activity rights. Go through your standard delegation procedure to grant the administrators the rights they need to perform their jobs, such as adding or deleting objects, modifying DNS properties, and creating Group Policy Objects (GPOs).

Selective authentication combined with the Allowed to Authenticate permission on a single DC forces all changes to happen only on that machine. With this setup, administrators can perform their duties, but any mistakes are restricted to one DC in a site that doesn't perform any user authentication. The changes remain there until the replication schedule permits them to propagate. If the replication schedule is manual (i.e., no scheduled times for replication), the changes won't propagate until somebody manually releases them.

This brings us to how to use this solution. You should separate your administrators into two groups. The administrators in one group make changes on the lag DC. The administrators in the other group regularly look at all the changes that have been made on the lag DC. If the changes are acceptable, they force a replication into the live environment. If the changes aren't valid, contain mistakes, or violate company policy, they inform the administrator who made the changes so that he or she can remedy the situation.

So, how does a verification administrator check the changes? In Windows 2003 and earlier, the easiest way is to have Audit DS Changes enabled in the DC's audit policy. This allows all changes made on the DC to be recorded in the security log. Because all changes are being made on a single DC, the verification administrator just has to look at one log and search for any change events that have occurred since the last replication.