Oui, les applications qui veulent interagir avec Active Directory ont réellement devrait être conçus pour utiliser les procédures appropriées de localisation des DC (qui sont bien documentées) ; malheureusement, très souvent, ils ne le sont pas.
Vous pouvez généralement contourner ce problème en faisant pointer votre application LDAP vers le nom de domaine Active Directory au lieu d'un DC spécifique, car chaque DC enregistre automatiquement un enregistrement A pour le nom de domaine pointant vers son adresse IP, ce qui fonctionne comme un DNS round robin ; cependant, cela peut et va causer deux problèmes importants :
- Si un DC est hors service, il sera quand même inclus dans la réponse DNS, ce qui peut provoquer des échecs LDAP si l'application n'est pas assez intelligente pour en essayer un autre.
- Cela ne tient pas compte de la topologie du site Active Directory ; si votre environnement est géographiquement distribué, vous pouvez vous retrouver avec une application à Londres s'authentifiant auprès d'un DC en Australie sur une liaison WAN lente et/ou peu fiable.
Une solution légèrement meilleure consiste à créer votre propre enregistrement DNS pour les applications LDAP sous la forme d'un enregistrement CNAME pointant vers un DC spécifique, tel que ldap.example.com pointant vers dc1.example.com et définissez un TTL lent (par exemple, 60 secondes) ; vous pouvez ensuite configurer votre application pour qu'elle utilise le service ldap.example.com pour tous ses besoins LDAP. Si/quand DC1 tombe en panne, vous pouvez alors remapper ldap.example.com a dc2.example.com et le TTL lent permettra à l'application d'être informée du changement dès que possible, ce qui minimisera les temps d'arrêt.
Dans tous les cas, il est vraiment préférable d'éviter les solutions d'équilibrage de charge, car LDAP n'est tout simplement pas conçu pour fonctionner avec elles et elles pourraient entraîner toutes sortes de problèmes.
