13.1 Termes clés des services LDAP

13.1.1 Clients et serveurs

Client LDAP— Application (par exemple, Internet Explorer ou l'utilitaire d'importation/conversion/exportation NetIQ).

Serveur LDAP— Serveur sur lequel nldap.dlm (pour Windows) ou libnldap.so (pour Linux) est en cours d'exécution.

13.1.2 Objets

Objet Groupe LDAP— Définit et gère les propriétés LDAP NetIQ sur un serveur LDAP.

Cet objet est créé lors de l'installation d'eDirectory. L'objet Groupe LDAP contient des informations de configuration pouvant être partagées par plusieurs serveurs LDAP.

Objet Serveur LDAP— Définit et gère l'accès des clients LDAP aux informations figurant sur un serveur LDAP NetIQ et l'utilisation qu'ils en font.

Cet objet est créé lors de l'installation d'eDirectory. L'objet Serveur LDAP représente des données de configuration propres au serveur.

La figure ci-après montre un objet Serveur LDAP dans NetIQ iManager.

Objet Serveur LDAP

13.1.3 Références

Référence— Message que le serveur LDAP envoie au client LDAP pour lui indiquer qu'il ne peut pas fournir de résultats complets et que d'autres données se trouvent peut-être sur un autre serveur LDAP.

Le renvoi contient toutes les informations nécessaires à la poursuite de l'opération.

Scénario : un client LDAP envoie une requête à un serveur LDAP, mais celui-ci ne trouve pas l'entrée cible localement. Grâce aux références de connaissances qu'il possède sur les partitions et les autres serveurs, le serveur LDAP identifie un autre serveur possédant plus d'informations sur l'entrée. Le serveur LDAP envoie ces informations au client.

Le client établit alors une nouvelle connexion LDAP avec le serveur identifié et tente à nouveau l'opération.

Les renvois présentent les avantages suivants :

  • Le client LDAP conserve le contrôle de l'opération.

    Le client ayant toujours connaissance des opérations, il prend de meilleures décisions et transmet des commentaires à l'utilisateur. Le client peut également décider de ne pas suivre le renvoi ou de signaler à l'utilisateur qu'il s'apprête à le suivre.

  • En général, les renvois permettent d'utiliser les ressources réseau plus efficacement que le chaînage.

    Le chaînage permet de transmettre deux fois une recherche à plusieurs entrées via le réseau. La première transmission passe du serveur qui détient les données à celui qui effectue le chaînage. La seconde passe du serveur qui effectue le chaînage au client.

    Le renvoi permet au client d'obtenir les données directement en provenance du serveur qui les détient, en une seule transmission.

  • Lorsqu'un client connaît l'emplacement de stockage d'une entrée, il peut aller directement sur le serveur qui détient les données.

    Le chaînage masque les détails au client. S'il ignore la provenance des données, le client n'ira probablement pas sur le serveur qui les détient.

Les renvois présentent les inconvénients suivants :

  • Le client doit savoir reconnaître et suivre les renvois.

  • Les clients LDAPv2 ne savent pas reconnaître les renvois ou utilisent une méthode obsolète et non standard pour les détecter.

  • Chaque partition eDirectory doit être gérée par un serveur LDAP.

    Sinon, aucun renvoi n'est transmis pour les données de cette partition.

Renvoi supérieur— Renvoi vers un serveur qui détient des données à un niveau de l'arborescence supérieur à celui du serveur avec lequel il communique. Reportez-vous à la Section 14.9, Configuration des renvois supérieurs.

Les renvois supérieurs traitent les requêtes concernant des objets situés dans une partition non-eDirectory de niveau supérieur ou contiguë dans une arborescence multifournisseur.

Pour qu'un serveur eDirectory puisse participer à ce type d'arborescence, eDirectory classe les données hiérarchiques au-dessus de lui dans une partition marquée comme « non experte ». Les objets de la zone non experte sont uniquement les entrées nécessaires à la construction de la hiérarchie DN appropriée. Ces entrées sont analogues aux entrées d'association X.500.

eDirectory permet de placer dans la zone non experte des informations de connaissance sous la forme de données de renvoi LDAP. Ces informations servent à envoyer des renvois au client LDAP.

Lorsqu'une opération LDAP est effectuée dans une zone non experte de l'arborescence eDirectory, le serveur LDAP recherche les données de référence correspondantes et transmet un renvoi au client.

chaînage— Protocole de résolution de nom basé sur un serveur.

Un client LDAP envoie une requête à un serveur LDAP, mais celui-ci ne trouve pas l'entrée cible localement. Grâce aux références de connaissances qu'il possède sur les partitions et sur d'autres serveurs de l'arborescence eDirectory, le serveur LDAP identifie un autre serveur LDAP possédant plus d'informations sur le DN. Le premier serveur LDAP contacte le serveur LDAP identifié (second).

Au besoin, ce processus se poursuit jusqu'à ce que le premier serveur en contacte un autre qui dispose d'une réplique de l'entrée. eDirectory gère alors tous les détails pour terminer l'opération. Ne connaissant pas les opérations serveur à serveur, le client suppose que le premier serveur a terminé la requête.

Sur un serveur LDAP, le chaînage présente les avantages suivants :

  • Il masque tous les détails de résolution de nom au client.

  • Il effectue automatiquement une nouvelle authentification.

  • Il joue le rôle de proxy pour le client.

  • Il fonctionne de manière transparente, même lorsque des serveurs de l'arborescence eDirectory ne prennent pas en charge les services LDAP.

Le chaînage présente les inconvénients suivants :

  • Il est possible que la transmission des commentaires du serveur au client prenne du temps, pendant que le serveur effectue un chaînage pour résoudre le nom.

  • Si l'opération requiert que le serveur LDAP envoie de nombreuses entrées via une liaison WAN, elle peut même s'avérer très longue.

  • Si plusieurs serveurs sont capables d'effectuer l'opération, des serveurs distincts peuvent traiter deux requêtes pour gérer la même entrée.

    eDirectory essaie de classer les serveurs en fonction du coût encouru pour les contacter. Pour l'équilibrage des charges, eDirectory sélectionne de façon aléatoire un serveur à faible coût.