Nombre maximal d’objets 

Chaque contrôleur de domaine dans une forêt AD sait générer environ 2,15 MILLIARDS d’objets durant sa durée de vie. Chaque DC dispose d’un identifiant unique qui lui est spécifique. Cet identifiant appellé Distinguished Name Tags (DNT) n’est ni répliqué, ni visible sur les autres DC. La plage de valeurs des DNT va de 0 à 2.147.483.393 (2^21 – 255). A chaque objet créé sur un DC, une valeur unique est utilisée.  Un DNT n’est jamais réutilisé, même si l’objet généré avec est supprimé.
Ainsi, la limite admise de la vie d’un DC n’est pas en temps mais en nombre de création d’objets. On considère généralement qu’il ne faut pas dépasser 2 milliards d’objets (en incluant ceux créés par réplication). Cette limite s’applique à la combinaison de tous les objets de toutes les partitions de la forêt : Domain NC, Configuration, Schéma et partitions applicatives hébergées sur un DC.

  • Soit un DC ayant généré 2 milliards d’objets, mais dont 500 millions (arf) ont été supprimés définitivement (via le processus de garbage collection). 
  • Si l’on installe un nouveau DC en le synchronisant via réplication (ç ane fonctionne pas en mode IFM), celui-ci devant créer des objets, n’en génèrera que 1,5 milliards, donc vous récupèrerez un peu de temps pour continuer le ménage :)

Il n’y a pas de processus de correction d’un DC dans cet état là. Un « léger » workaround est en revanche envisageable, si l’on assume qu’un certain nombre d’objets ont déjà été supprimés :

Pour information, dans le cas ou la limite des DNT est atteinte, le message d’erreur ressemble à :  “Error: Add: Operations Error. <1> Server error: 000020EF: SvcErr: DSID-0208044C, problem 5012 (DIR_ERROR), data -1076.”

Un léger parfum de Game Over non ?

Nombre maximal de Sid 

La limite de la vie d’un domaine se mesure aussi au nombre d’objets créés. Dans notre cas, celle-ci est d’un milliard de Sid générés. La raison est la taille du pool global d’identifiants relatifs, qui est sur 30 bits et qui garantit l'unicité de chaque objet du domaine. La limite réelle de celui-ci est de 2^30 RIDS.

Dans la mesure où ceux-ci ne sont jamais réuilisés, même en cas de suppression de l’objet lié, la limite est atteinte même s’il n’y a pas un milliard d’objets dans un domaine à un instant T. On peut donc dire que la durée de vie d’un domaine est égale à 1 milliards d’objets, que ceux-ci soient vivant ou morts :)

Lorsque le pool de RID est expiré, l’Event ID 16644 de source SAM apparait alors avec la description suivante : The maximum domain account identifier value has been reached. No further account-identifier pools can be allocated to domain controllers in this domain. Un Dcdiag affichera de meme : The DS has corrupt date: rIDAvailablePool value is not valid. Autrement dit EOF ^^

Quel Workaround dans ce cas? En admettant que vous ayez au préalable créé une trust vers un nouveau domaine, il est toujours possible de migrer les objets vers celui-ci, donc à voir comme la conquête d’un nouveau monde. Si vous n’avez pas prévu de créer un trust avant, ce n’est plus possible puisqu’il n’y a plus de RID de disponibles… et c’est la fin de votre monde.

Appartenance aux groupes

Un compte utilisateur, ordinateur ou groupe (AKA un Security Principal) peut être membre d’u maximum d’environ 1015 groupes. Cette limitation est due à la taille du jeton d’accès associé, qui est créé pour chaque SP. A noter que dans le cadre d’un modèle de délégation à N branches, typiquement lorsque l’on part sur un modèle RBAC, on peut éventuellement atteindre la limite rapidement.

Nombre maximum de GPO appliquées sur un compte

Le nombre maximum de GPO applicables sur un compte est de 999. Ca ne signifie bien sur pas qu'il n'est pas possible de dépasser 999 GPO dans un domaine :D

Limitations de relations d’approbation (trusts)

Les limitations en nombre de trusts viennent du nombre maximum de Trustes domain objetcs –TDO), la longueur du chemin, et la capacité du client à découvrir des trusts dispoinibles. On citera par exemple :

  •          Un client Kerberos peut traverser un maximum de 10 trusts pour localiser une ressource dans un autre domaine. Dans le cas contraire, la recherche échouera
  •           Lorsqu’un client effectue une recherche en passant par un trust, celle-ci est limitée au trusts directement établies avec son domaine, et les trusts transitives au sein d’une même forêt
  •           Il a été par ailleurs découvert que les performances des opérations basées sur des TDO s’effondrent totalement lorsque plus de 2400 TDOs existent dans la forêt... Mais dans ce cas là, il vous faut sérieusement penser à une refonte d'architecture.... et vous savez qui contacter :)