13.2 Présentation du fonctionnement de LDAP avec OpenText eDirectory

Cette section fournit les informations suivantes :

13.2.1 Connexion à OpenText eDirectory à partir de LDAP

Tous les clients LDAP se relient (se connectent) à OpenText eDirectory en tant qu'un des types d'utilisateurs suivants :

Utilisateur [Public] (liaison anonyme)
Utilisateur proxy (liaison anonyme d'utilisateur proxy)
Utilisateur NDS ou OpenText eDirectory (liaison d'utilisateur NDS)

Le type de liaison avec lequel l'utilisateur s'authentifie détermine le contenu auquel le client LDAP peut accéder. Les clients LDAP accèdent à un annuaire en créant une requête puis en l'envoyant à l'annuaire. Lorsqu'un client LDAP envoie une requête via les services LDAP pour OpenText eDirectory, OpenText eDirectory traite la requête des seuls attributs pour lesquels le client LDAP dispose de droits d'accès appropriés.

Si le client LDAP fait par exemple porter sa requête sur une valeur d'attribut (nécessitant le droit Lire) mais que l'utilisateur dispose uniquement du droit Comparer sur cet attribut, la requête est rejetée.

Les restrictions standard de connexion et de mot de passe s'appliquent toujours. Elles sont cependant fonction de l'emplacement à partir duquel s'exécute LDAP. Les restrictions de temps et d'adresse sont respectées, mais les restrictions d'adresse dépendent de l'endroit d'où la connexion à OpenText eDirectory a été effectuée ; dans le cas présent, il s'agit du serveur LDAP.

Vous pouvez configurer un timeout pour les connexions en écriture bloquées à partir des clients LDAP à l'aide de la variable d'environnement NDSD_NLDAP_WRITEBLOCK_TIMEOUT. Cette variable définit l'intervalle de temps pendant lequel une connexion entre un client LDAP et un serveur OpenText eDirectory reste ouverte pour que le client puisse lire les données à partir du serveur. Si la connexion est bloquée et que le client LDAP ne parvient pas à lire les données dans le délai spécifié, la connexion est considérée comme non valide, puis fermée. La valeur doit être indiquée en secondes pour cette variable, comme illustré dans l'exemple ci-dessous :

NDSD_NLDAP_WRITEBLOCK_TIMEOUT=<secondes>NDSD_NLDAP_WRITEBLOCK_TIMEOUT=60

La valeur par défaut est de 60 secondes.

REMARQUE :À partir d'OpenText eDirectory 9.2.6, la variable d'environnement NDSD_NLDAP_WRITEBLOCK_TIMEOUT s'applique aux connexions en lecture et en écriture bloquées à partir de clients LDAP. Dans la version précédente, à savoir OpenText eDirectory 9.2.5, cette variable s'appliquait uniquement aux connexions en écriture bloquées.

Connexion en tant qu'utilisateur [Public]

Une liaison anonyme est une connexion qui ne contient ni de nom d'utilisateur ni de mot de passe. Si un client LDAP sans nom ni mot de passe se connecte aux services LDAP pour OpenText eDirectory et que le service n'est pas configuré pour utiliser un utilisateur proxy, l'utilisateur est authentifié auprès d'OpenText eDirectory en tant qu'utilisateur [Public].

L'utilisateur [Public] est un utilisateur OpenText eDirectory non authentifié. Par défaut, l'utilisateur [Public] dispose du droit Parcourir sur les objets de l'arborescence OpenText eDirectory. Le droit Parcourir accordé par défaut à l'utilisateur [Public] permet de naviguer dans les objets OpenText eDirectory, mais verrouille l'accès à la majorité des attributs d'objets.

En règle générale, les droits par défaut [Public] sont trop limités pour la plupart des clients LDAP. Bien que vous puissiez modifier les droits [Public], leur modification confère ces droits à tous les utilisateurs. C'est la raison pour laquelle il est recommandé d'utiliser plutôt une liaison anonyme d'utilisateur proxy. Pour plus d'informations, reportez-vous à la section Connexion en tant qu'utilisateur proxy.

Pour conférer à un utilisateur [Public] un accès aux attributs des objets, vous devez transformer l'utilisateur [Public] en ayant droit du ou des conteneurs concernés, puis lui assigner les droits appropriés sur les objets et les attributs.

Connexion en tant qu'utilisateur proxy

Une liaison anonyme d'utilisateur proxy est une connexion anonyme liée à un nom d'utilisateur OpenText eDirectory. Si un client LDAP se lie anonymement aux services LDAP pour OpenText OpenText eDirectory et que le protocole est configuré pour utiliser un utilisateur proxy, l'utilisateur est authentifié auprès d'OpenText OpenText eDirectory en tant qu'utilisateur proxy. Le nom est alors configuré à la fois dans les services LDAP pour et dans OpenText eDirectory.

En règle générale, la liaison anonyme se fait sur le port 389 dans les services LDAP. Cependant,vous pouvez configurer manuellement d'autres ports lors de l'installation.

Les concepts‑clés des liaisons anonymes d'utilisateur proxy sont les suivants :

Tout accès d'un client LDAP par des liaisons anonymes est assigné par l'objet Utilisateur proxy.
Les clients LDAP ne fournissant pas de mot de passe lors des liaisons anonymes, l'utilisateur proxy doit avoir un mot de passe nul et ne doit avoir aucune restriction de mot de passe (intervalle de changement de mot de passe, par exemple). N'indiquez pas de date d'expiration du mot de passe ou n'autorisez pas l'utilisateur proxy à changer de mot de passe.
Vous pouvez limiter les emplacements depuis lesquels l'utilisateur peut se connecter en définissant des restrictions d'adresse pour l'objet Utilisateur proxy.
L'objet Utilisateur proxy doit être créé dans OpenText eDirectory et des droits sur les objets OpenText eDirectory que vous souhaitez publier doivent lui être assignés. Les droits d'utilisateur par défaut confèrent un accès en lecture à un ensemble limité d'objets et d'attributs. Assignez à l'utilisateur proxy des droits Lire et Rechercher sur tous les objets et attributs de chaque sous-arborescence à laquelle l'accès est nécessaire.
L'objet Utilisateur proxy doit être activé dans la page Général de l'objet Groupe LDAP qui configure les services LDAP pour OpenText eDirectory. C'est pourquoi il n'existe qu'un objet Utilisateur proxy pour tous les serveurs d'un groupe LDAP. Pour plus d'informations, reportez-vous à la section Configuration des objets LDAP.
Vous pouvez accorder à un utilisateur proxy des droits d'objet sur toutes les propriétés (par défaut) ou sur des propriétés spécifiques.

Pour accorder à l'utilisateur proxy des droits sur les propriétés sélectionnées :

Sur la page d'accueil d'OpenText Identity Console, cliquez sur la vignette Gestion des droits.
Cliquez sur Ayant droit.
Servez-vous de la fonction Rechercher un objetpour trouver l'objet dont vous souhaitez consulter la liste d'ayants droit ou saisissez directement son nom, puis cliquez sur OK.

La liste des ayants droit assignés à l'objet sélectionné s'affiche.

Cliquez sur Ajouter un ayant droit pour assigner un nouvel ayant droit à l'objet. Sélectionnez un ayant droit dans la liste, cliquez sur pour le supprimer de l'assignation.
Sélectionnez un ayant droit dont les informations doivent être modifiées si nécessaire, puis cliquez sur Droits assignés.
Sur l'écran Modifier l'ayant droit, assignez les droits nécessaires, puis cliquez sur Terminé.
Sur l'écran Modifier l'ayant droit, cliquez sur Ajouter une propriété, puis cochez la case Afficher toutes les propriétés dans le schéma.
Sélectionnez un droit héritable pour l'utilisateur proxy et assignez les droits si nécessaire.

Pour ajouter d'autres droits héritables, répétez les étapes 6 et 7.

Sélectionnez un nom de propriété dans la liste et cliquez sur pour le supprimer de l'assignation.
Cliquez sur Terminé, puis sur Appliquer.

Le message « Ressource modifiée avec succès ! » s'affiche.

Pour implémenter les liaisons anonymes d'utilisateur proxy, vous devez créer l'objet Utilisateur proxy dans OpenText eDirectory et lui assigner les droits appropriés. Assignez à l'utilisateur proxy des droits Lire et Rechercher sur tous les objets et attributs de chaque sous-arborescence à laquelle l'accès est nécessaire. Vous devez également activer l'utilisateur proxy dans les services LDAP pour OpenText eDirectory en spécifiant le même nom d'utilisateur proxy.

Sur la page d'accueil d'OpenText Identity Console, cliquez sur la vignette Configuration LDAP.
Cliquez sur Créer un objet.
Sur la page Créer un objet LDAP, spécifiez le Nom, sélectionnez le Type, puis recherchez le contexte d'un objet Utilisateur eDirectory.
Cliquez sur Créer, puis sur OK.

Utilisation de l'utilitaire ldapconfig sous Linux

Par exemple, vous trouverez des informations sur la manière dont le serveur LDAP traite les renvois LDAP dans Utilisation de renvois lors d'une recherche pour LDAP.

À l'invite du système, entrez la commande suivante :

ldapconfig -s "LDAP:otherReferralUsage=1"
Entrez le nom distinctif complet de l'utilisateur pour eDirectory (FDN utilisateur) et son mot de passe.

Connexion en tant qu'utilisateur NDS ou OpenText eDirectory

Une liaison d'utilisateur OpenText OpenText eDirectory est une connexion établie par un client LDAP à l'aide d'un nom d'utilisateur OpenText eDirectory complet et d'un mot de passe. La liaison d'utilisateur OpenText eDirectory est authentifiée dans OpenText eDirectory et le client LDAP a accès à toutes les informations que l'utilisateur OpenText eDirectory est autorisé à consulter.

Les concepts clés des liaisons d'utilisateur OpenText eDirectory sont les suivants :

Les liaisons d'utilisateur OpenText eDirectory sont authentifiées auprès d'OpenText eDirectory à l'aide du nom d'utilisateur et du mot de passe entrés au niveau du client LDAP.
Le nom d'utilisateur et le mot de passe OpenText OpenText eDirectory utilisés pour l'accès du client LDAP peuvent également être utilisés pour l'accès de Novell Client à OpenText eDirectory.
Lors de connexions non-TLS, le mot de passe OpenText eDirectory est transmis en texte clair entre le client LDAP et les services LDAP pour eDirectory.
Si les mots de passe en texte clair ne sont pas autorisés, toutes les requêtes de liaison OpenText eDirectory comportant un nom d'utilisateur ou un mot de passe sur des connexions non-TLS sont rejetées.
En cas d'expiration du mot de passe d'un utilisateur OpenText eDirectory, les requêtes de liaison OpenText eDirectory de cet utilisateur sont rejetées.

Assignation de droits OpenText eDirectory aux clients LDAP

Déterminez le type de nom d'utilisateur que les clients LDAP vont utiliser pour accéder à OpenText eDirectory :
- Utilisateur [Public] (liaison anonyme)
- Utilisateur proxy (liaison anonyme d'utilisateur proxy)
- Utilisateur NDS (liaison d'utilisateur NDS)
Pour plus d'informations, reportez-vous à la section Connexion à OpenText eDirectory à partir de LDAP.
Lorsque les utilisateurs utilisent un utilisateur proxy ou plusieurs noms d'utilisateur OpenText eDirectory pour accéder à LDAP, utilisez LDAP pour créer ces noms d'utilisateur dans OpenText eDirectory.
Assignez les droits OpenText eDirectory correspondants aux noms d'utilisateur que les clients LDAP vont utiliser.

Les droits par défaut qui sont accordés à la plupart des utilisateurs constituent des droits limités pour l'objet appartenant à l'utilisateur. Pour accorder l'accès à d'autres objets et à leurs attributs, vous devez changer les droits assignés dans OpenText eDirectory.

Lorsqu'un client LDAP demande l'accès à un objet et à un attribut OpenText OpenText eDirectory, OpenText OpenText eDirectory accepte ou refuse cette requête en fonction de l'identité OpenText eDirectory du client LDAP. Cette identité est définie à l'établissement de la liaison.

13.2.2 Assignations de classes et d'attributs

Une classe est un type d'objet dans un annuaire, par exemple un utilisateur, un serveur ou un groupe. Un attribut correspond à un élément d'annuaire qui définit des informations supplémentaires portant sur un objet spécifique. Par exemple, un objet Utilisateur peut avoir pour attribut un nom de famille ou un numéro de téléphone.

Un schéma est un ensemble de règles qui définit les classes et attributs permis dans un répertoire, ainsi que la structure du répertoire (des relations peuvent prévaloir entre les classes). Étant donné que les schémas des annuaires LDAP et OpenText eDirectory sont parfois différents, l'assignation de classes et d'attributs LDAP aux objets et aux attributs OpenText eDirectory correspondants peut s'avérer nécessaire. Ces assignations définissent la conversion des noms du schéma LDAP au schéma OpenText eDirectory.

Les services LDAP pour OpenText eDirectory proposent des assignations par défaut. Dans de nombreux cas, la correspondance entre les classes et attributs LDAP et les types et propriétés d'objets OpenText eDirectory est logique et intuitive. Toutefois, en fonction de vos besoins de mise en œuvre, vous désirerez peut-être reconfigurer l'assignation des classes et attributs.

Dans la plupart des cas, l'assignation d'une classe LDAP à un type d'objet OpenText eDirectory correspond à une relation de type un à un. Cependant, le schéma LDAP prend en charge les noms d'alias, tels que CN, et les noms communs faisant référence à un même attribut.

Assignation des attributs du groupe LDAP

La configuration par défaut des services LDAP pour OpenText eDirectory comprend un ensemble prédéfini d'assignations de classes et d'attributs. Celles-ci assignent un sous-ensemble d'attributs LDAP à un sous-ensemble d'attributs OpenText eDirectory. Si un attribut n'est pas encore assigné dans la configuration par défaut, une assignation auto‑générée est assignée à l'attribut. De même, si le nom de schéma est un nom LDAP valide ne comportant ni espace ni deux points, aucune assignation n'est nécessaire. Passez en revue l'assignation de classe et d'attribut et reconfigurez‑la au besoin.

Sur la page d'accueil d'OpenText Identity Console, cliquez sur la vignette Configuration LDAP.
Cliquez sur Groupe LDAP.
Sur la page Modifier le groupe LDAP, cliquez sur la liste déroulante Assignation d'attribut.
Ajoutez, supprimez ou modifiez les attributs de votre choix.

Étant donné que certains attributs LDAP peuvent disposer de noms de remplacement (comme NC pour nom commun), vous devrez peut-être assigner plusieurs attributs LDAP à un nom d'attribut OpenText eDirectory correspondant. Lorsque les services LDAP pour OpenText eDirectory renvoient les informations sur les attributs LDAP, ils renvoient la valeur du premier attribut correspondant repéré dans la liste.

Si vous assignez plusieurs attributs LDAP à un seul attribut OpenText eDirectory, vous devez réorganiser la liste afin de préciser l'attribut prioritaire, car l'ordre est important.
Cliquez sur Enregistrer.

Assignation de classes dans les groupes LDAP

Lorsqu'un client LDAP demande au serveur LDAP des informations sur les classes LDAP, le serveur renvoie les informations sur les classes OpenText eDirectory correspondantes. La configuration par défaut des services LDAP pour OpenText eDirectory comprend un ensemble prédéfini d'assignations de classes et d'attributs.

REMARQUE :OpenText eDirectory ne propage pas les assignations de classes dans les objets Groupe LDAP sur plusieurs serveurs LDAP. Pour utiliser la même assignation de classes sur plusieurs serveurs, ajoutez manuellement l'assignation à tous les objets Groupe LDAP dans votre environnement.

Sur la page d'accueil d'OpenText Identity Console, cliquez sur la vignette Configuration LDAP.
Cliquez sur Groupe LDAP.
Sur la page Modifier le groupe LDAP, cliquez sur la liste déroulante Assignation de classe.
Ajoutez, supprimez ou modifiez les classes de votre choix.

La configuration par défaut des services LDAP pour OpenText eDirectory comprend un ensemble prédéfini d'assignations de classes et d'attributs. Ces assignations assignent un sous-ensemble de classes et d'attributs LDAP à un sous-ensemble de classes et d'attributs OpenText eDirectory. Si un attribut ou une classe n'est pas encore assigné dans la configuration par défaut, une assignation auto-générée est assignée à l'attribut ou à la classe.

De même, si le nom de schéma est un nom LDAP valide ne comportant ni espace ni deux points, aucune assignation n'est nécessaire. Passez en revue l'assignation de classe et d'attribut et reconfigurez‑la au besoin.
Cliquez sur Enregistrer.

Assignation de classes et d'attributs LDAP

Étant donné que les schémas des annuaires LDAP et OpenText OpenText eDirectory sont différents, l'assignation de classes et d'attributs LDAP aux objets et aux attributs OpenText eDirectory correspondants s'avère nécessaire. Ces assignations définissent la conversion des noms du schéma LDAP au schéma OpenText eDirectory.

Aucune assignation de schéma LDAP n'est requise pour une entrée de schéma si le nom est un nom de schéma LDAP valide. Dans LDAP, les seuls caractères autorisés dans un nom de schéma sont les caractères alphanumériques et les tirets (-). Le nom de schéma LDAP ne doit pas comporter d'espace.

Pour garantir le résultat d'une recherche par ID d'objet après une extension de schéma autre que LDAP, comme pour les fichiers .sch, vous devez rafraîchir la configuration du serveur LDAP si le schéma s'étend en dehors de LDAP.

Assignations de plusieurs éléments à un seul

Pour prendre en charge LDAP depuis OpenText eDirectory, les services LDAP utilisent des assignations au niveau du protocole (plutôt qu'au niveau des services Annuaire) pour effectuer la conversion entre les attributs et les classes LDAP et OpenText eDirectory. C'est pourquoi deux classes ou attributs LDAP peuvent être assignés à la même classe ou au même attribut OpenText eDirectory.

Par exemple, si vous créez un Cn via LDAP, puis recherchez CommonName=Value, vous pouvez obtenir un nom commun susceptible d'avoir la même valeur d'attribut que Cn.

Si vous demandez tous les attributs, vous obtenez le premier attribut de la liste des assignations correspondant à cette classe. Si vous demandez un attribut d'après son nom, vous obtenez le nom correct.

Assignations de plusieurs classes à une seule

Nom de classe LDAP	Nom de classe eDirectory
alias aliasObject	Alias
groupOfNames groupOfUniqueNames group	Groupe
mailGroup rfc822mailgroup	NSCP:mailGroup1

Assignations de plusieurs attributs à un seul

Nom d'attribut LDAP	Nom d'attribut eDirectory
c countryName	C
cn commonName	CN
uid userId	uniqueID
description multiLineDescription	Description
l localityname	L
member uniqueMember	Member
o organizationname	O
ou organizationalUnitName	OU
sn surname	Nom
st stateOrProvinceName	S
certificateRevocationList;binary certificateRevocationList	ndspkiCertificateRevocationList
authorityRevocationList;binary authorityRevocationList	authorityRevocationList
deltaRevocationList;binary deltaRevocationList	deltaRevocationList
cACertificate;binary cACertificate	cACertificate
crossCertificatePair;binary crossCertificatePair	crossCertificatePair
userCertificate;binary userCertificate	userCertificate

REMARQUE :les attributs contenant la valeur ;binary concernent la sécurité. Ils figurent dans la table d'assignation, si votre application a besoin du nom récupéré avec la valeur ;binary. Si vous avez besoin qu'il soit récupéré sans ;binary, vous pouvez modifier l'ordre des assignations.

13.2.3 Différences de syntaxe

Les services LDAP et OpenText eDirectory n'utilisent pas la même syntaxe. Certaines différences importantes sont indiquées ci-dessous :

Virgules

LDAP utilise des virgules comme séparateur et non des points. Exemple de nom distinctif (ou complet) dans OpenText eDirectory :

CN=JANEB.OU=MKTG.O=EMA

Le même nom distinctif avec la syntaxe LDAP :

CN=JANEB,OU=MKTG,O=EMA

Autres exemples de noms distinctifs LDAP :

CN=Bill Williams,OU=PR,O=Bella Notte Corp
CN=Susan Jones,OU=Humanities,O=University College London,C=GB

Noms avec type

OpenText eDirectory utilise aussi bien les noms sans type (.JOHN.MARKETING.ABCCORP) que les noms avec type (CN=JOHN.OU=MARKETING.O=ABCCORP). LDAP utilise uniquement les noms avec type, le séparateur étant une virgule (CN=JEAN,OU=MARKETING,O=ABCSA).

Caractère d'échappement

La barre oblique inverse (\) est utilisée comme caractère d'échappement dans les noms distinctifs LDAP. Si vous utilisez le signe plus (+) ou la virgule (,), vous pouvez utiliser une barre oblique inverse pour changer de code.

Par exemple :

CN=Pralines\+Crème,OU=Saveurs,O=MFG (CN est Pralines+Crème)

CN=DCardinal,O=Lionel\,Thomas et Catherine,C=US (O correspond à Lionel, Thomas et Catherine)

Pour plus d'informations, reportez-vous au fichier RFC 2253 d'IETF (Internet Engineering Task Force).

Attributs de dénomination multiples

Vous pouvez définir des objets en utilisant dans le schéma plusieurs attributs de dénomination. Dans les services LDAP comme dans OpenText eDirectory, l'objet Utilisateur en possède deux : CN et UID. Le signe plus (+) sépare les attributs de dénomination dans le nom distinctif. Si les attributs ne sont pas explicitement libellés, le schéma détermine la chaîne associée à chaque attribut (la première serait CN et la seconde UID pour eDirectory et LDAP). Vous pouvez les réorganiser en un nom distinctif en libellant manuellement chaque portion.

Par exemple, voici deux noms distinctifs relatifs :

Smith (CN correspond à Smith CN=Smith)

Smith+Lisa (CN correspond à Smith et UID correspond à Lisa, CN=Smith UID=Lisa)

Les deux noms distinctifs relatifs (Smith et Smith+Lisa) peuvent exister dans le même contexte étant donné qu'ils doivent être référencés par deux noms distinctifs relatifs très différents.

13.2.4 Contrôles et extensions LDAP OpenText pris en charge

Le protocole LDAP 3 permet aux clients et aux serveurs LDAP d'utiliser des contrôles et des extensions pour étendre une opération LDAP. Les contrôles et les extensions vous permettent d'indiquer des informations supplémentaires comme partie d'une requête ou d'une réponse. Chaque opération étendue est identifiée par un OID, ou identificateur d'objet, une chaîne numérique d'octets nécessaire pour ajouter votre propre attribut ou classe d'objet à un serveur LDAP. Les clients LDAP peuvent envoyer des requêtes d'opération étendue en indiquant l'OID de l'opération étendue qui doit être effectuée, ainsi que les données qui lui sont propres. Lorsque le serveur LDAP reçoit la requête, il effectue l'opération étendue et envoie une réponse contenant un OID et des données supplémentaires au client.

Par exemple, un client peut inclure un contrôle qui indique un tri avec la requête de recherche qu'il envoie à ce serveur. Lorsque le serveur reçoit la requête de recherche, il trie les résultats de la recherche avant de les renvoyer au client. Les serveurs peuvent également envoyer des contrôles aux clients. Par exemple, un serveur peut envoyer un contrôle avec la requête d'authentification qui informe le client de l'expiration du mot de passe.

Par défaut, le serveur LDAP OpenText eDirectory charge toutes les extensions système, ainsi que les extensions et les contrôles facultatifs sélectionnés au démarrage du serveur LDAP. L'attribut extensionInfo des extensions facultatives de l'objet Serveur LDAP permet à l'administrateur du système de sélectionner ou de désélectionner les extensions et les contrôles facultatifs.

Pour que le protocole LDAP 3 puisse activer les opérations étendues, les serveurs doivent fournir la liste des contrôles et des extensions pris en charge dans les attributs supportedControl et supportedExtension de l'entrée rootDSE. L'entrée rootDSE (entrée propre au DSA [Directory System Agent - Agent du système d'annuaire]) est située à la racine de l'arborescence qui contient les informations de l'annuaire (DIT - Directory Information Tree). Pour plus d'informations, reportez-vous à la section Obtention d'informations sur le serveur LDAP.

Pour obtenir la liste des contrôles et extensions LDAP pris en charge, reportez-vous aux sections « Contrôles LDAP » et « Extensions LDAP » de la documentation relative au NDK d'intégration de LDAP et d'OpenText eDirectory.