Active Directory disaster recovery I

Active DirectoryThe importance of Active Directory disaster recovery is self-evident for system administrators.

Active Directory is one of the most critical services in Windows. To avoid downtime and productivity loss, developing an effective disaster recovery plan for issues related to Active Directory is crucial. This sounds easy, but it is surprising that many administrators have not even made plans for the most common Active Directory failure solution-accidental data deletion.

Accidental deletion of objects is one of the most common root causes of service failure. When I attended seminars and meetings, I often asked who had failed to delete Active Directory because of accidental data deletion. Almost everyone raises their hands every time.

To understand why data recovery is so complex, you must first understand how Active Directory restores and copies objects, how to delete objects, and the structure of authoritative and non-authoritative restores.

Storage objects

Active Directory is a specialized object database that implements the X.500/LDAP data model. Data storage is called the directory information tree or DIT) based on the Extensible storage engine (ESE), which is an index sequential access method (ISAM) database engine. In terms of concept, Active Directory stores the DIT in two tables: The data table contains the actual Active Directory object and attribute) and the link table contains the object ).

Each Active Directory object is stored in a separate row in the data table. Each attribute has one column. A data table contains all entries of all copies stored on the domain controller (DC. On a common DC, data tables contain entries from the domain NC naming context), configuration NC, and architecture NC. On a Global Catalog, a data table contains entries for each object in the forest.

Active Directory uses a 32-bit integer with a distinguished name Mark (DNT) to uniquely identify each row in the data table. DNT used for internal reference objects is much smaller than other identifiers such as a 16-byte binary structure of the distinguished name (DN) and objectGUID. However, unlike objectGUID, DNT is a local identifier and is different in each DC.

How to link objects in Active Directory

Active Directory manages two types of relationships between objects in DIT: parent-child relationships, also known as container relationships) and reference relationships, also known as links ). To implement parent-child relationships, Active Directory stores an additional column in the data table called the parent distinguished name Mark or PDNT. This column always contains the DNT of the parent object of the object.

Each attribute in Active Directory is defined by the attributeSchema object in the Active Directory architecture container. Some attributes in Active Directory are defined as Link Attributes, which are determined by a non-zero even value in the linkID attribute of the attributeSchema object. The link property establishes the relationship between objects in the directory, which can be single value or multi-value. The member attribute of a group object is an example of the multi-value link property-it establishes a link between the group object and its member object.

Even if it seems that the group's member attributes contain the Member's DN, for example, displayed through Active Directory users and computer management units), this is not the way in which Active Directory stores them. When you add the DN of a member object to the group's member attributes, the DNT of the Active Directory storage object is not its DN. Even Renaming an object to DNT does not change, you can rename the user object without sorting all the groups in the system to update the DN of each member attribute. This is how Active Directory maintains the integrity of reference in DIT. Figure 1 shows how a simplified data table is associated with a chain table. The three user objects Molly Clark, Alexander Tumanov, And Makoto Yamagishi shown in these tables are all members of the Senior Engineers group.

These links are called forward links. Similarly, Active Directory also provides backward Link Attributes. This provides a reference for the object returned from the link to the referenced link, meaning that the object has a forward link. The memberOf attribute of a user and a group is an example of the backward link attribute. The property Schema object describes a backward link property, which has a linkID value. Its value is 1 greater than the linkID value of an even number for the forward link property. For example, Windows Server^{®2003 the linkID value of the member attribute in the R2 architecture is 2, and the linkID value of the backward Link's memberOf attribute is 3. For details, Figure 2 provides a list of Link Properties defined by default in the Windows Server 2003 R2 architecture.}

The backward link property is always multi-value and is automatically maintained by Active Directory. In fact, you cannot directly modify the backward Link Attributes. Although it seems that the user or group's memberOf attribute can be modified through the Active Directory user and computer MMC snap-in, the snap-in actually modifies the member attribute of the corresponding group, active Directory updates the memberOf attribute in the background. This is why users can be added to the group without the permission on the user object, because you actually modify the member attributes of the group object. Because each DC manages its backward Link Attributes locally, the changes to the backward link will never be copied. Only copying changes to the forward link attributes, such as the group member attributes ).

On a common DC, a data table contains domain object entries and object entries from the configuration and architecture containers. However, some group types may contain references to objects in other domains. How does Active Directory store DNT of objects not in its data table? The answer is that the infrastructure host FSMO is flexible for single-host operations) the role owner and the object called the phantom object.

Phantom object

When a member is added from a domain to a group in another domain, Active Directory automatically creates a special object called phantom in the data table, which contains the objectGUID, objectSid, and DN of the new member. This provides DNT that can be stored in the member attributes of the group. If the domain controller is a global catalog, you do not need to create a phantom because each object in the forest has an entry in its data table.

DC with the basic FSMO role regularly checks entries in its data table based on the Global Catalog. When it finds that an object is moved, renamed, or deleted, it updates the phantom in the data table and copies the changes to other DC in the domain. Based on the reference count, the infrastructure host also deletes any phantom that is no longer referenced by the forward link attribute in the domain.

Phantom allows DC to manage references to objects in other domains in the forest, but the forward link property can also reference objects outside the forest-such as trusted domains. In this case, Active Directory creates an object called the external security subject (FSP) in the CN = ForeignSecurityPrincipals container in the domain NC. FSP contains the security identifier (SID) of the External Object and other attributes of the object in the external domain, but there is no process to ensure that FSP is up to date. For data recovery purposes, we will treat FSP like any other Active Directory object.

Delete object

Here, I focus on restoring users and their group members. However, the same principle applies to restoring other link attributes.

When Active Directory deletes an object, it does not physically Delete the object from DIT. On the contrary, it sets the isDeleted attribute of the object to true to mark it as deleted, so that the object is invisible to conventional directory operations. According to the schema definition, Active Directory deletes all properties that are not specified and changes the object's relative distinguished name (RDN) to <old RDN> \ 0 aDEL: <objectGUID>. Then, it moves the object to the NC's CN = Deleted Objects container. In the configuration NC, some object classes Active Directory are not moved to the "deleted objects" container .) Active Directory deletes any forward link pointing to other objects retained by the deleted object-this reduces the reference count in the chain table. If other objects contain forward links to existing deleted objects, Active Directory also deletes these links.

The obtained object is called tombstone. Active Directory copies the tombstone to other DC with the same changes. Note that Active Directory does not copy the changes made to the forward link to the deleted object. Each DC has the same changes locally, so you do not need to copy the changes. Later in this article, I will discuss the subsequent results of recovering group members.

Active Directory maintains the logically deleted objects in the DIT from CN = Directory Service, CN = Windows NT, CN = Services, CN = Configuration, the tombstoneLifetime attribute of DC = <root domain> is determined. The garbage collection process for each DC will delete the tombstone older than the configured tombstone lifetime. By default, tombstone^{®2000 Windows Server 2003 and Windows Server 2003 R2 are 60 days, and Windows Server 2003 SP1 is 180 days.}

Tombstone survival is of great significance for the restoration process. Backups older than the tombstone lifetime cannot be restored. Because the deleted and junk objects in the domain no longer have tombstone, the delete operation will never be replicated to the restored DC. The deleted object will be retained in the restored DC as the delayed object, and the restored DC will never be correctly aggregated with other DC in the domain.

Copy object

Whenever the domain controller performs any type of update operations, such as adding objects or modifying attributes, DC will assign a unique 64-bit number to the update operation, called the update serial number (USN ). Active Directory uses USN to mark updated objects and attributes to help determine whether to copy them.

Active Directory copies objects one by one. That is to say, if you modify the attribute of an object, Active Directory will only copy this attribute, not the entire object. To do this, Active Directory uses replication metadata to track its changes to each attribute. The replication metadata of an attribute includes:

Local USN, which identifies the change operation on the local DC.

The invocationID of the DC that causes the change, especially the invocationID attribute of the corresponding nTDSSettings object of the DC), identifies the specific generation of the DIT on the domain controller.

USN when the source operation is on the source DC.

Timestamp, including the DC system time when the source is changed.

32-bit version number, increasing each time the value is changed.

When the target DC requests a change from its source DC partner, it sends the USN that has recently successfully copied the change to the source DC with the latest vector containing the largest source USN. These source usns are the largest source usns seen by the Target DC from each DC with the copied NC copy. The source DC uses this information to send only those updates not seen by the Target DC.

When the target DC processes incoming attribute updates, it checks the version number of each attribute. If the version number of the INPUT attribute is greater than the current version of the attribute, DC stores the input value. If the input version is the same as the existing version of DC, DC compares the timestamp and uses the latest timestamp attribute. If the timestamp is the same, the target DC selects a value with the maximum invocationID. This ensures that each DC finally determines the same value for each copied property.

Copy link value

In Windows 2000, the method for copying multi-value Attributes in Active Directory is the same as that for copying Single-value attributes. This may cause problems for Large Dynamic group objects that may change the attributes of multi-value members on different DC. If one administrator adds a user to a group on one DC, and the other administrator adds another user to the Group on another DC in the replication latency window, then, Active Directory selects the last one to add and completely loses the previous one. Microsoft uses a process called LVR in Windows Server 2003 to handle this problem.

With the function level of the Windows Server 2003 forest or the function level of the Transition forest, Active Directory copies a single value of the multi-value forward link attribute, each value has its own copy metadata. This effectively solves the problem found in Windows 2000, that is, the updates of group members that are almost synchronized on different DC may cause data loss.

However, it is worth noting that. The upgraded forest function level does not automatically use the new copy metadata to fix the existing multi-Value Link Attributes. New metadata is available only for the values added after the forest is upgraded. This has a significant impact on the restoration of group members, and you will soon see it.

Backup

Windows includes a very basic NTBACKUP utility that can be used to perform DC system state backup. The system status of the domain controller includes its registry, SYSVOL, Active Directory DIT file, and key system files. Most third-party Backup utilities also provide the ability to back up and restore the DC system status.

To back up the system status of the disk file, run the following command:

NTBACKUP backup systemstate/F "<filename> & rdquo

Here, <filename> is the name of the backup file to be created, and the. bkf extension should be used.

For more information, click Active Directory disaster recovery details 2.