Conquer Active Directory’s Built-In Limits

Figure 1 shows that I changed the default Search Call Type from Sync. to Paged. The change instructs the DC to return any search results in batches specified in the Page size setting, thereby working around the 1000-record limit. Here's where the terminology gets confusing. You will remember that the DC's LDAP policy is called MaxPageSize. This policy has no relation to the Page size setting in the LDAP client. The MaxPageSize value is simply the maximum number of records the server returns. The Page size setting in my ldp.exe example tells the server to return results in batches of 16 (the default). You don't need to change the default. I set the Timeout (s) value to 60. In my experience, this setting can help avoid timeout problems when you use paging. I also changed the Attributes setting to 1.1. This setting instructs the DC to return no attributes. (By default, the DC still returns the distinguishedName attribute in the results.)

Those who have more than a passing interest in LDAP might like to know that ldp.exe sets page size by implementing LDAP control pagedResultsControl. You can find more information about using this LDAP control in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2696 (http://www.ietf.org/rfc/rfc2696.txt).

Another way to set the page size is to use ActiveX Data Objects (ADO) in a VBScript script. Listing 1 shows a script that searches for all user accounts within a domain. In an environment that has more than 1000 users, the script fails unless you use the Page size setting. As with the ldp.exe example, specifying a specific page-size value instructs the server to return the results in batches, providing an effective workaround to the 1000-record limit. To run the script, create a new file (e.g. PageSize.vbs), edit the code at callout A in Listing 1 to include your own domain name, then save the file. Open a command prompt, change to the same directory to which you saved the file, and type the following:

cscript PageSize.vbs

Group Membership Limit
If you have a midsized-to-large organization, you might have encountered a limit of 5000 group members in Win2K Server AD. The 5000-member limit isn't set in stone but rather is an approximate value. The limit exists because the AD Jet database engine can't handle write operations greater than a certain size when it stores and replicates data. Windows 2003 AD works around this limit through linked value replication (LVR). With LVR, AD replicates the individual values within the member attribute rather than the whole value when a group's membership changes. Aside from working around the 5000-member limitation, this replication method is clearly a much more efficient replication method, both in terms of network bandwidth usage and DC resource overhead.

Actually, the 5000 limit applies not only to group membership within AD but to any linked attributes. However, group membership is where most organizations see the problem. The member attribute is referred to as linked because it has a corresponding memberOf attribute. For example, say that the Sales group has member attribute values Tom, Dick, and Harry. If you then look at the Tom, Dick, and Harry objects in AD, you see that each has an attribute called memberOf with a value that includes the group Sales. The manager and directReports attributes also are examples of linked attributes.

The only workaround to the group membership limit in Win2K AD is to use group nesting. Nesting involves dividing the group into smaller groups, then making those groups members of the parent group. Nesting adds complexity because it increases the overall number of groups you must manage.

Kerberos Token Size
Win2K and later use Kerberos authentication by default. If a user account is a member of many groups (including nested groups), it might have problems with authentication. Authentication problems can manifest in different ways—for example, a slow or failed logon to a remote system, an inability to apply Group Policy, or errors when joining a computer to the domain. In this case, the limit stems from the way in which systems that participate in Kerberos authentication (e.g., Win2K file server, Microsoft IIS) assign tokens for accessing resources.

When assigning tokens, the system includes the user's SID and the SIDs of all security groups to which the user belongs. When you use group nesting, the number of SIDs can increase sharply, in which case the token might be too small to handle all of them. Tokens have a fixed size, which is specified in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize registry value. If you've migrated user accounts and associated groups from another domain, the addition of SID history can aggravate the token-size problem by increasing the number of SIDs.

How many groups do you need to trigger this type of problem? This question has no easy answer because both the MaxToken Size registry value and the service pack level of the system that assigns the token affect the maximum token size. In Win2K Service Pack 1 (SP1) and earlier, the limit is approximately 70 to 80 groups; with Win2K SP2 and later, it's about 120 groups. Win2K SP4 and Windows 2003 offer a better solution for the problem by addressing it at the DC level, although in some cases the token size still might not be sufficient. For these rare cases, Microsoft provides a formula for calculating the required MaxTokenSize registry value. For more information about the formula, solving the problem of too many groups, and the MaxTokenSize value, see the Microsoft article "New Resolution for Problems That Occur When Users Belong to Many Groups" (http://support.microsoft.com/?kbid=327825). As you can see, no easy workarounds exist for the problem, but you can generally avoid trouble if you have the latest service packs applied in your AD forest. At worst, you may need to apply the formula that the Microsoft article provides.

Love Your Limits
AD and its associated tools will always impose certain limits. The limits aren't meant to frustrate users; instead, they exist to protect AD from misuse and to improve system performance. Knowing the limits and how to safely work around them can greatly reduce your frustration and help you better understand how AD works.