Équilibrage de la charge et basculement de l'authentification Active Directory

Pour les applications qui s'authentifient auprès d'un contrôleur de domaine Active Directory, il serait évidemment préférable de simplement les pointer vers l'enregistrement DNS du domaine principal plutôt qu'un contrôleur de domaine spécifique pour le basculement, l'équilibrage de charge, etc.

Quelles sont les meilleures pratiques pour ces applications qui vous obligent à coder en dur l'IP d'un DC? Nous pourrions coder en dur l'adresse IP d'un équilibreur de charge à la place, donc si un contrôleur de domaine tombe en panne, cette application pourra toujours s'authentifier. Existe-t-il de meilleures alternatives?

Active Directory intègre déjà des techniques d'équilibrage de charge. Votre client Windows sait comment localiser les contrôleurs de domaine redondants sur son propre site et comment en utiliser un autre si le premier n'est pas disponible. Il n'est pas nécessaire d'effectuer un équilibrage de charge supplémentaire, comme les contrôleurs de domaine «en cluster», etc. tant que vous disposez de contrôleurs de domaine redondants.

D'une certaine manière, vous pouvez considérer un site Active Directory comme un «équilibreur de charge», car les clients de ce site choisiront au hasard l'un des contrôleurs de domaine du même site. Si tous les contrôleurs de domaine d'un site échouent ou si le site n'a pas de contrôleurs de domaine, les clients choisiront un autre site (soit le site le plus proche suivant, soit au hasard).

Vous pouvez équilibrer la charge du service DNS fourni par Active Directory pour les clients joints au domaine en plaçant un VIP sur un équilibreur de charge matériel et en ayant cet équilibre de charge VIP entre plusieurs des contrôleurs de domaine. Ensuite, sur vos clients, mettez ce VIP comme serveur DNS préféré dans la configuration TCP / IP.

Je le fais en ce moment pour une infrastructure mondiale et cela fonctionne très bien.

Mais cela ne s'applique qu'au service DNS.

N'essayez pas d'équilibrer la charge de vos contrôleurs de domaine pour l'authentification. C'est demander des ennuis. Vous auriez au moins à faire beaucoup de travail SPN personnalisé complexe et vous vous éjecteriez loin des limites du support Microsoft. De ce blog, que vous devriez lire , je vais le citer:

Retournez voir les fournisseurs et dites-leur que vous ne les considérez pas comme étant intégrés à AD et vous trouverez une solution différente.

Maintenant, comme pour les applications qui vous demandent de taper l' adresse IP d'un contrôleur de domaine? Eh bien, je vais simplement réitérer mon commentaire:

Celui qui a écrit une application qui vous oblige à coder en dur l'adresse IP d'un contrôleur de domaine ne sait pas ce qu'il fait.

il n'y a jamais eu de bonne raison de coder en dur une adresse IP ou d'utiliser une adresse IP pour résoudre les requêtes AD. Il n'y a pas de meilleures pratiques pour les mauvaises pratiques.

Plusieurs des autres réponses à cette question semblent supposer qu'il n'y a pas d'autre monde que les applications compatibles avec Microsoft. Malheureusement, ce n'est pas le cas, comme en témoigne la question initiale:

Quelles sont les meilleures pratiques pour ces applications qui vous obligent à coder en dur l'IP d'un DC?

Bien que Microsoft ne prenne pas en charge ou ne recommande pas l'utilisation d'une solution NLB devant Active Directory, il semble en effet qu'il existe certaines options pour authentifier les applications non compatibles avec Microsoft AD.

• Présentation de l'authentification proxy dans AD LDS
• I5 certifié F5 pour l'équilibrage de charge LDAP
• Authentification directe avec SASL

Un besoin réel d'AD externe «d'équilibrage de charge» est rare et difficile à faire correctement. Un besoin de requêtes typiques peut fonctionner correctement, mais un client et des applications Windows typiques doivent effectuer des mises à jour. Un client Windows tente d'établir une affinité avec un DC particulier, de sorte que s'il met à jour quelque chose et tente immédiatement une opération ultérieure, il atteint le même DC. Les développeurs d'applications font la même chose. Si vous écrivez du code qui crée un compte d'utilisateur, puis essayez de changer le mot de passe sur ce compte 1 ms plus tard, vous devez frapper le même cc.

Si vous deviez utiliser AD en amont avec une solution d'équilibrage de charge, vous vous assurez que ces approches et affinités ne se rompent pas.

Si le besoin est la disponibilité, par opposition à l'équilibrage de la charge, le clustering peut être plus approprié (le cluster peut des vers de côté).

Dans les grandes implémentations AD, une approche plus traditionnelle consiste à identifier les consommateurs majoritaires et à les placer dans un site avec leurs propres DC. Par exemple, si vous disposez de cinq serveurs Exchange, créez un site pour les sous-réseaux de ces serveurs et placez des GC dédiés dans ce site. La même chose s'appliquerait à d'autres serveurs tels que SharePoint.