14.8 Utilisation du serveur LDAP pour effectuer des recherches dans l'annuaire

Toujours chaîner

L'option Toujours chaîner est une option indiquant qu'aucun renvoi ne sera jamais effectué. Si vous sélectionnez cette option, le serveur LDAP eDirectory ne retourne jamais les renvois à d'autres serveurs eDirectory de l'arborescence eDirectory. Le serveur LDAP effectue une vérification auprès des autres serveurs LDAP pour le compte du client demandeur et transmet le renvoi à celui-ci.

L'option Toujours chaîner s'avère très utile si eDirectory est déployé dans une arborescence fédérée globale sous la forme de serveurs subordonnés.

Ces options de renvoi s'appliquent uniquement à la méthode de gestion des renvois dans l'arborescence eDirectory. Elles n'ont aucun effet sur le comportement des renvois sur les serveurs non-eDirectory.

La raison du blocage des renvois sur d'autres serveurs eDirectory est subtile, mais peut s'avérer précieuse. Si les données non expertes d'un serveur eDirectory 8.7 ou ultérieur sont répliquées sur un autre serveur eDirectory, plus ancien, un renvoi au serveur plus ancien risque de fournir à une application client une vue déformée de l'arborescence globale.

Par exemple, imaginons qu'un client LDAP mette en cache les renvois vers les serveurs LDAP et envoie des requêtes au dernier serveur avec lequel il a communiqué. Si le client est configuré pour envoyer des requêtes à un serveur eDirectory prenant en charge des renvois supérieurs, la vue de l'arborescence globale doit être normale pour ce client.

Toutefois, les serveurs LDAP antérieurs à eDirectory 8.7 ne comprennent pas les zones non expertes et les renvois supérieurs. Par conséquent, si le client fait suivre un renvoi vers un serveur équipé d'une version plus ancienne d'eDirectory dans l'arborescence eDirectory et continue à envoyer des requêtes à ce serveur plus ancien, le serveur ayant la version plus ancienne de LDAP présentera les données non expertes comme s'il s'agissait des données réelles de l'arborescence Annuaire.

Un client intelligent doit, cependant, interroger l'attribut supportedFeatures de RootDSE pour vérifier si le serveur prend ou non en charge les renvois supérieurs.

Préférer le chaînage

L'option Préférer le chaînage indique que les résultats de recherche ne comprennent généralement pas de renvois. Au lieu de cela, le serveur LDAP fait progresser l'opération de recherche sur l'ensemble des DSA eDirectory pour la compléter.

L'exception à cela est une opération de recherche accompagnée du contrôle de recherche persistant. Dans ce cas, étant donné que la mise en oeuvre NetIQ de la recherche persistante ne prend pas en charge le chaînage, les renvois sont envoyés si l'étendue de la recherche ne reste pas totalement locale.

Le serveur LDAP reçoit une opération de recherche. Si l'entrée de l'arborescence n'est pas stockée localement, le serveur effectue automatiquement un chaînage vers les autres serveurs. Une fois l'entrée localisée, le serveur LDAP joue le rôle de proxy pour le client LDAP. En utilisant la même identité que celle à laquelle le client LDAP est lié, le serveur LDAP s'authentifie auprès du serveur distant et continue l'opération de recherche sur celui-ci.

Le serveur LDAP qui a reçu la demande de recherche initiale envoie au client LDAP l'ensemble des entrées de recherche et le résultat. Comme le serveur LDAP se charge intégralement de la demande, le client LDAP ne sait pas que d'autres serveurs étaient impliqués.

Grâce au chaînage d'eDirectory, un serveur LDAP qui contient peu d'informations peut sembler contenir les données de la totalité de l'arborescence.

L'option Préférer le chaînage est importante en ce qui concerne les partitions.

Un client LDAP lance une recherche. DAir43 recherche l'entrée localement mais ne trouve qu'une partie des données. DAir43 effectue automatiquement un chaînage vers DigitalAir44, qui contient l'entrée nécessaire. DAir44 envoie les données à DAir43, et ce dernier envoie l'entrée au client LDAP.

Avec l'option Préférer le chaînage, le serveur LDAP effectue un chaînage vers d'autres serveurs pour traiter les requêtes de recherche (le cas échéant), sauf si l'opération est une recherche persistante. Pour plus d'informations sur la recherche persistante, reportez-vous à la Section 14.10, Recherche persistante : configuration d'événements eDirectory.

Préférer les renvois

L'option Préférer les renvois indique que les opérations de recherche doivent retourner des renvois à d'autres serveurs eDirectory de l'arborescence le cas échéant. Des renvois sont émis seulement si le serveur local peut assurer que le serveur qui contient les données est opérationnel et que le service LDAP est exécuté. Dans le cas contraire, l'opération est chaînée à un autre serveur ou échoue si cet autre serveur est inutilisable.

Vous disposez de deux partitions et vous exécutez une recherche de sous-arborescence. Vous en arrivez à un stade où les entrées recherchées ne figurent plus sur le serveur local. La recherche doit donc porter sur un autre serveur. Si le serveur qui contient la réplique de ces données (de cette partition) exécute aussi le fichier nldap.nlm, le serveur LDAP crée un renvoi LDAP et le retourne au client LDAP.

Si le serveur contenant la réplique n'exécute pas nldap.nlm, le serveur LDAP chaîne la requête vers l'autre serveur, terminant ainsi la recherche.

Lorsque nldap.nlm démarre, le serveur LDAP indique à eDirectory que le serveur LDAP est un point de renvoi. Si un client a reçu des renvois mais que ceux-ci cessent, le serveur LDAP n'est pas en service.

Toujours référer

L'option Toujours référer suit la même logique que Préférer les renvois, sauf que le renvoi par défaut est envoyé dans différentes situations de reprise après échec (par exemple si l'objet est introuvable ou si le serveur est en panne).

Si un autre serveur contenant le reste des données n'exécute pas le service LDAP, le premier serveur LDAP ne chaîne alors pas la requête au deuxième.

Si vous activez l'option Toujours référer, vous êtes autorisé à saisir un renvoi par défaut. Le champ Renvoi par défaut est utile pour associer deux serveurs LDAP de fournisseurs différents et constituer votre propre arborescence Annuaire.

Incapable de résoudre le DN de base, le serveur LDAP envoie au client la chaîne qui figure dans le champ Renvoi par défaut. Le renvoi indique au client LDAP de rechercher à l'endroit indiqué dans l'URL. Le client LDAP contacte le serveur iPlanet, qui exécute la recherche.

Si un renvoi par défaut est configuré et si le serveur ne trouve pas le DN de base recherché, le client reçoit ce renvoi par défaut.

Le renvoi présente le format d'une URL LDAP (par exemple, LDAP://123.23.45.6:389.

Lorsque le serveur LDAP transmet un renvoi par défaut à un client (parce que le DN de base est indisponible), il ajoute une barre oblique (/) et le DN recherché par le client. Le renvoi par défaut et les informations ajoutées sont transmis au client. Le client envoie la requête de recherche au serveur spécifié dans le renvoi par défaut.

L'objet Groupe LDAP comporte un champ de chaîne destiné au renvoi par défaut. Le serveur LDAP traite ces données comme une chaîne. Aucune validation n'a lieu. Tout ce qui est saisi est inséré au début du renvoi. Certaines données sont ajoutées à la fin de celui-ci. Le serveur LDAP s'attend à recevoir une chaîne semblable à une URL.

Lorsqu'ils reçoivent des renvois désignant d'autres serveurs eDirectory qui exécutent LDAP, les clients obtiennent deux renvois par serveur.

Pour faire la différence entre les deux renvois, le renvoi en texte clair commence par ldap:// et le port sécurisé par ldaps://.

En cas de renvoi provenant du serveur, le numéro de port est ajouté.

Filtrage de renvois

Si plusieurs serveurs de répliques sont en cours d'exécution dans une arborescence et que vous avez configuré les serveurs LDAP pour qu'ils retournent des renvois à l'aide de l'option Préférer les renvois/Toujours renvoyer, les serveurs LDAP retourneront des renvois si l'objet identifié par le DN dans l'opération demandée n'est pas présent localement. Dans ce cas, le client LDAP envoie une requête au serveur qui lui-même envoie une liste de renvoi de tous les serveurs LDAP contenant cet objet. À l'aide de cette liste de renvoi, les clients LDAP suivront l'un de ces renvois pour effectuer l'opération. Si le client choisit de suivre le renvoi vers un serveur en manque de ressources ou vers un serveur situé sur une liaison lente, il constatera une réponse lente de la part du serveur. Cette lenteur affecte les performances du client LDAP. Étant donné que les développeurs d'applications LDAP n'ont pas de connaissances complètes des serveurs et des configurations réseau, la solution à ce problème consiste à proposer un mécanisme de filtrage des renvois au niveau du serveur LDAP pour retourner les renvois de serveurs spécifiques. Les administrateurs disposeraient des connaissances nécessaires, par exemple, la nature des serveurs LDAP dans le réseau et les vitesses de liaison réseau pour effectuer la configuration appropriée du filtrage des renvois.

Définissez le filtre de renvoi sur l'objet Groupe LDAP à l'aide des attributs « referralIncludeFilter » et « referralExcludeFilter ». La configuration de ces filtres dans ces attributs sera applicable à tous les serveurs LDAP qui appartiennent à cet objet Groupe LDAP. Le serveur LDAP retournera tous les renvois LDAP correspondant au filtre referralIncludeList et omettra ceux qui correspondent au filtre referralExcludeFilter.

Si seul le filtre referralIncludeFilter est spécifié, les renvois LDAP correspondant aux valeurs referralIncludeFilter vont seront retournés aux clients LDAP, et tous les autres renvois seront exclus de la liste de renvoi. De même, si seul le filtre referralExcludeFilter est spécifié, les renvois LDAP qui ne correspondent pas aux valeurs referralExcludeFilter seront retournés aux clients LDAP. Si les deux filtres sont spécifiés et que le renvoi ne correspond pas à aucun d'eux, il sera exclu.

Si tous les renvois disponibles sont refusés par le filtre, le serveur se comporte comme si aucun renvoi n'est disponible et retourne LDAP_OTHER (80), que certains outils client rapportent comme une « Erreur inconnue ». Après avoir ajouté ou modifié ces attributs de filtre, si le serveur LDAP n'est pas rafraîchi, les modifications seront appliquées après le rafraîchissement automatique suivant.

Actuellement, l'ajout ou la modification de ces attributs de filtre n'est possible qu'avec l'onglet disponible dans iManager.

[ldap://] | [ldaps://] Adresse_IP[:port]

Dans ce cas, spécifier le port en texte clair ou le port TLS aura le même effet que d'ajouter ldap:// ou ldaps:// au début. Si vous ne spécifiez ni ldap ni ldaps, le filtre de correspondance est applicable aux renvois tant en texte clair que TLS.

Exemples :

Les attributs de filtre (referralIncludeFilter et referralExcludeFilter) sont à plusieurs valeurs. Vous pouvez choisir autant de filtres de correspondance que nécessaire.

Exemples de scénarios

« .2.3.4 » ou « *.2.3.4 » ne renvoie pas les adresses IP X.2.3.4.

« 2.3.4* » ne renvoie pas les adresses IP, telles que 2.3.41 ou 2.3.42.

Les noms DNS comme sever1.mydomain.com, ou *.mydomain.com ne sont pas pris en charge. L'ajout de la plage de ports aux filtres de type Autoriser l'adresse IP de renvoi sur le port start-to-end n'est pas pris en charge. Aucun contrôle de validation n'est effectué avant d'ajouter ces valeurs de filtre à ces attributs. Toutefois, dans le cas d'un filtre non valide, le serveur LDAP ignorera ces filtres et consignera les informations dans le fichier ndsd.log.