Search
Sponsors
Investigating group membership in a multi domain forest
In a multi domain forest, some strange behaviour occurs when you investigate the group membership of accounts and groups. Normally you would request the properties of an account or group and look at the 'Member of' tab to see which groups the user or group is a member of. Beware: This tab doesn't show you the memberships of the user in Global and Domain Local groups in other domains in the Forest, here's why:
The group properties displayed in the AD Users and Computers MMC console shows you the contents of attributes associated with the group object in AD. Group membership is contained in an attribute called Member. To ensure internal consistency for Group members, AD uses a trick taken from double entry accounting. Double entry accounting means that each link is stored twice, once as a forward link and once as a backward link.
AD designates the Member attribute of a group as a forward link attribute and associates it with a back link attribute called MemberOf on each object that is a member of the group. AD doesn’t actually store entries in a back link attribute. Instead, it calculates the back link contents on the fly by querying the associated forward links.
For example, when you open the properties of a user object in AD Users and Computers and select the Member Of tab, the domain
controller searches AD for any groups to which the user belongs and returns that list as if it were the contents of the MemberOf attribute.
If you look at the contents of the Member attribute for a group using an LDAP browser or the ADSI Editor, you would see a list of LDAP distinguished names in the format cn=user_name, ou=some_container,dc=domain_name,dc=domain_root. Actually, though, AD doesn’t store distinguished names in the forward link of a forward/back link pair. Instead, it stores the internal database identifier of each object assigned to the forward link. This maintains referential integrity of the object list.
AD is an LDAP directory service. In LDAP, it’s possible to divide the database into separate partitions, called naming contexts. Each naming context forms a unique replication unit. This reduces the size of the overall database hosted by any individual DC and avoids replicating changes between geographically or politically diverse portions of an organization. If an LDAP server gets a search request for an object in a naming context it doesn’t host, it returns a referral listing the LDAP servers where the client can find the correct naming context.
AD takes advantage of this LDAP feature by placing each domain into its own discrete naming context. Furthermore, an AD DC can only host a read-write replica of the naming context for its own domain. For example, a DC in Domain A would have a full, read-write replica of the Domain A naming context and no replica at all of the Domain B(within the same forest) naming context.
This creates a challenge for forward/back link attributes like Member and MemberOf. Here’s why:
When you add an user from Domain A to a domain local group in Domain B(within the same forest), you force the Domain Controller of Domain B to account for the entry of the user from Domain A by adding a database identifier for the Domain A user object into the member attribute of the group. But because the Domain B has no replica of the MathSci naming context and therefore has no database identifier for the user from Domain A object.
To overcome this challenge, a DC uses another accounting trick. It creates a balancing entry called a phantom record in its naming context to represent the object in the outside naming context. The phantom record consists of the outside object’s Distinguished Name, the object’s SID, and its Globally Unique Identifier, or GUID.
The Infrastructure Master periodically paws through the phantom records in its domain and verifies that the Distinguished Names of the phantom records match the Distinguished Names of the objects in the source domains. It does this by querying a Global Catalog server. If the Distinguished Name of a phantom record doesn’t exist in the GC, the Infrastructure Master checks to see if the GUID still exists. If so, it creates a new phantom record with a new Distinguished Name and deletes the old one. If the GUID doesn’t exist, it deletes the phantom record entirely. These phantom records then replicate from the Infrastructure Master to the other DCs in that domain.
Portions of this article come from an article written by Bill Boswell from Redmond Magazine