Partager via

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

Une 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 est de 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 de 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 en lecture seule suffirait. L’optimisation de ces scénarios prendrait deux chemins :

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

Pour plus d’informations, consultez :

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 de 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 et toutes les définitions de site de recommandations et le placement des contrôleurs de domaine sont conservés, mais les applications qui dépendent des références 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 des contrôleurs de domaine provenant de plusieurs domaines dans un même site, le réglage des paramètres DNS ou le déplacement du site d’une application.

Considérations relatives à l’optimisation pour les approbations

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 répertoires actifs de grande dispersion géographique lorsque l’authentification doit également transiter des liens très latents pour affecter le flux ci-dessus. 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 MaxConcurrentAPI pour prendre en charge la charge sur le canal sécurisé. Pour plus d’informations, consultez Comment optimiser les performances pour l’authentification NTLM à l’aide du paramètre MaxConcurrentApi.

  • Créez des approbations de raccourci en fonction de la charge.

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

  • Vérifiez que les considérations relatives à la localité sont prises en compte pour les approbations.

  • Activez Kerberos dans la mesure du possible et réduisez l’utilisation du canal sécurisé pour réduire le risque d’exécution de goulots d’étranglement MaxConcurrentAPI.

Les scénarios d’approbation inter-domaines ont toujours été un point problématique pour de nombreux clients. Les problèmes de résolution de noms et de connectivité, souvent dus à des pare-feu, entraînent un épuisement des ressources sur le contrôleur de domaine d’approbation 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 garantir le bon fonctionnement sont les suivants :

  • Vérifiez que la résolution de noms DNS et WINS que les contrôleurs de domaine d’approbation utilisent peut 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éintroduire des 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 la configuration correcte des redirecteurs, des transferts conditionnels et des copies secondaires pour les zones de recherche directe et inversée pour chaque ressource de l’environnement auquel un client peut 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.

    • Convergez les noms de site entre les domaines approuvés et d’approbation pour refléter le contrôleur de domaine dans le 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, selon les 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 approbations. 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 des requêtes entrantes est élevé. Le client peut rencontrer les attentes d’expiration du délai d’expiration au niveau du contrôleur de domaine en tant que threads suspendus, ce qui peut se traduire par des applications bloquées (si l’application exécute la requête dans le thread de premier plan). Pour plus d'informations, consultez Comment faire pour configurer un pare-feu pour les domaines et les approbations.

    • Utilisez DnsAvoidRegisterRecords pour éliminer les contrôleurs de domaine à faible latence, 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.

      Notes

      Le nombre de contrôleurs de domaine que le client peut consommer se limite à environ 50. Il s’agit des contrôleurs de domaine de capacité les plus optimaux et les plus élevés du site.

    • Envisagez de placer des contrôleurs de domaine à partir de domaines approuvés et d’approbation 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 uniquement 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.

Références supplémentaires