AD backups made easier
Active Directory (AD) is one of the most important containers of information in the entire environment. Not only does it store all the users, groups, and computers but it frequently acts as a container for configuration information for other services throughout the organization. An AD failure or loss of data would mean a huge outage for any Windows environment. Fortunately we have multiple safeguards in place for AD.
First, it’s a multi-master directory, which means multiple servers host their own copy of the AD database, ntds.dit, so if one domain controller (DC) fails there are always other DCs to provide directory services to the organization. No DC is considered special—you can remove or lose any DC and stand up another in its place at any time, which is the beauty of the multi-master replication model. Second, backups of AD can capture the entire content of AD, which can be restored from a historical point in time.
This actually brings us to an important point: Because of the multi-master nature of AD, it’s rare to restore a backup in the event we lose a DC. You just create a new DC and replicate the database from another DC.
However, what happens when you accidentally delete an object or a whole organizational unit (OU) of objects? (The most common cause of deletions is, after all, user error.) The deletion is replicated to all the other DCs, so you can’t just copy the deleted object back from another DC. With Windows Server 2008 R2 you can enable the Recycle Bin, so deleted objects can easily be restored.
But prior to Server 2008 R2, or if this feature isn’t enabled, you need to bring the object back from a backup or use third-party tools to try and reanimate the deleted objects. However, this reanimation loses most of an object’s attributes and all group memberships.
Even if you use the Recycle Bin in Server 2008 R2, you might need to put an object back to how it was at a point in time, so backups might still be required. The Recycle Bin doesn’t store historical copies of an object, and only an object that’s deleted makes it to the Recycle Bin.
AD backups aren’t pleasant to work with. You have to boot a DC into a special Directory Services Restore Mode (DSRM), which means the DC is no longer offering directory services. Then you have to restore a backup of AD and manually mark the objects you want to restore as authoritative, so they don’t get overwritten or deleted as soon as the DC is rebooted and starts replicating again.
Imagine not knowing which backup has the right version of an object you want, or being in an audit situation and needing to know what changed on an object. Manually restoring every backup to a DC through DSRM would be very time consuming. Even when you find the right backup, it’s very hard to do comparisons between the content of the backup and the live AD.
Active Directory Database Mounting Tool
Server 2008 introduced a solution to check the content of an AD backup without going through a painful restoration process. The Active Directory Database Mounting Tool, Dsamain.exe, allows an ntds.dit file to be mounted and exposed as an LDAP server, which means you can use such familiar tools as ADSIEdit, LDP.exe, and Active Directory Users and Computers to interact with a mounted database.
Obviously because you’re mounting on a DC, you can’t mount the AD database as the standard LDAP port of 389 but a custom port specified during the mount operation. Once it’s mounted, you can access both live AD content and AD content as it existed when the ntds.dit backup was taken.
I’ll show this in action later in the article. First, though, there’s one other important technology that goes along with the AD database mounting tool that, while not required, is extremely useful.
Active Directory Snapshots
To obtain a backup of AD you use backup software that calls the NTDS Volume Shadow Copy Service (VSS) writer, which is part of the VSS solution for each application or service and ensures the AD information on the disk is in a consistent state so it’s suitable to be backed up. You can view the NTDS VSS writer through the vssadmin list writers command. After you get a backup taken through VSS, you can open up the backup and extract the ntds.dit file, copy it somewhere, then mount it with the Dsamain tool, as we’ll see shortly.
If you’re using the Server 2008 backup utility to perform system-state backups, you could mount the virtual hard disk (VHD) file created natively by the in-box backup application in Server 2008 R2. You could mount it through the Disk Management snap-in or through the VHDMount tool with Server 2008 and just copy the ntds.dit file to a temporary location.
You could use another method, however, which works with normal backups and might be preferable for some environments. Using the same NTDS VSS writer, you can actually create snapshots of AD in-place on the DC, letting you keep point-in-time copies of AD locally for easy access.
We have seen this technology before with shadow copies of file shares that let you see file shares as they existed at previous points in the past. This is exactly the same; we take snapshots of AD at certain points in time and interact with them via the Dsamain tool.
So how much space do these snapshots actually use up? If you’re at a large company with a multi-gigabyte ntds.dit file, you need to factor in the disk space usage of these snapshots. Actually, the only disk space used is for the differences between AD and the point in time the snapshot was taken. A copy-on-write approach is taken, which means when you first take the snapshot there’s no difference between the snapshot and the live AD, so the size of the snapshot storage is basically zero. As AD changes, the old data in AD that’s being replaced by the new data is copied to the snapshot storage so the snapshot contains only the delta (difference) data. The more changes you make to AD, and the longer the snapshot remains, the larger the snapshot will become as the delta increases.
When you want to use a snapshot, it basically combines the information in the snapshot with the information in AD that hasn’t changed since the snapshot was taken. Obviously there’s a slight performance impact using a snapshot, as now any write to AD will first require the data being replaced to be copied to the snapshot storage.
The good news is that snapshots chain together, so if a daily snapshot is taken, then each snapshot contains only the delta information from the day the snapshot was taken until the time the next snapshot is created. At this point you might wonder if you even need to bother with a backup at all.
Looking at the development of Server 2008, initially the in-box backup application wasn’t going to support system-state backup, so the directory services needed its own mechanism, which became AD snapshots. However, Microsoft decided to add system-state support, so the mechanisms to actually restore from a snapshot were never implemented. This means you can’t perform a restore from a snapshot, and to actually perform object recovery in a supported fashion, you still need backups.
However, thanks to AD snapshots, you likely won’t need to use the backups as often. Note that an AD snapshot and a system-state backup don’t contain the same information. While an AD snapshot basically contains information related to AD, a system-state backup also contains the information needed to restore the entire OS. Thus, an AD snapshot is considerably smaller than a system-state backup.
Using AD Snapshots
Now let’s actually manage some snapshots and use them. Remember, you don’t have to use an AD snapshot—you can use the ntds.dit file extracted from a backup. However, for this example I focus on AD snapshots (which are just containers for ntds.dit copies).
You manage snapshots through the NTDSUTIL utility. The steps to manage snapshots involve activating the NTDS instance, then issuing the create command:
C:\Windows\system32\ntdsutil.exe: snapshot snapshot: activate instance ntds
which returns Active instance set to "ntds";
snapshot: create
returns Creating snapshot...Snapshot set \{02eb0c44-701c-4a82-97d1-e3f938844867\} generated successfully.
You can combine all of these commands above into a single line for easy execution or for scheduling snapshot creation:
ntdsutil "activate instance ntds" snapshot create quit quit
To create a list of the snapshots, use the following command:
snapshot: list all
which returns this list:
1: 2009/10/04:12:19 \{02eb0c44-701c-4a82-97d1-e3f938844867\}
2: C: \{5c69a713-98a5-4a97-8aed-c6ce528e8de4\}
Notice that although I took a single snapshot, I actually have two entries. When you take a snapshot, you get a snapshot entry for the complete snapshot that encompasses all the volumes in the snapshot.
You then have an entry for each volume. In this case, only one volume is in the snapshot because the system drive, AD database, and AD logs are all on the C drive. However, if the AD database and AD logs were on different drives, you would also see entries for the volumes containing the database and log files.
To delete a snapshot you have a choice of two commands. Simply type
delete
or
delete
Now that we have a snapshot, we need to mount it onto the file system so we can then access the ntds.dit file contained within the snapshot. Until the snapshot has been mounted it’s not visible in Explorer.
Once mounted, a new folder will be created on the system drive in the format of $SNAP__VOLUME. For example, I created $SNAP_200910041219_VOLUMEC$. To mount it, we use the mount command with either the snap ID or the snap GUID:
snapshot: mount \{02eb0c44-701c-4a82-97d1-e3f938844867\}
and we are told the folder where the snapshot has been mounted:
Snapshot \{5c69a713-98a5-4a97-8aed-c6ce528e8de4\} mounted as
C:\$SNAP_200910041219_VOLUMEC$\.
Once a snapshot is mounted it will stay mounted until manually dismounted. Also note that I mounted the main snapshot ID, which then mounted the volume snapshots that it contained. We can now open Explorer, see that the snapshot is available, and browse its content, including the C:\Windows\NTDS folder, which Figure 1 shows.
Security is maintained: The permissions you have on the files in the snapshot are the same ones you had permission on when the snapshot was taken. To dismount, use the unmount command, passing the GUID or snapshot ID:
snapshot: unmount \{02eb0c44-701c-4a82-97d1-e3f938844867\}
Now you can use the Dsamain tool to offer LDAP services to the ntds.dit file you've exposed through a snapshot or that you copied from a backup. Open an elevated command prompt window and pass the dsamain command path to the ntds.dit file through the /dbpath switch and the LDAP access port through the /ldapport switch:
C:\>dsamain /dbpath C:\$SNAP_200910041219_VOLUMEC$ \Windows\NTDS\ntds.dit /ldapport 51389
You must include ntds.dit in the path, and remember also that you can’t use port 389 for the LDAP as the live AD will be using this; it’s common to use port 51389 instead. An event log is generated notifying you that the database is mounted. Keep the command prompt window open as it contains the dsamain process that's hosting the access.
Although we only passed an LDAP port number, the Dsamain process also opened ports for LDAP-SSL, Global Catalog (GC), and Global Catalog-SSL. The port numbers assigned are just increments of the port we passed for LDAP, so if we passed 51389 for LDAP, then port 51390 would be used for LDAP-SSL, 51391 for GC, and so on.
If you wish to use specific values then use the /sslPort, /gcport and /gcsslport parameters. If you have an ntds.dit file from an earlier version of Windows, you can open it via the /allowupgrade switch. Another useful switch is /allowNonAdminAccess, which as the switch name suggests, allows non-Domain and non-Enterprise admins to access the data. We can now access the data using the standard tools and scripts.
The only difference is we can’t use the default ports for LDAP, GC, and the others; we need to pass the ports we have specified. Let’s use Active Directory Users and Computers: Start it as normal (DSA.msc), then right-click the root of the navigation and select Change Domain Controller.
Choose This Domain Controller or AD LDS instance and type in the IP address and port as shown in Figure 2. You are now accessing the snapshot copy of AD. Numerous tools are available that do comparisons of AD instances and use data in the snapshot for purposes such as object reanimation.
A good one is the Directory Service Comparison Tool, which can be found at lindstrom.nullsession.com/?page_id=11. After you perform the analysis, you can close the Dsamain instance offering the access by pressing Ctrl+C, which will write a 1004 event confirming the service was shutdown. You can now unmount the snapshot through NTDSUTIL.
A Good Start for a Great Feature
As we have seen, just because we can’t directly restore objects from a snapshot or backup exposed via Dsamain doesn’t mean it’s useless. We can use tools to do comparisons between a snapshot and another snapshot or the live AD, and we can copy attributes from a snapshot in the live AD—we just can’t perform a traditional restore and keep attributes such as SID. We can use the information exposed through Dsamain to make sure we have the right backup to restore from or use it to get the information we need to perform an object reanimation. The AD snapshot feature is a great tool for AD admins; I can only hope in the future its role expands to actually allow object restoration.