Performing an Authoritative Restore of Active Directory Objects

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

On the domain controller that is being restored, an authoritative restore process returns a designated object or container of objects to its state at the time of the backup. For example, you might need to perform an authoritative restore if an administrator inadvertently deletes an organizational unit (OU) containing a large number of users. If you restore the server from backup, the normal, nonauthoritative restore process does not restore the inadvertently deleted OU because the restored domain controller is updated following the restore process to the current status of its replication partners, which have deleted the OU. Recovering the deleted OU requires authoritative restore. You can use authoritative restore to mark the OU as authoritative and let the replication process restore it to all the other domain controllers in the domain.

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.

When an object is marked for authoritative restore, its version number is changed so that it is higher than the existing version number of the (deleted) object in the Active Directory replication system. This change ensures that any data that you restore authoritatively is replicated from the restored domain controller to other domain controllers in the forest.

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 optimize data consistency, integrity, and security.

It is important to ensure successful recovery of the information that is being restored. Group membership is particularly sensitive and can be affected greatly by the procedures that you perform during an authoritative restore.

Important Preliminary Download Requirement for Windows Server 2003

Before you perform an authoritative restore on a domain controller that is running Windows Server 2003, you must install an update that fixes problems that can cause unexpected results that follow authoritative restore procedures. The required update is available in Knowledge Base article ID 943576 (https://go.microsoft.com/fwlink/?LinkID=123945). Review the information and use the links in the article to install the hotfix. For more information, see Known Issues for Authoritative Restore.

Selecting Objects to Restore

When you select 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 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.

Group Membership Restoration Following Authoritative Restore

When a user object is inadvertently deleted, you can restore it by marking the user object as authoritative during an authoritative restore procedure. However, depending on the functional level of the forest at the time that any groups to which the user belongs were created (or the forest functional level at the time that the user was added to the group, if they are different), the user's group memberships might not be restored in the process. Multiply this condition by hundreds or thousands of users when an OU is deleted. In this case, additional steps are required to restore the group memberships of user accounts that are restored.

LVR and Restoration of Group Memberships

Restoration of group memberships for user objects that are deleted and restored authoritatively differs, depending on whether the group was created (or its membership was updated) before or after the implementation of Windows Server 2003 functionality called linked-value replication (LVR). LVR is a feature that is available when the forest has a functional level of Windows Server 2003 interim or Windows Server 2003. In groups that are created before LVR is in effect, the member attribute is replicated as a single value. Therefore, any change to the group's membership results in replication of the entire member attribute. In groups that are created after LVR is in effect, or in groups that are created before LVR but that are updated after LVR is in effect, updates to the member attribute are replicated separately. In this case, group memberships are restored when you use Ntdsutil to authoritatively restore a user, group, or computer object.

The memberOf attribute (or any back-link attribute) is generated only because of its link to the member attribute (or any corresponding forward-link attribute). For this reason, restoring the membership on a user object necessarily involves updating the member attribute on the group object to include the distinguished name of the restored user.

When you use the Ntdsutil command-line tool to authoritatively restore a subtree or single object, the ability of Ntdsutil to restore the group memberships of an object that is authoritatively restored depends on whether the group was created before or after LVR was implemented. For example, if a user object is restored and the user belongs to group G1 that was created before LVR was implemented and the user belongs to group G2 that was created after LVR was implemented (the functional level of the forest was raised to Windows Server 2003 interim or Windows Server 2003), the member attribute of G2 is updated during authoritative restore (and, therefore, the memberOf attribute of the restored user is updated), but the member attribute of G1 is not updated.

However, improvements in the version of Ntdsutil that was introduced in Windows Server 2003 with Service Pack 1 (SP1) provide the ability to also restore the memberships of groups that were created before LVR was implemented.

Authoritative Restore Improvements Introduced in Windows Server 2003 SP1

Beginning with Windows Server 2003 with SP1, during an authoritative restore, Ntdsutil creates a text file that identifies the authoritatively restored objects and uses this file to create an LDAP Data Interchange Format (LDIF) file. The LDIF file can be used to regenerate all back-links on the restored objects in a forest where LVR is not in effect.

If you need to restore a large number of users (for example, if you delete an OU) in domain X and your forest also contains domain Y and domain Z, authoritative restore requires the restoration of domain X and then the use of Ntdsutil to generate and run the LDIF file against a domain controller in each additional domain.

In most cases, you begin the authoritative restore process by performing a nonauthoritative restore from backup. If you can identify a global catalog server that has not received replication of the deletions and you can isolate it before replication occurs, you can perform the authoritative restore without first restoring from backup. For information about using a latent global catalog server for authoritative restore, see Recovering deletions without restoring from backup. In either case, you then perform the additional steps to restore group memberships, if necessary. The steps that you perform are different if you are restoring the objects on a domain controller running a version of Windows Server beginning with Windows Server 2003 with SP1.

Files for Recovering Group Memberships Following Authoritative Restore

When you perform authoritative restore on a domain controller that is running Windows Server 2003 with SP1, Ntdsutil creates the following files that you can use to recover group memberships:

• ar_YYYYMMDD-HHMMSS_links_Domain.ldf, which is an LDIF file that is generated for the domain in which you perform the authoritative restore procedure. This file contains back-link information for the restored objects. If you perform the procedure on a global catalog server, a separate .ldf file is created for each domain in the forest. You can use this file with the Ldifde command-line tool to import the back-links to recover universal and global group memberships in environments that include pre-LVR groups. For environments that do not include pre-LVR groups, the Ntdsutil tool recovers group memberships automatically in the recovery domain and in the forest (for universal groups) if the recovery domain controller is a global catalog server. If the restore includes security principals that can have memberships in domain local groups in other domains, a text file that is also generated during authoritative restore is required to restore the memberships in the additional domains.

• ar_YYYYMMDD-HHMMSS_objects.txt, which is a text file that contains a list of the authoritatively restored objects. This file is generated for each individual object or container that you mark as authoritative. You can use this file to generate an .ldf file that you can use to recover memberships in domain local groups and universal groups (if you are not restoring a global catalog server) in other domains. This file is created on any domain controller that you authoritatively restore. Global catalog servers do not store the member attribute of domain local groups. Therefore, even if you perform the restore on a global catalog server, you must always use this file to generate an .ldf file in any domain where there are domain local groups of which restored security principals might be members. You must create a separate .ldf file for each object or container that you mark as authoritative.

Using a Global Catalog Server for Authoritative Restore

If possible, perform the authoritative restore on a global catalog server in the domain where the objects were deleted to recover security principals and group memberships. Global catalog servers store a single, writable domain and a partial, read-only replica of all other domains in the forest. A partial replica means that the global catalog stores all objects, but with a limited set of attributes on each object. Check the properties of the NTDS Settings object of the server object in Active Directory Sites and Services to confirm that a domain controller is a global catalog server.

Global Catalog and Group Memberships

In relation to the three types of security groups—global groups, domain local groups, and universal groups—global catalog servers are best suited for recovering group memberships after an authoritative restore procedure because they store memberships of all universal groups in the forest and all global groups in the domain.

Security group memberships are restored on a global catalog server as follows:

• Global groups: Security principals (users, groups, and computers) can be members of only the global groups that are created in the same domain. Global catalog servers store a writable domain directory partition. Therefore, they can restore global group memberships for the recovery domain.

• Universal groups: Security principals can be members of universal groups that are created in any domain. However, the member attribute is among the attributes that are stored on the read-only universal group objects in the global catalog. Therefore, a global catalog server can recover universal group memberships for all domains in the forest. A domain controller that is not a global catalog server stores only universal group objects that are created in its own domain.

• Domain local groups: Security principals can be members of domain local groups that are created in any domain. Memberships in domain local groups in the recovery domain are restored automatically during authoritative restore. However, the global catalog does not store the member attribute for read-only domain local group objects. Therefore, for restored security principals that have memberships in domain local groups in other domains, you must recover these memberships by performing follow-up procedures in each additional domain. The follow-up procedures are described in Create an LDIF file for recovering back-links for authoritatively restored objects.

Recovering Deletions Without Restoring from Backup

If you can isolate a global catalog server (or any domain controller, but preferably a global catalog server) in the domain where the deletion occurred before the server receives replication of the deletion, you might be able to avoid performing a preliminary restore from backup (nonauthoritative restore) and having to extend the restore process to other domains. Use the repadmin /showrepl command to determine the date and time of the latest inbound replication of the domain directory partition where the deletions occurred.

Global catalog servers often have greater replication latency than ordinary domain controllers, and they are better restore candidates in general because they store universal group memberships. If you can stop inbound replication on a latent global catalog server, you can perform authoritative restore on the global catalog server to recover the deleted memberships for all groups in the domain and for all universal groups in other domains.

If you want to use a latent global catalog server for restoring deleted objects, you must take steps to stop inbound replication immediately. You can use one of the following methods to stop replication:

• Use the Services snap-in to stop AD DS. In this case, other services continue to operate.

• Take the global catalog service offline by restarting it in Directory Services Restore Mode (DSRM). In this case, all other directory-related services are stopped in addition to AD DS.

• Use Repadmin.exe to stop inbound replication. In this case, the domain controller continues to operate but does not receive replication updates.

Retention (Merge) of New Group Memberships or Other Attributes Following Authoritative Restore

The authoritative restore procedure results in a merge of authoritatively restored objects and attributes and existing objects and attributes. For example, do not expect that users that have been added to a group (after the backup that is used to restore the deleted group) will be removed by an authoritative restore of the group object. Instead, new attributes of objects that are specified in the authoritative restore are preserved during replication. Therefore, authoritative restore does not remove group memberships that were added between the time of the backup that is used for authoritative restore and the time of the restore procedure.

Objects and attributes are preserved during authoritative restore as follows:

• If an object exists in the backup, before inbound replication occurs, the post-restore directory partition contains the version of the object that exists in the restored backup.

• If an object was created after the backup was made and there are additional domain controllers that store the directory partition, after inbound replication occurs, the restored directory partition also includes the set of objects that were created after the backup.

• If an object contains new attributes that are not contained in the backup but that exist in the directory partition of an additional domain controller in the domain at the time of the restore, after inbound replication the version of the object and attributes as they existed in the backup—plus any new attributes that were added to the object after the backup—are preserved.

Authoritative restore affects only the objects and attributes that existed at the time of the backup. This functionality applies to objects with linked attributes and nonlinked attributes alike. For example, if you are restoring an object that has attribute A and attribute B in the backup version and has attributes A’, B’, and C in the current directory, attribute C is retained after authoritative restore. Therefore, a group object that has the member value of User1 in the backup and has both User1 and User2 in the current directory includes both of those memberships after authoritative restore of the group object. Any post-backup memberOf or member attribute values that were added to a user or group, respectively, are not affected by replication updates after the restore procedure.

If you want to remove group memberships—or any other unwanted object attribute—complete the following steps:

1. Delete the object whose updates you do not want to retain.

2. Allow the deletion to replicate throughout the forest.

3. Back up a domain controller that has received the deletion.

4. Authoritatively restore the object that you deleted from the backup that does not contain the unwanted values.

Procedures for Domain Controllers Running Windows Server 2003 with SP1, Windows Server 2003 with SP2, or Windows Server 2003 R2

These procedures include the use of an LDIF file to restore group memberships following authoritative restore of the objects. If you are restoring objects that can belong to groups in more than one domain, additional steps are required.

Task requirements

The following tools are required to perform the procedures for this task:

• Ntbackup.exe

• Ntdsutil.exe

• Repadmin.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, Back up system state. You can use this backup if your recovery is not successful and you can try again.

2. Restart the domain controller in Directory Services Restore Mode locally

   Or

   Restart the domain controller in Directory Services Restore Mode Remotely

3. Restore Active Directory from backup. Be sure to use a backup that contains the deleted objects.

   Restore system state backup 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 pre-deletion membership intact.

   To ensure that replication does not occur, click No at the end of the procedure so that the domain controller does not restart.

4. Mark the object or objects 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 replication must occur between the domain controller that originates the restored changes and 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. Use the following procedure to run the LDIF file that was created in step 2 on this domain controller to add the missing group memberships in the domain that you have just restored:

   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. Back up system state on the recovered domain controller.

9. 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. Perform the following procedures on the recovery domain controller:

1. Turn off inbound replication.

2. If you do not have a current backup of the recovery domain controller, Back up system state. You can use this backup if your recovery is not successful and you can try again.

3. Restart the domain controller in Directory Services Restore Mode locally.

   Or

   Restart the domain controller in Directory Services Restore Mode Remotely.

4. Mark the object or objects authoritative.

5. Restart the domain controller normally.

6. Synchronize replication with all partners.

7. Run an LDIF file to recover back-links in this domain.

8. Turn on inbound replication.

9. Back up system state on the recovered domain controller.

10. 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 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, and if the .ldf file generated during authoritative restore shows back-links for objects in other domains, perform the following steps on a domain controller in each additional domain:

1. Restart the domain controller in Directory Services Restore Mode locally

2. Restore Active Directory from backup.

   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 Directory Services Restore Mode, 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 (not in Directory Services Restore Mode).

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.

Procedures for Domain Controllers Running Windows Server 2003 with No Service Pack Installed

To complete this task, perform the following procedures in order:

1. Restore Active Directory from backup

   Restore system state to return the domain controller to its state at the time of the backup. To ensure that replication does not occur, click No at the end of the procedure so that the domain controller does not restart.

2. Mark the object or objects authoritative

   Mark the object or objects that you want to restore so that replication does not overwrite them when you restart the domain controller.

3. Restart the computer normally, but in isolation. This step allows you to control replication so that inbound replication does not update any restored object before forcing outbound replication. You cannot turn off inbound replication in Directory Services Restore Mode.

   The most common way to start a computer in isolation is to remove the network connection from the domain controller by physically removing the network cable. Alternative methods may be possible, depending on your network hardware and enterprise practices.

   It is important to prevent the domain controller from communicating with any other domain controller in the domain or forest. You should also isolate the domain controller from any clients that might change an object in the directory.

4. Turn off inbound replication

   This step is required only if the domain or forest functional level is Windows 2000 native or earlier. By turning off inbound replication, you ensure that no changes replicate in to the domain controller and alter group membership.

5. Reconnect the computer to the network.

   After you turn off inbound replication, it is safe to reconnect the domain controller to the network.

   If you isolated your computer by removing the network cable or by disconnecting the network connection from the domain controller, reconnect it to bring the domain controller back onto the network.

   If you followed other procedures based on your enterprise network equipment, follow the equipment's recommendations for reconnecting the domain controller to the network.

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 replication must occur between the domain controller that originates the restored changes and 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. Restart the domain controller in Directory Services Restore Mode locally

8. Mark the object or objects authoritative

   One of the challenges of restoring objects, and their group memberships, is the fact that the membership and object may replicate in different orders. If the membership replicates before a user is restored, the receiving domain controller will not update the membership because the user does not exist. To overcome the effects of this behavior, it is necessary to mark the objects that have been restored as authoritative a second time and once again have the information replicated out.

9. Restart the computer normally (not in Directory Services Restore Mode).

   After the authoritative restore of the object or objects has completed a second time, you can restart the domain controller in normal mode.

10. Turn on inbound replication