This is the first of six articles by contributor Dean Wells that dissect the Active Directory architecture related to the Infrastructure Master. Dean is Director of Technology Solutions at MSEtechnology, a consulting organization that provides services such as solution analysis, solution design and implementation and technology seminars as well as customized training.
In part one, we focus on the technical motivations, the role and general behaviors of the Infrastructure Master and a number of related and/or dependent technologies. Understanding these key Active Directory components and the interaction among them assists in the design, implementation and troubleshooting of an Active Directory network.
The role of the Infrastructure Master
The Infrastructure Master (IM) is a domain-wide FSMO (Flexible Single Master of Operations) role responsible for an unattended process that "fixes-up" stale references, known as phantoms, within the Active Directory database or DIT (Directory Information Table). Phantoms are created on Domain Controllers (DCs) that require a database cross-reference between an object within their own database and an object from another domain within the forest. This occurs, for example, when you add a user from one domain to a group within another domain in the same forest.
Each DC is individually responsible for creating its own phantoms with the notable exception of Global Catalogs (GCs). Since GCs store a partial copy of all objects within the forest, they are able to create cross-domain references without the need for such phantoms. Phantoms are deemed stale when they no longer contain up-to-date data, which occurs because of changes that have been made to the foreign object the phantom represents, e.g., when the target object is renamed, moved, migrated between domains or deleted. The IM is exclusively responsible for locating and fixing stale phantoms. Any changes introduced as a result of the "fix-up" process must then be replicated to all remaining DCs within the domain.
Note: The Infrastructure Master does not perform the "fix-up" role within a single domain forest since phantoms are unnecessary.
The Active Directory database
Active Directory's DIT, logs and other database-specific files are maintained using an ESE (Extensible Storage Engine) database typically stored in %SystemRoot%NTDS. An ESE database comprises tables, columns and indices over columns. A number of tables exist that include a data-table and a link-table. The data-table contains the bulk of Active Directory's objects and their properties. The link-table stores the relationship between cross-referenced objects allowing the DSA (Directory Services Agent) to, for example, efficiently compute a given user's group membership.
Residing between the core directory service and ESE is the dblayer (database layer). The dblayer forms the bridge between the core directory and ESE and ensures that their respective requirements are met.
Distinguished Name Tags
Records within Active Directory's database use a 32-bit numeric key known as a DNT (Distinguished Name Tag). Simplified, DNTs are comparable to row numbers within a spreadsheet. These numeric row references are used sequentially. They do not support re-use and facilitate the means by which records within the Active Directory database cross-reference one another, such as in the case of group membership.
Note: Distinguished Name Tags are local to each Domain Controller, i.e., they do not replicate. Two Domain Controllers within the same domain will, in almost all cases, use entirely different DNTs to represent the same objects.
The dblayer's cross-referencing mechanism dictates that the two objects involved in a cross-reference are local to the database maintaining them. For circumstances in which one of the objects is not local to the database, Active Directory provides two mechanisms to meet the cross-reference criterion. They are represented by two distinct structural entities: the aforementioned phantom and Foreign Security Principals (FSPs).
As previously discussed, phantoms provide a database-local reference to objects in other domains within the same forest. FSPs, however, provide a similar local reference to objects beyond the local forest, e.g., objects across an external trust. Phantoms maintain limited local data about the foreign object they represent typically consisting of only three of the target object's properties:
DN (Distinguished Name)
object GUID (Globally Unique Identifier)
object SID (Security Identifier)
Note: Phantoms also maintain a reference count indicating how many objects within the local DIT refer to them. When the reference count reaches 0, the phantom is removed.
In contrast, FSPs maintain only the foreign object's SID and, perhaps, a foreign security identifier, an implementation-specific component defined upon the origin of a non-Windows security principal.
Dean Wells has been in the information technology industry since 1987 providing consulting and training services on the leading platforms. Originally from the U.K., he is now the Director of Technology Solutions and a co-founder of MSEtechnology, a consulting/training organization. Dean is a Microsoft Directory Services and Security MVP and delivers internal-only classes to Microsoft Product Support Services on Windows Infrastructure technologies.