Вы находитесь на странице: 1из 8

Active Directory Maximum Limits - Scalability

Updated: April 19, 2011

Applies To: Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows
Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008

This topic describes Active Director scalability and other limitations, as well as
recommendations that apply when you are designing or implementing an Active Directory
infrastructure. These limitations include the following:

Maximum Number of Objects

Maximum Number of Security Identifiers

Maximum Number of Security Identifiers per Object

Group Memberships for Security Principals

FQDN Length Limitations

File Name and Path Length Limitations

Additional Name Length Limitations

Maximum Number of GPOs Applied

Trust Limitations

Maximum Number of Accounts per LDAP Transaction

Recommended Maximum Number of Users in a Group

Recommended Maximum Number of Domains in a Forest

Recommended Maximum Number of Domain Controllers in a Domain

Recommended Maximum Kerberos Settings

Maximum Number of Objects


Each domain controller in an Active Directory forest can create a little bit less than 2.15 billion
objects during its lifetime.

Each Active Directory domain controller has a unique identifier that is specific to the individual
domain controller. These identifiers, which are called Distinguished Name Tags (DNTs), are not
replicated or otherwise visible to other domain controllers. The range of values for DNTs is from
0 through 2,147,483,393 (231 minus 255). As objects are created on a domain controller, a
unique value is used. A DNT is not reused when an object is deleted. Therefore, domain
controllers are limited to creating approximately 2 billion objects (including objects that are
created through replication). This limit applies to the aggregate of all objects from all partitions
(domain NC, configuration, schema, and any application directory partitions) that are hosted on
the domain controller.

Because new domain controllers start with low initial DNT values (typically, anywhere from 100
up to 2,000), it may be possible to work around the domain controller lifetime creation limit—
assuming, of course, that the domain is currently maintaining less than 2 billion objects. For
example, if the lifetime creation limit is reached because approximately 2 billion objects are
created, but 500 million objects are removed from the domain (for example, deleted and then
permanently removed from the database through the garbage collection process), installing a new
domain controller and allowing it to replicate the remaining objects from the existing domain
controllers is a potential workaround. However, it is important that the new domain controller
receives the objects through replication and that such domain controllers not be promoted with
the Install from Media (IFM) option. Domain controllers that are installed with IFM inherit the
DNT values from the domain controller that was used to create the IFM backup.

At the database level, the error that occurs when the DNT limit is reached is ―Error: Add:
Operations Error. <1> Server error: 000020EF: SvcErr: DSID-0208044C, problem 5012
(DIR_ERROR), data -1076.‖

Maximum Number of Security Identifiers


There is a limit of approximately 1 billion security identifiers (SIDs) over the life of a domain.
This limit is due to the size of the global relative identifier (RID) pool of 30 bits that makes each
SID (that is assigned to user, group, and computer accounts) in a domain unique. The actual limit
is 230 or 1,073,741,823 RIDs. Because RIDs are not reused—even if security principals are
deleted—the maximum limit applies, even if there are less than 1 billion security principals in
the domain.

Note
RIDs are assigned in blocks of 500 by default from the domain controller that holds the RID
operations master role in each domain. If a domain controller is demoted, the unused RIDs that
were allocated to the domain controller are not returned to the global RID pool and are therefore
no longer available for use in the domain.

When all the available RIDs are assigned for a domain, the Directory Service log in the
Application and Service Logs of Event Viewer also displays Event ID 16644 from an event log
source of the Security Accounts Manager (SAM) that reads ―The maximum domain account
identifier value has been reached. No further account-identifier pools can be allocated to domain
controllers in this domain.‖ If you run Dcdiag when all the available RIDs are assigned for a
domain, you see the error message ―The DS has corrupt data: rIDAvailablePool value is not
valid.‖
A partial work-around to this limitation is to create an additional domain to hold accounts and
then migrate accounts to the new domain. However, you must create a trust relationship to
migrate accounts in advance of reaching the limit. Creating a trust requires the creation of a
security principal, which is also known as a trust user account. For more information about this
limit, see articles 316201 (http://go.microsoft.com/fwlink/?LinkID=115211) and 305475
(http://go.microsoft.com/fwlink/?LinkId=115212) in the Microsoft Knowledge Base.

Note
The Active Directory database does not set limits on the number of objects in a container, such
as organizational units (OUs). You might experience limits when you work with multiple
thousands of objects. These limits are configured to help provide a certain level of application or
service availability. For example, the Active Directory Users and Computers snap-in is
configured by default to display a maximum of 2,000 objects per container. You can adjust this
value by using the Filter Options settings on the View menu. There are also adjustable
Lightweight Directory Access Protocol (LDAP) policies that are set by default to improve
domain controller performance. These policies are described in article 315071 in the Microsoft
Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=135481).

Maximum Number of Security Identifiers per Object


The limitation for the number of security identifiers (SIDs) you can have per Active Directory
object using the ntSecurityDescriptor attribute comes from a limitation in the size of the access
control list (ACL), which is 64K. Since access control entries (ACEs) vary in size, the actual
number of entries (SIDs) is approximately 1,820. For additional details, see How Security
Descriptors and Access Control Lists Work (http://go.microsoft.com/fwlink/?LinkId=214683).

Group Memberships for Security Principals


Security principals (that is, user, group, and computer accounts) can be members of a maximum
of approximately 1,015 groups. This limitation is due to the size limit for the access token that is
created for each security principal. For more information, see article 328889 in the Microsoft
Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=115213). For a detailed discussion of
access token limitations, see Addressing Problems Due to Access Token Limitation
(http://go.microsoft.com/fwlink/?LinkId=146571).

FQDN Length Limitations


Fully qualified domain names (FQDNs) in Active Directory cannot exceed 64 characters in total
length, including hyphens and periods (.). For example, the following host name has
65 characters; therefore, it is not valid in an Active Directory domain:

server10.branch-15.southaz.westernregion.northamerica.contoso.com
This is an important limitation to keep in mind when you name domains. This limitation is due to
the MAX_PATH length of 260 characters that the Win32 application programming interfaces
(APIs) define, in combination with the way in which Group Policy objects (GPOs) are stored in
the SYSVOL share. For more information, see article 245809 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkID=115219). For more information about naming
limitations, see article 909264 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkID=106629).

File Name and Path Length Limitations


The physical files that Active Directory components use, such as SYSVOL, database
(NTDS.DIT), and log file paths, are constrained by the MAX_PATH length of 260 characters, as
defined by the Win32 APIs. When you are determining where to place your SYSVOL and
database files during Active Directory installation, avoid nested folder structures that make the
full file path to the SYSVOL folder, database, and log files longer than 260 characters. For more
information, see article 245809 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=115219).

Additional Name Length Limitations


There are additional limitations regarding name lengths in Active Directory. The following limits
are described in article 909264 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkID=106629):

NetBIOS computer and domain names are limited to 15 characters.

Domain Name System (DNS) host names are limited to 24 characters.

OU names are limited to 64 characters.

Name Length Limits from the Schema

Default limits on attribute names for Active Directory objects that are imposed by the schema
include the following. These items provide examples of schema-limited name attributes:

Display names are limited to 256 characters. For more information, see Display-Name
Attribute (http://go.microsoft.com/fwlink/?LinkId=153705).

Common names are limited to 64 characters. For more information, see Common-Name
Attribute (http://go.microsoft.com/fwlink/?LinkId=153706).

The SAM-Account-Name attribute (also known as the pre–Windows 2000 user logon
name) is limited to 256 characters in the schema. However, for the purpose of backward
compatibility the limit is 20 characters. For more information, see SAM-Account-Name
Attribute (http://go.microsoft.com/fwlink/?LinkId=153707).
Name Length Limitations for LDAP Simple Bind Operations

During binds to the directory, simple LDAP bind operations limit the distinguished name (also
known as DN) of the user to 255 total characters. If you attempt a simple LDAP bind with more
than 255 characters, you might experience authentication errors, such as the following:

Error <49>: ldap_simple_bind_s() failed: Invalid Credentials


Server error: 80090308: LdapErr: DSID-0C0903AA, comment:
AcceptSecurityContext error, data 57, v1771
Error 0x80090308 The token supplied to the function is invalid

You can avoid this issue by ensuring that the applications, scripts, and utilities that attempt to
bind to your directory use secure LDAP binds. You can also avoid this issue by reducing the
depth of the OU structure or the length of the OU names. For example, the following
distinguished name is 261 characters:

CN=BobKelly,OU=CorporateVicePresidents,OU=CorporateOfficers,OU=ViewOfPugetSou
ndOffices,OU=TopFloor,OU=Building1557,OU=CorporateCampus,OU=Redmond,OU=Washin
gton,OU=NorthWestern,OU=UnitedStatesOfAmerica,OU=NorthAmerica,DC=BusinessGrou
p,DC=humongousinsurance,DC=com

If the OU named CorporateVicePresidents is shortened to CVP, the distinguished name for the
user account BobKelly is only 242 characters.

Maximum Number of GPOs Applied


There is a limit of 999 Group Policy objects (GPOs) that you can apply to a user account or
computer account. This does not mean that the total number of policy settings on the system is
limited to 999. Rather, a single user or computer will not be able to process more than 999
GPOs. This limit exists for performance reasons.

Trust Limitations
Trust limitations arise from the number of trusted domain objects (TDOs), the length of trust
paths, and the ability of clients to discover available trusts. Limitations that apply include the
following:

Kerberos clients can traverse a maximum of 10 trust links to locate a requested resource
in another domain. If the trust path between the domains exceeds this limit, the attempt to
access the domain fails.

When a client searches out a trust path, the search is limited to the trusts that are
established directly with a domain and the trusts that are transitive within a forest.

Previous testing shows that the increased time to complete TDO-related operations, such
as authentication across domains, deteriorates performance noticeably if the
Active Directory implementation in an organization contains more than 2,400 TDOs.
For more information about trust limitations, see ―Practical Limitations of Trusts‖ in How
Domain and Forest Trusts Work (http://go.microsoft.com/fwlink/?LinkID=35356).

Maximum Number of Accounts per LDAP Transaction


When you write scripts or applications that perform LDAP transactions, the recommended limit
is to perform no more than 5,000 operations per LDAP transaction. An LDAP transaction is a
group of directory operations (such as add, delete, and modify) that are treated as one unit. If
your script or application performs more than 5,000 operations in a single LDAP transaction, you
are at risk of running into resource limits and an operational time-out. If that happens, all the
operations (changes, additions, and modifications) in the transaction are rolled back, which
means that you lose all those changes.

As an example, if you are using Active Directory Service Interfaces (ADSI) to write a script, the
SetInfo method completes a transaction. For more information about ADSI Methods, see
Active Directory Service Interfaces (http://go.microsoft.com/fwlink/?LinkID=4487).

As another example, when you use the System.DirectoryServices (S.DS) namespace in the
Microsoft .Net Framework, the DirectoryEntry.CommitChanges method completes an LDAP
transaction. For more information about the DirectoryEntry.CommitChanges method, see
DirectoryEntry.CommitChanges () (http://go.microsoft.com/fwlink/?LinkId=115220).

Note
Regardless of the method that you use for LDAP transactions, you should plan to send less than
5,000 directory operations in a single transaction. To learn more about the LDAP data structure
that commits changes, see LDAPMod (http://go.microsoft.com/fwlink/?LinkId=115221).

Recommended Maximum Number of Users in a Group


For Windows 2000 Active Directory environments, the recommended maximum number of
members in a group is 5,000. This recommendation is based on the number of concurrent atomic
changes that can be committed in a single database transaction.

Starting with Windows Server 2003, the ability to replicate discrete changes to linked
multivalued properties was introduced as a technology called Linked Value Replication (LVR).
To enable LVR, you must increase the forest functional level to at least
Windows Server 2003 interim. Increasing the forest functional level changes the way that group
membership (and other linked multivalued attributes) is stored in the database and replicated
between domain controllers. This allows the number of group memberships to exceed the former
recommended limit of 5,000 for Windows 2000 or Windows Server 2003 at a forest functional
level of Windows 2000.

So far, testing in this area has yet to reveal any new recommended limits to the number of
members in a group or any other linked multivalued attribute. Production environments have
been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million
members.

Important
Increasing the forest functional level to Windows Server 2003 interim or higher does not modify
the way that existing group members are stored or replicated. To do that, you must remove the
members that were added to the group before the forest functional level was increased to
Windows Server 2003 and then add them back again to the appropriate groups. Any group
members that you either add or remove after the forest functional level is increased will be LVR
enabled, even if the group contains other members that are not LVR enabled.
For more information about linked attributes, see Linked Attributes
(http://go.microsoft.com/fwlink/?LinkId=142909). For more information about the replication
process, see How the Active Directory Replication Model Works
(http://go.microsoft.com/fwlink/?LinkId=142908).

Recommended Maximum Number of Domains in a Forest


For Windows 2000 Server, the recommended maximum number of domains in a forest is 800.
For Windows Server 2003, the recommended maximum number of domains when the forest
functional level is set to Windows Server 2003 (also known as forest functional level 2) is 1,200.
This restriction is a limitation of multivalued, nonlinked attributes in Windows Server 2003. For
more information, see ―Maximum Database Record Size‖ in How the Data Store Works
(http://go.microsoft.com/fwlink/?LinkId=134791).

Recommended Maximum Number of Domain Controllers in


a Domain
Because the File Replication Service (FRS) is used to replicate SYSVOL in a
Windows Server 2003 domain, we recommend a limit of 1,200 domain controllers per domain to
ensure reliable recovery of SYSVOL.

If any Active Directory domain in your network is expected to exceed 800 domain controllers
and those domain controllers are hosting Active Directory–integrated Domain Name System
(DNS) zones, review article 267855 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=115222).

For more information about FRS limitations, see the FRS Technical Reference
(http://go.microsoft.com/fwlink/?LinkId=115302).

Recommended Maximum Kerberos Settings


The maximum recommended size for a Kerberos ticket is 65,535 bytes, which is configured
through the MaxTokenSize REG_DWORD value in the registry
(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa\Kerberos\Parameters).
Increasing this value from the default may cause errors, particularly when Web browsers or Web
servers are used. For additional information about Kerberos tickets, including error conditions
that can occur when Kerberos ticket size limits are set too low or too high, see Additional
Resources for Troubleshooting Kerberos (http://go.microsoft.com/fwlink/?LinkId=134740).

Оценить