Performing Authoritative Restore of Active Directory Objects

An authoritative restore process returns a designated, deleted Active Directory object or container of objects to its predeletion state at the time when it was backed up. For example, you might have to perform an authoritative restore if an administrator inadvertently deletes an organizational unit (OU) that contains a large number of users. In most cases, there are two parts to the authoritative restore process: a nonauthoritative restore from backup, followed by an authoritative restore of the deleted objects. If you perform a nonauthoritative restore from backup only, the deleted OU is not restored because the restored domain controller is updated after the restore process to the current status of its replication partners, which have deleted the OU. To recover the deleted OU, after you perform nonauthoritative restore from backup and before allowing replication to occur, you must perform an authoritative restore procedure. During the authoritative restore procedure, you mark the OU as authoritative and let the replication process restore it to all the other domain controllers in the domain. After an authoritative restore, you also restore group memberships, if necessary.

Note
If you can isolate a domain controller in the domain that has not received replication of the deletion, the preliminary, nonauthoritative restore from backup is not necessary. For more information, see Recovering deletions without restoring from backup.

You can restore objects in domain directory partitions, application directory partitions, and the configuration directory partition, as follows:

• Domain directory partitions: You must restore the objects on a domain controller in the domain.
  
• Application directory partitions: You must restore the objects on a domain controller that hosts the application directory partition. If you delete an entire application directory partition, you must restore the domain naming operations master to recover the application directory partition.
  
• Configuration directory partitions: You can restore objects on any domain controller in the forest.
  

Note
You can also restore Group Policy objects (GPOs). For information about restoring GPOs, see “Back Up, Restore, Import, and Copy Group Policy Objects” in online Help for the Group Policy Management Console (GPMC).

When an Active Directory object is marked for authoritative restore, its version number is changed so that the number is higher than the existing version number of the deleted object, which replicates as a tombstone in the Active Directory replication system. The change in version number ensures that any object that you restore authoritatively is replicated from the restored domain controller to other domain controllers in the forest, updating the tombstone object to the restored object.
An authoritative restore is most commonly used to restore corrupt or deleted objects, often to recover unintentionally deleted user and group objects. An authoritative restore should not be used to restore an entire domain controller, nor should it be used as part of a change-control infrastructure. Proper delegation of administration and change enforcement will help optimize data consistency, integrity, and security.

Determining objects to restore

Before you perform an authoritative restore operation, determine the objects that must be restored. On domain controllers that are running Windows Server 2008, you can use Ntdsutil to take a snapshot of the directory database. A snapshot is a shadow copy—created by the Volume Shadow Copy Service (VSS)—of the volumes that contain the Active Directory database and log files. You can use the Active Directory database mounting tool (Dsamain.exe) to mount these database snapshots and view the directory data in a Lightweight Directory Access Protocol (LDAP) tool such as Active Directory Users and Computers, ADSI Edit, or Ldp. The database mounting tool can improve recovery processes by providing a means to compare data as it exists in snapshots or backups that are taken at different times so that you can better decide which data to restore after data loss. This eliminates the need to restore multiple backups to compare the Active Directory data that they contain. When inadvertent deletions or modifications occur, you can use a snapshot to compare the data in the current directory against data in the snapshot. If you take regular snapshots, you can sometimes avoid having to restore AD DS if you can identify the differences in the data and return the affected objects to their correct state.
When a recovery operation is required, you can use a database snapshot to assess the differences and determine the objects that you want to authoritatively restore. For information about using VSS shadow copies and the Active Directory database mounting tool, see the Step-by-Step Guide for Using the Active Directory Database Mounting Tool in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkID=103333).

Selecting objects to restore

When you are selecting objects that you want to replicate authoritatively, it is important to select the object that is lowest in the directory subtree as possible that you can still use to recover the deleted objects. In this way, you avoid reverting objects back in time that are not related to the deletion. Objects other than the deleted objects might have been modified after the backup was created.
When you restore an OU, any changes that are made up to the time that a backup is restored are rolled back to their values at the time of the backup. For any user accounts, computer accounts, and security groups in the restored OU that were not among the deletions being restored, this rollback might mean the loss of the most recent changes to passwords, home directory, profile path, location and container information, group membership, and any security descriptors that are defined on those objects and attributes.
For example, if an object with a password, such as a user or computer or trust account, is authoritatively restored, the password value of the restored object reverts to the password value at the time of the backup. In this case, user, computer, and service accounts that have a record of only the current password cannot log on because they have no record of the password that existed when the backup was created. In this way, group membership or other data can also be lost. Updates to the password are blocked because the restored value is authoritative during replication. To minimize the impact of rolling unrelated objects back in time, target as few objects as possible. If you have relatively few deletions to restore, you might be able to restore each object individually.
If you have a relatively large number of deleted objects to restore, use the container object that contains most of the deleted objects. Ideally, the container that you restore will contain all the objects that you need to recover.

Selecting application directory partitions to restore

If you are restoring an application directory partition, the selection process is different from the process that you use to select other Active Directory objects. To authoritatively restore an application directory partition, follow the procedures that are provided for this task but use the procedure in Performing Authoritative Restore of an Application Directory Partition to mark the application directory partition as authoritative, and do not perform the procedures for restoring group memberships.

Authoritative restore procedures

Procedures for this task restore deleted objects and back-links for the restored objects in the domain of the deletions. If you are restoring security principals that might belong to groups in more than one domain or if you are restoring other objects that have back-links to objects in another domain, additional steps are required.
Task requirements
The following tools are required to perform the procedures for this task:

• Repadmin.exe
  
• Remote Desktop Connection (optional)
  
• Bcdedit.exe (optional)
  
• Ntdsutil.exe
  

To complete this task, perform procedures according to the conditions in your environment:

• Procedures for restoring after deletions have replicated
  
  
• Procedures for restoring before deletions have replicated
  
  
• Procedures for recovering group memberships (and any other back-link attributes) in other domains
  
  

Procedures for restoring after deletions have replicated

If you are performing authoritative restore on a domain controller that has already received replication of the deletions, perform the following procedures on the recovery domain controller:

1. If you do not have a current backup of the recovery domain controller, Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin). You can use this backup if your recovery is not successful and then try again.
   
2. Restart the Domain Controller in Directory Services Restore Mode Locally
   
   Or
   
   Restart the Domain Controller in Directory Services Restore Mode Remotely
   
   Restore from backup requires restarting the domain controller in DSRM. Taking the domain controller offline by stopping AD DS is not sufficient to run Ntdsutil procedures to restore from backup.
   
3. Restore AD DS from Backup (Nonauthoritative Restore)
   
   Use this procedure to return the domain controller to its state at the time of the backup so that any groups that are being restored—or whose members are being restored—are present in the directory with their predeletion membership intact. When Ntdsutil.exe generates the .ldf file during authoritative restore, it searches for member attributes that refer to objects that are contained in the text file, which contains the objects that are marked for authoritative restore.
   
   To ensure that replication does not occur, do not restart the domain controller after the restore procedure.
   
4. Mark an Object or Objects as Authoritative
   
   Mark the object or objects that you want to restore so that replication does not overwrite them when you restart the domain controller.
   
5. Restart the domain controller normally.
   
6. Synchronize Replication with All Partners
   
   For the newly restored object to become available and be instantiated in its restored form on all domain controllers, successful outbound replication must occur from the domain controller that originates the restored changes to its partners.
   
   Make sure that all domain controllers in the domain and all global catalog servers in the forest have received the restored objects.
   
7. Run an LDIF File to Recover Back-Links in this domain. This procedure updates the group memberships of a restored security principal object or container of objects in the recovery domain. Perform this procedure for each individual object or container that you marked as authoritative.
   
8. If the .ldf file shows back-links for objects in other domains, perform the procedures in Procedures for recovering group memberships (and any other back-link attributes) in other domains.
   

Procedures for restoring before deletions have replicated

If you have identified a global catalog server or other domain controller that has not received replication of the deletions and for which you have a recent backup, you do not have to perform a preliminary restore from backup. You do not have to perform the authoritative restore procedure in DSRM. Instead, you can stop the AD DS service. Perform the following procedures on the recovery domain controller:

1. Turn Off Inbound Replication. Leave inbound replication turned off until you have finished marking objects that you want to replicate authoritatively.
   
2. If you do not have a current backup of the recovery domain controller, Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin). You can use this backup if your recovery is not successful and then try again.
   
3. Use the Services snap-in to stop AD DS.
   
4. Mark an Object or Objects as Authoritative
   
   Mark the object or objects that you want to restore so that replication does not overwrite them when you restart the domain controller.
   
5. Use the Services snap-in to restart AD DS.
   
6. Synchronize Replication with All Partners
   
   For the authoritatively marked objects to become available and be instantiated on all domain controllers, successful outbound replication must occur from the domain controller that originates the authoritative changes to its partners.
   
   Make sure that all domain controllers in the domain and all global catalog servers in the forest have received replication of the authoritative objects.
   
7. Run an LDIF File to Recover Back-Links in this domain. This procedure updates the group memberships of a restored security principal object or a container of objects in the recovery domain. Perform this procedure for each individual object or container that you marked as authoritative.
   
8. Turn on Inbound Replication.
   
9. Back up the recovered domain controller. See Perform a System State Backup of a Domain Controller by Using the Command Line (Wbadmin) (http://go.microsoft.com/fwlink/?LinkId=118357) or Perform a Backup of Critical Volumes of a Domain Controller by Using the GUI (Windows Server Backup) (http://go.microsoft.com/fwlink/?LinkId=116312).
   
10. If the .ldf file shows back-links for objects in other domains, complete the procedures in Procedures for recovering group memberships (and any other back-link attributes) in other domains.
    

Procedures for recovering group memberships (and any other back-link attributes) in other domains

You can recover group memberships in other domains either by adding the members manually to the respective groups or by using the text file from the original authoritative restore procedure to generate one or more .ldf files that you can use to recover back-links in other domains. Be aware that restored objects might have back-links other than group memberships.
If you have restored security principal objects or other objects that have back-link attributes in a forest that has more than one domain and you do not want to restore the back-links manually, perform the following steps on a domain controller in each additional domain:

Note

For restored security principals, these steps are required only if the restored security principals have memberships in domain local or universal groups in a different domain from the recovery domain. If you restored the security principals on a global catalog server, you need to recover only domain local group memberships in other domains. In some cases, these accounts might be few enough that you can manually recreate the memberships instead of following these procedures.

1. Restart the Domain Controller in Directory Services Restore Mode Locally
   
   Or
   
   Restart the Domain Controller in Directory Services Restore Mode Remotely
   
2. Restore AD DS from Backup (Nonauthoritative Restore)
   
   When the group members were deleted, the member attribute (forward link) on any group of which they were members was removed from the group object. This procedure is required to restore the member attribute on group objects for those group members that were deleted. This attribute is required to regenerate the memberOf attribute value on the restored group members.
   
3. While still in DSRM, use Ntdsutil to Create an LDIF File for Recovering Back-Links for Authoritatively Restored Objects.
   
   In this procedure, you must specify the location of the .txt file that was generated by Ntdsutil during the authoritative restore procedure.
   
4. Restart the domain controller normally.
   
5. Run an LDIF File to Recover Back-Links in this domain on a domain controller other than the domain controller that you restored from backup and on which you created the LDIF file. Because you have just restored the domain controller on which you created the LDIF file from backup, perform this procedure on a different domain controller to be sure that the group objects you update are current. This procedure updates the group memberships of a restored security principal object or container of objects. Perform this procedure for each individual object or container that you marked as authoritative.

More Reference: http://technet.microsoft.com/en-us/library/cc816878%28WS.10%29.aspx