This is the third of six articles by contributor Dean Wells that dissect the Active Directory architecture. Dean...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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 two, we focused on cross-references, link-pairs and phantoms. This article will further explain how foreign security principals and the Infrastructure Master (IM) are critical to the Active Directory architecture.
Foreign Security Principals (FSPs)
FSPs represent objects foreign to the forest that require representation within the database. For example, an FSP is required when expressing a relationship between groups in the local forest and security principals that exist across an external or cross-forest trust. Due to implementation specifics, FSPs are also used to express relationships within a domain between "well-known" security-principals, such as the group Everyone, and more commonplace objects, such as the Pre-Windows 2000 Compatible Access group.
Note: The IM is not responsible for maintaining FSPs.
Well-known security principals
Well-known security principals do not exist within the Active Directory database in the traditional sense, nor is their membership managed or stored in the same way. Instead, a forest-wide placeholder exists within the configuration partition's WellKnown Security Principals container. These placeholders are used by the user interface's object picker and are not designed to serve as a means for managing the membership of these well-known groups. Well-known security principals are self-managing (with regard to their membership) in that they automatically group users according to something the user is doing or the means by which they are doing it. For example, a user logging on locally to a computer will be dynamically granted membership within the well-known group Interactive. When the same user connects to the same computer across the network, the user is automatically assigned membership within the Network group while losing membership in the Interactive group.
Note: The security identifiers (SIDs) of well-known security principals, as expected, become part of a user's identity, i.e., the SID is present within their access token, but only for as long as and only in the location where the condition that originally caused the membership to occur remains true and the connection remains active.
The Infrastructure Master and Global Catalogs
When working within multi-domain forests, the IM must not co-reside on a global catalog (GC) since it will never have cause to create phantoms. If all domain controllers (DCs) within a particular domain are GCs, the core functionality of the IM is moot since GCs already possess both sides of the cross-reference, again, eliminating the DC's need to create phantoms which, in turn, prevents it from detecting stale phantoms and finally from communicating any resulting changes to other DCs within the domain. The IM is also technically unnecessary in domains hosted by only a single domain controller.
Operational breakdown of the Infrastructure Master
The Infrastructure Master runs once daily and is throttled by a variety of constraints designed to both optimize the process and minimize its impact. In other words, it will run for no longer than two days in a single cycle but will more aggressively reschedule itself in the event an earlier cycle fails to complete. During each run-cycle, the IM scans the local phantom index collecting a predefined number of entries. For each entry within the index, a query that is keyed on the phantom's GUID is submitted to a GC requesting that it return the object's SID and domain name (DN). The SID and DC from the global catalog are then compared against the corresponding SID and DN of the local phantom; the following outcomes and resulting actions are possible –
- SID and DN match → do nothing, proceed to next phantom
- SID and/or DN do not match → improve phantom with GC's value(s)
- object not found → remove phantom
Since phantoms do not maintain replication metadata, special measures must be taken by the IM to ensure that any improvements made to its local phantoms, as a result of the IM-process, are replicated to the remaining DCs within the domain. This is achieved by using a specifically purposed object class and attribute that serve as a vehicle to replicate a description of the changes as opposed to the changes themselves.
Specifically, the Infrastructure Master creates an instance of the infrastructureUpdate class. The object is created beneath "cn=Infrastructure,dc=
Note: The "cn=Infrastructure" object serves as both the initial container for the "infrastructureUpdate" instances mentioned above and also to maintain the current role holder for the Infrastructure FSMO (Flexible Single Master Operations). Although it may not appear to be a container, any object within Active Directory is capable of serving as another object's parent.
It is important to note that immediately following their creation, each infrastructureUpdate instance is deleted (or tombstoned) in order to prevent an indefinite buildup of these objects within the domain. The tombstoning process does NOT destroy theDNReferenceUpdate attribute since the base schema dictates that the attribute is preserved upon logical deletion.
Triggering the Infrastructure Master
The IM can manually be triggered by submitting an operational attribute against the role holder using, for example, LDP –
- Select Connect → Connect
- Enter the fully qualified name of the IM
- Select Connect → Bind
- Supply administrative credentials
- Select Browse → Modify
- Supply a null (or blank) DN
- Supply the attribute "checkPhantoms"
- Supply an attribute value of "1"
- Click "Enter" to place the action in the entry-list
- Click "Run"
Monitoring the operations of the Infrastructure Master
Several approaches exist that permit the actions performed by the IM to be viewed. They include: increasing the applicable logging (though this tends to carry a lot of event-baggage) and submitting an LDAP query for the replicated entries created by the IM. The following defines the configuration when using the LDAP query approach –
- base = cn=Deleted Objects, dc=
- scope = onelevel
- filter = objectcategory=infrastructureUpdate
- attributes = dnReferenceUpdate whenChanged
- call type = extended
- controls = return deleted objects / 1.2.840.1135184.108.40.2067 extended DN / 1.2.840.1135220.127.116.119
Note that, depending upon your environment, it may be necessary to alter the time, timeout and sizing limitations governing the query. The resulting output displays the relevant attributes from any infrastructureUpdate instances created within the tombstone lifetime of the forest (this defaults to 60 days or 180 days depending upon the operating system used to build the forest).
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.
More on the Active Directory architecture:
Part 1: Infrastructure Master
Part 2: Cross-references and phantoms
Part 3: Foreign security principals
Part 4: SID filtering and trust relationships
Part 5: Tickets, tokens and the authentication process
Part 6: SID filtering, usage scenarios and configuration