How to Rollback and Recover Active Directory Object Attributes

How to Rollback and Recover Active Directory Object Attributes

Editors note: This is the 4th in a series of blogs around Active Directory (AD) backup and recovery using STEALTHbits, StealthRECOVER. Read the 1st blog, An Introduction to Active Directory Backup and Recovery, the 2nd blog, Active Directory Object Recovery, and the 3rd blog Active Directory Recover (Recycle Bin).

The previous two posts in this series focused on Active Directory deleted object recovery. This post will explore a different type of Active Directory recovery. Consider the following scenario:

Our story begins with a mild-mannered I.T. professional who has recently begun to teach themselves PowerShell. After noticing that a significant number of their domain’s user accounts do not contain any mailing address information, our protagonist quickly comes to the realization that they have discovered the perfect opportunity to leverage their nascent scripting superpowers.

The central (and only) character in this narrative next decides that their best course of action is to first identify all of the user accounts that are missing address attributes and then to update those objects with the mailing address of their organization’s main office. I mean, that’s better than nothing, right? Our hero’s efforts culminate in the execution of the following script:

Get-ADUser -Filter {streetAddress -ne '*'} | Set-ADUser -streetAddress '123 Main Street' -l 'Madison' -st 'Wisconsin' -postalCode '53701'

Unfortunately for our burgeoning PowerShell prodigy, the -ne operator used in their filter is an equality operator. This innocent oversight (combined with the inexplicable failure to test this script required for this cautionary tale to have any chance of actually occurring) results in a line of PowerShell that is useful only in updating the address attributes of every user object in the domain with a streetAddress value that isn’t literally an asterisk.

Oops.

While the events described above are solely the product of this author’s admittedly wild imagination and any resemblance to a reasonably plausible scenario is completely coincidental, they illustrate a situation which will inevitably lead to the need to restore the values of a number of attributes across a large collection of Active Directory objects.

As was discussed in this series’ previous post, the Active Directory Recycle Bin introduced changes which result in the retention of object attribute values for a period of time. Unfortunately, that period of time only begins once an object has been deleted, which means the Active Directory Recycle Bin doesn’t help us in this situation.

Active Directory doesn’t actually retain attribute modifications at all, which means that it doesn’t inherently have an answer for this recovery scenario. I mean, technically, you could try building a process around the hope that you are able to become aware of any and all undesirable changes quickly, find a domain controller that has not yet received those changes through replication, and make its objects authoritative. That’s a bit like building your retirement savings plan around a napkin with “win lottery” scribbled on it.

Since Active Directory does not maintain a historical record of an object’s attribute values, our first step toward a solution to this problem is finding something that does. Luckily, when it comes to Active Directory backups, there is no shortage of backup tools available.

One option is to use Microsoft’s Windows Server Backup (“WBADMIN”) tool. Installing the Windows Server Backup feature will install the wbadmin.exe command line tool. It also provides access to the Windows PowerShell cmdlets for Windows Server Backup and a Windows Server Backup MMC snap-in.


All three flavors are simply different ways of leveraging a single underlying application, so a backup taken by any of them is visible to all of them.

There is one important caveat to be aware of with WBADMIN: when configured to store backups in a specific folder, only the most recent copy of the backup is retained. Subsequent backups overwrite the content of the previous backup, which adds a subtle layer of complexity to the management of the backup process.

That said, this batch script will create a folder named using the current date in a YYYYMMDD format below a specified UNC path and then back up the Active Directory ntds.dit file to that folder using WBADMIN’s START BACKUP command:

@echo off
set backupRoot=\\FILESHARE\NtdsBackups\
set backupFolder=%date:~-4,4%%date:~-10,2%%date:~7,2%
set backupPath=%backupRoot%%backupFolder%
mkdir %backupPath%
wbadmin start backup -backuptarget:%backupPath% -include:C:\Windows\NTDS\ntds.dit -quiet

The results of this operation include a Volume Shadow Copy Service (“VSS”) snapshot of the ntds.dit file. The downside of this approach is that the process results in a file that contains only my lab’s 20MB ntds.dit file, but is considerably larger than 20MB. This isn’t a big deal in my lab, but all of that extra disk utilization is not going to scale well in a production environment.

Another option available from Microsoft is NTDSUTIL.exe, a command-line tool for accessing and managing a Windows Active Directory database. NTDSUTIL is dangerously powerful (i.e., your production environment is not the place to learn how to use it), but that’s due in large part to the fact that it contains a suite of incredibly useful commands. Of interest to us in this post is its SNAPSHOT command, which captures the state of Active Directory at the time of the snapshot:

The big downside to this approach is that NDTSUTIL backups are written to the volume that hosts Active Directory, which isn’t ideal.

These two options are far from your only choices, but they’ve given us plenty of backups to choose from during a restore. Now we just have to crack them open and take a look inside. To do so, we’ll use the Active Directory Domain Services Database Mounting Tool (“DSAMAIN”). DSAMAIN will allow us to mount the ntds.dit files hiding in our backups so that we can explore them using LDAP.

We’ll start with one of the VHD images created by WBADMIN. First, we need to find one of our VHDs, mount it, and assign a drive letter to its primary partition.

Next, we find the path to the ntds.dit file in our mounted backup, open a command prompt as administrator, and use the following command to mount the ntds.dit file:

dsamain -dbpath “E:\Windows\NTDS\ntds.dit” -ldapport 10389

Closing the command prompt will stop DSAMAIN, so make sure to keep it open until you finish your restore.

Now that the WBADMIN backup is mounted, we’ll mount the snapshot taken by NTDSUTIL.  To do this, we will open a new command prompt as administrator, use the snapshot command to list our backups, choose one to mount and copy the drive path that is assigned by NTDSUTIL.

Next, we find the path to the ntds.dit file located below the path assigned by NTDSUTIL, open yet another command prompt as administrator and use the following command to mount the ntds.dit file:

dsamain -dbpath “C:\$SNAP_201903261110_VOLUMEC$\Windows\NTDS\ntds.dit” -ldapport 20389

After I had taken the two backups that we just mounted, I changed the Description attribute of my trusty test user Delete Q. Me.

Opening PowerShell, we can use the Get-ADUser cmdlet to look at our test user. Active Directory listens on port 389, by default. If you were paying attention, you might have noticed that we mounted our two backups on ports 10389 and 20389. Using the optional Server parameter will allow us to see what our test user looks like live and in both of our mounted backups.

As you can see, the current value of the Description attribute is “Oops” and both backups contain the previous value, “Demo User Account”.

We can also use PowerShell’s Get-ADUser cmdlet to help restore this attribute to the value captured in our backups. If we grab a copy of the object from one of the mounted back ups we can use that object’s copy of the attribute to set the value of the live object’s attribute:

$UserBackup = Get-ADUser -Identity dqme -Properties Description -Server dc01:10389
Set-ADUser -Identity dqme -Description $UserBackup.Description -Server dc01:389

In practice, it looks like that. Notice that the value of the Description attribute has been restored to the value captured in the mounted backup.

Now that wasn’t too bad, but it was also just a lab exercise. It involved only one specific attribute change made to one specific object. We also knew which backups contained the information we needed for our restore operation. In a real-world recovery scenario, this process can get unpleasant in a hurry. This type of recovery scenario is actually the kind of thing where a tool like StealthRECOVER can provide a lot of value. It allows you to schedule snapshots of Active Directory, search for changes across multiple snapshots, and rollback changes at the object or attribute level.

The final post in this series will discuss the backup and recovery of Group Policy Objects.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free StealthAUDIT® Trial!

No risk. No obligation.