If you are struggling to understand Global Catalog Servers (GCS); Universal Security Groups; and Group Replication, it may help to think about what is actually happening during the user logon process and why.
When a User logs onto a Microsoft Domain Network, two things need to happen. The Logon Service has to:
- Verify the User Credentials (Username and Password)
- Determine which “Security Groups” the user is a member of (this establishes the permissions they have on the network)
For the purposes of this exercise, it is the second part of the process that we are interested in.
Obtaining a list of Security Groups is an essential part of the user’s “Access Token”. The access token is generated on the fly each time the user logs onto the network. It acts as a security pass for the duration of the session. So, when the user attempts to access a resource (anywhere within the forest), the operating system compares the permissions on the user access token with the security permissions on the resource (such as a file share) in order to determine if access can be granted.
In accordance with best practices, User Accounts should only be added to Global Security Groups within their Own (Local) Domain. Global Security Groups can then be added to Universal Security Groups in order to grant permissions to resources in other Domains throughout the Forest.
The membership list of Global Groups for the user’s “Local” Domain are replicated to every Domain Controller within that Domain ONLY. So, it is a relatively easy task for the DC that is processing the logon to query its own copy of the Active Directory Database and obtain a list of all Global Groups to which that user is a member. Users cannot be members of Global Groups within other Domains, so finding those is not an issue. So far, so good.
Note: The “Access Token” includes a FULL list of all the security groups that particular user is a member of, plus all of the security groups that those groups are themselves a member of. For instance, if the user is a direct member of “G_Sales”, and “G_Sales” is in turn a member of “G_Contracts”, then BOTH groups will be individually listed on the Access Token. This is very important to remember!
That just leaves us with the task of determining which Universal Groups the user is a member of. Remember, Universal Groups grant permissions to resources within another domain in the forest.
Universal Groups membership is not stored within the database of the Local Domain, so the DC cannot simply query its own Active Directory Database – remember a DC only knows about objects within its own Domain.
Universal Groups “live” in the Forest, and their membership lists are stored on a special type of Domain Controller called a Global Catalog Server. There must be at least one Global Catalog Server (GCS) within each Forest – the very first Domain Controller within the Forest is automatically designated the role of GCS. So, the DC processing the user logon must be able to contact a GCS within the Forest to find out which Universal Groups the User is also a member of.
Note: if a GCS cannot be found, the logon process will Fail!
When all of the Group Membership information has been gathered, the “Access Token” will be generated and issued to the user account.
|Access Token for “DomainA.User A”|
|Group Membership List:|
Hopefully, you can now see why it is important that ALL security groups are listed within the Access Token (even if membership is indirectly a result of “G_Sales” being a member of “G_Contracts”). If ALL Security Groups were not listed within the Access Token, the User would be denied access to “G_Contracts” and “U_Sales” resources, and would only be able to access “G_Sales” resources.