Windows Server Hacks: Configuring Universal Group Cachingby Mitch Tulloch, author of Windows Server Hacks
Universal groups are a cool feature of Active Directory-based networks running Windows 2000 or Windows Server 2003. After all, they let you escape from the nesting limitations of local and global groups in Windows NT (and the even bigger maze of rules regarding nesting of domain local and global groups in Windows 2000).
Universal groups can contain almost anything, including domain users, computers, global groups, and other universal groups from both the local domain and any other domain in the forest, and you can nest them to any degree as well. Of course, you can only use universal groups if your Windows 2000 domain is running in Windows 2000 native mode (or your Windows Server 2003 domain is running in Windows 2000 native functional level or higher). So if you're still running your domain in Windows 2000 mixed mode (or Windows 2000 mixed functional level), you're out of luck.
Universal groups have their downside however, especially on networks running Windows 2000. This is because by default only global catalog (GC) servers contain a list of all universal groups in the forest. So, if you're using universal groups and you try to log on to a domain, there needs to be a GC server available to enumerate your universal group membership before you can be authenticated to the domain (otherwise the Netlogon service can't create an accurate access token for you and therefore logon fails).
In other words, no GC server, no network logon -- you're stuck with logging on using cached credentials stored on your client machine as a result of your last successful network logon. And these cached credentials won't let you access your home folder if it's on a network share, so you won't get any work done. Also, your administrator may even have configured the following Group Policy setting in the Default Domain Policy to disable cached credentials on all client computers in the domain:
Interactive logon: Number of previous logons to cache (in case domain controller is not available).
This policy setting is found under:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options
It is set to 10 by default in the Local Security Policy of Windows 2000 or later machines. But security-conscious administrators will set it to 0 to prevent situations such as when you have to disable a user's account when they're suddenly fired from their job. In such a situation, if the user finds out and simply disconnects his laptop from the LAN before he tries to log on, he still has his cached credentials on his machine. This means that if he can sneak into the building later he may still be able to gain some limited access to the network's resources and do damage.
This requirement that a GC server be available when a user logs on doesn't apply, of course, if your network has only one Active Directory domain, since every domain controller in your forest would then have a complete list of all universal groups and their membership. It does become an issue, however, if you have a branch office connected by a slow WAN link to headquarters, as you've probably configured the remote network as a separate site to have more control over replication traffic between the two locations.
In a one-domain scenario you're darned if you do and darned if you don't as far as GC placement is concerned. That is, you need a GC in the remote site if you're using universal groups so users in that site can log on, but by placing a GC server in the remote site you're also increasing replication traffic over your slow WAN link.
Enter universal group caching, a new feature of Windows Server 2003. By configuring universal group caching on the domain controllers in your remote site, you ensure that a user's universal group membership information is available when he tries to log on and there is no GC available at the remote site. Enabling universal group caching is easy. Just open Active Directory Sites and Services, connect to a domain controller in the remote site, expand the Sites container, expand the name of the site, right-click on NTDS Site Settings, select Properties, and select the checkbox:
Figure 1. Enabling universal group caching on a Windows Server 2003 domain controller in a site.
Then repeat this procedure for all other domain controllers in the site.
But while it's easy to enable this feature, how does it work and can it be tweaked? Basically when a user first logs on to a domain controller that has this feature enabled, his universal group membership (and also his global group membership) is cached for future use. The next time he tries to log on, the domain controller looks this information up in the cache instead of trying to contact a GC server to obtain it. The information in the cache is refreshed by default every 480 minutes (8 hours), becomes stale by default after 10,080 minutes (7 days), and expires by default after 259,200 minutes (180 days) if the user hasn't logged on again during that time.
You can tweak these settings by editing the registry, specifically:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Cached Membership Refresh Interval
This is a
DWORD value that specifies the refresh interval in minutes.
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Cached Membership Staleness
This is another
DWORD value that specifies the time-threshold for cache staleness.
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Cached Membership Site Stickiness
This is another
DWORD value that specifies the cache expiration time interval in minutes.
The cached UG membership info itself is stored as a SID blob as the
msDS-Cached-Membership attribute of each user object in Active Directory. This attribute is not replicated between domain controllers, which is why you have to enable UG caching on each domain controller, since each one independently updates its own cache. Because of this not being replicated, there's an outside chance that a user who previously logged on to one domain controller in the site and then later tries logging on to a different domain controller may sometimes be unable to do so.
This might occur, for example, if the refresh interval has not yet triggered on other domain controllers in the site, or more commonly if replication over the WAN link is configured to take place only occasionally (once a week) and the cache could therefore become stale. By tweaking the registry settings described above you can work around these issues if your situation warrants it.
If you experience problems with UG caching you can also enable error logging for this feature by setting:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\20 Group Caching
Set this to 5 and have full diagnostic information written to the Directory Service event log. Of course, don't try any of these registry hacks in a production environment until you've thoroughly studied their effect in a test environment. It's probably best if you talk to Microsoft Product Support Services (PSS) also, before you start hacking your Active Directory environment anyway, as these are only some of the available registry settings for UG caching and the remainder are still undocumented.
There's also a known hack for eliminating Windows 2000's need for having a GC present for logons when universal groups are being used. This information is found in KB 241789, but read it through carefully as there are potentially serious security issues associated with using this hack.
Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.
Return to WindowsDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.