Utilisation du serveur LDAP pour effectuer des recherches dans l'annuaire
Cette section fournit les informations suivantes :
Définition de limites de recherche
Les attributs suivants de l'objet Serveur LDAP contrôlent la méthode de recherche du serveur LDAP dans l'annuaire :
- Limite d'entrées de recherche
Cette option limite la taille d'une recherche. La valeur par défaut est 0, indiquant qu'il n'y a pas de limite de taille. Afin d'éviter de surcharger le serveur LDAP, vous pouvez limiter le nombre d'entrées que le serveur LDAP renvoie lors d'une requête.
Scénario : limitation de la taille d'une recherche---Henri lance une recherche qui peut renvoyer des milliers de réponses liées aux objets trouvés. Toutefois, vous avez défini une limite de dix résultats. Le serveur LDAP interrompt la recherche après avoir renvoyé dix résultats. Un message système informe Henri que la recherche a été arrêtée bien que d'autres données soient disponibles.
- Limite de temps de recherche
Limite la durée de recherche du serveur. La valeur par défaut est 0, indiquant qu'il n'y a pas de limite de temps.
La figure suivante illustre ces attributs dans Novell iManager.
-
Dans Novell iManager, cliquez sur le bouton Rôles et tâches
. -
Cliquez sur LDAP > Présentation LDAP > Afficher les serveurs LDAP.
-
Cliquez sur Objet Serveur LDAP > Recherches.
-
Faites défiler jusqu'à atteindre la section Restrictions, entrez des valeurs, puis cliquez sur OK.
Le client peut également définir des limites de temps pour les requêtes (par exemple, limiter la recherche à deux secondes). En cas de conflit entre la limite définie par le client et celle du serveur LDAP, ce dernier emploie la valeur la plus faible.
La recherche repose sur des ACL (Access Control Lists). De ce fait, une recherche anonyme peut renvoyer simplement quelques entrées, celles que l'utilisateur Public est autorisé à voir, même si l'annuaire en contient des milliers.
Utilisation des renvois
Un renvoi est une méthode qui permet au client de résoudre des noms. Un client LDAP envoie une requête à un serveur LDAP, qui tente de trouver localement l'entrée cible. Si le serveur ne parvient pas à trouver l'entrée cible, il utilise les références de connaissance dont il dispose pour générer un renvoi vers un second serveur qui possède plus d'informations sur l'entrée. Le premier serveur envoie les informations de renvoi au client LDAP.
Le client LDAP établit alors une connexion avec le second serveur LDAP et tente de nouveau l'opération. Si le second serveur LDAP possède l'entrée cible de l'opération, il l'exécute. Sinon, il transmet également un renvoi dans la réponse au client. Ce processus se poursuit jusqu'à ce que l'un des événements suivants se produise :
- Le client contacte un serveur qui possède l'entrée et peut effectuer l'opération voulue.
- Le serveur LDAP renvoie une erreur indiquant que l'entrée n'existe pas.
- Le serveur LDAP indique que plus aucun renvoi ne peut être suivi.
Une nouvelle fonctionnalité de LDAP pour eDirectory 8.7 occasionne un comportement légèrement différent des renvois par rapport aux anciennes versions de eDirectory et NDS. Ce changement de comportement influe sur la manière dont vous configurez les services LDAP.
Renvois par défaut
Généralement, une URL de renvoi par défaut contient une URL LDAP pointant vers un serveur qui contient la racine de l'arborescence. Une URL LDAP a la syntaxe suivante : ldap://hôte:port.
Entrez un renvoi par défaut dans le champ URL de renvoi par défaut :
Au départ, le serveur LDAP eDirectory envoyait le renvoi par défaut dans un certain nombre de situations de reprise après échec. De nombreux utilisateurs estimaient ce comportement étrange et parfois imprévisible. Les services LDAP pour eDirectory 8.8 vous permettent de contrôler le moment du renvoi par défaut pour n'importe quel type de renvoi subordonné.
La nouvelle option est une valeur (paramètre) qui réside dans l'attribut ldapDefaultReferralBehavior sur le serveur LDAP et les objets Groupe LDAP. Il s'agit d'un nombre entier qui est un masque binaire des bits ci-dessous.
Si pour l'opération, le serveur LDAP est configuré pour Toujours référer et si l'une des conditions indiquées est respectée et que la valeur correspondante est définie, le renvoi par défaut est exécuté.
Définition de renvois pour les opérations de recherche
Une fonctionnalité interagissant avec LDAP pour eDirectory 8.7 entraîne une légère modification du comportement des renvois par rapport aux anciennes versions de eDirectory et NDS. Ce changement de comportement influe sur la manière dont vous configurez les services LDAP.
Vous pouvez configurer le serveur LDAP eDirectory pour qu'il transmette les renvois à d'autres serveurs eDirectory de l'arborescence. Par défaut, le serveur LDAP chaîne toutes les opérations vers d'autres serveurs eDirectory pour le compte de l'utilisateur et aucun renvoi n'est jamais retourné.
Avant eDirectory 8.7, les options de renvoi n'existaient que comme paramètres de l'objet Groupe LDAP. Avec eDirectory 8.8, elles existent également pour l'objet Serveur LDAP. Tout paramètre de l'objet Serveur LDAP est prioritaire sur ceux de l'objet Groupe LDAP.
L'attribut ldapSearchReferralOption vous permet de définir l'option de renvoi. Dans les versions antérieures des services LDAP pour eDirectory 8.7, cet attribut pouvait être défini à l'aide des options suivantes :
- Préférer le chaînage (option par défaut)
- Prefer Referrals (Préférer les renvois)
- Toujours référer
Ces options de renvoi s'appliquent uniquement à la référence et au chaînage à d'autres serveurs eDirectory de l'arborescence eDirectory. Ces paramètres de configuration ne contrôlent pas les renvois provenant d'une partition non experte. Ainsi, même si vous sélectionnez une option (par exemple Toujours chaîner) dans la liste déroulante Options de renvois, les renvois parviendront toujours aux autres serveurs depuis des partitions non expertes.
Pour prendre en charge les renvois supérieurs vers des DSA non-eDirectory, les services LDAP pour eDirectory 8.7.a disposent d'une option Toujours chaîner. Pour plus de détails, reportez-vous à la section Toujours chaîner.
La figure ci-dessous illustre les listes déroulantes de renvoi LDAP destinées aux recherches et aux autres opérations.
Les « autres » opérations eDirectory incluent des renvois pour les opérations d'ajout, de suppression, de modification et de liaison.
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 les renvois supérieurs, l'arborescence globale devrait s'afficher normalement pour ce client.
Toutefois, les serveurs LDAP antérieurs à eDirectory 8.7 ne prennent pas en charge 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 de 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.
En revanche, les opérations de recherche accompagnées du contrôle de recherche persistante constituent une exception. Dans ce cas, comme la mise en oeuvre Novell de la recherche persistante ne prend pas en charge le chaînage, les renvois sont transmis 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 de 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.
Scénario : recherche d'informations dans une autre partition---Dans la société Digital Airlines, Luc sélectionne l'option Préférer le chaînage pour le serveur LDAP DAir43. DAir43 se trouve dans la partition A. La partition B est une sous-partition de A et contient le serveur LDAP DAir44.
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 Recherche persistante : configuration en fonction des événements eDirectory.
Prefer Referrals (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, si ce n'est 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 hors service).
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.
Scénario : utilisation d'un serveur par défaut---Vous disposez d'une arborescence LDAP. Une partie de cette arborescence est gérée par eDirectory. Une partition subordonnée est gérée par iPlanet. Dans le champ Renvoi par défaut, vous placez une URL renvoyant au serveur iPlanet. Un client LDAP lance une recherche.
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 que le serveur ne trouve pas le DN de base recherché, le client reçoit ce renvoi par défaut.
Le renvoi présente la forme 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.
- un renvoi qui dirige le client vers le port en texte clair ;
- un renvoi qui dirige le client vers le port sécurisé.
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é.
Définition de renvois pour d'autres opérations
Le paramétrage initial de l'option de renvoi ne s'appliquait qu'à l'opération de recherche. Pour fournir à d'autres opérations une option comparable, l'attribut ldapOtherReferralOption est utilisé. Cet attribut autorise les mêmes valeurs et contrôle le comportement des opérations qui ne comprennent pas de recherche (à l'exception de la liaison, qui n'émet jamais de renvois).
Pas de prise en charge de la gestion de DSA IT
Dans les services LDAP pour eDirectory 8.8, les relations distribuées entre les serveurs eDirectory d'une arborescence eDirectory sont gérées par d'autres moyens que la commande Gérer DSA IT. La commande Gérer DSA IT n'autorise pas le client LDAP à interroger ou à mettre à jour les références eDirectory subordonnées ou croisées.
Fonctionnalité non prise en charge
Les services LDAP pour eDirectory 8.8 ne prennent pas en charge les références subordonnées. Il n'est pas possible de créer de façon fiable une partition non experte qui soit subordonnée à une partition experte et de lui faire émettre des renvois. Si optez pour ce cas de figure, les renvois ne sont transmis que lors de la résolution du DN de base pour une opération. Les références SearchResultReferences ne sont pas envoyées.
Il n'existe aucune prise en charge des mises à jour distribuées de données dans la zone non experte. Si un changement de nom se produit sur le serveur racine, il n'existe aucun mécanisme intégré permettant de copier cette modification sur le serveur eDirectory qui contient les mêmes données dans une zone non experte.
Recherche de répliques filtrées
Un filtre limite la quantité de données que contient la réplique. De ce fait, une réplique filtrée n'affiche pas l'ensemble des données réelles contenues dans l'annuaire. Voici quelques exemples de filtres appliqués à une réplique :
- La réplique contient uniquement des objets Utilisateur.
- La réplique contient tous les objets Utilisateur, mais ces derniers ne contiennent que des numéros de téléphone et des adresses d'expédition.
Comme les données d'une réplique filtrée sont incomplètes, une recherche LDAP peut donner lieu à des résultats tronqués. Par conséquent, une requête de recherche LDAP n'examine pas, par défaut, les répliques filtrées.
Lorsque vous effectuez une recherche dans les répliques filtrées, celle-ci peut ne pas retourner les résultats par filtre de réplique dans les cas suivants :
- Si les objets correspondant au filtre de recherche ne sont pas présents sur le serveur de répliques filtrées locales, les résultats peuvent ne pas correspondre au filtre de la réplique locale, dans la mesure où les résultats peuvent être trouvés par un serveur de répliques complètes.
- Lorsque la base de recherche ne se trouve pas en local sur le serveur de répliques filtrées, les objets correspondant au filtre de recherche peuvent être obtenus sur un serveur de répliques complètes, mais peuvent ne pas correspondre au filtre de la réplique locale.
Vous pouvez cependant configurer un serveur LDAP pour rechercher dans les répliques filtrées si vous êtes certain que ces dernières contiennent les données dont vous avez besoin.
