This is the second 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 on the Infrastructure Master we focused on the technical motivations, the role and general behaviors of the Infrastructure Master and a number of the related and/or dependent technologies. In this article, we will explain how cross-references, link-pairs and phantoms are critical to the AD architecture.
Cross-references and link-pairs
When creating a cross-reference relationship between two objects within a database, it is beneficial if the objects and the database itself (or in the case of Active Directory, the dblayer) are aware of or are able to maintain the integrity of the cross-reference; this is referred to as referential integrity. For example, although both a user and a group require knowledge of any group-membership relationship between them, the action of adding a new
Link-pair relationships exist between two attributes and are initially defined within the Active Directory schema. They express a self-maintaining relationship between two otherwise distinct attributes -- for example, the default or base schema defines a group's member attribute and a user's memberof attribute as a link-pair.
A link-pair comprises precisely two attributes: one defined as a writeable forward-link and the other a read-only back-link. The attributes express their mutual relationship with one another using numeric linkIDs; forward-links use even numbers while back-links use odd numbers. Each linkID must be unique within the schema but its actual value is (or should be) of no significance short of the mathematical relationship to its partner. A back-linked attribute's relationship with its forward-linked counterpart is expressed by defining its linkID as equal to the forward-link's linkID + 1 (often expressed as n+1 or n–1). Using the earlier example from the base schema –
Note: The linkIDs used to express a particular link-pair are arbitrary and are of no particular concern (they must, however, be unique within the forest). Only the relative relationship between linkIDs (i.e., back-link = n–1) is of significance. In an effort to reduce potential conflicts, linkIDs may be obtained from Microsoft (or auto-generated when using Windows 2003). The auto-generation behavior can be triggered only when defining a new attribute's linkID using the 1.2.840.1135126.96.36.199 control OID (object identifier). Additional instructions can be found on the Microsoft Developer Network (MSDN).
Forward-linked properties must use any of the DN-based attribute syntaxes such as 188.8.131.52, 184.108.40.206 or 220.127.116.11. Back-linked properties may use only 18.104.22.168. Forward-links may be single or multi-valued while back-links must be multi-valued.
Note: Multi-valued attribute limitations exist within both Window 2000 and Windows 2003 that can be mitigated by defining an attribute as linked with no back-linked counterpart. Windows 2000 is able to maintain ~850 non-linked multi-valued property values whilst Windows 2003 is able to maintain ~1300. Further, attributes defined with a forward linkID for which no back-linked counterpart exists should not be referred to as link-pairs since the second half of the pair does not exist; they are merely linked attributes. Finally, back-links cannot be created without first creating the corresponding forward-link.
The two object references that comprise the two halves of a link-pair are maintained within the DIT's link-table. In the following example, of a simplified representation of the link-pair relationship, we assume that:
User1 is a member of Group1
User2 is a member of Group2
NOTE that member attribute above represents membership using the member's DNT.
When the DSA reads the value of an attribute for a given object, it must first determine whether the requested attribute-value resides within the data-table or is computed from the link-table. The DSA determines this by reading the linkID for the requested attribute from the schema; possible outcomes are as follows –
1. attribute's linkID not defined → data resides in data-table
2. attribute's linkID is defined → data resides in link-table, result computed
The following example outlines the process used to compute the value of a back-linked attribute per the table above, i.e., derive User2's group membership –
1. a read request is received for the memberof attribute for User2
2. the schema defines memberof as linked1. the linkID for memberof is 3 and is odd, it is identified as a back-link3. User2's DNT is determined to be à 641979
2. 1 is subtracted from the linkID to derive the forward link
3. the forward-link is therefore 2 (i.e., memberof's linkID – 1)
4. the DSA initiates a process that results in the link-table being queried for the forward-link-DNT of those entries whose –1. linkID = 25. the result is DNT 641977 (the DNT of Group2)
2. back-link-DNT = 641979
6. the user is a member of the object at DNT 641977
7. the relevant attributes are then read from DNT 641977 to derive its naming properties
1. the user is therefore determined to be a member of Group2
Note: When replicating the relationship between two cross-referenced objects, i.e., a link-pair, the object containing the forward-link attribute (known as the "from") is identified on the wire by its object GUID. The object(s) to which the attribute-values refer (known as the "to") are resolved from the source DC's local DNTs to DNs, are then placed on the wire as DNs and resolved to local DNTs on the receiving DC.
Though not directly visible within the commonplace Active Directory management tools, phantoms do manifest themselves when viewing the attribute of the local object that caused the phantom to be created, e.g. when viewing a group's membership attribute within Active Directory Users & Computers.
Phantoms also serve a number of other structural purposes such as maintaining both the order of and component names that comprise the DN of an NC (naming context) head. For example, a forest named mydomain.net is represented using two distinct (typically consecutive for a forest-root DN) rows in the DIT; the first stores the value "net" in a record whose DNT might be "1457," whilst the second stores a value of "mydomain" in row "1458" along with a pointer to row "1457," i.e., the row containing the next element within the name. This pointer is known as the PDNT (Parent Distinguished Name Tag) and is also used to fabricate the object hierarchy within the directory.
Semantics: In the generic form, phantoms are better described as "records," not "objects," since they are structures that exist at the dblayer in order to fulfill dblayer requirements. FSPs, however, are "objects," because they are defined as structural classes within Active Directory's schema and are clearly visible as object instances within the domain.
In my next article, I'll discuss Foreign Security Principals and continue the discussion of the Infrastructure Master from part one.
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.