Windows Server 2008 introduced some better tools for reviewing directory service changes, such as Dsmain. With this tool, you can mount an LDAP database created in a backup (or created using the Ntdsutil utility), then use a script to compare all objects between the offline LDAP backup and the live lag-site forest, thereby letting you see all changes that have yet to propagate. Server 2008 also has enhanced event auditing, which lets you see more information about changes and create custom views to show only changed objects.
There are also third-party audit tools that you can use. These tools let you capture changes in real time and compare different databases on different DCs, providing an easy way to see what has changed.
Had the selective authentication solution been in place, the opening scenario would have played out much differently. Here's what would have happened: The junior administrator sees he needs to delete the account for Steve Johnson, so he logs on to the Microsoft Management Console (MMC) Active Directory Users and Computers (ADUC) console in the Admin Forest using his account, which is also in the Admin Forest. He navigates to the production forest and tries to connect to a DC. Because selective authentication is being used in an external trust, he can only connect to the lag DC—all other DCs give him an access denied message. He searches for Steve Joh* and accidentally deletes Steve Johanson on the lag DC. At this point, the mistake is made, but it's confined to the lag DC.
The verification administrator logs on to the production forest and looks at the changes made on the lag DC. He notices that the account for CIO Steve Johanson has been deleted. Instead of replicating the change to another site and allowing it to spread throughout the forest, he simply contacts the junior administrator about the problem. He also takes the lag DC offline until after the CIO's meeting is over. The CIO can access his resources and won't know about the mistake until he sees the monthly status report—at which point he will thank you profusely.
Note that there are a few caveats when using this solution:
- The chances of a erroneous DS change impacting the production environment have been mitigated but not eliminated. A verification administrator might miss seeing a problem and propagate an erroneous change. This is especially likely if there are a large volume of changes being made. Verification administrators can get caught up in the number of events and not look at them as closely as they should.
- The domain and enterprise administrator accounts still exist in the production forest and can make changes. So, if they really wanted to, administrators could circumvent the system and make changes directly on any DC in the production forest instead of on the lag DC.
Although these caveats exist, they're offset by the solution's potential benefits. Besides the obvious one (i.e., reducing the chance that an erroneous change impacts the production environment), the benefits include the following:
- You have a straightforward way to audit and report on heritage object changes (especially if you use Server 2008) because every change takes place on one DC.
- You add a bit of protection against account compromise. If an administrator account is compromised, the scope is restricted to the lag DC. So, all you need to do is wipe the lag DC and Admin Forest DCs clean, which is much less work than rebuilding AD and all its data.
Obviously, this solution isn't well-suited for a large multinational forest because it would create a tsunami of change verifications. It's also not well-suited for a call center Help desk that does password resets because the new passwords need to be immediately available to users.
However, this solution is well-suited for
- Organizational units (OUs) that contain highly visible accounts, such as the CIO's account.
- mall AD environments in which untrained staff work as AD administrators.
- Small AD environments in which an erroneous change can be catastrophic.
- Probationary administrators. (You can make sure that they know what they're doing before you let them loose.)
- Administrators of critical services, such as DNS.
- Configuration administrators of line of business (LOB) applications that store data in AD, where a mistake will make the application nonfunctional.
Using selective authentication in an external trust provides an effective solution for protecting AD objects from administrative errors. Although it requires some upfront work to set up, it can save you a lot of grief later on. As an advanced Microsoft feature, selective authentication is one more security tool that you can pull out of your bag of tricks.