Recovering Tombstoned AD Users

Date: 2010-06-21

Unfortunately, while performing routine maintenance on Active Directory OUs, I found myself in a perilous situation. Picture this: it was a busy afternoon, and I was sorting through user accounts to tidy up our AD structure. Stress levels were already elevated due to an ever incresing list of pending tasks. Little did I know that the next few clicks would lead to an IT nightmare.

As fate would have it, I mistakenly deleted the CEO's AD user account. In the realm of IT mishaps, this was the equivalent of accidentally spilling a cup of coffee on your new £1000 laptop – catastrophic. I kept my composure and quickly realised the gravity of the situation.

The timing could have been worse. The CEO had an imminent flight to catch, and her last-minute preparations were underway. Just minutes after arriving at to the airport, she tried to access her mailbox but encountered an unexpected "access denied" error. Panic ensued, and so did the phone calls. Four missed calls from the CEO to the IT Service Desk line, an alarming voicemail, and a polite yet urgent note from her secretary demanding a resolution before her scheduled flight, which of course, was probably not going to happen. The flight lands in Germany in 3 hours time.

Talk about pressure! Genuinely, I had exactly three hours to rectify my blunder and return everything to normalcy as if it never happened. The clock was ticking, and the stress was palpable.

After having a little cry with my head in my hands, my boss asked what's wrong. We went for a walk, where I explained what happened. Long story short, i was told to man up and just focus on a fix. Worst case scenario we can restore from backup, right? Well yes we probably could, but i;ve never done that before.

In this challenging scenario, I had to act swiftly, making every second count. The complex web of group memberships, permissions, and access settings came to the forefront. It was the IT equivalent of defusing a bomb, and I was determined to accomplish the task.

To recover the CEO's AD user account and salvage the day, I embarked on a journey that involved old-school DSGET and DSSET commands, intricate attribute manipulation, and a little touch of modern wizardry.

I would like to show you how I managed to pull off this daring rescue mission.

Step 1: Understanding Tombstoned Objects

Fact: When an User is deleted from AD, it's actually marked for deletion and moved to the "Deleted Objects" container, where it remains for a specific retention period.

This delayed removal is part of AD's replication process, ensuring that all domain controllers are aware of the object deletion.

TIP: If no value is returned. 180 days is the default value defined in the 2008R2 Schema.

Step 2: Assessing the Situation

Begin by determining why the user account was deleted and whether there's a valid reason for its recovery. Collect information about the user's previous group memberships, access rights, and group policies to recreate the account as accurately as possible. This step can save time in the subsequent recovery process.
I made some notes...

Most of this information i knew beforehand.
Not knowing the environment would have made discovery of permissions and group memberships very difficult to determine.

TIP: Restoring a domain controller from backup, isolated from the network, and then querying the deleted user's memberships would be a logical approach. You could perhaps export all user attributes...

Step 3: Locate the Tombstoned User Object

Locating the tombstoned user object is your first step in the recovery process.
TIP: It's inside the Deleted Objects container, located directly beneath the root of your domain. With a little bit of dsquery work, and a sequence of improved ldap filters later..

I FOUND IT !!!!! →

Step 4: Restore the Tombstoned User Object

Restoring a tombstoned user object involves reanimating it from the Deleted Objects container and returning it to its original location in Active Directory. My problem now was the fact I also deleted the OU the user resided inside.. So I had to restore it to the /Directors folder.
Here's how you can restore the tombstoned user object:

Use DSMOVE to resurrect the user from the grave

Step 5: Enabling the User Account

Re-enable the User

While the user has been recovered from the grave, they will remain disabled. To activate the user, right-click on their object, navigate to "Properties," and uncheck the "Account is disabled" box; or use the old-school commands.

IT'S ALIVE...

Now set a new password
Of course nobody really knows the CEOs password...

Of course, all users with a password being set, must conform to group policies, the default position being `users must change passwords set by others`.

This is the CEO, abroad - it's a heck of an inconvenience having to change passwords right now, especially due to no fault of their own.

Check out the ADUC User > Properties > Account tab. Toggle off the option 'User must change password at next login`.

Step 6: Fix the LegacyExchangeDN, MailAlias and Mail attributes

I restored my deleted user via BackupExec, restoring it to a new target (user) object. Meaning I had two users: Bossy Boots and The Boss (Restored)
So I could compare the user attributes side by side in ADUC.

Setting the legacyExchangeDn caused a conflict the first-time. This is because the restored user object has the identical reference. I dropped this value from the restored user, then re-ran the dsmod command.

TIP: Enabling the Advanced Filter in ADUC, provides the 'Additional Attributes` tab on the user properties

This didn't sort all the mailbox related attributes out first time-around. Mail-flow was clearly affected for anyone emailing the CEO.

After a little reading, "ProxyAddresses" was missing.

Step 7: Re-attach Mailbox(es), Security Groups and other attributes

4) Re-associate mailbox with the user
I don't have to be concerned with Archive mailboxes, we have a super-old MS Exchange setup. Thus i just needed to fix the mailbox specific attributes.

At this time the Outlook Address Books needed to be rebuilt and even one person complained the CEO was not in their address-book. Oops; my fault.. come back tomorrow :)

After a lot of reading i was left with:
proxyAddresses:
X500:/o=Contoso/ou=First Administrative Group/cn=Recipients/cn=imtheboss
SMTP:bossy.boots@company.com
legacyExchangeDN: /o=Contoso/ou=First Administrative Group/cn=Recipients/cn=imtheboss
mailNickname:imtheboss
msExchHomeServerName: MAIL01
homeMDB: VIP

I cheated, i made the ProxyAddress changes via the Microsoft Exchange Control Panel. Mimicing the values from another user. The rest was set via ADUC, advanced filter, additional attributes area.

ISSUE DISCOVERED: The Outlook Address Books retrieval process on MS Exchange stopped working. Clearly the user attributes retrieved via LDAPstarted to cause problems for staff, finding the CEO... Oops.. I simply restarted the Address Book service on MS Exchange. Seemed to do the trick.

I wasn't entirely sure why this command failed.

Couldn't find the precise root-cause of this error... one for a rainy day. This worked via the GUI, so i took it as a typo or formatting issue on my end.

I never noticed the proxyAddresses SMTP vs smtp values changing case sensativity before. Clearly the uppercase is the default compose/reply address. X500 is an internally routed address. and there was an older X400 address. I cloned all the attributes, and pruned out my restored user, then hit close to save changes all at once.

Put the user attributes and groups back
As you saw at the start of part 2 (paper with blue ink/font)... I knew the missing security groups already.

I also had their mobile number to add in; but I didn't know their landline. Thankfully the Outlook Address Book had everything else I needed.

Step 7: Re-attach Mailbox(es) and Security Groups

Get them logged into windows.
Luckily this went without a hitch, i had remote-desktop options to all PCs, and simply unlocked her laptop docked in her office. I rebooted for good measure, logged in again, got a new kerberos token.. just seemed to work. No errors, no odd event log items on the client device.
I checked the domain controller on site too, no issues after the reboot. Several auth expiry items before that timeslot.. i can live with that.

Step 8: The dreaded phone call

Of course, her flight landed, and her mobile had to be re-registered with ActiveSync. She called and advised that my boss explained the entire situation. She genuinely said, "Just let me know if I can do anything to help or get you time to focus on the restore." Thankfully, I was already prepared to get her up and running.

However, her mailbox wasn't working on her mobile. I had forgotten to restore the ActiveSync object beneath her user account! It was a valuable learning experience. Fortunately, we also used a Blackberry Enterprise Server backend, and the provisioning process was automated. It kicked in about 20 minutes later without much effort on my side.

Her laptop came online and connected to the VPN a couple of minutes later. I asked her to reboot as a pre-caution, which she did with almost no real issues.

This version maintains the same story but provides a smoother and more concise narrative.

That was one stressful day...

Page updated

Report abuse