Module Apache mod_authnz_ldap

Langues Disponibles: en | + fr

+ + + + +

Description:	Permet d'utiliser un annuaire LDAP pour l'authentification +HTTP de base.
Statut:	Extension
Identificateur de Module:	authnz_ldap_module
Fichier Source:	mod_authnz_ldap.c
Compatibilité:	Disponible depuis les versions 2.1 et supérieures +d'Apache

Sommaire

+ +

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 OpenLDAP SDK (versions 1.x et + 2.x), du + Novell LDAP SDK et du SDK iPlanet + (Netscape).
Implémentation de politiques d'autorisation complexes en les + définissant via des filtres LDAP.
Mise en oeuvre d'une mise en cache des opérations LDAP + élaborée 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.

Sujets

Sommaire
Mises en garde à caractère général
Mode opératoire
Les directives requises
Exemples
Utilisation de TLS
Utilisation de SSL
Mise à disposition des informations de +connexion
Utilisation d'Active +Directory
Utilisation de Microsoft + FrontPage avec mod_authnz_ldap

Directives

AuthLDAPAuthorizePrefix
AuthLDAPBindAuthoritative
AuthLDAPBindDN
AuthLDAPBindPassword
AuthLDAPCharsetConfig
AuthLDAPCompareAsUser
AuthLDAPCompareDNOnServer
AuthLDAPDereferenceAliases
AuthLDAPGroupAttribute
AuthLDAPGroupAttributeIsDN
AuthLDAPInitialBindAsUser
AuthLDAPInitialBindPattern
AuthLDAPMaxSubGroupDepth
AuthLDAPRemoteUserAttribute
AuthLDAPRemoteUserIsDN
AuthLDAPSearchAsUser
AuthLDAPSubGroupAttribute
AuthLDAPSubGroupClass
AuthLDAPURL

Traitement des bugs

Voir aussi

Mises en garde à caractère général

Ce module effectue une mise en cache des résultats du processus +d'authentification et d'autorisation en fonction de la configuration du +module mod_ldap. Les modifications effectuées au niveau +du serveur LDAP d'arrière-plan comme les +verrouillages ou révocations d'utilisateurs, les changements de mot de +passe, ou les changements d'appartenance à un groupe (et cette liste +n'est pas exhaustive), ne seront pas immédiatement propagées jusqu'au +serveur HTTP. Consultez les directives du module +mod_ldap pour plus de détails à propos de la +configuration de la mise en cache. +

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 (NdT : en anglais ou + dans le code source : search/bind). 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 (compare).

+ +

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 :

+ +

Confection 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 + confectionné 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, ou éventuellement à un de ses sous-groupes.
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.

+ +

L'accès est accordé à 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`.
`AuthLDAPMaxSubGroupDepth`	Détermine la profondeur maximale de l'arborescence des + sous-groupes qui seront évalués au cours des opérations de + comparaisons initiées par la directive `Require + ldap-group`.
`AuthLDAPSubGroupAttribute`	Détermine l'attribut à utiliser lors de l'extraction de + membres de sous-groupes du groupe courant au cours des + opérations de comparaison initiées par la directive + `Require ldap-group`.
`AuthLDAPSubGroupClass`	Spécifie les valeurs de classe d'objet LDAP à utiliser pour + déterminer si les objets extraits de l'annuaire sont bien des + objets de type groupe (et non des objets de type utilisateur), + au cours du traitement des sous-groupes initié 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.

+ +

Depuis la version 2.4.8, les directives require LDAP supportent + les expressions.

+ +

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=Example?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=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example

+ +

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

Require ldap-group cn=Administrators, o=Example

+ + +

Les membres peuvent aussi se trouver dans les sous-groupes du + groupe LDAP spécifié si la directive AuthLDAPMaxSubGroupDepth a été + définie à une valeur supérieure à 0. Par exemple, supposons que les + entrées suivantes existent dans l'annuaire LDAP :

dn: cn=Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Managers, o=Example
+uniqueMember: cn=Administrators, o=Example
+uniqueMember: cn=Users, o=Example
+
+dn: cn=Managers, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Bob Ellis, o=Example
+uniqueMember: cn=Tom Jackson, o=Example
+
+dn: cn=Administrators, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Barbara Jenson, o=Example
+uniqueMember: cn=Fred User, o=Example
+
+dn: cn=Users, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Allan Jefferson, o=Example
+uniqueMember: cn=Paul Tilley, o=Example
+uniqueMember: cn=Temporary Employees, o=Example
+
+dn: cn=Temporary Employees, o=Example
+objectClass: groupOfUniqueNames
+uniqueMember: cn=Jim Swenson, o=Example
+uniqueMember: cn=Elliot Rhodes, o=Example

+ +

Les directives suivantes autoriseraient alors l'accès à Bob + Ellis, Tom Jackson, Barbara Jenson, Fred User, Allan Jefferson, et + Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes + (car ils sont situés dans un sous-groupe de niveau de profondeur 2) + :

Require ldap-group cn=Employees, o=Example
+AuthLDAPMaxSubGroupDepth 1

+ + +

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

+ + +

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=Example

+ + +

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="active"

+ + +

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="active"

+ + + + +

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.

+ +

Lorsqu'on utilise une expression dans un + filtre, il faut s'assurer que les filtres LDAP sont correctement échappés + afin de se prémunir contre toute injection LDAP. Pour ce faire, + il est possible d'utiliser la fonction ldap.

+ +

<LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
+  Require ldap-filter (memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)
+</LocationMatch>

+ + + + +

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.example.com:389/ou=People, o=Example?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.example.com ldap2.example.com/ou=People, o=Example"
+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.example.com/ou=People, o=Example?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.example.com/o=Example?uid
+Require ldap-group cn=Administrators, o=Example
```
+ +
+ Accorde l'accès à tout utilisateur appartenant au groupe dont le + nom correspond au nom d'hôte du serveur virtuel. Dans cet exemple, + on utilise une expression pour + construire le filtre. +
```
AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=%{SERVER_NAME}, o=Example
```
+ +
+ Pour l'exemple suivant, on suppose que tout utilisateur de chez + Example 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.example.com/o=Example?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.example.com/o=Example?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_".

+ +

Au cours du processus d'autorisation, 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 + "AUTHORIZE_".

+ +

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 d'Active +Directory

+ +

Active Directory peut supporter plusieurs domaines à la fois. + Pour faire la distinction entre les utilisateurs de plusieurs + domaines, on peut ajouter à l'entrée de l'utilisateur dans + l'annuaire un identifiant appelé Nom + Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se + compose en général du nom de compte de l'utilisateur, suivi du nom + du domaine considéré, par exemple untel@nz.example.com.

+ +

Vous voudrez probablement configurer le module + mod_authnz_ldap afin de pouvoir authentifier les + utilisateurs de n'importe quel domaine de la forêt Active Directory. + Ainsi, untel@nz.example.com et + untel@au.example.com pourront être authentifiés en une + seule fois par la même requête.

+ +

Pour y parvenir, on utilise le concept de Catalogue Global + d'Active Directory. Ce Catalogue Global est une copie en lecture + seule des attributs sélectionnés de tous les serveurs de la forêt + Active Directory. Une requête vers le + Catalogue Global permet donc d'atteindre tous les domaines en une + seule fois, sans avoir à se connecter aux différents serveurs, via + des liaisons dont certaines peuvent être lentes.

+ +

Lorsqu'il est activé, la Catalogue Global est un serveur + d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL). + Pour rechercher un utilisateur, effectuez une recherche sur + l'attribut userPrincipalName, avec une base de recherche + vide, comme suit :

+ +

AuthLDAPBindDN apache@example.com
+AuthLDAPBindPassword password
+AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub

+ + +

Les utilisateurs devront s'authentifier en entrant leur UPN, de + la formeuntel@nz.example.com.

+ +

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       "the url"
+AuthGroupFile     "mygroupfile"
+Require group     "mygroupfile"

+ + +

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.

+ +

Directive AuthLDAPAuthorizePrefix

+ + + + + + + + + +

Description:	Spécifie le préfixe ajouté aux variables d'environnement +durant la phase d'autorisation
Syntaxe:	`AuthLDAPAuthorizePrefix préfixe`
Défaut:	`AuthLDAPAuthorizePrefix AUTHORIZE_`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap
Compatibilité:	Disponible depuis la version 2.3.6

Cette directive permet de spécifier le préfixe ajouté aux + variables d'environnement durant la phase d'autorisation. Si la + valeur spécifiée est AUTHENTICATE_, les utilisateurs de ces + variables d'environnement verront les mêmes informations, que le + serveur effectue une authentification, une autorisation, ou les + deux.

+ +

Note

+ Aucune variable d'autorisation n'est définie lorsqu'un utilisateur + s'est vu autoriser l'accès via la directive

Require
+    valid-user

. +

+ +

Directive AuthLDAPBindAuthoritative

+ + + + + + + + +

Description:	Détermine si l'on doit utiliser d'autres fournisseurs +d'authentification lorsque le serveur ne peut pas valider les données +d'authentification de l'utilisateur, alors que ce dernier possède un +DN.
Syntaxe:	`AuthLDAPBindAuthoritative off\|on`
Défaut:	`AuthLDAPBindAuthoritative on`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

Par défaut, des fournisseurs d'authentification sont appelés + si un utilisateur ne possède pas de DN, mais ne le sont pas si + l'utilisateur possède un DN et si son mot de passe ne peut pas être + vérifié lors d'une connexion au serveur LDAP. Si la directive + AuthLDAPBindAuthoritative est + définie à off, d'autres modules d'authentification + configurés auront une chance de valider le mot de passe de + l'utilisateur si la tentative de connexion au serveur LDAP échoue + pour une raison quelconque (avec les données d'authentification + fournies).

Ceci permet aux utilisateurs présent à la fois dans l'annuaire + LDAP et dans un fichier AuthUserFile de s'authentifier + lorsque le serveur LDAP est disponible, alors que le compte de + l'utilisateur est verrouillé ou que son mot de passe est + inutilisable pour une raison quelconque.

+ +

Voir aussi

AuthUserFile
AuthBasicProvider

Directive AuthLDAPBindDN

+ + + + + + + +

Description:	Un DN optionnel pour se connecter au serveur +LDAP
Syntaxe:	`AuthLDAPBindDN dn`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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.

+ +

Directive AuthLDAPBindPassword

+ + + + + + + + +

Description:	Mot de passe à utiliser en conjonction avec le DN de +connexion
Syntaxe:	`AuthLDAPBindPassword mot-de-passe`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap
Compatibilité:	exec: est disponible depuis la version 2.4.5 du +serveur HTTP Apache.

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.

+ +

Si la valeur spécifiée débute par "exec:", la commande qui suit sera + exécutée, et la première ligne renvoyée par la commande sur la + sortie standard sera utilisée comme mot de passe.

# Mot de passe spécifié directement
+AuthLDAPBindPassword secret
+
+# Exécution de /path/to/program pour obtenir le mot de passe
+AuthLDAPBindPassword exec:/path/to/program
+
+# Exécution de /path/to/otherProgram avec un argument pour obtenir le mot de passe
+AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"

+ + + +

Directive AuthLDAPCharsetConfig

+ + + + + + +

Description:	Chemin du fichier de configuration de la correspondance +langage/jeu de caractères
Syntaxe:	`AuthLDAPCharsetConfig chemin-fichier`
Contexte:	configuration globale
Statut:	Extension
Module:	mod_authnz_ldap

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.

+ +

Directive AuthLDAPCompareAsUser

+ + + + + + + + + +

Description:	Utilisation des données d'authentification de l'utilisateur +pour effectuer les comparaisons pour l'attribution des autorisations
Syntaxe:	`AuthLDAPCompareAsUser on\|off`
Défaut:	`AuthLDAPCompareAsUser off`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap
Compatibilité:	Disponible depuis la version version 2.3.6

Lorsque cette directive est définie, et si + mod_authnz_ldap a authentifié l'utilisateur, les + recherches LDAP pour les autorisations utilisent le nom distinctif + trouvé (DN) et le mot de passe d'authentification basique HTTP de + l'utilisateur authentifié au lieu des données d'authentification + configurées au niveau du serveur.

+ +

Les vérifications d'autorisation ldap-attribute, + ldap-user, et ldap-group (niveau simple seulement) + utilisent des comparaisons.

+ +

Cette directive n'a d'effet sur les comparaisons effectuées au + cours des traitements de groupe imbriqués, et lorsque la directive + AuthLDAPSearchAsUser + est aussi activée.

+ +

Cette directive ne doit être utilisée que si votre serveur LDAP + n'autorise pas les recherches anonymes, ou si vous ne pouvez pas + utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN. +

+ +

Directive AuthLDAPCompareDNOnServer

+ + + + + + + + +

Description:	Utilise le serveur LDAP pour comparer les DNs
Syntaxe:	`AuthLDAPCompareDNOnServer on\|off`
Défaut:	`AuthLDAPCompareDNOnServer on`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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 + des 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.

+ +

Directive AuthLDAPDereferenceAliases

+ + + + + + + + +

Description:	À quel moment le module va déréférencer les +alias
Syntaxe:	`AuthLDAPDereferenceAliases never\|searching\|finding\|always`
Défaut:	`AuthLDAPDereferenceAliases always`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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.

+ +

Directive AuthLDAPGroupAttribute

+ + + + + + + + +

Description:	L'attribut LDAP utilisé pour vérifier l'appartenance d'un +utilisateur à un groupe.
Syntaxe:	`AuthLDAPGroupAttribute attribut`
Défaut:	`AuthLDAPGroupAttribute member uniqueMember`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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.

+ +

Directive AuthLDAPGroupAttributeIsDN

+ + + + + + + + +

Description:	Utilise le DN de l'utilisateur pour vérifier son +appartenance à un groupe
Syntaxe:	`AuthLDAPGroupAttributeIsDN on\|off`
Défaut:	`AuthLDAPGroupAttributeIsDN on`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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=Example. Si la + directive est à on, mod_authnz_ldap va + vérifier si cn=Babs Jenson, o=Example est un membre du + groupe. Dans le cas contraire, mod_authnz_ldap + vérifiera si bjenson est un membre du groupe.

+ +

Directive AuthLDAPInitialBindAsUser

+ + + + + + + + + +

Description:	Détermine si le serveur effectue la recherche initiale du +DN en utilisant le nom propre de l'utilisateur pour l'authentification +de base +et non de manière anonyme, ou en utilisant des données d'authentification +codées en dur pour le serveur
Syntaxe:	`AuthLDAPInitialBindAsUser off\|on`
Défaut:	`AuthLDAPInitialBindAsUser off`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap
Compatibilité:	Disponible depuis la version 2.3.6

Par défaut, le serveur convertit le nom d'utilisateur pour + l'authentification de base en nom distinctif LDAP (DN) soit de + manière anonyme, soit avec un couple nom/mot de passe dédié. Cette + directive permet de forcer le serveur à utiliser les véritables nom + d'utilisateur et mot de passe fournis par l'utilisateur pour + effectuer la recherche initiale du DN.

+ +

Si le nom d'utilisateur ne peut pas s'authentifier directement + et nécessite de légères modifications, voir la directive AuthLDAPInitialBindPattern.

+ +

Non disponible dans la cas d'une autorisation seule

+ On ne peut utiliser cette directive que si ce module + effectue une authentification, et n'a aucun effet si ce module + n'est utilisé que pour les processus d'autorisation. +

+ +

Voir aussi

AuthLDAPInitialBindPattern
AuthLDAPBindDN
AuthLDAPCompareAsUser
AuthLDAPSearchAsUser

Directive AuthLDAPInitialBindPattern

+ + + + + + + + + +

Description:	Spécifie la modification a apporter au nom d'utilisateur +pour l'authentification de base lors de l'authentification auprès du +serveur LDAP pour effectuer une recherche de DN
Syntaxe:	`AuthLDAPInitialBindPattern regex substitution`
Défaut:	`AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur +distant utilisé tel quel)`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap
Compatibilité:	Disponible depuis la version 2.3.6

Si la directive AuthLDAPInitialBindAsUser est + définie à ON, le nom utilisateur pour l'authentification de + base sera transformé selon l'expression rationnelle + regex et l'argument substitution spécifiés.

+ +

L'expression rationnelle est comparée au nom d'utilisateur pour + l'authentification de base courant. L'argument + substitution peut contenir des références arrières, mais + n'effectue aucune autre interpolation de variable.

+ +

AuthLDAPInitialBindPattern (.+) $1@example.com

+ +

AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com

+ + +

Non disponible dans la cas d'une autorisation seule

+ On ne peut utiliser cette directive que si ce module + effectue une authentification, et n'a aucun effet si ce module + n'est utilisé que pour les processus d'autorisation. +

Débogage

+ Le DN de substitution est enregistré dans la variable + d'environnement LDAP_BINDASUSER. Si l'expression + rationnelle ne convient pas, le nom d'utilisateur est utilisé + tel quel. +

+ +

Voir aussi

AuthLDAPInitialBindAsUser
AuthLDAPBindDN

Directive AuthLDAPMaxSubGroupDepth

+ + + + + + + + + +

Description:	Spécifie la profondeur d'imbrication des sous-groupes +maximale prise en compte avant l'abandon de la recherche de +l'utilisateur.
Syntaxe:	`AuthLDAPMaxSubGroupDepth Nombre`
Défaut:	`AuthLDAPMaxSubGroupDepth 10`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap
Compatibilité:	Disponible à partir de la version 2.3.0 du serveur HTTP +Apache

Lorsque cette directive est définie à une valeur X + non nulle, en combinaison avec l'utilisation de la directive + Require ldap-group DN-groupe, les données de connexion + fournies seront utilisées pour vérifier l'appartenance de + l'utilisateur à l'objet de l'annuaire DN-groupe ou à + tout sous-groupe du groupe courant en tenant compte de la profondeur + d'imbrication maximale X spécifiée par la directive.

Se référer à la section Require + ldap-group pour un exemple plus détaillé.

+ +

Performances dans le cas des groupes imbriqués

Lorsque les directives + AuthLDAPSubGroupAttribute et + AuthLDAPGroupAttribute se recouvrent (comme + c'est le cas par défaut et requis par les schémas LDAP courants), la + recherche de sous-groupes au sein de grands groupes peut être très + longue. Si vos groupes sont très grands et non imbriqués, définissez + la directive AuthLDAPMaxSubGroupDepth à 0.

+ + +

Directive AuthLDAPRemoteUserAttribute

+ + + + + + + + +

Description:	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
Syntaxe:	`AuthLDAPRemoteUserAttribute uid`
Défaut:	`none`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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.

+ +

Directive AuthLDAPRemoteUserIsDN

+ + + + + + + + +

Description:	Utilise le DN de l'utilisateur pour définir la variable +d'environnement REMOTE_USER
Syntaxe:	`AuthLDAPRemoteUserIsDN on\|off`
Défaut:	`AuthLDAPRemoteUserIsDN off`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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.

+ +

Directive AuthLDAPSearchAsUser

+ + + + + + + + + +

Description:	Utilise les données d'authentification de l'utilisateur +pour la recherche des autorisations
Syntaxe:	`AuthLDAPSearchAsUser on\|off`
Défaut:	`AuthLDAPSearchAsUser off`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap
Compatibilité:	Disponible depuis la version 2.3.6

Lorsque cette directive est définie, et si + mod_authnz_ldap a authentifié l'utilisateur, les + recherches LDAP pour définir les autorisations utilisent le nom + distinctif (DN) trouvé et le mot de passe pour l'authentification de + base HTTP de l'utilisateur authentifié, au lieu des données + d'authentification configurées au niveau du serveur.

+ +

Les vérifications d'autorisation ldap-filter et + ldap-dn utilisent des recherches.

+ +

Cette directive n'a d'effet sur les comparaisons effectuées au + cours des traitements de groupe imbriqués, et lorsque la directive + AuthLDAPCompareAsUser + est aussi activée.

+ +

+ + +

Voir aussi

AuthLDAPInitialBindAsUser
AuthLDAPCompareAsUser

Directive AuthLDAPSubGroupAttribute

+ + + + + + + + + +

Description:	Spécifie les noms d'attribut, un par directive, utilisés +pour différencier les membres du groupe courant qui sont eux-mêmes des +groupes.
Syntaxe:	`AuthLDAPSubGroupAttribute attribut`
Défaut:	`AuthLDAPSubgroupAttribute member uniqueMember`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap
Compatibilité:	Disponible à partir de la version 2.3.0 du serveur HTTP +Apache

Un objet groupe LDAP peut contenir des membres qui sont des + utilisateurs et des membres qui sont eux-mêmes des groupes (appelés + sous-groupes ou groupes imbriqués). La directive + AuthLDAPSubGroupAttribute spécifie l'attribut utilisé + pour identifier les groupes, alors que la directive + AuthLDAPGroupAttribute + spécifie l'attribut utilisé pour identifier les utilisateurs. On peut + spécifier plusieurs attributs en répétant la directive plusieurs fois. Si + elle n'est pas définie, mod_authnz_ldap utilise les + attributs member et uniqueMember.

+ +

Directive AuthLDAPSubGroupClass

+ + + + + + + + + +

Description:	Spécifie quelles valeurs d'objectClass LDAP identifient les +objets de l'annuaire qui sont des groupes au cours du traitement des +sous-groupes.
Syntaxe:	`AuthLDAPSubGroupClass ObjectClass-LDAP`
Défaut:	`AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap
Compatibilité:	Disponible à partir de la version 2.3.0 du serveur HTTP +Apache

Un objet groupe LDAP peut contenir des membres qui sont des + utilisateurs et des membres qui sont eux-mêmes des groupes (appelés + sous-groupes ou groupes imbriqués). La directive + AuthLDAPSubGroupAttribute + permet d'identifier les + membres qui sont des sous-groupes du groupe courant (à l'opposé des + membres utilisateurs). La directive + AuthLDAPSubGroupClass permet de spécifier les valeurs + d'objectClass LDAP utilisées pour vérifier que certains membres sont + en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent + alors faire l'objet d'une recherche d'autres membres utilisateurs ou + sous-groupes. On peut spécifier plusieurs attributs en répétant + cette directive plusieurs fois. Si cette directive n'est pas + définie, mod_authnz_ldap utilise les attributs + groupOfNames et groupOfUniqueNames.

+ +

Directive AuthLDAPURL

+ + + + + + + +

Description:	URL specifying the LDAP search parameters
Syntaxe:	`AuthLDAPURL url [NONE\|SSL\|TLS\|STARTTLS]`
Contexte:	répertoire, .htaccess
Surcharges autorisées:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

La documentation de cette directive + n'a pas encore t traduite. Veuillez vous reporter la version + en langue anglaise.