4 votes

Deon Price avatar

Équilibrage de charge LDAP à partir d'un contrôleur de domaine via F5

Demandé el 9 de Mars, 2016
Quand la question a-t-elle été
9586 affichage
Nombre de visites la question a
5 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Je sais que l'équilibrage de charge ou la bascule de basculement de LDAP sur un contrôleur de domaine Windows n'est généralement pas une bonne idée en raison des problèmes de Kerberos et SPN.

MAIS, j'ai beaucoup d'applications non-Windows qui utilisent LDAP pour l'authentification et l'autorisation. Elles sont actuellement dirigées vers un seul contrôleur de domaine, ce serait bien d'avoir un VIP et un pool avec tous mes contrôleurs de domaine derrière.

Alors, quel est le problème ici lorsque je vois ceci?:

https://devcentral.f5.com/questions/ad-dcs-behind-f5

Est-ce que le F5 fait quelque chose de spécial? Est-ce qu'il se rabat simplement sur NTLM? Ou se contente-t-il d'utiliser une simple liaison LDAP à AD? (ou liaison SLDAP).

Quelle est la meilleure façon pour les clients non-Windows d'utiliser LDAP? Devraient-ils simplement être conçus dès le départ pour utiliser les enregistrements SRV de localisation DNS? AD-LDS devrait-il être déployé et équilibré?

Est-ce que j'ai raté quelque chose?

Demandé el 9 de Mars, 2016 par Deon Price

Réponses

Trop de publicités?

4voto

Massimo avatar
Massimo Points 67633

Oui, les applications qui veulent interagir avec Active Directory devraient vraiment être conçues pour utiliser des procédures de localisation de DC appropriées (qui sont bien documentées); malheureusement, bien souvent ce n'est pas le cas.

Vous pouvez généralement contourner cela en pointant 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 fonctionnera 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; cela pourrait causer des échecs LDAP si l'application n'est pas assez intelligente pour essayer un autre.
  • Cela ne tiendra pas compte de la topologie du site Active Directory; si vous avez un environnement distribué géographiquement, vous pourriez vous retrouver avec une application à Londres s'authentifiant contre un DC en Australie via une liaison WAN lente et/ou peu fiable.

Une solution légèrement meilleure est de créer votre propre enregistrement DNS pour les applications LDAP sous forme d'un enregistrement CNAME pointant vers un DC spécifique, tel que ldap.example.com pointant vers dc1.example.com, et définir un TTL lent dessus (par ex. 60 secondes); vous pouvez ensuite configurer votre application pour utiliser ldap.example.com pour tous ses besoins LDAP. Si/quand DC1 tombe en panne, vous pouvez alors remapper ldap.example.com vers dc2.example.com, et le TTL lent garantira que l'application prendra connaissance du changement dès que possible, minimisant ainsi les temps d'arrêt.

En tout cas, il est vraiment préférable d'éviter les solutions de répartition 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.

Répondu el 9 de Mars, 2016 par Massimo (67633 Points )

0 votes

Avatar de Deon Price

Je vois, bonnes informations. Et si c'est une simple authentification, en utilisant un nom / mot de passe et en utilisant un cryptage au niveau de la session ? Je suppose que c'est pourquoi cela fonctionne bien avec un F5 puisque Kerberos n'est pas du tout utilisé, non ? Y a-t-il des problèmes avec cela autre que ce n'est pas le meilleur en termes de sécurité ?

Commenté el 9 de Mars, 2016 par Deon Price

1 votes

Avatar de Massimo

Ce n'est pas un problème de sécurité ... c'est un problème de protocole; LDAP n'est tout simplement pas conçu pour fonctionner avec l'équilibrage de charge. Microsoft ne le prend pas en charge, et personne non plus (jusqu'à et y compris F5). Il est tout à fait possible que tout fonctionne parfaitement dans 99% des situations, mais dès qu'il y aura inévitablement un problème, absolument personne ne vous soutiendra si vous avez placé un équilibreur de charge devant vos contrôleurs de domaine, et vous ne pourrez pas exclure si votre problème est en fait causé par celui-ci ou par quelque chose de complètement sans rapport. TL;DR: Vous cherchez juste des ennuis.

Commenté el 9 de Mars, 2016 par Massimo

0 votes

Avatar de Deon Price

Que diriez-vous de quelque chose comme ceci : windowsitpro.com/article/network-load-balancing-nlb/… et synchroniser LDS avec AD.

Commenté el 10 de Mars, 2016 par Deon Price
Afficher 3 autres commentaires

1voto

fartheraway avatar
fartheraway Points 4886

Presque tous les produits d'authentification LDAP non Windows que j'ai vus sont capables d'utiliser une entrée DNS. Au lieu de pointer vers un serveur spécifique, vous pouvez pointer vers la racine de votre domaine. Cela devrait fonctionner dans la grande majorité des situations.

Cela est possible car si vous effectuez une recherche à la racine de votre domaine par exemple example.com, cela devrait renvoyer tous les IPs de vos contrôleurs de domaine. Cela permet à la rotation standard du DNS de prendre le relais, sans avoir besoin d'une configuration spécialisée.

Répondu el 9 de Mars, 2016 par fartheraway (4886 Points )

1voto

Mike42 avatar
Mike42 Points 849

Est-ce plus orienté vers la haute disponibilité ou les performances?

Pour les performances, je tiens à souligner ceci:

J'ai beaucoup d'applications non Windows qui utilisent LDAP pour l'authentification et l'autorisation. Elles sont actuellement dirigées vers un seul contrôleur de domaine.

La solution rapide évidente ici est de diriger certaines de vos applications vers vos contrôleurs de domaine supplémentaires. Bien sûr, ce n'est pas idéal car cela laisse les applications vulnérables en cas de panne d'un contrôleur de domaine, mais c'est une manière facile de répartir votre charge immédiatement.

Pour la haute disponibilité, vous pouvez diriger les applications vers le nom de domaine ou (encore mieux) un CNAME du nom de domaine. Ce n'est pas idéal, car cela signifie un ajustement manuel du DNS en cas de problème, mais cela facilitera la réponse.

Vous pouvez combiner ces techniques en utilisant des enregistrements CNAME vers plusieurs contrôleurs de domaine. La charge est répartie et vous pouvez facilement ajuster un enregistrement CNAME pour un contrôleur de domaine individuel en cas de panne.

Répondu el 9 de Mars, 2016 par Mike42 (849 Points )

1voto

Thecamelcoder avatar
Thecamelcoder Points 11

Un défi lié à l'utilisation d'un répartiteur de charge est, en fonction de l'activité, certaines applications peuvent demander une poignée à un DirectoryEntry. Le DirectoryEntry inclut le nom du serveur. C'est plus courant pour les mises à jour, mais peut également se produire pour les lectures/requêtes. Évidemment, dans ce cas, vous ne passez pas par le répartiteur de charge. Est-ce suffisant pour l'authentification ? Peut-être.

J'ai appris que si vous mettez un service à disposition, les gens peuvent l'utiliser pour autre chose que ce que vous avez prévu. Donc ce VIP "authentification seulement" que vous avez configuré? Peut-être que quelqu'un décide de l'utiliser pour autre chose. C'est vraiment important. Que se passe-t-il s'il y a un problème ?

Un autre problème est de savoir quels sont les contrôles de santé ? Il n'est pas rare qu'un contrôleur de domaine soit en ligne sur les ports 389/636 mais ne fonctionne pas correctement. Donc un simple contrôle de port peut ne pas être suffisant.

Traditionnellement, la résilience de la connexion à l'Active Directory (le processus de localisation du contrôleur de domaine) est déléguée au client. Lorsque vous commencez à y toucher pour la rendre "très disponible", vous prenez en charge les problèmes. Et certains de ces problèmes peuvent être difficiles et difficiles à diagnostiquer et à résoudre. Qui va vous soutenir ? F5? Microsoft? Bonne chance avec ça.

Répondu el 9 de Mars, 2016 par Thecamelcoder (11 Points )

0 votes

Avatar de Deon Price

Donc, en fin de compte, il s'agit de s'assurer que l'application peut gérer la reprise après incident, c'est-à-dire - vous pouvez entrer plus d'un nom de serveur pour le contrôleur de domaine, OU, l'application peut gérer le processus de localisation du contrôleur de domaine. L'équilibrage de charge LDAP se fait à vos propres risques.

Commenté el 10 de Mars, 2016 par Deon Price

0 votes

Avatar de Thecamelcoder

C'est bien ça, oui. Relying sur un simple DNS lookup est une erreur courante lors de la tentative d'utilisation de Active Directory. J'ai vu cette erreur même avec des produits commerciaux très courants.

Commenté el 10 de Mars, 2016 par Thecamelcoder

0 votes

Avatar de user339468

Une véritable application LDAP n'utilise pas les localisateurs DC car elle n'intègre pas Active Directory ; ce ne sont que des clients LDAP. Quelques applications avancées sont capables d'utiliser les enregistrements DNS SRV mais cela ne signifie pas qu'elles utiliseront ceux enregistrés dans l'AD ; elles peuvent avoir leurs propres exigences.

Commenté el 10 de Mars, 2016 par user339468
Afficher 3 autres commentaires

1voto

Bill avatar
Bill Points 11

J'ai 3 serveurs dans un groupe VIP pour cette circonstance.

De plus, l'utilisation du nom de domaine est souvent mauvaise car cela atteindra le premier centre de données de la liste retournée, si l'application n'est pas consciente du site (la plupart ne le sont pas). Cela pourrait être n'importe où dans le pays et ce serait mauvais pour la charge WAN et la latence.

Répondu el 10 de Août, 2017 par Bill (11 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X