Conception de l’infrastructure du service d’annuaire
La conception d’une infrastructure de serveurs d’annuaire consiste à définir une topologie physique qui permettra de supporter la disponibilité, l’évolutivité et la gestion du service d’annuaire à l’ensemble de ses clients. Il faudra donc étudier l’intégration de l’infrastructure de serveurs LDAP à une topologie adaptée au service qui doit être rendu. Pour ce faire, LDAP offre des méthodes de distribution et de réplication des informations afin de concevoir une architecture d’annuaire adaptée au besoin de l’entreprise. La distribution permettra de répartir l’information ou de "cascader" les données au travers de différents annuaires créant ainsi une sorte de délégation d’une ou plusieurs parties de l’annuaire vers d’autres annuaires. On parle alors de serveur d’annuaire distribué par le biais d’entrées contenant des serveurs LDAP "référents". La réplication concerne, quant à elle, la partie de la redondance des informations. Elle n’est d’ailleurs cependant pas standardisée par la norme LDAPv3, fort heureusement, la plupart des fournisseurs d’annuaire l’implémente dans leurs produits. Une dernière chose à considérer lors de la conception d’une infrastructure informatique est sa disponibilité, c’est-à-dire sa capacité à rendre le service proposé 24 h/24 et 7 j/7. Une partie de ce chapitre sera donc dédiée à l’étude de l’intégration d’une solution de haute disponibilité à l’infrastructure du service d’annuaire et à une présentation d’un "load-balancer" applicatif.
1. Les différentes topologies
Ainsi, la première chose à faire lors de la conception de l’infrastructure réseau d’un système informatique est de déterminer sa topologie. C’est-à-dire de définir une architecture physique d’un ou plusieurs serveurs pouvant être interconnectés de façon hiérarchique dans des lieux géographiquement éloignés. La topologie va donc demander une grande réflexion basée fortement sur les critères suivants :
	•	Du volume d’informations (en nombre d’entrées) contenues dans l’annuaire. 
	•	Du nombre d’équipements informatiques devant s’y connecter.
	•	De la répartition géographique de ces équipements informatiques.
	•	De la répartition des données de l’annuaire.
	•	De la redondance des informations de l’annuaire.
	•	Et de l’importance de la disponibilité de l’annuaire.
L’ensemble permet de ces critères d’établir une liste d’au moins cinq topologies différentes qui vont être détaillées dans les sections suivantes.
a. Un service d’annuaire local
Si le service d’annuaire LDAP se concentre sur un seul site, pour un très petit nombre d’utilisateurs et d’équipements, et dont la disponibilité n’est pas problématique (cas d’une infrastructure de test), alors vous pouvez opter pour un simple et unique annuaire LDAP.
¬
Figure 3-8 : Service d’annuaire local
La figure 3-8 montre ainsi un échange direct entre un client et un serveur LDAP où le client LDAP s’adresse à un seul et unique annuaire LDAP. Si le serveur LDAP tombe, seuls les utilisateurs contenus dans la base locale du client LDAP pourront s’authentifier sur celui-ci.
b. Un service d’annuaire local avec référent(s)
Cette topologie permet aux annuaires LDAP de faire référence à d’autres annuaires LDAP. En d’autres termes, elle permet à un annuaire LDAP de déléguer une partie de son DIT sur un autre annuaire ou bien de permettre une redirection vers d’autres annuaires en cas de requêtes provenant de clients LDAP pour des DIT non connus... un peu comme des passerelles par défaut dans une architecture d’équipements réseau. Le modèle LDAPv3 définit que, dans ce cas, le serveur LDAP répondra au client par le nom et l’adresse IP du serveur LDAP à joindre, le client LDAP devra donc reformuler sa requête auprès de ce dernier. Cependant, certains serveurs LDAP, dont OpenLDAP, proposent de charger une fonctionnalité appelée "chaînage" qui ordonne au serveur LDAP de faire suivre directement la requête du client au serveur LDAP délégué. Puis, le résultat sera donc envoyé par le premier serveur LDAP sans que le client ne sache que sa requête a été transmise à un autre serveur LDAP. Les figures 3-9 et 3-10 suivantes schématisent ainsi le trajet des requêtes LDAP selon que la fonction "chaînage" soit activée ou pas.
¬
Figure 3-9 : Service d’annuaire local avec référent
¬
Figure 3-10 : Service d’annuaire local avec référent en chaînage
c. Un service d’annuaire local et répliqué
Dans le cas où votre annuaire LDAP se destinerait à une utilisation restreinte et locale, mais dont l’utilisation serait indispensable et ne nécessiterait donc aucune indisponibilité du service LDAP, alors il faudrait lui ajouter un second serveur LDAP et configurer la réplication Peer To Peer entre les deux serveurs.
¬
Figure3-11 : Service d’annuaire local et répliqué
La figure 3-11 illustre bien ce cas où un client LDAP a connaissance dans sa configuration de deux serveurs d’annuaire, mais n’utilise le second qu’en cas de perte de son serveur d’annuaire principal. Par ailleurs, la réplication entre les deux annuaires permet au client d’avoir accès aux mêmes informations, en toute transparence et sans dysfonctionnement en cas de perte de l’annuaire principal (peut-être tout de même une légère latence... mais selon le client LDAP utilisé, ce paramètre pourra être configuré.
d. Un service d’annuaire distribué et répliqué
Si vous comptez déployer un service LDAP au sein d’une organisation constituée de quelques sites très proches géographiquement, avec des milliers d’utilisateurs et de nombreuses ressources informatiques reliées à celui-ci, alors il faudra envisager de déployer plusieurs annuaires sur les différents sites et mettre en place une réplication "Provider/Consumer" entre eux.
¬
Figure 3-12 : Service d’annuaire distribué et répliqué
La figure 3-12 montre une entreprise A constituée de plusieurs sites 1, 2 et 3. Ces sites sont bien entendu tous reliés au réseau informatique de l’entreprise. Cependant, les liaisons réseau intersites ayant des débits plus faibles (car ce sont généralement des liaisons plus coûteuses), il convient donc de ne pas les engorger avec trop de données. Ainsi, pour éviter qu’un utilisateur connecté à un serveur du site 3 ne puisse s’authentifier auprès d’un serveur LDAP du site 1, nous allons déployer une architecture LDAP dite "Esclave" sur le site 3 qui sera alimentée par l’infrastructure LDAP dite "Maître" du site 1.
¬
Du fait de la réplication LDAP unilatérale de "maître à esclave", il convient donc d’effectuer les enregistrements dans l’annuaire depuis les serveurs LDAP du site 1... autrement, on s’exposerait à une inconsistance des informations contenues dans les différents annuaires de l’entreprise.
e. Un service d’annuaire distribué et répliqué avec référents
Ce type de topologie est destiné aux organisations internationales constituées de plusieurs sites à travers le monde.
Dans ce cas, il faudra constituer l’infrastructure en deux parties :
	•	Une colonne vertébrale de serveurs LDAP hébergeant la version intégrale de l’annuaire.
	•	Des annuaires LDAP par site ne contenant que les ressources du site (=du domaine) et se référant aux annuaires de premier niveau pour les ressources en dehors du domaine.
¬
Figure 3-13 : Service d’annuaire distribué et répliqué avec référents
La figure 3-13 montre la colonne vertébrale de serveurs LDAP répartis dans le monde, et répliquant entre eux le contenu intégral de l’annuaire de l’entreprise A (la racine de l’annuaire est : dc=entrepriseA,dc=com). En revanche, nous pouvons observer que les annuaires LDAP d’un pays (ici la France) ne répliquent qu’une partie de l’annuaire (leurs racines sont : ou=fr,cn=pays,cn=site,dc=entrepriseA,dc=com)... Ils n’ont donc pas connaissance de l’intégralité de l’annuaire de l’entreprise et donc, dans le cas qui nous intéresse, de la branche : ou=us,cn=pays,cn=site, dc=entrepriseA,dc=com.
Ce qui, dans le cas présent, a des répercussions sur la façon dont l’annuaire "français" va authentifier des utilisateurs "non français". Ainsi, les utilisateurs "Ali" et "Yanis" étant dans la branche ou=fr, ils seront directement authentifiés par les annuaires LDAP "français". En revanche, si l’utilisateur "Tom" référencé dans la branche ou=us de l’annuaire de l’entreprise, tente de s’authentifier sur un client LDAP connecté à un annuaire LDAP "français", alors ce dernier devra rediriger le client LDAP vers l’annuaire de la région Europe qui répondra par la suite directement au client LDAP.
¬
Dans cet exemple, le client LDAP reçoit directement la réponse du serveur LDAP de premier niveau (celui de l’anneau primaire). Ceci n’est dans ce cas pas réalisable, et devra donc être réalisé par les serveurs LDAP locaux.
2. La haute disponibilité des annuaires
Si la topologie choisie doit permettre une disponibilité du service 24 h/24 et 7 jours/7, alors il faut se poser la question sur la façon dont ce service peut être rendu.
Le fait de configurer deux serveurs OpenLDAP en réplication "Peer To Peer" permet d’assurer la redondance du service LDAP et des données de l’annuaire. Mais en revanche, le serveur OpenLDAP n’a aucune fonction de redirection du service LDAP si un des deux annuaires tombe ou devient inactif. Il convient donc de transférer cette capacité à réagir à une défaillance d’un annuaire LDAP à l’agent (ou client) LDAP ou bien à un équipement réseau (ou logicielle) entre le serveur LDAP et ses clients. Ce cas est illustré dans la figure 3-14 où le client LDAP se trouve dans l’incapacité de joindre le serveur "LDAP A" pour lequel il est configuré.
¬
Figure 3-14 : Perte d’un serveur LDAP dans un service d’annuaire local et répliqué
a. Configuration de multiples serveurs LDAP
Le problème de l’exemple précédent (Figure 3-14) peut être résolu en spécifiant l’existence d’un deuxième serveur LDAP au client LDAP. Les clients OpenLDAP par exemple, permettent la configuration de plusieurs annuaires LDAP dans leurs fichiers de configuration. Ainsi, si le client LDAP n’arrive plus à joindre son serveur, il contactera (après un timeout défini) le second annuaire de sa liste et ainsi de suite (voir figure 3-15). Une fois la communication rétablie avec le serveur "LDAP A", il abandonnera sa connexion avec le serveur "LDAP B".
¬
Figure 3-15 : Configuration agent LDAP avec de multiples serveurs LDAP
b. Configuration de la mise en cache LDAP
Il y a également la possibilité d’améliorer la fonction de haute disponibilité au travers d’un système de cache directement configuré sur les clients LDAP. Grâce à cela, l’authentification reste tout de même possible même si le client LDAP ne parvient à joindre aucun annuaire LDAP ou s’il est lui-même déconnecté du réseau (voir figure 3-16).
Cette fonction est disponible pour la plupart des clients LDAP dédiés aux systèmes d’exploitation, ce qui n’est pas forcément le cas sur les équipements réseau ou les applications informatiques.
¬
Ce mécanisme est à utiliser avec précaution, car s’il est très appréciable pour son côté fonctionnel (à savoir que même si aucun annuaire n’est disponible, il est toujours possible de se connecter aux serveurs), il l’est moins d’un point de vue de la sécurité où des accréditations d’utilisateurs partis de l’entreprise sont toujours utilisables, bien qu’effacés de l’annuaire LDAP. Il convient donc de paramétrer cette fonctionnalité de manière raisonnée en vidant par exemple le cache toutes les semaines.
¬
Figure 3-16 : Mise en cache par le client LDAP local
c. Ajout d’un équipement matériel ou applicatif de type commutateur IP avec ou sans équilibrage de charge en "Front-end"
Il se peut que certaines applications ou équipements réseau, au travers d’API ou d’agents LDAP, ne puissent intégrer la possibilité de définir plusieurs annuaires LDAP dans leur configuration... et dans ce cas, il faudra alors penser à une autre solution. Ceci pourrait donc être assuré par un service tiers, applicatif ou matériel (équipement réseau), se chargeant d’intercepter les requêtes LDAP afin de les rediriger vers un annuaire actif de l’infrastructure LDAP.
Ce modèle de haute disponibilité offre également la possibilité de recourir à la fonction d’"équilibrage de charge" permettant ainsi de répartir le nombre de requêtes LDAP entre les différents annuaires, ou bien même dans des cas très avancés de cette fonction, d’être capable de surveiller l’état de charge des serveurs LDAP afin de non plus équilibrer la charge en 50/50, mais en 90/10 par exemple.
¬
Figure 3-17 : Service d’annuaire local avec commutateur IP et équilibrage de charge
Ainsi, la figure 3-17 montre un client LDAP qui sera configuré pour ne s’adresser qu’à un seul annuaire... enfin, ceci est vrai dans sa configuration. Mais l’Alias ou l’adresse IP déclarée dans sa configuration sera celui/celle d’un équilibreur de charge qui jouera donc le rôle d’un commutateur IP et redirigera les requêtes vers les annuaires LDAP de façon équilibrée, ou unilatérale si l’un des annuaires est injoignable pour des raisons d’opérations de maintenance ou bien de pannes.
Par ailleurs, selon le type (ou disons l’intelligence) du "load-balancer", il pourra être en mesure d’évaluer la charge actuelle d’un annuaire LDAP (mesure de l’activité CPU, mémoire et temps de traitement d’une requête LDAP), et donc, de ne plus le solliciter de requêtes.
3. Présentation d’un cluster de répartition de charge (load-balancing cluster)
Afin de configurer une architecture LDAP garantissant une haute disponibilité du service et de ses données, il convient d’intégrer un équipement matériel ou applicatif qui aura comme tâche principale de diriger les requêtes LDAP des clients vers le serveur actif. Et en cas de perte de ce dernier, il devra donc être capable de rediriger les requêtes sur l’autre annuaire. Par ailleurs, sa seconde fonction est l’équilibrage de charge. En effet, en fonction de ses capacités, il est capable de diriger les opérations LDAP sur l’un ou l’autre des serveurs LDAP, soit selon un procédé simple de type "round-robin" ou bien plus complexe en intégrant la possibilité de sonder la charge des serveurs LDAP au niveau par exemple de la mémoire ou du CPU.
L’exemple qui va suivre présentera l’application nommée WNLB pour Websphere Network Load Balancer issue d’un ensemble d’applications présentes dans le produit IBM Websphere Edge Components (anciennement connu sous le nom d’IBM Websphere Edge Server) qui intègre deux fonctionnalités : le cluster à répartition de charge et le proxy caching. Dans le but de son utilisation avec un serveur LDAP, seule la fonction de cluster appelée "network dispatcher" sera présentée.
La topologie d’une architecture LDAP en haute disponibilité intégrant un "load-balancer" a déjà été présentée précédemment. La figure 3-18 ci-après montre désormais comment est structuré cet équipement et la façon dont il s’intègre dans une architecture LDAP.
¬
Figure 3-18 : Structure du WNLB
a. Fonction de haute disponibilité en mode "actif/passif" (clustering)
Il apparaît bien évidemment que pour assurer sa fonction de haute disponibilité, l’application "load-balancer" doit être installée sur deux serveurs différents : l’un sera actif et l’autre en attente (passif). Le serveur passif contacte à intervalles réguliers le serveur actif afin de s’assurer de son état de marche, prêt à prendre immédiatement le relais en cas d’impossibilité de communiquer avec ce dernier (voir figure 3-19).
¬
Figure 3-19 : Haute disponibilité du WNLB
¬
La fonction de haute disponibilité de ce produit n’est pas très fiable, car elle n’intègre pas la notion de ’quorum’, garantissant au nœud actif son intégrité sur le réseau, ainsi qu’un mécanisme de ’fencing’ permettant de mettre hors d’état de nuire le nœud du cluster défaillant.
¬
Figure 3-20 : Haute disponibilité du WNLB
La figure 3-20 montre ainsi que lorsque le nœud actif rencontre un problème, le nœud passif active alors l’adresse IP appelée VIP pour virtual IP et reprend l’activité de "load-balancer" en répartissant les requêtes LDAP sur chaque serveur LDAP. Cette panne du nœud actif a bien entendu été totalement transparente pour le client LDAP qui est configuré pour utiliser la VIP et non l’adresse de chacun des nœuds composant le "load-balancer".
b. Fonction de répartition de charge (load-balancing)
La seconde fonction de cette application est sa faculté à distribuer les requêtes entre les serveurs LDAP (entre deux ou plusieurs serveurs) en fonction tout d’abord de leur état de fonctionnement et ensuite de leur état de charge. C’est sur ce dernier point que les différents "load-balancer" existant sur le marché vont se distinguer. Dans l’application de répartition de charge, cela sera le thread "Advisor" qui sera chargé de sonder, selon un intervalle régulier et paramétrable, la disponibilité et la charge des serveurs LDAP. Une fois le serveur LDAP identifié, il mettra à jour l’information pour que le thread de distribution nommé "dispatcher" envoie les requêtes LDAP vers le bon serveur.
¬
Figure 3-21 : Répartition de charge du WNLB
La figure 3-21 montre ainsi plusieurs scénarios (a), (b) et (c) :
	•	Dans le cas (a), les requêtes LDAP sont dirigées vers les deux serveurs, car tous les deux sont disponibles et non surchargés.
	•	Dans le cas (b), les requêtes LDAP sont dirigées vers le serveur LDAP_B, car le serveur LDAP_A est injoignable (par exemple, crashé).
	•	Dans le cas (c), les requêtes LDAP sont dirigées vers le serveur LDAP_B, car le serveur LDAP_A est surchargé : CPU élevé + temps de traitement élevé, mais pas forcément liés au nombre de connexions LDAP qui reste faible.
c. Méthode de réponse du "load-balancer"
Un dernier point important lors de l’intégration d’un "load-balancer" est de savoir où seront situés les clients LDAP : en interne, sans pare-feu entre les clients et l’infrastructure de serveurs LDAP ou bien au contraire avec un pare-feu (ou même plusieurs) pouvant être positionné entre les clients et les serveurs LDAP. Le WNLB possède ainsi deux méthodes qui permettent de s’adapter à la topologie réseau : la méthode MAC forwarding ou la méthode NAT/NAPT forwarding.
La méthode MAC forwarding est utilisée dans le cas où les clients et les serveurs LDAP se trouvent dans le même réseau ou lorsqu’aucun pare-feu ne bloque les communications directes entre les clients et les serveurs LDAP. Cette méthode est donc à privilégier au possible, car très rapide et peu gourmande en ressources systèmes. La figure 3-22 montre son fonctionnement :
1.	Le client envoie une requête LDAP au "load-balancer".	
2.	Puis le "load-balancer" transmet la requête au serveur LDAP désigné en fonction de sa disponibilité et de certains critères. Le "load-balancer" en profite pour changer l’adresse MAC source des paquets IP par celle du client.	
3.	Le serveur LDAP traite la requête et répond directement au client LDAP, car il utilisera les informations des adresses sources (IP et MAC) transmises par le "load-balancer".	
¬
Figure 3-22 : MAC Forwarding
La méthode NAT/NAPT forwarding est quant à elle utilisée lorsque l’architecture de serveurs LDAP se trouve séparée des clients LDAP par des pare-feu ou tout simplement si ceux-ci sont distants les uns des autres. Cette méthode est plus coûteuse en termes de ressources systèmes (processing), car le serveur LDAP ne répondra pas directement au client LDAP, mais devra traverser à nouveau le "load-balancer" qui lui seul est autorisé à traverser le pare-feu.
Les étapes de communication se déroulent donc ainsi :
1.	Le client envoie une requête LDAP au "load-balancer".	
2.	Puis le "load-balancer" transmet la requête au serveur LDAP désigné en fonction de sa disponibilité et de certains critères.	
3.	Le serveur LDAP traite la requête et répond au "load-balancer".	
4.	Enfin, le "load-balancer" répond au client LDAP.	
¬
Figure 3-23 : NAT/NAPT Forwarding
d. Exemple de configuration pour la fonction cluster à répartition de charge en mode dispatcher (sous AIX)
Dans l’exemple suivant (figure 3-24), il sera alors question de la configuration de deux WNLB. Ceux-ci ne seront par ailleurs pas installés sur deux serveurs distincts, mais directement sur les serveurs LDAP pour lesquels ils assurent le service de haute disponibilité et de répartition de charge. On parle alors d’installation en mode ’collocated’ de l’application WNLB.
Dès lors, l’application WNLB gérera la fonction de haute disponibilité par l’utilisation de sa propre @IP ou @VIP (virtual Internet Protocol address) qu’elle basculera d’un nœud à l’autre en fonction de l’apparition d’une panne sur un des deux nœuds ; cela sera d’ailleurs cette VIP qui apparaîtra dans la configuration de chacun des clients LDAP de l’entreprise.
La fonction de répartition de charges est, quant à elle, effectuée en surveillant la disponibilité des services LDAP sur chacun des serveurs LDAP.
Ainsi, si l’application WNLB constate qu’un des deux serveurs n’est plus joignable, alors elle cessera de lui envoyer des requêtes LDAP.
¬
Figure 3-24 : Schéma de la configuration
	•	Les paquetages à installer :
[serveur_aix:]lslpp -l ’*ibmlb*’ 
  Fileset                      Level  State      Description 
  ---------------------------------------------------------------------- 
-Path: /usr/lib/objrepos 
  ibmlb.admin.rte           6.1.0.40  COMMITTED  LB Administration 
  ibmlb.base.rte            6.1.0.40  COMMITTED  LB Base 
  ibmlb.disp.rte            6.1.0.40  COMMITTED  LB Dispatcher 
  ibmlb.doc.rte             6.1.0.40  COMMITTED  LB Documentation 
  ibmlb.lb.driver           6.1.0.40  COMMITTED  LB Dispatcher Device Driver 
  ibmlb.lb.license           6.1.0.0  COMMITTED  LB licence 
  ibmlb.ms.rte              6.1.0.40  COMMITTED  LB Metric Server 
  ibmlb.msg.en_US.admin.rte 
                            6.1.0.40  COMMITTED  LB Admin Messages -U.S.
                                                 English 
  ibmlb.msg.en_US.doc       6.1.0.40  COMMITTED  Load Balancer Documentation 
                                                 -U.S. English 
  ibmlb.msg.en_US.lb.rte    6.1.0.40  COMMITTED  LB Messages -U.S. English

	•	Les répertoires suivants seront installés :
# Répertoire des fichiers exécutables et binaires  
/opt/ibm/edge/lb/servers/bin 
# Répertoire des fichiers de configuration du dispatcher  
/opt/ibm/edge/lb/servers/configurations/dispatcher 
# Répertoire des fichiers de log  
/opt/ibm/edge/lb/servers/logs/dispatcher

	•	Exemple de fichier de configuration ’/opt/ibm/edge/lb/servers/configurations/dispatcher/default.cfg’ pour chaque nœud du cluster :
# 
### srv_ldap_A avec nœud WNLB actif 
# 
### Executor 
dscontrol executor start 
dscontrol executor set nfa srv_ldap_A 
dscontrol executor set hatimeout 15 
 
### Manager 
dscontrol manager start manager.log 10004 
dscontrol manager reach set loglevel 5         
 
### Cluster ### 
dscontrol cluster add 10.10.110.3 
dscontrol cluster set 10.10.110.3 proportions 49 50 1 0 
 
### HA definitions 
dscontrol highavailability heartbeat add srv_ldap_A srv_ldap_B 
dscontrol highavailability backup add primary auto 10080 
 
### ldaps ( tcp:636 ) 
dscontrol port add 10.10.110.3:636 staletimeout 720 stickytime 60 
method mac reset no 
dscontrol server add 10.10.110.3:636: srv_ldap_A collocated yes 
dscontrol server add 10.10.110.3:636: srv_ldap_B 
dscontrol advisor start ldap 10.10.110.3:636 
dscontrol advisor loglevel ldap 10.10.110.3:636 4 
dscontrol advisor interval ldap 10.10.110.3:636 15 
dscontrol advisor timeout ldap 10.10.110.3:636 10 
dscontrol advisor retry ldap 10.10.110.3:636 2

# 
### srv_ldap_B avec nœud WNLB standby 
 
# 
### Executor 
dscontrol executor start 
dscontrol executor set nfa srv_ldap_B 
dscontrol executor set hatimeout 15 
 
### Manager 
dscontrol manager start manager.log 10004 
dscontrol manager reach set loglevel 5         
 
### Cluster ### 
dscontrol cluster add 10.10.110.3 
dscontrol cluster set 10.10.110.3 proportions 49 50 1 0 

### HA definitions 
dscontrol highavailability heartbeat add srv_ldap_B srv_ldap_A 
dscontrol highavailability backup add backup auto 10080 
 
### ldaps ( tcp:636 ) 
dscontrol port add 10.10.110.3:636 staletimeout 720 stickytime 60 
method mac reset no 
dscontrol server add 10.10.110.3:636: srv_ldap_A  
dscontrol server add 10.10.110.3:636: srv_ldap_B collocated yes 
dscontrol advisor start ldap 10.10.110.3:636 
dscontrol advisor loglevel ldap 10.10.110.3:636 4 
dscontrol advisor interval ldap 10.10.110.3:636 15 
dscontrol advisor retry ldap 10.10.110.3:636 2 
dscontrol advisor timeout ldap 10.10.110.3:636 10

	•	Commande de vérification :
# dscontrol manager report 10.10.110.3 
---------------------------------------------------------------- 
|       SERVER  |    IP ADDRESS  |   STATUS   | 
---------------------------------------------------------------- 
| srv_ldap_A    |   10.10.110.10 |     ACTIVE | 
| srv_ldap_B    |  10.10.110.11  |     ACTIVE | 
---------------------------------------------------------------- 
----------------------------- 
|   MANAGER REPORT LEGEND   | 
----------------------------- 
| ACTV | Active Connections | 
| NEWC | New Connections    | 
| SYS  | System Metric      | 
| NOW  | Current Weight     | 
| NEW  | New Weight         | 
| CONN | Connections        | 
----------------------------- 
---------------------------------------------------------------- 
|     clusterldap    |        |        |        |        |      
|   10.10.110.3      | WEIGHT |  ACTV  |  NEWC  |  PORT  |   SYS 
|     PORT:   636    |NOW  NEW|   50%  |   50%  |    0%  |    0% 
|--------------------------------------------------------------- 
|srv_ldap_A          | 12  12 |      2 |      0 |    230 |      | 
|srv_ldap_A          |  7  7  |      6 |      0 |     97 |      0 
---------------------------------------------------------------- 
--------------------------------------------------- 
|    ADVISOR    |    CLUSTER:PORT     |  TIMEOUT  | 
--------------------------------------------------- 
|          ldap |     10.10.110.3:636 |        10 | 
--------------------------------------------------- 
 
Les paramètres "ACTV, NEWC, PORT et SYS" sont utilisés pour calculer 
les "poids" rapportés par les advisors. 
Plus un poids est élevé, plus il est utilisé. 
Si un paramètre est mis à -1 (= indisponibilité), alors son  
"poids"=0 et donc pas utilisé.
4. Un service d’annuaire local avec délégation  d’authentification (PTA)
Un autre cas de figure peut aussi se présenter lorsque l’annuaire LDAP doit déléguer la validation des mots de passe de certains utilisateurs à un annuaire Microsoft Active Directory. Ce mécanisme se nomme alors PTA pour Pass Through Authentication.
La figure 3-25 illustre un service d’annuaire permettant à une entité (ou une équipe) au sein d’une grande organisation de déployer son propre annuaire afin d’en être totalement autonome. Néanmoins, en vue de conserver l’unicité du mot de passe de chaque utilisateur contenu dans l’annuaire, ce dernier contactera l’annuaire central de l’entreprise lors de la phase d’authentification de l’utilisateur au client LDAP.
¬
Figure 3-25 : Service d’annuaire local avec délégation d’authentification
Ainsi cette figure montre un utilisateur A qui se connecte avec son couple d’identifiants "nom utilisateur/mot de passe" depuis un client LDAP. Son mot de passe est transmis au serveur LDAP qui vérifiera l’existence du compte utilisateur et contrôlera la validité du mot de passe. Dans le cas présent, le serveur LDAP contient des utilisateurs dont les mots de passe sont soit stockés localement, soit font référence à un autre annuaire LDAP de type Active Directory.
Il apparaît que le mot de passe de l’utilisateur A est stocké sur le serveur Active Directory. Du coup, le serveur LDAP va communiquer le mot de passe au serveur Active Directory et attendre sa réponse. Si la réponse est positive, alors le serveur LDAP autorisera l’utilisateur A à s’authentifier sur le client LDAP ; dans le cas contraire, l’utilisateur ne sera pas autorisé à s’authentifier sur le système ciblé.
¬
Si le serveur LDAP s’accorde à conserver le même identifiant ("username" ou "uid") de l’utilisateur que celui se trouvant sur l’annuaire central de l’entreprise, alors l’utilisateur aura l’impression de détenir un identifiant unique (SUL) pour se connecter à l’ensemble des ressources informatiques de l’entreprise. C’est donc un confort considérable pour l’utilisateur qui ne devra se soucier que d’un seul mot de passe, mais aussi pour l’administrateur informatique qui n’appliquera qu’une seule et même politique de mot de passe à partir d’un seul système informatique... en revanche, la politique de gestion des comptes sera toujours à la charge du système contenant... les comptes... logique  !