Recovering deleted Active Directory Objects – Tombstone reanimation

To start off, sorry to disappoint, no zombie jokes here just routine AD stuff 😉

When deleting an object, Active Directory will not actually delete that object immediately (in most cases) but rather it will keep it for a period of time as a tombstone object. This means it will remove some of its attributes, add the isDeleted=True attribute, and place the object in the Deleted Object container.

—

The tombstone objects do have a limited life however; they will be removed after a certain amount of time by the AD garbage collection process.

The life of the tombstone objects is determined here (nr. of days):

Configuration namespace > Services > Windows NT > Directory Service > tombstoneLifetime:

—

To start we need to play attention to the object’s systemFlags attribute (This is an optional attribute of the TOP class). The systemFlags will determine what we can “tell” AD to do with an object.

Let’s take two of its possible values for example:

33554432 (0x02000000)

The object is not moved to the Deleted Objects container when it is deleted. It will be deleted immediately.

2147483648 (0x80000000)

The object cannot be deleted.

If the object’s systemFlags attribute is NOT 0, verify here what its constraints are applied to the object  http://msdn.microsoft.com/en-us/library/windows/desktop/ms680022%28v=vs.85%29.aspx

—

Next we need to focus on what attributes will be kept (and therefore recoverable) when the object is tombstoned. This is controlled by the attribute’s searchFlags.

If the searchFlags’ bit 3 is 0 then the attribute is will be discarded, if it’s 1 the the attribute is kept (00001000 = keep; 00000000 = delete)

Let’s take a look at two attributes in the schema partition:

Object-Sid:

The searchFlags’ decimal value is 9, if we translate this in binary 00001001 so the attribute will be kept when the object is tombstoned.

Surname:

The searchFlags’ decimal value is 5, if we translate this in binary 00000101 so the attribute will not be kept when the object is tombstoned.

Note. I will cover in a future article how to change the searchFlags attribute in order to keep it in the tombstone

———————————————

———————————————

Let’s recover an object (of course use your own domain naming convention)

Start Ldp.exe

Connect > domain1.com

Bind > enter your credentials

—

Before we do anything else we must enable ldp.exe to show the deleted objects:

Options > Controls > Load Predefined > Return deleted objects > OK

Should look like this:

—

The deleted objects can be found either using tree view

View > Tree > BaseDN “DC=domain1, DC=com”

Navigate to “CN=Deleted Objects,DC=domain1, DC=com” and expand

or using the search option

Browse > Search

—

Earlier I deleted user4.test. Let’s take a closer look at the tombstone:

First of all we see that the object’s DN now incorporates its GUID. The Deleted Objects is a flat container so this is done in order to prevent overlap in case another object with the same name gets deleted.

Of particular interest is the lastKnownParent attribute. Its value tells us the object’s previous location so it’s very useful if we want to restore it in the same OU.

—

We right-click the object we want to restore and select Modify.

Select Operation Delete.

Write in the Attribute field: isDeleted

Hit enter

Do not hit RUN yet!

–

Select Operation Replace

Write in the Attribute field: distinguishedName

Write in the Value field: the future DN of the object

(I often just combine the object’s previous CN with value of lastKnownParent if you want to restore in the object’s previous location)

Hit Enter

Final result should look like this:

Hit RUN

The object is restored!

Samba 4 released: The First Open Source Active Directory Compatible Server

This is huge! No other way of saying it.

An open source Active Directory implementation fully compatible nonetheless with Microsoft’s own solution is a game changer!

Here is the link to the announcement (their servers are getting hammered as of this posting):

https://www.samba.org/samba/news/releases/4.0.0.html

some quote’s so you can get an idea:

" LDAP directory server, Heimdal Kerberos authentication server, a secure Dynamic DNS server, 
and implementations of all necessary remote procedure calls for Active Directory. Samba 4.0
provides everything needed to serve as an Active Directory Compatible Domain Controller for
all versions of Microsoft Windows clients currently supported by Microsoft, including the 
recently released Windows 8."

–

"support for features such as Group Policy, Roaming Profiles, Windows Administration tools
and integrates with Microsoft Exchange"

–

"The Samba 4.0 Active Directory Compatible Server can also be joined to an existing Microsoft
Active Directory domain, and Microsoft Active Directory Domain Controllers can be joined to a
Samba 4.0 Active Directory Compatible Server"

I would also like to say: Big props to the Microsoft engineers who helped the Samba team bring this!

Time to fire up some virtual machines! 🙂

Time synchronization in Active Directory – PDC configuration

Blog entry under construction

Clock synchronization hierarchy in Active directory:

Local Workstation > Domain Controller > Child Domain PDC > Forest Root PDC

Screenshot from my lab:

w32tm /monitor

We can see that the DC2-2008 domain controller synchronizes with the PDC emulator as it should.

The problem is that in a default installation, the forest root PDC synchronizes the clock with itself RefID: ‘LOCL’

The solution is to sync the forest root PDC with one or more NTP servers.

Option 1 – sync directly with an internet time server

Option 2 – sync with a dedicated time server on your internal network (Microsoft recommendation to avoid linking a PDC to a internet server)

For the purpose of this article we’ll use a self built Linux NTP server. To create your own :

https://sysadminemporium.wordpress.com/2012/12/03/installing-and-configuring-a-linux-ntp-server/

———————————

Configuring the root PDC emulator

Add an inbound firewall exception to the PDC server for UDP 123.

Windows Firewall with Advanced Security > Inbound Rules > New Rule > Port

—

Configure the PDC to switch to NTP updates:

w32tm /config /syncfromflags:manual /manualpeerlist:”NTPserver1 NTPserver2” /reliable:yes /update

Note. manual peer list can contain a list of servers (local or internet) for time synchronization. Separate server names with spaces.

—

Initiate a resync

w32tm /resync

—

Final result should look like this:

Notice the difference with the first picture! The RefID now shows the NTP server used for sync.

————————–

PS Registry modifications and fine tuning:

Modified registry keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
Parameters\Type=NTP
Parameters\NtpServer="name of the NTP server(s)"
Config\AnnounceFlags=5
TimeProviders\NtpServer\Enabled=1

You can also do a lot of fine tuning in the regstry. For example

Config\MaxPosPhaseCorrection=172800
 Config\MaxNegPhaseCorrection=172800

Changing their values will alter the maximum allowable clock correction

For more details please visit:
http://blogs.msdn.com/b/w32time/archive/2009/02/02/group-policy-settings-explained.aspx

Tracking who deleted an Active Directory account

Someone just deleted a very important AD account. Your job, should you choose to accept it, is to track down the vile perpetrator and enact swift justice!  😉

Account name: user5.test

Location: domain1.com

Tools for the job: ldp.exe; repadmin; event-log

Note. This is done with 2008R2 DC servers, Forest functional level 2003 / Domain Functional level 2003.  If you run server 2003 the event log numbers will be most likely different.

—

Step 1. ldp.exe

Acquire the deleted object’s DN.

The object’s old DN is not valid anymore, what we need is the new tombstone DN (a bit special since it includes the GUID to insure uniqueness)

Start Ldp.exe

Connect > domain1.com

Bind > appropriate credentials

—

Before we do anything else we must enable ldp.exe to show the deleted objects:

Options > Controls > Load Predefined > Return deleted objects > OK

Should look like this:

—

View > Tree > BaseDN “DC=domain1, DC=com”

Navigate to “CN=Deleted Objects,DC=domain1, DC=com” and expand

Note. Replace domain1.com with your own naming convention of course 😉

Locate user5 test and grab the tombstone DN ( object’s old GUID + old DN)

Note. I will provide in a later article the details on managing and recovering tombstone objects, and further details about ldp.exe (amazing AD admin tool)

—

Step 2. repadmin

Find out on what DC the object was deleted.

repadmin /showobjmeta DCname “DN”

Note. Mare sure the DC used has replicated, and use the deleted object’s tombstone DN we grabbed in Step 1.

Aha! What do we see here? The isDeleted attribute originated on the DC2-2008 domain controller:

Note: More details on this function can be found here: https://sysadminemporium.wordpress.com/2012/11/22/hello-world/

—

Step 3. event-log

Accessing the DC2-2008’s event-log

Windows Logs > Security

What do we have here? A 4726 Account management Log!

A closer look:

Success! User5.test was deleted by Domain1\andrei.ursuleac

Ugh…that is my account…time to run!

Finding disabled user accounts

To start off, if you’ve never used LDAP filters it would be very useful to familiarize yourself with them (they are very handy in any Directory implementations of significant size). Some resources on LDAP filters can be found here:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa746475%28v=vs.85%29.aspx

and for a comprehensive coverage of the subject:

http://www.ldapexplorer.com/en/manual/109010000-ldap-filter-syntax.htm

————————————————————————–

And now to the actual LDAP filter we’ll be using:

(&(objectCategory=Person)(UserAccountControl:1.2.840.113556.1.4.803:=2))

Breaking it up

(&(...)(...))

the & (AND) operator so both statements must be true

objectCategory=Person

will return only user accounts

UserAccountControl:1.2.840.113556.1.4.803:=2

Will return only accounts that have the UserAccountControl attribute flagged as disabled.

The weird number we see here (1.2.840.113556.1.4.803) represents the LDAP_MATCHING_RULE_BIT_AND rule

Info regarding bitwise filter: http://support.microsoft.com/kb/269181

2 is the decimal value for ACCOUNTDISABLE

Note:  Pay special attention to this attribute (UserAccountControl) and its flags: http://support.microsoft.com/kb/305144

————————————————————————–

And now to put the filter to work:

Option 1 using the dsquery command

dsquery * -filter "(&(objectCategory=Person)(UserAccountControl:1.2.840.113556.1.4.803:=2))" -limit 3

Note: Use the limit switch to control the number of objects returned. For unlimited use 0

Option 2 PowerShell

Import-Module ActiveDirectory
Get-ADObject -LDAPFilter {(&(objectCategory=Person)(UserAccountControl:1.2.840.113556.1.4.803:=2))}

Option 3 PowerShell using a .net object (useful in old domains where you cannot use the PowerShell AD module)

$ADSearch = New-Object DirectoryServices.DirectorySearcher
$ADSearch.Filter = '(&(objectCategory=Person)(UserAccountControl:1.2.840.113556.1.4.803:=2))'
$ADSearch.SearchRoot = 'LDAP://DC=Contoso,DC=com'
$ADSearch.PageSize=1000
$ADSearch.FindAll()

Option 4 use ldp.exe

A tutorial on the usage of ldp.exe will be provided in another post.

Getting an object’s replication metadata

Why? How?

Why? You can find out when an object’s attribute was changed and what domain controller made that change. Now if you audit the DC’s logs you could also track who made those changes.

Here is a very interesting case study from Microsoft documenting such an issue:

http://blogs.technet.com/b/askpfeplat/archive/2012/03/05/how-to-track-the-who-what-when-and-where-of-active-directory-attribute-changes-part-i-the-case-of-the-mysteriously-modified-upn.aspx

How? Repadmin command using the following syntax:

 repadmin /showobjmeta DCname “Object’s DN”

e.g.

repadmin /showobjmeta ContosoDC01 "CN=Doe, John,OU=User Accounts, DC=Contoso,DC=com"

Note: The command in the example runs only on one DC. If replication has not occurred yet the information might be outdated. If in doubt run the command against multiple DCs and check the attribute version.

Here is an action shot from my home lab:

We can see that the description attribute change for user2.test was replicated from the DC2-2008 controller on 2012-11-19 23:08.

(yes I know domain1.com is the most original domain name ever 🙂 )

p.s. A quick PowerShell script to make the command more user friendly (fills in the object’s DN):

$SAMAcc=Read-Host;
$objDN=dsquery * -filter "(SAMAccountName=$SAMAcc)";  
repadmin /showobjmeta ContosoDC01 $objDN;