Partager via

Limites maximales et évolutivité des services de domaine Active Directory

Cette rubrique décrit les limites maximales pour certains aspects de votre environnement Active Directory qui peuvent affecter l’évolutivité. Nous vous recommandons de garder ces limites à l’esprit lors de la planification de votre déploiement Active Directory.

Nombre maximal d’objets

Chaque contrôleur de domaine dans une forêt Active Directory peut créer presque 2,15 milliards d’objets au cours de sa durée de vie.

Chaque contrôleur de domaine Active Directory possède un identifiant unique spécifique au contrôleur de domaine individuel. Ces identifiants, appelés Distinguished Name Tags (DNTs), sont des valeurs uniques qui ne sont ni répliquées ni visibles par d’autres contrôleurs de domaine. La plage de valeurs pour les DNTs va de 0 à 2 147 483 393 (231 moins 255). Lorsque vous supprimez un objet, aucun nouvel objet que vous créez par la suite ne peut utiliser le même DNT. Par conséquent, les contrôleurs de domaine sont limités à la création de moins de deux milliards d’objets, ce qui inclut également les objets que le contrôleur de domaine réplique. Cette limite s’applique à l’ensemble des objets de toutes les partitions hébergées sur le contrôleur de domaine, y compris le réseau d’ordinateurs du domaine (NC), la configuration, le schéma, et toutes les partitions de répertoire d’application.

Il existe des moyens possibles de contourner la limite de création d’un contrôleur de domaine au cours de sa durée de vie. Par exemple, vous pouvez retirer des objets du domaine en les supprimant définitivement. Vous pouvez également installer un nouveau contrôleur de domaine qui réplique les objets restants à partir du contrôleur de domaine potentiel. Cependant, vous devez vous assurer que le nouveau contrôleur de domaine reçoit les objets par réplication et que vous ne le promouvez pas en utilisant l’option Install from Media (IFM). Les contrôleurs de domaine installés en utilisant IFM héritent des valeurs DNT du contrôleur de domaine sur lequel la sauvegarde IFM était basée.

Lorsque vous atteignez la limite DNT sur une base de données, vous voyez le message d’erreur suivant :

Error: Add: Operations Error. <1> Server error: 000020EF: SvcErr: DSID-0208044C, problem 5012 (DIR_ERROR), data -1076.

Vous pouvez exécuter la commande suivante pour vérifier l’attribut approximateHighestInternalObjectID afin de voir le plus haut DNT actuellement utilisé par votre contrôleur de domaine :

$ossupported = $false
 
# max possible DNTs
$maxdnts = [System.Math]::Pow(2, 31) - 255
 
# connect rootDSE
$root = [ADSI]"LDAP://rootDSE"
 
# get operational attribute dsaVersionString
$root.RefreshCache("dsaVersionString")
 
# get version string usable in System.Version
$osverstring = $root.dsaVersionString[0].Substring(0, $root.dsaVersionString[0].IndexOf(" "))
 
try
{
    $osver = New-Object System.Version $osverstring
 
    # we need at least W2K12 DC to see the approximateHighestInternalObjectID exposed
    if ($osver.Major -gt 6)
    { $ossupported = $true }
 
    elseif ($osver.Major -eq 6)
    { $ossupported = ($osver.Minor -ge 2) }
}
 
catch
{ Write-Host "ERROR: Could not evaluate DC OsVer!"  }
 
if ($ossupported)
{
    # get operational attribute approximateHighestInternalObjectID
    $root.RefreshCache("approximateHighestInternalObjectID")
 
    Write-Host "Approx highest committed DNT: $($root.approximateHighestInternalObjectID[0])"
 
    Write-Host "DNTs left for new assignments: $($maxdnts - $root.approximateHighestInternalObjectID[0]) from $maxdnts"
}
 
else
{ Write-Host "approximateHighestInternalObjectID not exposed (DC OsVer: $osverstring)" }

Nombre maximal d’identificateurs de sécurité

Le nombre maximal d’identificateurs de sécurité que vous pouvez créer au cours de la durée de vie d’un contrôleur de domaine est de 2 147 483 647 identificateurs relatifs (RIDs). Pour plus d’informations sur l’émission et le suivi des RIDs, veuillez consulter la section Managing RID Issuance.

Cette limite est due à la taille du pool global d’identificateurs relatifs (RID) qui rend chaque SID attribué aux comptes d’utilisateurs, de groupes, et d’ordinateurs dans un domaine unique. Les RIDs ne sont pas réutilisés même si vous supprimez leurs principaux de sécurité, donc la limite maximale s’applique toujours, peu importe combien de principaux de sécurité se trouvent dans le domaine.

Remarque

Les RIDs sont attribués par blocs de 500 par défaut à partir du contrôleur de domaine qui détient le rôle maître des opérations RID dans chaque domaine. Si vous rétrogradez un contrôleur de domaine, les RIDs non utilisés initialement attribués au contrôleur de domaine ne retournent pas dans le pool global des RIDs et deviennent indisponibles pour une utilisation dans le domaine.

Windows Server commence à préparer une limite artificielle pour l’émission de RID lorsque le nombre de RIDs disponibles atteint 90 pour cent de l’espace global de RID disponible. Lorsque le nombre de RIDs disponibles atteint moins de un pour cent de cette limite, les contrôleurs de domaine qui demandent des pools de RID reçoivent l’événement d’avertissement Directory-Services-SAM 16656 dans leur journal des événements système.

Une solution partielle à la limite de RID consiste à créer un domaine supplémentaire pour héberger des comptes, puis à migrer des comptes vers ce nouveau domaine. Cependant, vous devez créer toutes les relations d’approbation nécessaires pour le nouveau domaine avant d’atteindre la limite. La création d’une relation d’approbation nécessite un principal de sécurité, également connu sous le nom de compte utilisateur d’approbation.

Remarque

La base de données Active Directory ne fixe pas de limites au nombre d’objets dans un conteneur, mais fixe des limites lorsque vous travaillez avec plusieurs milliers d’objets. Microsoft a configuré ces limites pour fournir un certain niveau de disponibilité des applications ou des services. Vous pouvez ajuster ces limites en reconfigurant les paramètres d’options de filtrage dans le menu d’affichage ou en modifiant les politiques du protocole Lightweight Directory Access Protocol (LDAP). Pour plus d’informations, consultez KB 315071.

Nombre maximal d’entrées dans les listes de contrôle d’accès discrétionnaire et de sécurité

Cette limitation s’applique au nombre d’entrées que vous pouvez avoir dans une liste de contrôle d’accès discrétionnaire (DACL) ou une liste de contrôle d’accès de sécurité (SACL) d’un objet Active Directory utilisant l’attribut ntSecurityDescriptor. La limite elle-même est basée sur les limitations de taille de la liste de contrôle d’accès (ACL), qui est de 64 K. Comme les entrées de contrôle d’accès (ACE) peuvent varier en taille en raison de la présence d’un ou plusieurs identifiants globalement uniques (GUID), le nombre maximum réel d’entrées (SIDs) peut être compris entre 1 100 et 1 820. Pour plus d’informations, veuillez consulter la section Comment fonctionnent les descripteurs de sécurité et les listes de contrôle d’accès.

Appartenances à des groupes pour les principaux de sécurité

Les principaux de sécurité, tels que les comptes d’utilisateurs, de groupes, et d’ordinateurs, peuvent être membres d’un maximum de 1 015 groupes. Cette limitation est due au fait que le jeton d’accès que vous créez pour chaque principal de sécurité a une limite de taille qui n’est pas affectée par la manière dont vous imbriquez les groupes. Pour plus d’informations, consultez KB 328889.

Pour plus d’informations sur la manière dont un contrôleur de domaine crée la structure de données utilisée pour les décisions d’autorisation, consultez les articles suivants :

Limitations de longueur des FQDN

Les noms de domaine complets (FQDN) dans Active Directory ne peuvent pas dépasser 64 caractères de longueur totale, y compris les traits d’union et les points. Cette limitation existe parce que les interfaces de programmation d’applications (APIs) Win32 et les objets de stratégie de groupe (GPOs) stockés dans le partage SYSVOL définissent la valeur MAX_PATH comme étant de 260 caractères. Pour plus d’informations, consultez KB 909264.

Limitations de longueur de nom de fichier et de chemin

Les fichiers physiques utilisés par les composants Active Directory, tels que SYSVOL, la base de données (NTDS.DIT) et les chemins des fichiers journaux, sont limités par la longueur MAX_PATH de 260 caractères, telle que définie par les APIs Win32. Lorsque vous décidez où placer vos fichiers SYSVOL et de base de données lors de l’installation d’Active Directory, évitez les structures de dossiers imbriqués qui rendent le chemin complet des fichiers physiques dans votre Active Directory supérieur à 260 caractères.

Autres limitations de longueur de nom

Les limites de longueur de nom suivantes, qui sont décrites dans la section KB 909264, s’appliquent également aux noms de ressources et de fichiers dans Active Directory :

  • Les noms d’ordinateurs et de domaines NetBIOS peuvent avoir seulement 15 caractères de long.

  • Les noms d’hôtes du système de noms de domaine (DNS) peuvent avoir seulement 24 caractères de long.

  • Les noms d’OU peuvent avoir seulement 64 caractères de long.

Limites de longueur de nom issues du schéma

Le schéma impose les limites par défaut suivantes sur les noms d’attributs pour les objets Active Directory :

  • Les noms d’affichage ne peuvent avoir que 256 caractères de long, comme décrit dans la section Attribut Display-Name (nom d’affichage).

  • Les noms communs ne peuvent avoir que 64 caractères de long, comme décrit dans la section Attribut Common-Name (nom commun).

  • L’attribut SAM-Account-Name ne peut avoir que 256 caractères de long dans le schéma. Cependant, pour des raisons de compatibilité rétroactive, la limite Active Directory pour les utilisateurs est de 20 caractères. Pour plus d’informations, veuillez consulter la section Attribut SAM-Account-Name.

Limitations de longueur de nom pour les opérations d’authentification simple LDAP

Lors des authentifications au répertoire, les opérations d’authentification simple LDAP limitent le nom distingué (DN) de l’utilisateur à 255 caractères. Si vous tentez une authentification simple LDAP avec plus de 255 caractères, vous pourriez rencontrer les erreurs d’authentification suivantes :

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

Vous pouvez éviter ce problème en vous assurant que les applications, scripts et utilitaires qui tentent de s’authentifier à votre répertoire utilisent des authentifications LDAP sécurisées. Vous pouvez également essayer de réduire la profondeur de la structure d’OU ou la longueur des noms d’OU. Par exemple, le nom distingué suivant fait 261 caractères :

CN=BobKelly,OU=CorporateVicePresidents,OU=CorporateOfficers,OU=ViewOfPugetSoundOffices,OU=TopFloor,OU=Building1557,OU=CorporateCampus,OU=Redmond,OU=Washington,OU=NorthWestern,OU=UnitedStatesOfAmerica,OU=NorthAmerica,DC=BusinessGroup,DC=humongousinsurance,DC=com

Si vous raccourcissez l’OU nommé CorporateVicePresidents à CVP, le nom distingué du compte utilisateur BobKelly fait désormais seulement 242 caractères et est donc dans la limite.

Nombre maximal de GPOs appliqués

Active Directory limite à 999 le nombre de GPOs que vous pouvez appliquer à un compte d’utilisateur ou d’ordinateur. Cette limite ne signifie pas que le nombre total de paramètres de stratégie sur le système est limité à 999. Au lieu de cela, un seul utilisateur ou ordinateur ne peut pas traiter plus de 999 GPOs. Cette limitation existe pour éviter les problèmes de performances causés par le traitement de trop nombreux GPOs en même temps.

Limitations d’approbation

Les limitations d’approbation s’appliquent au nombre d’objets de domaine approuvés (TDOs), à la longueur des chemins d’approbation et à la capacité des clients à découvrir les approbations disponibles. Les limitations d’approbation pour Active Directory incluent les limites suivantes :

  • Les clients Kerberos peuvent traverser jusqu’à 10 liens d’approbation pour localiser une ressource demandée dans un autre domaine. Si le chemin d’approbation entre les domaines dépasse cette limite, la tentative d’accès au domaine échoue.

  • Lorsque le client recherche un chemin d’approbation, la recherche est limitée aux approbations établies directement avec un domaine et aux approbations transitives au sein d’une forêt.

  • Des tests antérieurs montrent que le temps accru pour effectuer des opérations liées aux TDOs, telles que l’authentification entre les domaines, détériore les performances de manière notable si l’implémentation Active Directory dans une organisation contient plus de 2 400 TDOs.

Pour plus d’informations sur les limitations d’approbation, veuillez consulter la section Limitations pratiques des approbations.

Nombre maximal de comptes par transaction LDAP

Lorsque vous écrivez des scripts ou concevez des applications qui effectuent des transactions LDAP, nous vous recommandons d’effectuer au maximum 5 000 opérations par transaction LDAP. Une transaction LDAP est un groupe d’opérations de répertoire traitées comme une seule unité, telles que l’ajout, la suppression et la modification. Si vous effectuez plus de 5 000 opérations dans une seule transaction LDAP, vous risquez de rencontrer des limites de ressources et un délai d’expiration opérationnel. Si vous rencontrez ce problème, toutes les opérations de la transaction sont annulées, ce qui entraîne la perte de toutes les modifications apportées pendant la transaction. Pour en savoir plus sur la structure de données LDAP qui engage des modifications, consultez la section Structure LDAPModA.

Pour les environnements Active Directory de Windows 2000, le nombre maximal recommandé de membres dans un groupe est de 5 000. Cette recommandation est basée sur le nombre de modifications atomiques simultanées qui peuvent être engagées dans une seule transaction de base de données.

À partir de Windows Server 2003, la capacité de répliquer des modifications discrètes aux propriétés multivaluées liées a été introduite en tant que technologie appelée Linked Value Replication (LVR). Pour activer LVR, vous devez augmenter le niveau fonctionnel de la forêt à au moins Windows Server 2003 interim. L’augmentation du niveau fonctionnel de la forêt modifie la manière dont l’appartenance à un groupe (et d’autres attributs multivalués liés) est stockée dans la base de données et répliquée entre les contrôleurs de domaine. Cela permet au nombre d’appartenances à des groupes de dépasser l’ancienne limite recommandée de 5 000 pour Windows 2000 ou Windows Server 2003 avec un niveau fonctionnel de forêt Windows 2000.

Jusqu’à présent, les tests dans ce domaine n’ont révélé aucune nouvelle limite recommandée quant au nombre de membres dans un groupe ou tout autre attribut multivalué lié. Des environnements de production ont été signalés avec plus de 4 millions de membres, et les tests de mise à l’échelle de Microsoft ont atteint 500 millions de membres.

Important

L’augmentation du niveau fonctionnel de la forêt à Windows Server 2003 interim ou supérieur ne modifie pas la manière dont les membres existants d’un groupe sont stockés ou répliqués. Pour cela, vous devez retirer les membres qui ont été ajoutés au groupe avant que le niveau fonctionnel de la forêt ne soit augmenté à Windows Server 2003, puis les ajouter à nouveau dans les groupes appropriés. Tous les membres du groupe que vous ajoutez ou supprimez après l’augmentation du niveau fonctionnel de la forêt seront activés pour LVR, même si le groupe contient d’autres membres qui ne sont pas activés pour LVR. Pour plus d’informations sur les attributs liés, consultez la section Attributs liés. Pour plus d’informations sur le processus de réplication, consultez la section Fonctionnement du modèle de réplication Active Directory.

Le tableau suivant répertorie le nombre maximal recommandé de domaines pour chaque niveau de fonctionnement de domaine.

Niveau de fonctionnement du domaine Nombre maximal recommandé de domaines
Windows 2000 Server 800
Windows Server 2003 1 200
Windows Server 2025 3 000

La limite de 1 200 pour Windows Server 2003 est une limitation des attributs non liés multivalués dans Windows Server 2003. Pour plus d’informations, veuillez consulter la rubrique « Taille maximale de l’enregistrement de base de données » (/previous-versions/windows/it-pro/windows-server-2003/cc772829(v=ws.10)).

Nous recommandons de limiter à 1 200 le nombre de contrôleurs de domaine que vous utilisez par domaine. Cette limite garantit que vous pouvez récupérer de manière fiable votre SYSVOL en cas de sinistre.

Si vous prévoyez qu’un domaine Active Directory dans votre réseau comptera plus de 1 200 contrôleurs de domaine, et que ces contrôleurs de domaine hébergent des zones de système de noms de domaine (DNS) intégrées à Active Directory, nous vous recommandons de consulter la rubrique KB 267855 à des fins de planification.

La taille maximale recommandée pour un ticket Kerberos est de 48 000 octets. Vous pouvez définir la taille du ticket en configurant la valeur REG_DWORD MaxTokenSize dans la clé HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa\Kerberos\Parameters du registre ou via les stratégies de groupe, comme décrit dans la section KB 938118.

Remarque

La valeur maximale autorisée de MaxTokenSize est de 65 535 octets. Si vous utilisez Kerberos pour la gestion des clés IP Security (IPsec), la limite est de 65 536 octets. Cependant, en raison de l’encodage HTTP base64 des jetons de contexte d’authentification, nous vous recommandons de ne pas définir l’entrée de registre maxTokenSize à une valeur supérieure à 48 000 octets. À partir de Windows Server 2012, la valeur par défaut de l’entrée de registre MaxTokenSize est de 48 000 octets.

Pour plus d’informations sur les tickets Kerberos, consultez la section Ressources supplémentaires pour la résolution des problèmes Kerberos.

Nombre maximal de valeurs d’attributs non liés

La base de données Active Directory stocke les valeurs d’attributs non liés dans un répertoire lié qui doit tenir sur une page de base de données. En conséquence de cette exigence de taille, la limite maximale des attributs non liés pour un objet qui ne porte qu’un seul attribut est de 1 200. Dans les forêts Windows Server 2025, vous pouvez augmenter la limite jusqu’à 3 000.

Dans des déploiements réels, des erreurs commencent à apparaître lorsque l’objet approche de la limite des attributs non liés. Le code d’état pour ces types d’erreurs est 0x00000b et correspond à la chaîne « LDAP_ADMIN_LIMIT_EXCEEDED La limite d’administration sur le serveur a été dépassée ».

Pour plus d’informations sur la limite, consultez l’article Détails de la base de données AD, Plusieurs enregistrements DNS sur un seul nom DNS et Erreur de réplication Active Directory 8304 : la taille maximale sur un objet a été dépassée.

Taille maximale des objets Active Directory

Pour modifier un attribut contenant beaucoup de données, vous devez stocker les nouvelles et anciennes valeurs dans la transaction de base de données. Le stockage des valeurs permet de revenir en arrière sur la transaction si la base de données s’arrête au milieu de la transaction. La taille maximale d’une transaction limite la taille totale du blob des données de valeur d’attribut à 5 Mo.

La taille maximale des transactions Active Directory que vous pouvez effectuer affecte également la limite du nombre de membres de groupes avant la réplication de la valeur de lien et le nombre de transactions dans les modifications d’appartenance à un groupe.