Sommaire

+ +mod_authnz_ldap +Permet d'utiliser un annuaire LDAP pour l'authentification +HTTP de base. +Extension +mod_authnz_ldap.c +authnz_ldap_module +Dosponible depuis les versions 2.1 et supérieures +d'Apache + +

Ce module permet aux frontaux d'authentification comme + mod_auth_basic d'authentifier les utilisateurs via + un annuaire ldap.

+ +

mod_authnz_ldap supporte les fonctionnalités + suivantes :

+ +

Support vérifié du SDK OpenLDAP (versions 1.x et + 2.x), du + SDK LDAP Novell et du SDK iPlanet + (Netscape).
Implémentation de politiques d'autorisation complexes en les + définissant via des filtres LDAP.
Mise en oeuvre élaborée d'une mise en cache des opérations LDAP + via mod_ldap.
Support de LDAP via SSL (nécessite le SDK Netscape) ou TLS + (nécessite le SDK OpenLDAP 2.x ou le SDK LDAP Novell).

+ +

Lorsqu'on utilise mod_auth_basic, ce module est + invoqué en affectant la valeur ldap à la directive + AuthBasicProvider.

+ +mod_ldap +mod_auth_basic +mod_authz_user +mod_authz_groupfile + +

Sommaire + +

+ Mode opératoire + +
- La phase + d'authentification
- La phase d'autorisation
+
+ Les directives requises + +
+
Exemples
Utilisation de TLS
Utilisation de SSL
Mise à disposition des informations de + connexion
+ Utilisation de Microsoft FrontPage avec + mod_authnz_ldap + +
- Comment ça marche
- Mises en garde
+

+ +

Mode opératoire + +

L'utilisateur se voit accorder l'accès selon un processus en deux + phases. La première phase est l'authentification, au cours de + laquelle le fournisseur d'authentification + mod_authnz_ldap vérifie que les informations de + connexion de l'utilisateur sont valides. Elle est aussi connue sous + le nom de phase de recherche/connexion. La deuxième + phase est l'autorisation, au cours de laquelle + mod_authnz_ldap détermine si l'utilisateur + authentifié a la permission d'accéder à la ressource considérée. + Elle est aussi connue sous le nom de phase de + comparaison.

+ +

mod_authnz_ldap comporte un fournisseur + d'authentification authn_ldap et un gestionnaire d'autorisation + authz_ldap. Le fournisseur d'authentification authn_ldap peut être + invoqué en affectant la valeur ldap à la directive + AuthBasicProvider. Le + gestionnaire d'autorisation authz_ldap enrichit la liste des types + d'autorisations de la directive Require en y ajoutant les + valeurs ldap-user, ldap-dn et + ldap-group.

+ +

La phase d'authentification + +

Au cours de la phase d'authentification, + mod_authnz_ldap recherche une entrée de l'annuaire + LDAP qui correspond au nom d'utilisateur fourni par le client HTTP. + Si une correspondance unique est trouvée, + mod_authnz_ldap tente de se connecter au serveur + hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot + de passe fourni par le client HTTP. Comme ce processus effectue tout + d'abord une recherche, puis une connexion, il est aussi connu sous + le nom de phase de recherche/connexion. Voici le détail des étapes + constituant la phase de recherche/connexion :

+ +

Construction d'un filtre de recherche en combinant les attribut + et filtre définis par la directive AuthLDAPURL avec le nom d'utilisateur et le mot de + passe fournis par le client HTTP.
Recherche dans l'annuaire LDAP en utilisant le filtre + construit précédemment. Si le résultat de la recherche est + négatif ou comporte plusieurs entrées, refus ou restriction de + l'accès.
Extraction du DN (distinguished name) de l'entrée issue du + résultat de la recherche, et tentative de connexion au serveur + LDAP en utilisant ce DN et le mot de passe fournis par le client + HTTP. Si la connexion échoue, refus ou restriction de + l'accès.

+ +

Les directives utilisées durant la phase de recherche/connexion + sont les suivantes :

+ + + + + + + + + + + + + + + + + + + + +

AuthLDAPURL	Spécifie le serveur LDAP, le DN de base, l'attribut à + utiliser pour la recherche, ainsi que les filtres de recherche + supplémentaires.
AuthLDAPBindDN	Un DN optionnel pour se connecter durant la phase de + recherche.
AuthLDAPBindPassword	Un mot de passe optionnel pour se connecter durant la phase + de recherche.

+ +

La phase d'autorisation + +

Au cours de la phase d'autorisation, + mod_authnz_ldap tente de déterminer si + l'utilisateur est autorisé à accéder à la ressource considérée. Une + grande partie de cette vérification consiste pour + mod_authnz_ldap en des opérations de comparaison au + niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue + sous le nom de phase de comparaison. + mod_authnz_ldap accepte les directives Require suivantes pour + déterminer si les informations de connexion permettent d'accorder + l'accès à l'utilisateur :

+ +

Avec la directive Require ldap-user, + l'autorisation d'accès est accordée si le nom d'utilisateur + spécifié par la directive correspond au nom d'utilisateur fourni + par le client.
Avec la directive Require + ldap-dn, l'autorisation d'accès est accordée si le DN + spécifié par la directive correspond au DN extrait du résultat de + la recherche dans l'annuaire LDAP.
Avec la directive Require ldap-group, + l'autorisation d'accès est accordée si le DN extrait du résultat de + la recherche dans l'annuaire LDAP (ou le nom d'utilisateur fourni + par le client) appartient au groupe LDAP spécifié par la + directive.
Avec la directive + Require ldap-attribute, l'autorisation d'accès + est accordée si la valeur de l'attribut extraite de la recherche + dans l'annuaire LDAP correspond à la valeur spécifiée par la + directive.
Avec la directive + Require ldap-filter, l'autorisation d'accès + est accordée si le filtre de recherche renvoie un objet + utilisateur unique qui corresponde au DN de l'utilisateur + authentifié.
dans tous les autres cas, refus ou restriction de + l'accès.

+ +

Sous réserve du chargement de modules d'autorisation + supplémentaires, d'autres valeurs de la directive Require peuvent être + spécifiées. Notez que si vous utilisez une valeur Require fournie par un autre module + d'autorisation, vous devrez vous assurer que la directive AuthzLDAPAuthoritative est + définie à off, afin de pouvoir confier la phase + d'autorisation au module qui a fourni l'autre valeur Require. Lorsqu'aucune directive LDAP + Require spécifique n'est + fournie, la phase d'autorisation peut être confiée à d'autres + modules, comme si AuthzLDAPAuthoritative était + définie à off. +

+ +

L'accès est autorisé à tous les utilisateurs authentifiés si + une directive Require + valid-user est présente (nécessite le module + mod_authz_user).
Avec la directive Require group, l'autorisation + d'accès est accordée si le module + mod_authz_groupfile a été chargé et si la + directive AuthGroupFile a été + définie.
etc...

+ + +

Durant la phase de comparaison, mod_authnz_ldap + utilise les directives suivantes :

+ + + + + + + + + + + + + + + + + + + + + + + + + + +

AuthLDAPURL +	On utilise l'attribut spécifié dans l'URL pour les + opérations de comparaison initiées par la directive + `Require ldap-user`.
AuthLDAPCompareDNOnServer	Détermine le comportement de la directive `Require + ldap-dn`.
AuthLDAPGroupAttribute	Détermine l'attribut utilisé pour les opérations de + comparaison initiées par la directive `Require + ldap-group`.
AuthLDAPGroupAttributeIsDN	Spécifie si l'on doit utiliser le DN ou le nom de + l'utilisateur lors des opérations de comparaison initiées par la + directive `Require ldap-group`.

+ +

Les directives requises + +

Les directives Require d'Apache sont utilisées + au cours de la phase d'autorisation afin de s'assurer que + l'utilisateur est autorisé à accéder à une ressource. + mod_authnz_ldap enrichit la liste des types d'autorisations avec les + valeurs ldap-user, ldap-dn, + ldap-group, ldap-attribute et + ldap-filter. D'autres types d'autorisations sont + disponibles, sous réserve du chargement de modules d'autorisation + supplémentaires.

+ +

Require ldap-user + +

La directive Require ldap-user permet de spécifier + les noms des utilisateurs autorisés à accéder à la ressource. + Lorsque mod_authnz_ldap a extrait un DN unique de + l'annuaire LDAP, il effectue une opération de comparaison LDAP en + utilisant le nom d'utilisateur spécifié par la directive + Require ldap-user, pour vérifier si ce nom + d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder + l'accès à plusieurs utilisateurs en plaçant plusieurs nom + d'utilisateurs sur la même ligne séparés par des espaces. Si un nom + d'utilisateur contient des espaces, il doit être entouré de + guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs + en utilisant une directive Require ldap-user par + utilisateur. Par exemple, avec la directive AuthLDAPURL définie à + ldap://ldap/o=Airius?cn (spécifiant donc que l'attribut + cn sera utilisé pour les recherches), on pourra + utiliser les directives Require suivantes pour restreindre l'accès + :

+ +Require ldap-user "Barbara Jenson"
+Require ldap-user "Fred User"
+Require ldap-user "Joe Manager"
+ + +

De par la manière dont mod_authnz_ldap traite + cette directive, Barbara Jenson peut s'authentifier comme + Barbara Jenson, Babs Jenson ou tout autre + cn sous lequel elle est enregistrée dans l'annuaire + LDAP. Une seule ligne Require ldap-user suffit pour + toutes les valeurs de l'attribut dans l'entrée LDAP de + l'utilisateur.

+ +

Si l'attribut uid avait été spécifié à la place de + l'attribut cn dans l'URL précédente, les trois lignes + ci-dessus auraient pû être condensées en une seule ligne :

+Require ldap-user bjenson fuser jmanager +

+ +

Require ldap-group + +

Cette directive permet de spécifier un groupe LDAP dont les + membres auront l'autorisation d'accès. Elle prend comme argument le + DN du groupe LDAP. Note : n'entourez pas le nom du groupe avec des + guillemets. Par exemple, supposons que l'entrée suivante existe dans + l'annuaire LDAP :

+ +dn: cn=Administrators, o=Airius
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Airius
+uniqueMember: cn=Fred User, o=Airius
+ + +

La directive suivante autoriserait alors l'accès à Fred et + Barbara :

+Require ldap-group cn=Administrators, o=Airius + + + +

Le comportement de cette directive est modifié par les directives + AuthLDAPGroupAttribute et + AuthLDAPGroupAttributeIsDN.

+ +

Require ldap-dn + +

La directive Require ldap-dn permet à + l'administrateur d'accorder l'utorisation d'accès en fonction du DN. + Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si + le DN extrait de + l'annuaire correspond au DN spécifié par la directive Require + ldap-dn, l'autorisation d'accès est accordée. Note : + n'entourez pas Le DN de guillemets.

+ +

La directive suivante accorderait l'accès à un DN spécifique + :

+Require ldap-dn cn=Barbara Jenson, o=Airius + +

Le comportement ce cette directive est modifié par la directive + AuthLDAPCompareDNOnServer.

+ +

Require ldap-attribute + +

La directive Require ldap-attribute permet à + l'administrateur d'accorder l'autorisation d'accès en fonction des + attributs de l'utilisateur authentifié dans l'annuaire LDAP. Si la + valeur de l'attribut dans l'annuaire correspond à la valeur + spécifiée par la directive, l'autorisation d'accès est accordée.

+ +

La directive suivante accorderait l'autorisation d'accès à tout + utilisateur dont l'attribut employeeType a pour valeur "actif" :

+ + Require ldap-attribute employeeType=actif + +

Plusieurs paires attribut/valeur peuvent être spécifiées par une + même directive en les séparant par des espaces, ou en définissant + plusieurs directives Require ldap-attribute. La logique + sous-jacente à une liste de paires attribut/valeur est une opération + OU. L'autorisation d'accès sera accordée si au moins une paire + attribut/valeur de la liste spécifiée correspond à la paire + attribut/valeur de l'utilisateur authentifié. Si elle contient des + espaces, la valeur, et seulement la valeur, doit être entourée de + guillemets.

+ +

La directive suivante accorderait l'autorisation d'accès à tout + utilisateur dont l'attribut city aurait pour valeur "San Jose", ou + donc l'attribut status aurait pour valeur "actif" :

+ + Require ldap-attribute city="San Jose" status=actif + +

+ +

Require ldap-filter + +

La directive Require ldap-filter permet à + l'administrateur d'accorder l'autorisation d'accès en fonction d'un + filtre de recherche LDAP complexe. L'autorisation d'accès est + accordée si le DN renvoyé par le filtre de recherche correspond au + DN de l'utilisateur authentifié.

+ +

La directive suivante accorderait l'autorisation d'accès à tout + utilisateur possédant un téléphone cellulaire et faisant partie du + département "marketing" :

+ + Require ldap-filter &(cell=*)(department=marketing) + +

Alors que la directive Require ldap-attribute se + contente d'une simple comparaison d'attributs, la directive + Require ldap-filter effectue une opération de recherche + dans l'annuaire LDAP en utilisant le filtre de recherche spécifié. + Si une simple comparaison d'attributs suffit, l'opération de + comparaison effectuée par ldap-attribute sera plus + rapide que l'opération de recherche effectuée par + ldap-filter, en particulier dans le cas d'un annuaire + LDAP de grande taille.

+ +

Exemples + +

+ Accorde l'autorisation d'accès à tout utilisateur présent dans + l'annuaire LDAP, en utilisant son UID pour effectuer la + recherche : + +AuthLDAPURL "ldap://ldap1.airius.com:389/ou=People, o=Airius?uid?sub?(objectClass=*)"
+Require valid-user + +
+ L'exemple suivant est similaire au précédent, mais les champs + dont les valeurs par défaut conviennent sont omis. Notez aussi + la présence d'un annuaire LDAP redondant : +AuthLDAPURL "ldap://ldap1.airius.com ldap2.airius.com/ou=People, o=Airius"
+Require valid-user + +
+ Encore un exemple similaire aux précédents, mais cette fois, + c'est l'attribut cn qui est utilisé pour la recherche à la place + de l'UID. Notez que ceci peut poser problème si plusieurs + utilisateurs de l'annuaire partagent le même cn, + car une recherche sur le cn doit + retourner une entrée et une seule. C'est pourquoi cette + approche n'est pas recommandée : il est préférable de choisir un + attribut de votre annuaire dont l'unicité soit garantie, comme + uid. + +AuthLDAPURL "ldap://ldap.airius.com/ou=People, o=Airius?cn"
+Require valid-user + +
+ Accorde l'autorisation d'accès à tout utilisateur appartenant au + groupe Administrateurs. Les utilisateurs doivent s'authentifier + en utilisant leur UID : + +AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid
+Require ldap-group cn=Administrators, o=Airius + +
+ Pour l'exemple suivant, on suppose que tout utilisateur de chez + Airius qui dispose d'un bippeur alphanumérique possèdera un + attribut LDAP qpagePagerID. Seuls ces utilisateurs + (authentifiés via leur UID) se verront accorder l'autorisation + d'accès : + +AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(qpagePagerID=*)
+Require valid-user + +
+
L'exemple suivant illustre la puissance des filtres pour + effectuer des requêtes complexes. Sans les filtres, il aurait + été nécessaire de créer un nouveau groupe LDAP et de s'assurer + de la synchronisation des membres du groupe avec les + utilisateurs possédant un bippeur. Tout devient limpide avec les + filtres. Nous avons pour but d'accorder l'autorisation d'accès à + tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager + qui ne possède pas de bippeur, mais doit tout de même pouvoir + accéder à la ressource :
+ +AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(|(qpagePagerID=*)(uid=jmanager))
+Require valid-user + + +
Ce dernier exemple peut sembler confus au premier abord ; en + fait, il permet de mieux comprendre à quoi doit ressembler le + filtre en fonction de l'utilisateur qui se connecte. Si Fred + User se connecte en tant que fuser, le filtre devra + ressembler à :
+ + (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser)) + +
Un recherche avec le filtre ci-dessus ne retournera un + résultat positif que si fuser dispose d'un bippeur. Si + Joe Manager se connecte en tant que jmanager, le filtre + devra ressembler à :
+ + (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager)) + +
Un recherche avec le filtre ci-dessus retournera un + résultat positif que jmanager dispose d'un + bippeur ou non
+

+ +

Utilisation de TLS + +

Pour l'utilisation de TLS, voir les directives du module + mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

+ +

Un second paramètre optionnel peut être ajouté à la directive + AuthLDAPURL pour + remplacer le type de connexion par défaut défini par la directive + LDAPTrustedMode. Ceci + permettra de promouvoir la connexion établie via une URL du type + ldap:// au statut de connection sécurisée sur le même + port.

+ +

Utilisation de SSL + +

Pour l'utilisation de SSL, voir les directives du module + mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

+ +

Pour spécifier un serveur LDAP sécurisé, utilisez + ldaps:// au lieu de + ldap:// dans la directive AuthLDAPURL.

+ +

Mise à disposition des informations de +connexion + +

Au cours du processus d'authentification, les attributs LDAP + spécifiés par la directive AuthLDAPUrl sont enregistrés + dans des variables d'environnement préfixées par la chaîne + "AUTHENTICATE_".

+ +

Si les champs attribut contiennent le nom, le CN et le numéro de + téléphone d'un utilisateur, un programme CGI pourra accéder à ces + informations sans devoir effectuer une autre requête LDAP pour + les extraire de l'annuaire.

+ +

Ceci a pour effet de simplifier considérablement le code et la + configuration nécessaire de certaines applications web.

+ +

Utilisation de Microsoft + FrontPage avec mod_authnz_ldap + +

Normalement, FrontPage utilise des fichiers utilisateur/groupe + spécifiques à FrontPage-web (c'est à dire les modules + mod_authn_file et + mod_authz_groupfile) pour effectuer toute + l'authentification. Malheureusement, il ne suffit pas de modifier + l'authentification LDAP en ajoutant les directives appropriées, car + ceci corromprait les formulaires de Permissions dans le + client FrontPage, qui sont censés modifier les fichiers + d'autorisation standards au format texte.

+ +

Lorsqu'un site web FrontPage a été créé, lui adjoindre + l'authentification LDAP consiste à ajouter les directives suivantes + à chaque fichier .htaccess qui sera créé dans + le site web :

+AuthLDAPURL            "l'url"
+AuthGroupFile mon-fichier-de-groupes
+Require group mon-fichier-de-groupes
+

+ +

Comment ça marche + +

FrontPage restreint l'accès à un site web en ajoutant la + directive Require valid-user aux fichiers + .htaccess. La directive Require valid-user + permettra l'accès à tout utilisateur valide du point de vue + LDAP. Cela signifie que tout utilisateur possédant une entrée + dans l'annuaire LDAP sera considéré comme valide, alors que + FrontPage ne considère comme valides que les utilisateurs + enregistrés dans le fichier des utilisateurs local. En remplaçant + l'autorisation par groupe LDAP par une autorisation par fichier de + groupe, Apache sera en mesure de consulter le fichier des + utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP + - lors du processus d'autorisation des utilisateurs.

+ +

Une fois les directives ajoutées selon ce qui précède, les + utilisateurs FrontPage pourront effectuer toutes les opérations de + gestion à partir du client FrontPage.

+ +

Avertissements + +

Lors du choix de l'URL LDAP, l'attribut à utiliser pour + l'authentification doit aussi être valide pour le fichier des + utilisateurs de mod_authn_file. A cette fin, + l'UID est idéal.
Lorsqu'ils ajoutent des utilisateurs via FrontPage, les + administrateurs de FrontPage doivent choisir des noms + d'utilisateurs qui existent déjà dans l'annuaire LDAP (pour des + raisons évidentes). De même, le mot de passe que l'administrateur + entre dans le formulaire est ignoré, car pour l'authentification, + Apache utilise le mot de passe de l'annuaire LDAP, et non le mot + de passe enregistré dans le fichier des utilisateurs, ce qui peut + semer la confusion parmi les administrateurs web.
Pour supporter FrontPage, Apache doit être compilé avec + mod_auth_basic, mod_authn_file + et mod_authz_groupfile. Ceci est dû au fait + qu'Apache doit utiliser le fichier de groupes de + mod_authz_groupfile pour déterminer le niveau + d'accès d'un utilisateur au site web FrontPage.
Les directives doivent être placées dans les fichiers + .htaccess. Elles ne fonctionneront pas si vous les + placez dans une section Location ou Directory. Ceci est dû au fait que pour savoir + où se trouve la liste des utilisateurs valides, + mod_authnz_ldap doit être en mesure d'atteindre + la directive AuthGroupFile qui se trouve + dans les fichiers .htaccess de FrontPage. Si les directives + de mod_authnz_ldap ne sont pas situées dans le + même fichier .htaccess que les directives FrontPage, + la configuration ne fonctionnera pas, car + mod_authnz_ldap ne sera jamais en mesure de + traiter le fichier .htaccess, et par conséquent ne + pourra jamais trouver le fichier des utilisateurs géré par + FrontPage.

+ + +AuthzLDAPAuthoritative +Empêche tout autre module d'authentification d'authentifier +l'utilisateur si le module courant échoue. +AuthzLDAPAuthoritative on|off +AuthzLDAPAuthoritative on +directory.htaccess + +AuthConfig + + +

Cette directive doit être définie à off si ce module + doit confier l'autorisation de l'utilisateur à d'autres modules + d'autorisation en cas d'échec. Le contrôle n'est passé à des modules + de plus bas niveau que s'il n'existe aucun DN ou règle qui + corresponde au nom d'utilisateur fourni (tel qu'il est transmis par + le client).

Lorsqu'aucune directive LDAP Require spécifique n'est utilisée, + l'autorisation peut être confiée à d'autres modules, comme si + AuthzLDAPAuthoritative était + définie à off.

+ + + + +AuthLDAPBindAuthoritative +Détermine si d'autres fournisseurs d'authentification +doivent être utilisés lorsqu'un utilisateur correspond à un DN, alors +que le serveur ne parvient pas à se connecter avec les données +d'authentification. +AuthLDAPBindAuthoritativeoff|on +AuthLDAPBindAuhtoritative on +directory.htaccess + +AuthConfig +Disponible dans les versions supérieures à 2.2.14 + + +

Par défaut, d'autres fournisseurs d'authentification ne sont + sollicités que si l'utilisateur ne correspond à aucun DN, mais pas + lorsque celui-ci correspond à un DN alors que le serveur ne parvient + pas à se connecter avec les données d'authentification. Si la + directive AuthLDAPBindAuthoritative est + définie à off, d'autres modules d'authentification seront + en mesure de valider l'utilisateur si l'identification LDAP (avec + les données d'authentification courantes) échoue pour une raison + quelconque.

Ceci permet à un utilisateur présent à la fois dans LDAP et dans + AuthUserFile de + s'authentifier lorsque le serveur LDAP est disponible alors que son + compte est bloqué ou que son mot de passe est inutilisable.

+ +AuthUserFile +AuthBasicProvider + + + +AuthLDAPBindDN +Un DN optionnel pour se connecter au serveur +LDAP +AuthLDAPBindDN dn +directory.htaccess + +AuthConfig + + +

Cette directive permet de définir un DN optionnel pour se + connecter au serveur afin d'y rechercher des entrées. Si aucun DN + n'est spécifié, mod_authnz_ldap tentera une + connexion anonyme.

+ + + + +AuthLDAPBindPassword +Mot de passe à utiliser en conjonction avec le DN de +connexion +AuthLDAPBindPassword mot-de-passe +directory.htaccess + +AuthConfig + + +

Cette directive permet de spécifier un mot de passe à utiliser en + conjonction avec le DN de connexion. Notez que ce mot de passe + constitue en général une donnée sensible, et doit donc être protégé + de manière appropriée. Vous ne devez utiliser les directives + AuthLDAPBindDN et AuthLDAPBindPassword que si + vous en avez vraiment besoin pour effectuer une recherche dans + l'annuaire.

+ + + + +AuthLDAPCharsetConfig +Chemin du fichier de configuration de la correspondance +langage/jeu de caractères +AuthLDAPCharsetConfig chemin-fichier +server config + + + +

La directive AuthLDAPCharsetConfig permet + de définir le chemin du fichier de configuration de la + correspondance langage/jeu de caractères. chemin-fichier + est un chemin relatif au répertoire défini par la directive + ServerRoot. Ce fichier contient une liste + de correspondances extension de langage/jeu de caractères. La + plupart des administrateurs utilisent le fichier + charset.conv fourni qui associe les extensions de + langage courantes à leurs jeux de caractères.

+ +

Le fichier contient des lignes au format suivant :

+ + + extension de langage jeu de caractères + [Nom du langage] ... + + +

L'extension est insensible à la casse. Les lignes vides et les + lignes commençant par un dièse (#) sont ignorées.

+ + + + +AuthLDAPCompareDNOnServer +Utilise le serveur LDAP pour comparer les DNs +AuthLDAPCompareDNOnServer on|off +AuthLDAPCompareDNOnServer on +directory.htaccess + +AuthConfig + + +

Lorsque cette directive est définie à on, + mod_authnz_ldap utilise le serveur LDAP pour + comparer les DNs. Il s'agit de la seule méthode infaillible pour + comparer les DNs. mod_authnz_ldap va rechercher + dans l'annuaire le DN spécifié par la directive Require dn, puis extraire ce DN et le + comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette + directive est à off, mod_authnz_ldap effectue une + simple comparaison de chaînes. Cette dernière approche peut produire + de faux négatifs, mais elle est beaucoup plus rapide. Notez + cependant que le cache de mod_ldap peut accélérer + la comparaison de DNs dans la plupart des situations.

+ + + + +AuthLDAPDereferenceAliases +A quel moment le module va déréférencer les +alias +AuthLDAPDereferenceAliases never|searching|finding|always +AuthLDAPDereferenceAliases Always +directory.htaccess + +AuthConfig + + +

Cette directive permet de spécifier à quel moment + mod_authnz_ldap va déréférencer les alias au cours + des opérations liées à LDAP. La valeur par défaut est + always.

+ + + + +AuthLDAPGroupAttribute +L'attribut LDAP utilisé pour vérifier l'appartenance d'un +utilisateur à un groupe. +AuthLDAPGroupAttribute attribut +AuthLDAPGroupAttribute member uniquemember +directory.htaccess + +AuthConfig + + +

Cette directive permet de spécifier quel attribut LDAP est + utilisé pour vérifier l'appartenance d'un utilisateur à un + groupe. On peut spécifier plusieurs attributs en répétant cette + directive plusieurs fois. Si la directive n'est pas définie, + mod_authnz_ldap utilise les attributs + member et uniquemember.

+ + + + +AuthLDAPGroupAttributeIsDN +Utilise le DN de l'utilisateur pour vérifier son +appartenance à un groupe +AuthLDAPGroupAttributeIsDN on|off +AuthLDAPGroupAttributeIsDN on +directory.htaccess + +AuthConfig + + +

Lorsqu'elle est définie à on, cette directive + indique que c'est le DN de l'utilisateur qui doit être utilisé pour + vérifier son appartenance à un groupe. Dans le cas contraire, c'est + le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que + le client envoie le nom d'utilisateur bjenson, qui + correspond au DN LDAP cn=Babs Jenson,o=Airius. Si la + directive est à on, mod_authnz_ldap va + vérifier si cn=Babs Jenson, o=Airius est un membre du + groupe. Dans le cas contraire, mod_authnz_ldap + vérifiera si bjenson est un membre du groupe.

+ + + + +AuthLDAPRemoteUserAttribute +Spécifie l'attribut dont la valeur renvoyée au cours de la +requête de l'utilisateur sera utilisée pour définir la variable +d'environnement REMOTE_USER +AuthLDAPRemoteUserAttribute uid +none +directory.htaccess + +AuthConfig + + +

Lorsque cette directive est définie, la variable d'environnement + REMOTE_USER sera définie à la valeur de l'attribut + spécifié. Assurez-vous que cet attribut soit bien inclus dans la + liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans + le cas contraire, cette directive n'aurait aucun effet. Si elle est + présente, cette directive l'emporte sur AuthLDAPRemoteUserIsDN. Elle + peut s'avérer utile par exemple, si vous souhaitez que les + utilisateurs se connectent à un site web en utilisant leur adresse + email, alors qu'une application sous-jacente nécessite un nom + d'utilisateur comme identifiant.

+ + + + +AuthLDAPRemoteUserIsDN +Utilise le DN de l'utilisateur pour définir la variable +d'environnement REMOTE_USER +AuthLDAPRemoteUserIsDN on|off +AuthLDAPRemoteUserIsDN off +directory.htaccess + +AuthConfig + + +

Lorsque cette directive est à on, la variable d'environnement + REMOTE_USER sera définie avec la valeur du DN complet + de l'utilisateur authentifié, et non plus avec simplement le nom + d'utilisateur fourni par le client. Elle est définie à off par + défaut.

+ + + + +AuthLDAPUrl +L'URL permettant de spécifier les paramètres de la +recherche LDAP +AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS] +directory.htaccess + +AuthConfig + + +

Une URL conforme à la RFC 2255 qui permet de spécifier les + paramètres à utiliser pour la recherche dans l'annuaire LDAP. La + syntaxe de l'URL est :

+ldap://hôte:port/DN-de-base?attribut?portée?filtre +

Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs + LDAP, la syntaxe sera :

+AuthLDAPUrl "ldap://ldap1.example.com +ldap2.example.com/dc=..." + +

ldap

Pour ldap non sécurisé, utilisez la chaîne + ldap. Pour ldap sécurisé, utilisez à la place la + chaîne ldaps. LDAP sécurisé n'est disponible que si + Apache a été lié avec une bibliothèque LDAP supportant SSL.

hôte:port

Il s'agit du nom/port du serveur ldap + (dont la valeur par défaut est + localhost:389 pour ldap, et + localhost:636 pour ldaps). Pour + spécifier plusieurs serveurs LDAP redondants, indiquez + simplement leur liste en les séparant par des espaces. + mod_authnz_ldap tentera alors de se connecter + à chacun des serveurs jusqu'à ce qu'il parvienne à se + connecter avec succès.

+ +

lorsqu'une connection a été établie avec un serveur, elle + reste active pendant toute la durée de vie du processus + httpd, ou jusqu'à ce que le serveur LDAP + cesse de fonctionner.

+ +

Si le serveur LDAP cesse de fonctionner, et ainsi + interrompt une + connexion existante, mod_authnz_ldap tentera + de se reconnecter en commençant par le premier serveur de la + liste, et ainsi de suite avec les serveurs redondants + suivants. Notez que ce processus n'a rien à voir avec une + véritable recherche de type round-robin.

DN-de-

Le DN de la branche de l'annuaire à partir de laquelle + toutes les recherches seront lancées. Il doit au moins + correspondre à la racine de votre annuaire, mais vous pouvez + aussi indiquer une branche plus spécifique.

attribut

Il s'agit de l'attribut à utiliser pour la recherche. + Bien que la RFC + 2255 autorise une liste d'attributs séparés par des virgules, + seul le premier sera retenu, sans tenir compte des autres + attributs fournis. Si aucun attribut n'est fourni, l'attribut + par défaut est uid. Il est judicieux de choisir un + attribut dont la valeur sera unique parmi toutes les entrées de + la branche de l'annuaire que vous aurez définie.

portée

Il s'agit de la portée (scope) de la recherche. Elle peut prendre + les valeurs one ou sub. Notez que la + RFC 2255 supporte aussi une portée de valeur base, + mais cette dernière n'est pas supportée par le module. Si la + portée n'est pas définie, ou si elle est définie à + base, c'est la valeur de portée par défaut + sub qui sera utilisée.

filtre

Il s'agit d'un filtre de recherche LDAP valide. Si aucun + filtre n'est spécifié, le filtre par défaut + (objectClass=*) sera utilisé, ce qui corrspond à + une recherche de tous les types d'objets de l'arborescence. La + taille des filtres est limitée à environ 8000 caractères (valeur + de la macro MAX_STRING_LEN dans le code source + d'Apache), ce qui s'avère plus que suffisant pour la plupart des + applications.

+ +

Pour une recherche, les attribut, filtre et nom d'utilisateur + fournis par le client HTTP sont combinés pour créer un filtre de + recherche du style : + (&(filtre)(attribut + =nom-utilisateur)).

+ +

Par exemple, considérons l'URL + ldap://ldap.airius.com/o=Airius?cn?sub?(posixid=*). + Lorsqu'un client tentera de se connecter en utilisant le nom + d'utilisateur Babs Jenson, le filtre de recherche sera + : (&(posixid=*)(cn=Babs Jenson)).

+ +

On peut encore ajouter un paramètre optionnel pour permettre à + l'URL LDAP de surcharger le type de connexion. Ce paramètre peut + prendre l'une des valeurs suivantes :

+ +

NONE: Etablit une connexion non sécurisée sur le port LDAP par + défaut, ce qui est équivalent à ldap:// sur le port + 389.
SSL: Etablit une connexion sécurisée sur le port LDAP sécurisé + par défaut, ce qui est équivalent à ldaps://.
TLS | STARTTLS: Etablit une connexion sécurisée par élévation de niveau sur + le port LDAP par défaut. Cette connexion sera initialisée sur le + port 389 par défaut, puis élevée à un niveau de connexion + sécurisée sur le même port.

+ +

Voir plus haut pour des exemples d'URLs définies par la directive + AuthLDAPURL.

+ +

Lorsque la directive AuthLDAPURL a été définie dans + un contexte particulier, et si un autre module a effectué + l'authentification correspondant à la requête, le serveur essaiera + de faire correspondre le nom d'utilisateur à un DN au cours du + processus d'autorisation, que des prérequis LDAP spécifiques soient + présents ou non. Pour ignorer les échecs de mise en correspondance + d'un nom d'utilisateur avec un DN au cours du processus + d'autorisation, définissez + AuthzLDAPAutoritative à "off".

+ + + + +