Introduction

The AD Directory Information Tree (DIT) is implemented as a transactional database using the Extensible Storage Engine (ESE). The primary database file is named ntds.dit and by default is stored in %SystemRoot%\NTDS, but can be relocated during the initial promotion process or manually via the ntdsutil command (see Recipe 16.8 for more details).

Each database write transaction is initially stored in a log file called edb.log, which is stored in the same directory as ntds.dit. That log file can grow to 10 MB in size after which additional log files are created (e.g., edb00001.log), each growing to up to 10 MB. After the transactions in the log files are committed to the database, the files are rotated. These log files are useful when a domain controller is shut down unexpectedly. When the DC comes back online, Active Directory can replay the log files and apply any transactions that may have not previously been written to disk. The edb.chk file stores the last committed transaction, which can be used to determine the transactions in the log files that have yet to be committed. Two 10 MB placeholder files called res1.log and res2.log are used if the disk runs out of space and Active Directory needs to commit changes.

In order to recover portions of Active Directory, or the entire directory itself, you need to have a solid backup strategy in place. You can back up Active Directory while it is online, which means you do not need to worry about having regular downtime just to do backups. Restoring Active Directory is also easy. To do any type of restore, you have to boot into offline mode, more commonly referred to as Directory Services (DS) Restore Mode, where the Active Directory database is not active. You can then restore a single object, an entire subtree, or the complete database if necessary. For a detailed discussion on backing up and restoring Active Directory, see Chapter 13 in Active Directory, Second Edition (O'Reilly).

You need to be familiar with how deleted objects are treated in Active Directory, which can affect your backup procedures. When an object is deleted, the original object is removed, but a tombstone object is created in its place that contains a small subset of the original object's attributes. These objects are stored in the cn=Deleted Objects container in the naming context the original object was located in.

The deleted object is named using the following format: <OrigName>\0ADEL:<ObjectGUID>, where <OrigName> was the original RDN of the object, <ObjectGUID> is the GUID of the original object, and \0 is a null-terminated character. For example, if I deleted the jsmith user object, its tombstone object would have a distinguished name, such as the following:

CN=jsmith\0ADEL:fce1ca8e-a5ec-4a29-96e1-c8013e533d2c,CN=Deleted[RETURN] 
Objects,DC=rallencorp,DC=com

After a period of time known as the tombstone lifetime (60 days is the default), the tombstone object is finally removed from Active Directory. At that point, no remnants of the former object exist in Active Directory.

Tombstone objects are important to understand in regard to your backup strategy because you should not keep backups longer than the tombstone lifetime. If you attempt to restore a backup that is older than the tombstone lifetime, it may introduce objects that were deleted, but the tombstone object no longer exists. Under normal conditions, if you do a nonauthoritative restore from backup, objects that were valid when the backup was taken, but were deleted afterward will not be re-added. A check is done before injecting new objects via the nonauthoritative restore to determine if a tombstone object exists for it. If a tombstone object exists for it, Active Directory knows the object was deleted after the backup. If the tombstone object has already expired (e.g., the backup is older than 60 days), Active Directory has no way to determine if the object was previously deleted and will happily re-add it. Reinjected deleted objects are referred to as lingering or zombie objects.

The tombstone lifetime value is stored in the tombStoneLifetime attribute on the following object: cn=Directory Service,cn=Windows NT, cn=Services, cn=Configuration, <ForestRootDN>.

The Anatomy of a Deleted Object

Deleted objects are stored in the Deleted Objects container of a naming context. You cannot browse that container by default. You need to enable an LDAP control, as explained in Recipe 16.16, to view deleted objects. Table 16-1 contains some of the attributes that are stored with deleted objects.

The attributes that are preserved in tombstone objects are determined by attributeSchema objects that have the 01000 bit enabled (8 in decimal) in the searchFlags attribute.

Table 16-1. Useful attributes of deleted objects

Attribute	Description
isDeleted	The value for this attribute is TRUE for deleted objects.
lastKnownParent	Distinguished name of container the object was contained in. This is new in Windows Server 2003.
name	RDN of the object original object.
userAccountControl	This attribute is copied from the original object after it is deleted. This only applies to user and computer objects.
objectSID	This attribute is copied from the original object after it is deleted. This only applies to user and computer objects.
sAMAccountName	This attribute is copied from the original object after it is deleted. This only applies to user and computer objects.