Things in Active Directory get deleted. Sometimes, it’s an accident (or maliciously done) and the object really shouldn’t have been deleted. Other times, something happens that causes great chunks of Active Directory to become corrupted. The oldest technique for dealing with these problems is called an “Authoritative Restore”. In the past, this process involved restoration of the System State of a domain controller. If your domain controllers are virtualized and you’re using a hypervisor-level backup tool like Altaro, restoring just the System State is not an option. Fortunately, that’s not really a problem.
What is Active Directory Authoritative Restore
Active Directory is, at its core, a database. In Windows NT 4.0 and earlier, the domain had a single master copy of the database which lived on a designated Primary Domain Controller (PDC). All other domain controllers were set as Backup Domain Controllers (BDC). Changes could only be made directly to the PDC, which would then send copies out to all the BDCs. Damage in this environment almost always meant a restore of the PDC.
When Active Directory was introduced with Windows 2000 Server, the database became “multi-master”. Every domain controller from then on was writable (until the introduction of the Read-Only Domain Controller in 2008, which is pretty much a BDC). Since updates can be made on any DC, it is possible for the same object to have multiple updates from separate domain controllers. To address this, Active Directory has a conflict resolution technique that involves local Update Sequence Numbers and activity timestamps. When replication occurs, this information can be used to determine which change was made last; with the exception of an object deletion, the newest change prevails. You can read more about the process in this TechNet article.
With this model in mind, the non-authoritative restore is easiest to understand. It brings back the database on a domain controller in the state that it was in at the time of the backup. Assuming that at least one replication cycle has passed since that backup occurred, other domain controllers already know that the USNs on those objects were already processed, so they’re ignored. The purpose of a non-authoritative restore is mainly to repair a domain controller that has become damaged in some way without rebuilding it entirely.
An authoritative restore marks the entire Active Directory database or specific objects in a way that causes them to override any other replication changes in the directory. As far as I can tell, that method is, “I’m going to add a gigantic number to my local USN so that there’s just no way anyone else has a higher one!” It works, so I won’t criticize. This technique can be used to recover deleted items, repair a completely corrupted Active Directory topology, or return an incorrectly modified object to an earlier state.
Authoritative Restore in a Single Domain Controller Environment
When there is only one domain controller, there is really no distinction between an authoritative or non-authoritative restore, because replication never occurs. Restoring a domain controller’s system state overwrites the NTDS.DIT file that contains the database. Without any incoming replication activity with newer information, all changes newer than the restore are simply lost.
Active Directory Recycle Bin
Your first, best option for recovering deleted Active Directory objects is the Active Directory Recycle Bin. This was introduced without much fanfare in Windows Server 2008 R2. Many administrators still haven’t heard of it today. Some only learn of it after they need it, which is not helpful because it is disabled by default. It doesn’t entirely save you from the need to perform an Active Directory restore, though, because it can only restore deleted items. If you just want to undo a change, it can’t help. If your directory has suffered corruption or other catastrophic failures, it likely can’t help with that, either.
If you are reading this for information purposes and haven’t yet enabled your AD recycle bin, you might want to think about doing that now.
Active Directory Recycle Bin in 2012+. 2012 and later are functionally the same, but there is now a user interface to make it a bit smoother.
Of course, I wrote this article for the times that the AD Recycle Bin won’t help you. Let’s move along to that.
How to perform an Authoritative Restore of Active Directory with Altaro VM Backup
As I mentioned in the opening text, you can restore the entire directory or individual objects. There is only one point of deviation between the two tasks, so I’m going to show you everything in a single list of steps. Take care to choose the correct option or you’ll have a fully restored database when you may not want one. Also, I’m showing how to do this with the Hyper-V version specifically. The difference will be in the cleanup routine.
The nice thing about performing this in a virtual environment is that you can do it a lot more safely and quickly than you can in a physical environment. I did some testing with the old system state restore steps, and that took over three hours with my hardware. On the same systems using Altaro VM Backup, I was able to perform the same process in less than an hour. Since I’m assuming you have much better hardware than my test lab, you can probably do all this in a half hour or less.
Before you can start, you need to know the Distinguished Name (DN) of the object. This is a fancy term that means “the entire LDAP form of the object”, sort of like a fully-qualified DNS name, only in LDAP. If you don’t know this but can guess at it, go ahead and try these steps. If you have never used the LDAP name structure before, then time for a crash course — don’t worry, it’s actually fairly simple. There are a number of two-character type labels: CN for Canonical Name (in Active Directory Users and Computers, this is the Name field as it appears in the list), OU for Organizational Unit, DC for each separate component of the domain name. The different components are separated by commas. They are ordered like DNS, which means that they appear in the exact opposite order of the way you drill down to them in ADUC. For example, my non-administrative user account in my lab in LDAP format is:
CN=Eric Siron,OU=Users: Standard,DC=siron,DC=int
Now that you’ve seen the “hard way”, an easier way (if your DC is new enough to have the AD PowerShell cmdlets) is to get the (DN) for a similar object. A few examples:
Get-ADOrganizationalUnit -Filter 'Name -like "*Human Resources*"'
These will all return a list of objects, one of which is the DistinguishedName (you can pipe to select if you want to narrow it down right away). Of course, this won’t show you the name of the deleted object because it’s deleted, but you can run it on the most similar object that you know of to get the pattern. If you just don’t know the object, I can actually help you with that. Look at step 4 when you get there.
Aside from that and a good backup, you don’t need anything else. It’s very nice to have the Directory Services Repair/Restore Mode password for the domain controller that you’ll be working with, but I can show you how to get around not having that… also in step 4.
- Open Altaro VM Backup and go to the Restore tab on the lower left. Click to check the location that you want to restore from. Click Next.
- Choose the virtual domain controller that you want to restore. Click Next.
- The first thing to do on this page is select which version of the VM to restore. If you don’t have a copy that pre-dates the deletion, then there isn’t anything else you can do. If there is, choose it. After that, we encounter the first point of deviation. If you want, you can stop and delete the original DC and then restore this with the same name. I chose to restore a clone instead. I strongly recommend that you do the same: use the power of virtualization any time you can. This allows the domain controller to stay online for the maximum possible amount of time which gives you plenty of breathing room if you need to guess. It ensures that you don’t have to rebuild backup jobs and anything else that refers to the VM by GUID. If you clone and can’t find the object or anything else goes wrong in the clone, then the worst case scenario is that the object just isn’t recovered. Whatever you choose to do, you definitely want to check the box near the bottom to Disable network card or you’ll have all kinds of horrible problems that are much worse than a little IP conflict. I will list the rest of these directions as though you are working from a clone. After you accept the options on this screen, the restore proceeds. You can follow it on the dashboard.
- Once your clone VM is created, what you must do next depends on whether or not you have access to the Directory Services Restore/Repair Mode password for this domain controller. If you have it and you have the DN of the object(s) to recover, good job! Jump to step 5. Otherwise, be happy that you didn’t attach the restored VM to the network and follow these substeps:
- Connect to the VM’s console and boot it up normally. Log in as a domain administrator using an account/password combination that was valid when the backup was taken.
- Remember how I said I could help you find the DN of the deleted item(s)? Well, you’re working with a copy of the AD database as it was when this backup was taken and its not replicating since it can’t connect to any other DCs. Go ahead and poke around in Active Directory Users and Computers and/or PowerShell until you get the name(s) of the object(s) that you’re looking for. If you’re working in PowerShell, you can even copy/paste the DN to a text file for really easy access later.
- Open an elevated command or PowerShell prompt.
- Type ntdsutil and press Enter.
- Type set dsrm password and press Enter.
- Type reset password on server null and press Enter. You actually type the word “null”. If you’d rather type in the actual host name, OK.
- You’ll be prompted to enter the new password twice. Try to remember it this time. The domain admin password might be what’s wrecked next time.
- Type quit and press Enter twice.
- Shut down the VM and proceed to step 5.
- Open the restore VM’s console directly and power it on. Start pressing F8 as soon as the Hyper-V splash appears. If you did it right, you’ll be greeted with the following menu where you’ll want to select Directory Services Repair Mode (Directory Services Restore Mode in earlier versions). If you’re not lucky and miss it, first be really happy that you didn’t allow it to connect to the network. Second, shut it down (gracefully!) and try again until you get the menu.
- When the machine boots up, you cannot log in as a regular domain administrator. You need to change the user name that you log in with. On 2012+, click the white back arrow with the white circle around it, then click Other User. I think on 2008 R2 and earlier the user name field was there for you to type into, but feel free to leave a comment to correct me. In the user name field, type “.Administrator”. For the password, use your DSRM password.
- When the system boots, you’ll know all is as it should be if it has the old all-black background with Safe Mode emblazoned on it.
- Open an elevated command prompt and type the following:
- activate instance ntds
- authoritative restore
- What you do next depends on what you want to restore.
- To restore the entire database, type: restore database. Press OK. You can’t do anything else, so proceed to step 10 (or shut the VM down and go back to step 1 if you didn’t mean to restore the whole database).
- To restore a single object (not an OU), use its Distinguished Name: restore object "CN=Eric Siron,OU=Users: Standard,DC=siron,DC=int". You can keep typing lines to restore multiple objects. You can also proceed to sub-step 3 if you need to restore OUs. For you PowerShell buffs, encapsulating the name in single quotes instead of double-quotes will cause syntax errors.
- To restore an OU: restore subtree "OU=Users: Service Accounts,DC=siron,DC=int".
- You should see some cryptic output such as the following that includes the word “Successfully” at least once. If not, either you mistyped something or the object is not in this backup set.
- Type quit until you get back to the command prompt. Shut down the VM.
- Let’s pause here and take stock of what we have. If you followed me straight through, then there is an active copy of the domain controller that’s running without the deleted object. There is an offline clone of the same domain controller that contains a copy of the object(s) that you want to recover that are marked as authoritative. There is at least one other functioning domain controller. If you don’t have all of these things, then STOP. Do not proceed until you have an offline domain controller with an authoritative copy of the items to restore and one other domain controller.
- Perform a graceful shutdown of the original domain controller that you restored a clone of. It should replicate out any pending information before shutting down, but you’re free to use Active Directory Sites and Services to force it to replicate before shutting down, if you like.
- Replace the live VM’s virtual hard disks with those of the clone. For Hyper-V, it’s a pretty quick process using Hyper-V Manager and Explorer that you can probably figure out on your own (remove the old, add the new). I don’t work with VMware enough to be able to give you the complete process there, but as I recall, it isn’t difficult either. Here are PowerShell versions for Hyper-V:
- First, run Get-VMHardDiskDrive -VM svdc1 and keep the output on screen (by not closing the screen) or copy it to notepad (which works just fine even in Core/Hyper-V Server). You need to know the ControllerType, ControllerNumber, ControllerLocation, and Path. If the Path is truncated, run Get-VMHardDiskDrive | select ControllerType, ControllerNumber, ControllerLocation, Path | fl.
- Detach the hard drives from the VM: Get-VMHardDiskDrive -VMName svdc1 | Remove-VMHardDiskDrive.
- Rename the file(s) that you detached (use the items from step 1), ex: ren 'C:LocalVMsVirtual Hard Diskssvdc1_os.vhdx' svdc1_os.vhdx.prerestore.
- Copy in the same file(s) from the restored VM, ex: cp 'C:AltaroRestoredsvdc1 (30-08-2015 04h39m23 Clone)*.vhdx' 'C:LocalVMsVirtual Hard Disks'.
- Using the information from step 1, attach the restored file(s) to the VM: Add-VMHardDiskDrive -VMName svdc1 -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0 -Path 'C:LocalVMsVirtual Hard Diskssvdc1_os.vhdx'.
- Turn the original virtual machine on. Allow it to boot normally. Verify that the items that you recovered looks as you expect. You can force replication to get the changes out quickly, if you’d like.
If everything is as you expect, get rid of the clone. The disks that it came with and the backup files that you created in 14.2-3 are mostly harmless, but they should still be removed as soon as you’re certain that everything is OK.