Conquer Active Directory’s Built-In Limits

The more you use Active Directory (AD), the more likely you find yourself the unhappy victim of one or more of the limits imposed either by AD itself or by an interface you use to administer it. The AD limits exist primarily to optimize AD's performance—they relate only marginally to the number of objects you can have. For example, the maximum number of user accounts possible in a Windows NT domain was 40,000. The number of user accounts possible in an AD domain is huge. I don't know the absolute maximum, but Korea.com (an Internet portal providing a range of Web services to Korean citizens) has an 8-million-user-account AD implementation. Here are some common AD limits and tips for adjusting or working around them should they become problematic.

MMC Folder Display Limit
When you use the Windows 2000 Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to display the contents of an organizational unit (OU) or container that contains more than 2000 objects, you see an error message stating that AD can't display all the objects and giving advice for changing the default option. If you have Windows Server 2003, you see a slightly more helpful message stating the limit and the number of objects AD is trying to display.

To change the default display limit, click View, Filter Options and change the Maximum number of items displayed per folder value. Be aware that this limit exists for a good reason: Displaying the contents of an OU that contains 30,000 objects can take a long time.

Search Buffer Size
After overcoming the default 2000-object display limit, you might be frustrated yet again if you try to display the contents of an OU that contains more than 10,000 objects. The source of the frustration is the default AD search buffer size, which certain UI tools (including the Active Directory Users and Computers snap-in) use. The buffer stores query results and by default is limited to 10,000 objects to improve performance.

The Microsoft article "Controlling the Active Directory Search Buffer Size" (http://support.microsoft.com/?kbid=243281) describes two ways to change this default. The first option involves changing a registry value. Add a new DWORD value named QueryLimit to the HKEY_CURRENT_USERSoftwarePoliciesMicrosoftWindowsDirectory UI registry subkey. Set the value for QueryLimit to the limit you think you need. You might need to add the Windows and Directory UI subkeys if they aren't present.

The second method also applies the registry setting but does so through Group Policy. Open the Group Policy Object (GPO) you want to edit (e.g., Default Domain Policy). In the treeview pane, navigate to User Configuration, Administrative Templates, Desktop, Active Directory. Enable the Maximum size of Active Directory searches policy and set the value you want.

I prefer the second approach because it avoids incorrectly entered registry values. I've also seen problems with the first method when used with the Run As feature and dedicated administrative accounts. The registry value doesn't work with accounts specified by using Run As, probably because the specified account isn't affected by HKEY_CURRENT_USER settings. If you want to use Run As after applying the second (GPO) method, in order to apply the Group Policy setting you must perform a normal Windows logon at least once for any accounts you plan to specify with Run As.

Interestingly, although the setting (using either method) works well for the Active Directory Users and Computers snap-in, it appears to have no effect on the MMC Active Directory Service Interfaces (ADSI) Edit snap-in. I haven't found a way to use ADSI Edit to display more than 10,000 objects.

LDAP Maximum Page Size
You're probably aware that AD supports Lightweight Directory Access Protocol (LDAP) 3.0. AD's LDAP support lets you search the directory from an LDAP-compliant client. To protect against Denial of Service (DoS) attacks and searches that might adversely impact performance, AD imposes a maximum page size of 1000 when returning the results of LDAP queries. In other words, AD returns no more than 1000 records at a time in response to an LDAP query. For example, if you execute an LDAP subtree search for all user objects in your domain, the search will return 1000 records and a Size Limit Exceeded error if your domain has more than 1000 user objects.

You have two options for working around this limit. The first is to change the maximum page size from the client; the second is to modify the MaxPageSize LDAP policy on your domain controllers (DCs) to set a higher limit. As a best practice, you should use the first method and leave the LDAP policy alone. As users and applications make increasing use of AD, inefficient LDAP queries become more likely. The maximum page-size setting protects AD from inefficient queries. The main danger with modifying the policy is that doing so can inhibit DC performance. To learn more about changing LDAP policies, see the Microsoft article "HOW TO: View and Set Lightweight Directory Access Protocol Policies by Using Ntdsutil.exe in Windows 2000" (http://support.microsoft.com/?kbid=315071).

One way to set the maximum page size on an LDAP client is to use the ldp.exe LDAP client from the Windows 2003 or Win2K support tools. To use this method, follow these steps:

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_MACHINESYSTEMCurrentControlSetControlLsaKerberosParametersMaxTokenSize 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.