Partager via

Positionnement approprié des contrôleurs de domaine et des considérations relatives au site

La définition de site appropriée est essentielle aux performances. Les clients qui tombent hors de site peuvent rencontrer des performances médiocres pour les authentifications et les requêtes. En outre, avec l’introduction d’IPv6 sur les clients, la demande peut provenir de l’adresse IPv4 ou de l’adresse IPv6 et Active Directory doit avoir des sites correctement définis pour IPv6. Le système d’exploitation préfère IPv6 à IPv4 quand les deux sont configurés.

À compter de Windows Server 2008, le contrôleur de domaine tente d’utiliser la résolution de noms pour effectuer une recherche inversée afin de déterminer le site dans lequel le client doit se trouver. Cela peut entraîner l’épuisement du pool de threads ATQ et empêcher le contrôleur de domaine de répondre. La résolution appropriée consiste à définir correctement la topologie de site pour IPv6. Pour contourner ce problème, vous pouvez optimiser l’infrastructure de résolution de noms pour répondre rapidement aux demandes du contrôleur de domaine. Pour plus d'informations, consultez Réponse différée du contrôleur de domaine Windows Server 2008 ou Windows Server 2008 R2 aux requêtes LDAP ou Kerberos.

Un autre point à prendre en compte est la recherche de contrôleurs de domaine en lecture/écriture pour les scénarios où les contrôleurs de domaine en lecture seule sont utilisés. Certaines opérations nécessitent l’accès à un contrôleur de domaine accessible en écriture ou ciblent un contrôleur de domaine accessible en écriture lorsqu’un contrôleur de domaine Read-Only suffirait. L’optimisation de ces scénarios prend deux chemins :

  • Contacter les contrôleurs de domaine accessibles en écriture lorsqu’un contrôleur de domaine Read-Only suffirait. Cela nécessite une modification du code d’application.
  • Lorsqu’un contrôleur de domaine accessible en écriture peut être nécessaire. Placez les contrôleurs de domaine en lecture-écriture à des emplacements centraux pour réduire la latence.

Pour plus d’informations, consultez les informations de référence suivantes :

Optimiser pour les références

Les références sont la façon dont les requêtes LDAP sont redirigées lorsque le contrôleur de domaine n’héberge pas une copie de la partition interrogée. Lorsqu’une référence est retournée, elle contient le nom unique de la partition, un nom DNS et un numéro de port. Le client utilise ces informations pour poursuivre la requête sur un serveur qui héberge la partition. Il s’agit d’un scénario DCLocator, toutes les définitions de site de recommandations et le placement du contrôleur de domaine sont maintenus, mais les applications qui dépendent des renvois sont souvent ignorées. Il est recommandé de s’assurer que la topologie AD, y compris les définitions de site et le placement du contrôleur de domaine, reflètent correctement les besoins du client. Cela peut également inclure l’utilisation de contrôleurs de domaine à partir de plusieurs domaines dans un site unique, l’optimisation des paramètres DNS ou le déplacement du site d’une application.

Considérations relatives à l’optimisation des fiducies

Dans un scénario intra-forêt, les approbations sont traitées selon la hiérarchie de domaines suivante : Domaine petit-enfant -> Domaine enfant -> Domaine racine de forêt -> Domaine enfant -> Domaine petit-enfant. Cela signifie que les canaux sécurisés à la racine de la forêt, et chaque parent, peut devenir surchargé en raison de l’agrégation des demandes d’authentification transitant par les contrôleurs de domaine dans la hiérarchie d’approbation. Cela peut également entraîner des retards dans les Active Directory d'une grande dispersion géographique lorsque l'authentification doit aussi transiter par des liens à forte latence, ce qui impacte ce flux. Les surcharges peuvent se produire dans des scénarios d’approbation inter-forêts et de bas niveau. Les recommandations suivantes s’appliquent à tous les scénarios :

  • Ajustez correctement l’API MaxConcurrentAPI pour prendre en charge la charge sur le canal sécurisé. Pour plus d’informations, consultez Comment effectuer le réglage des performances pour l’authentification NTLM à l’aide du paramètre MaxConcurrentApi.

  • Créez des relations de confiance abrégées selon les besoins en fonction de la charge.

  • Vérifiez que chaque contrôleur de domaine du domaine est en mesure d’effectuer la résolution de noms et de communiquer avec les contrôleurs de domaine dans le domaine approuvé.

  • Assurez-vous que les considérations locales sont prises en compte pour les fiducies.

  • Activez Kerberos lorsque cela est possible et minimisez l’utilisation du canal sécurisé pour réduire le risque de rencontrer des goulots d’étranglement MaxConcurrentAPI.

Les scénarios d’approbation inter-domaines sont un domaine qui a été constamment un point de douleur pour de nombreux clients. La résolution de noms et les problèmes de connectivité, souvent en raison de pare-feu, provoquent l’épuisement des ressources sur le contrôleur de domaine de confiance et ont un impact sur tous les clients. En outre, un scénario souvent négligé optimise l’accès aux contrôleurs de domaine approuvés. Les domaines clés pour s’assurer que cela fonctionne correctement sont les suivants :

  • Vérifiez que la résolution de noms DNS et WINS que les contrôleurs de domaine approuvés utilisent peuvent résoudre une liste précise de contrôleurs de domaine pour le domaine approuvé.

    • Les enregistrements ajoutés de manière statique ont tendance à devenir obsolètes et réintroduisent les problèmes de connectivité au fil du temps. Les transferts DNS, le DNS dynamique et la fusion des infrastructures WINS/DNS sont plus faciles à gérer à long terme.

    • Assurez-vous de la bonne configuration des redirecteurs, des transferts conditionnels et des copies secondaires pour les zones de recherche directes et inverses pour chaque ressource de l'environnement à laquelle un client pourrait avoir besoin d'accéder. Là encore, cela nécessite une maintenance manuelle et a tendance à devenir obsolète. La consolidation des infrastructures est idéale.

  • Les contrôleurs de domaine du domaine d’approbation tenteront de localiser les contrôleurs de domaine dans le domaine approuvé qui se trouvent d’abord sur le même site, puis de revenir aux localisateurs génériques.

    • Pour plus d’informations sur le fonctionnement de DCLocator, consultez Recherche d’un contrôleur de domaine dans le site le plus proche.

    • Harmonisez les noms de site entre les domaines de confiance et les domaines faisant confiance pour refléter un contrôleur de domaine au même emplacement. Vérifiez que les mappages d’adresses IP et de sous-réseau sont correctement liés aux sites dans les deux forêts. Pour plus d’informations, consultez Localisateur de domaine dans une approbation de forêt.

    • Vérifiez que les ports sont ouverts, en fonction des besoins de DCLocator, pour l’emplacement du contrôleur de domaine. Si des pare-feu existent entre les domaines, vérifiez que les pare-feu sont correctement configurés pour toutes les relations de confiance. Si les pare-feu ne sont pas ouverts, le contrôleur de domaine d’approbation tente toujours d’accéder au domaine approuvé. Si la communication échoue pour une raison quelconque, le contrôleur de domaine d’approbation fera expirer la demande au contrôleur de domaine approuvé. Toutefois, ces délais d’expiration peuvent prendre plusieurs secondes par requête et peuvent épuiser les ports réseau sur le contrôleur de domaine de confiance si le volume de requêtes entrantes est élevé. Le client peut rencontrer des délais d'attente au contrôleur de domaine sous forme de threads bloqués, ce qui peut se traduire par des applications bloquées (si l'application traite la requête en utilisant un thread en premier plan). Pour plus d’informations, consultez Comment configurer un pare-feu pour les domaines et les approbations.

    • Utilisez DnsAvoidRegisterRecords pour éliminer les contrôleurs de domaine mal performants ou à latence élevée, tels que ceux des sites satellites, de la publicité aux localisateurs génériques. Pour plus d’informations, consultez Comment optimiser l’emplacement d’un contrôleur de domaine ou d’un catalogue global qui réside en dehors du site d’un client.

      Note

      Il existe une limite pratique d’environ 50 pour le nombre de contrôleurs de domaine que le client peut consommer. Il doit s’agir des contrôleurs de domaine ayant la capacité la plus élevée et les plus optimisés pour le site.

    • Envisagez de placer des contrôleurs de domaine à partir de domaines approuvés et de confiance dans le même emplacement physique.

Pour tous les scénarios d’approbation, les informations d’identification sont routées en fonction du domaine spécifié dans les demandes d’authentification. Cela est également vrai pour les requêtes vers les API LookupAccountName et LsaLookupNames (ainsi que d’autres, il s’agit simplement des API les plus couramment utilisées). Lorsque les paramètres de domaine de ces API sont passés une valeur NULL, le contrôleur de domaine tente de trouver le nom de compte spécifié dans chaque domaine approuvé disponible.

Additional References