Authoritative Restore of Active Directory

An Authoritative Restore of Active Directory is one of the hardest tasks in Windows Server 2003.  To succeed, you need to understand how Active Directory Replication works, be an expert with NTDSutil, find the backup tapes and above all, a sound written plan.

 

Because you can only test an Authoritative Restore in Directory Services Restore Mode (F8 on the boot menu).

 

  • Typical Authoritative Restore Scenario
  • Why do you need an Authoritative Restore?
  • Authoritative Restore Plan and Example
  • Learning Points for Authoritative Restore
  • Summary of Authoritative Restore

 

Typical Authoritative Restore Example

 

Let us take a minute to understand what can go wrong and thus trigger the need for an Authoritative Restore.  You instruct a junior administrator to delete a user account in the Bosses OU.  They open up Active Directory Users and Computers, select the OU.  Now instead of selecting the individual user, they select the entire OU container object and press delete.  Even though they get two warning messages, they ignore them and press OK.  In this scenario we have to assume that this deletion is replicated to all other domain controllers before the senior administrator realizes what has happened.  There is no recycle bin to restore the users, the LostAndFound folder is no good in this situation.  What we need is a laborious Authoritative Restore.

 

Why do you need an Authoritative Restore?

 

It is worth spending a minute taking stock of why we need an Authoritative Active Restore as opposed to a non-Authoritative restore.  The heart of the problem is that in the above scenario, Active Directory is too clever for its own good.  If you delete an ordinary file and restore it from backup, then great, you have the old file back just as it was.  However, when you restore Active Directory, the other domain controllers try and be smart and replicate later transactions so a non-authoritative restore is no good for recovering an OU.  What happens is another Domain Controller just replicates the transactions that deleted the OU because they are newer than the restored version.  As we will see, an Authoritative Restore tricks the other Domain Controllers into accepting the old object by artificially incrementing its version number by 100000.

 

Authoritative Restore Plan

 

Knowledge is power.  Now that we understand the problem, we can make a plan and then put it into action.  NTDSutil will play the star role.  To recap the example problem is that someone deleted an OU called Bosses.

 

  1. The plan is to start with a normal restore.  This is a non-authoritative restore, nothing fancy - yet.  Once you have verified the initial restore, reboot, then press F8, and select Directory Services Restore Mode.  Now its over to NTDSutil and ADSI Edit. (Incidentally if you have trouble with the DSRM password, check here.)
     
  2. While NTDSutil will carryout the actual Authoritative Restore, ADSI Edit will help identify the LDAP name of the deleted OU.  As a matter of tactics we only want to restore one branch or one SubTree of active directory.  If for example, 20 users had been created since the initial disaster, we would not want to wipe them out by the Authoritative Restore.  Fortunately, from the normal restore ADSI Edit will reveal the whereabouts of the OU.  Let us assume that the deleted object was: OU=bosses,DC=ourdom,DC=com.  The point is we only want to restore this one part of Active Directory, all the other objects must be left as they are.
     
  3. Remember, we are in Directory Services Restore Mode, so we are all set to run NTDSutil, here are the commands:

 

Authoritative Restore Example

 

E:\ntdsutil>ntdsutil

ntdsutil: authoritative restore

authoritative restore: restore object OU=bosses,DC=ourdom,DC=com

 

Opening DIT database... Done.

 

The current time is 06-17-05 12:34.12.

Most recent database update occurred at 06-16-05 00:41.25.

Increasing attribute version numbers by 100000.

 

Counting records that need updating...

Records found: 0000000012

 

Learning Points for Authoritative Restore

 

  1. NTDSutil has about 8 modes, we want specifically, Authoritative Restore.
     
  2. Success or failure depends employing ADSI Edit to get the correct path, for me this is the most nerve wracking part of the exercise.
     
  3. Notice how NTDSutil increases the version number by 100000.  This makes sure that these restored object have a later version number than any equivalent object on the other domain controllers.  As a result, when you reboot this machine it will replicate the restored OU=bosses to the other domain controllers.
     
  4. NTDSutil is a Microsoft utility built-in to Windows Servers.

 

Summary of Authoritative Restore
 

'Self heal' works against you restoring when you try and restore Active Directory objects.  The trick, which NTDSutil performs, is to fool AD that the restore has a higher version number than any existing Active Directory records.  Mastering Authoritative Restore is like passing your final NTDSutil exam.  

 

Take the time to understand the role played by ADSI Edit in obtaining the restored object, for example, OU=bosses,DC=ourdom,DC=com