Directory Services - Tombstone Objects and Phantom Objects

In this blog post I’m going to write about both phantom and tombstone objects in Active Directory as it’s a grey area for most of us. Lastly I’m going to address the issue as to why the Infrastructure Master should not be placed on a global catalog server in a multi-domain forest. We all know you shouldn’t do it but remembering why is another thing!

Objects in Active Directory are represented in 4 stages throughout their life.

Stage 1: Normal Objects

These are your typical active directory objects. You can view them through all appropriate Active Directory LDAP interface tools.

Stage 2: Tombstone Objects

When an object is deleted from active directory it becomes a tombstone object for the length of the tombstone lifetime interval set in the schema (default is 60 days). This can be changed using an LDAP editing tool such as ADSIedit.

Objects in tombstone state maintain some of their original form. They remain in a non-phantom state and the objectGUID attribute does not change at all. However some things get changed, for example the object gets moved to the DeletedObjects container, the object’s DN attribute contains (esc)DEL:GUID and most of the other objects attributes get completely stripped out and removed.

Tombstones objects get replicated like any other object to all other domain controllers in a domain.

You can restore an object that was deleted from AD by using LDAP tools such as LDP.exe – check out this awesome article from Daniel Ramawidjaja’s blog:

http://dani3lr.wordpress.com/2009/06/22/restore-deleted-objects-in-active-directory-database-using-tombstone-reanimation-ldp-exe/

Stage 3: Object Removed Completely

If the tombstone period of the object runs out AD removes it completely. However if there is a reference to the object still, the object remains in AD and becomes a phantom object.

Stage 4: Phantom Objects

Phantom objects are low-level database objects that Active Directory uses for internal management operations. Two common instances of phantom objects are:
- Objects that have been deleted (tombstone passed but object still present).
- A domain local group has a member user from another domain in the Active Directory forest.

Phantom objects are special kinds of internal database tracking objects that cannot be viewed through any LDAP interface.

Deleted objects that have exceeded the tombstone period will remain in AD, the object itself is deleted and a phantom object is created in its place. Phantom objects get automatically removed by the infrastructure master when the references are removed.

When an account is added to a group in active directory, the only thing referenced in the group membership is the objects GUID. In the active directory tools if you were to view the membership of a group say in “Active Directory Users and Computers”, the AD Tool must be able to display the accurate with the display name for each of the users instead of just showing the administrator a bunch of GUID’s. Most administrators think that the global catalog takes care of this; however AD actually uses phantom objects for cross-domain group-to-user references – on this point I would like to say that every time you add a member to a domain local group from another domain, a phantom object is created to reference the remote user.

Ok cool so we are starting to understand what phantom objects are, but what do they contain?

Phantom objects contain a minimal set of information to let a domain controller refer to the location in which the original object exists. The only attributes a phantom object contains is:
- Distinguished Name of the object
- Object GUID
- Object SID

The infrastructure master is responsible for updating phantom objects (if the foreign object name is modified in anyway) and deleting phantom objects if the reference object no longer exists! The infrastructure master knows if the reference object has been renamed or deleted by comparing the information in global catalog against the phantom object’s and making changes as needed. By default the infrastructure master checks the global catalog and compares phantom objects every 2 days however you can change this by making a registry key change on the infrastructure master see Microsoft KB248047 for more information on how to do this.

Why the Infrastructure Master should not be on a Global Catalog?

Global Catalog contains a partial replica of every object in the forest right? By partial replica we mean all objects will exist however not all attributes that belong to an object will exist.

For example everyone’s phone number is stored in global catalog by default:



However the user’s passwords are not – which is a good thing:



Ok back to the question, so why can’t the infrastructure master be a global catalog?

Well because a global catalog server stores all objects from all domains in its AD database, the infrastructure master looks and goes “oh there is already a reference to that object in my database, there is no need to create/update a phantom object for that”. It will never update anything because it does not contain any references to objects it does not hold!

Because the global catalog server holds a partial replica of every object in the forest, the infrastructure master, if placed on a global catalog server, will never update anything, because it does not contain any references to objects that it does not hold.

Phantom Objects and the Global Catalog

One more thing I would like to point out is domain controllers that are global catalog servers do not use phantom objects to do cross-domain references as they already have the information in the global catalog they need. If you have every domain controller in a single domain that is part of a multi-domain forest, you do not need the infrastructure master role on a domain controller that is not a global catalog server as there are no domain controllers that will need to use phantom lookups! A domain controller only uses phantom objects to perform lookups if it is not a global catalog server. On Microsoft KB223346 “FSMO placement and optimization on Active Directory domain controllers” Microsoft backup what I just said by saying:

Two exceptions to the "do not place the infrastructure master on a global catalog server" rule are:

Single domain forest: In a forest that contains a single Active Directory domain, there are no phantoms, and so the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not.

Multidomain forest: If every domain controller in a domain that is part of a multidomain forest also hosts the global catalog, there are no phantoms or work for the infrastructure master to do. The infrastructure master may be put on any domain controller in that domain.