[AIX Solaris HP-UX Linux Windows][z/OS]

Protocole LDAP (Lightweight Directory Access Protocol)

La présente section répond aux questions qui traitent de LDAP (Lightweight Directory Access Protocol) et de son fonctionnement et propose une présentation de haut niveau à propos de X.500 et LDAP.

LDAP est un protocole classique qui fournit un moyen de stocker et d'extraire des informations sur des personnes, des groupes ou des objets sur un serveur d'annuaire X.500 ou LDAP centralisé. X.500 permet l'organisation et l'interrogation de ces informations, à l'aide de LDAP, à partir de plusieurs serveurs Web utilisant différents attributs. Les requêtes LDAP peuvent être simples ou complexes selon le besoin afin d'identifier une entité individuelle ou un groupe d'entités désiré. LDAP réduit les ressources système requises en ajoutant uniquement un sous-ensemble fonctionnel du X.500 Directory Access Protocol (DAP) original.

Le module LDAP d'IBM® HTTP Server permet l'utilisation d'un serveur d'annuaire X.500 pour des besoins d'authentification et d'autorisation. IBM HTTP Server peut utiliser cette fonction pour limiter l'accès d'une ressource à un ensemble d'utilisateurs défini. Cette capacité réduit les coûts administratifs généralement requis pour gérer les informations de groupe et d'utilisateur pour chaque serveur Web.

Vous pouvez configurer le module LDAP d'IBM HTTP Server afin d'utiliser des connexions SSL ou TCP/IP au serveur d'annuaire X.500. Le module LDAP peut être configuré pour référencer un seul ou plusieurs serveurs LDAP.

Présentation de X.500. X.500 fournit un service d'annuaire doté de composants capables d'extraction plus efficace. LDAP utilise deux des composants suivants : le modèle d'information, qui détermine la forme et le caractère et l'espace de nom, qui permet l'indexation et la référence de l'information.

La structure de répertoire X.500 se distingue des autres répertoires dans le stockage et l'extraction des informations. Ce service d'annuaire associe les informations aux attributs. Une interrogation basée sur les attributs est générée et est transmise au serveur LDAP et le serveur retourne les valeurs respectives. LDAP utilise une approche simple, sous forme de chaîne, pour représenter les entrées de répertoire.

Un annuaire X.500 se compose d'entrées saisies basées sur l'attribut ObjectClass. Chaque entrée se compose d'attributs. L'attribut ObjectClass identifie le type d'entrée, par exemple, une personne ou une organisation, qui détermine les attributs requis et facultatifs.

Vous pouvez diviser les entrées, organisées dans une structure arborescente, parmi les serveurs d'une distribution géographique et organisationnelle. Le service d'annuaire attribue un nom distinctif (DN) aux entrées, selon leur position dans la hiérarchie de distribution.

Présentation de Lightweight Directory Access Protocol. L'accès à un annuaire X.500 nécessite Directory Access Protocol (DAP). Cependant, DAP a besoin de grandes quantités de ressources système et de mécanismes de prise en charge afin de gérer la complexité du protocole. LDAP a été introduit pour permettre aux postes de travail d'avoir accès au service d'annuaire X.500.

LDAP, un protocole client-serveur, peut gérer certaines des ressources importantes requises par les clients DAP. Un serveur LDAP ne peut que retourner les résultats ou les erreurs au client, nécessitant peu d'intervention de la part du client. S'il est incapable de répondre à une demande client, un serveur LDAP doit chaîner la demande à un autre serveur X.500. Le serveur doit compléter la demande ou renvoyer une erreur au serveur LDAP, qui, à son tour, transmet l'information au client.

IBM HTTP Server prend en charge les serveurs LDAP suivants :
[8.5.5.0 ou suivante]

Utilisation de ldapsearch pour déboguer les problèmes de configuration LDAP

Certains instances peuvent empêcher le bon fonctionnement de votre configuration LDAP. Exemple :
  • Le nom distinctif n'est pas dans la liste de contrôle d'accès de l'administrateur et ne peut pas effectuer des requêtes LDAP.
  • Le nom distinctif a été verrouillé dans LDAP en raison de nombreuses tentatives de connexion infructueuses.
  • Le mot de passe de nom distinctif a peut-être été modifié.
  • Le serveur LDAP n'autorise peut-être pas les requêtes anonymes.
  • Le filtre par défaut défini dans WebSphere Application Server peut ne pas correspondre à vos paramètres (par example, objectclass=someObjectClass est défini)
  • Le pare-feu n'autorise pas la communication sur le port.
  • LDAP est défini pour l'utilisation d'un port non standard autre que 389.
  • L'ID administrateur LDAP est utilisé pour l'ID serveur, mais l'ID administrateur n'est pas défini en tant qu'utilisateur standard.
Pour ces instances et d'autres qui pourraient empêcher le bon fonctionnement de votre configuration LDAP, vous pouvez déboguer rapidemet le problème à l'aide de ldapsearch. ldapsearch est un utilitaire de ligne de commande similaire à celui que WebSphere Application Server utilise pour interroger le serveur LDAP dans la console d'administration. Exemple :
ldapsearch –h <Host> -p <Port> -b “<BaseDN>” –D <BindDN> -w <Bind Password> “<User Filter>”
où :
Host
Nom d'hôte du serveur LDAP. Le nom d'hôte peut être un nom court, un nom long ou une adresse IP.
Port
Nom du port LDAP par défaut, c'est-à-dire 389.
BaseDN
L'emplacement de début de requêtes dans votre arborescence LDAP.
BindDN
Nom distinctif qualifié complet qui a le droit de se lier à votre serveur LDAP et d'excuter les requêtes demandées. Certains serveurs LDAP autorisent les requêtes anonymes, de sorte qu'aucune liaison de nom distinctif ou de mot de passe de liaison n'est requis
Bind Password
Mot de passe du nom distinctif de liaison.
User Filter
Châîne utilisé pour interroger le serveur LDAP.
Exemple de requêtes ldapsearch :
C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" uid=test
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test
C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(uid=test)(objectclass=ePerson))"
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test
Rubrique de concept    

Dispositions pour les centres de documentation | Commentaires

Dernière mise à jour : October 09, 2014 04:36 AM EDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=ihs-dist&topic=cihs_ldap
Nom du fichier : cihs_ldap.html