Problem: John was awakened from a dead sleep by the Benny Hill theme ring tone he had just downloaded to his cell phone earlier that evening----one of his junior Network Admins had accidentally deleted one of their larger account OU's. In the blink of an eye five thousand user objects had been removed from AD. John was horrified to hear that his company's CEO was among one of the many deleted accounts. He took a second to regain his composure. No problem, he thought to himself, they ran system state backups nightly, and had practiced restoring them just in case they ran into problems like this one.
They successfully restored the system state backup of one of their DC's and issued the ntdsutil "Authoritative Restore" command for that particular OU. After about two hours of frantic work everything appeared to be back to normal.
The help desk calls started rolling in the next day. Many users were reporting that they were being denied access to resources that they once had access to. It appeared that the user's group membership was out of whack. After some investigation, John discovered that while some DC's had correct group membership for the affected users, many others did not...
For my first technical post I thought I would go over one of the more common Active Directory issues that I see: AD user and group restore.
This problem manifests itself in any numbers of ways, but most commonly someone just accidentally deletes an OU.
The procedure itself is fairly straightforward, (the recovery process is very well documented) but there are some peculiarities that you sometimes run into during the process.
Here is a simplified list of steps required to recover users along with their group membership:
*** Steps summarized from KB 840001 *** This article is updated regularly. Please consult the article for the latest information.
Determine if the deletion has already replicated to all of your Global Catalog DC's. If there is a latent GC/DC that has not processed any part of the deletion, then disconnect it from the network or disable inbound replication with the repadmin.exe command. (repadmin /options dc_name +DISABLE_INBOUND_REPL)
If there isn't a latent DC, then you will have to find a recent system state backup from a GC/DC from the domain where the deletion occurred.
Reboot the recovery DC into DS restore mode and perform an authoritative restore (or if you did not find a latent DC, restore the system state and then perform the authoritative restore)
If you did not have to restore the system state, reboot normally. Reboot with the network cable disconnected if you did restore the system state, and then disable inbound replication with the repadmin command.
Initiate outbound replication to all dc's in the domain (and gc's in the forest) with the repadmin /syncall command:
repadmin /syncall dc_name /d /e /P YourDomainDN (such as dc=microsoft,dc=com)
/d: identifies servers by distinguished name in messages.
/e: Enterprise; includes partners in all sites.
/P Pushes changes outward from the home server.
*Here is where you have to be careful, and why it is important to fully understand all of the commands that you run in a production environment.
Some documentation states to use the /A option as well with the repadmin command. The /A option tells repadmin to synchronize all directory partitions that are held on the server. This would be fine to use in a small environment, but probably not a good idea if you have a lot of DC's, or have DC's with slow WAN links. If you are just restoring users and groups then we just need to synchronize the domain partition.
Wait for end to end replication to occur, and then proceed with fixing up group membership:
(here it gets a little tricky)
If all groups are LVR enabled then group membership was corrected when you issued the authoritative restore command. Information on LVR is available at the bottom of this post.
Method 1: If you performed the authoritative restore on a DC with 2003 SP1 then it created one or more ldif files that you can import with ldifde.exe to correct group membership. (ldifde -i -k -f filename.ldf -s Recovery_DCname)
* Be sure to specify the -s option along with the name of the name of the recovery dc name or it may connect to another DC and the command will fail.
Method 2: If this is a Windows 2000 DC or a Server 2003 DC without SP1 then you need to correct group membership manually. We have a utility called groupadd.exe that can aid you using this method.
Method 3: If you don't mind rolling back group membership to the time that the system state was created, you can boot back into DS restore mode and issue another authoritative restore command. (here you need to issue the command against the container that your groups exist in)
Outbound replicate again via repadmin, and then re-enable inbound replication.
repadmin /options dc_name -DISABLE_INBOUND_REPL
Finally perform another system state backup, and you are done.
If for some reason you do not have a good system state backup or a latent dc, you can manually "undelete" individual users on Server 2003.
There are steps in KB 840001 describing how this is done with ldp.exe, but alternatively you can use adrestore.exe.
Please note that only a limited set of attributes are restored with the user:
SID, ObjectGUID, LastKnownParent, SAMAccountName
Beginning with SP1, SidHistory is also retained.
Information on LVR (Linked Value Replication)
The following information was taken from a Server 2003 class I attended. I couldn't find a good online source for it.
"In Windows 2000, the smallest unit of data that can be replicated is an attribute. In the case of multi-valued attributes, such as the "member" attribute on a group, a change to one value of the multi-value prompts replication of the entire attribute including all of the unchanged values as well" With LVR enabled groups only changes made to the individual values of multi-valued attributes get replicated.
LVR is enabled on the switch to Windows Server 2003 Forest functional mode or 2003 Interim mode.
"Existing groups are not immediately converted to LVR. Instead, the groups are converted only as group membership changes. Individual members are added or deleted using LVR, and the old style attribute is no longer replicated. When new groups are created, all new members are stored and replicated using LVR "
In order to determine if LVR is enabled use the following repadmin command: repadmin /bind %servername% then check to see if "Linked_Value_Replication" states "Yes"
Wow, sorry for the long post. My intent with this post was to just provide a broad overview of the process, and throw in some of the useful tips that I have discovered along the way during countless calls.
Please let me know if you like or dislike the style presented with this post, and let me know if you have any questions.