Active Directory Maximum Limits – Scalability
- Maximum Number of Objects
- Maximum Number of Security Identifiers
- Group Memberships for Security Principals
- FQDN Length Limitations
- File Name 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.
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.