Universal Group Membership Caching: Lessons Learned the Hard Way
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
For more information on Windows Server, visit our Windows Server Reference Guide or sign up for our Windows Newsletter.
When I first read about Universal Group Membership Caching, I thought I understood the concept fairly well. However, when I decided to start testing this new Windows Server 2003 Active Directory feature, I was surprised by some of what I discovered. I found that group memberships were not always cached as I expected and that I could log onto user accounts when the global catalog server was offline (I didn't think that should be possible). I've learned quite a bit since then and I'll share some of my discoveries concerning Universal Group Membership Caching that might save you some trouble if you're planning to use this feature in the future.
Before I get into detailing Universal Group Membership Caching, let's take a look at the components and situations that necessitate the caching universal group membership.
Universal Groups
Universal groups allow users (and groups) from multiple domains to have membership in a single group that is available throughout the Active Directory forest. This is useful in a forest with multiple Active Directory domains to simplify resource access permissions. If users or groups from different domains need access to resources that are located in multiple domains, a universal group can be used to allow for that access.
Enabling Universal Groups
In Windows 2000 Active Directory domains, the domain mode had to be set to Windows 2000 Native in order to enable the use of universal groups. Universal groups couldn't be created in Mixed mode (the domain mode below Windows 2000 Native). This limitation existed because, in Windows 2000 Mixed mode, there was an expectation that Windows NT 4.0 backup domain controllers might be maintaining backup copies of the domain database. Since Windows NT 4.0 domain controllers don't support universal groups, Windows 2000 Active Directory domains in the Windows 2000 Mixed domain mode wouldn't allow them to be created. However, when the domain mode is increased to Windows 2000 Native, Windows NT 4.0 backup domain controllers are no longer supported, so the new universal group type can be created. In Windows Server 2003, the term functional level replaces domain mode. Universal groups can be created in Windows Server 2003 Active Directory domains once the domain functional level is increased to Windows 2000 Native or the higher functional level of Windows Server 2003.
Universal Group Membership Verification: Required for Logon
Once the domain mode or functional level is increased, universal group membership information is required during the user logon process. This is because the user's access token—which allows the user to gain access to resources—must be updated with the user's security identifier (SID), system rights, and all group memberships. In Windows 2000 Active Directory domains, access to a global catalog server is required for users to log onto the domain. When Windows Server 2003 was released, I tested the logon process to see whether new user accounts would be able to log on when there were no global catalog servers in the domain. I found that new users' accounts (ones that haven't been used for previous logons) couldn't log on when the global catalog server was offline.
Is Universal Group Membership Status Really Required for a Successful Logon?
In preparation for writing this article, I configured a test network to ensure that I correctly describe the Windows Server 2003 interface and output:
- I installed a single Active Directory domain with four domain controllers.
- I created two Active Directory sites, one named Main and the other named Branch.
- In each site, I placed two domain controllers running Windows Server 2003. One of the domain controllers in the Main site functions as the only global catalog server for the domain and holds all five Flexible Single Master Operations (FSMO) roles.
- I added two Windows XP Professional client computers to the Branch site.
- I created a universal group named Internal_Auditors. The domain functional
level is Windows 2000 Native and all domain controllers recognize this increased
functional level (see Figure 1).
Figure 1 Domain functional level: Windows 2000 Native.
- Next, I cleared the Global Catalog check box for the domain controller that was performing as the global catalog server for the domain. I ensured that none of the four domain controllers were functioning as global catalog servers.
- I created four user accounts in the Branch organizational unit: BU1, BU2,
BU3, and BU4. As I created each user account, I received a warning message
indicating that the global catalog server could not be contacted (see Figure
2).
Figure 2 Message indicating that the global catalog server is offline.
)
)
The Microsoft TechNet article "What Is the Global Catalog?" states that global catalog servers are required for new user accounts to log on. Therefore, you might expect that my subsequent logon attempts with these four accounts failed. However, I was able to log on using all four Branch user accounts. As a matter of fact, I even added the BU3 and BU4 user accounts to the Internal_Auditors universal group before attempting to log on with those accounts. I was still able to log onto the domain, and I did see the universal group membership of Internal_Auditors in the BU3 and BU4 access tokens after running the whoami /all command.
One significant fact frequently isn't stated explicitly in the documentation I've seen on this topic: Only in a multi-domain forest are global catalog servers required for logon. As previously stated, the domain functional level must also be Windows 2000 Native or higher. Since I only had a single domain environment at this point, however, the global catalog server was not required for the domain accounts to log on. Therefore, I created a few more user accounts and added another domain to the forest. Once the new domain was in place, I was no longer able to log on with new user accounts without the global catalog server. However, I could log on with the accounts that I previously created, using the computers that had previously logged on. This was allowed because cached credentials on the local computers were used to authenticate the user accounts.