Serveur Apache HTTP Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4 > Modules

# 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é: | Dosponible 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`.

### Directives

### Sujets

- Sommaire
- 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

### Voir aussi

- `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
  - Require ldap-user
  - Require ldap-group
  - Require ldap-dn
  - Require ldap-attribute
  - Require ldap-filter
- 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`
  - 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 (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 :

1. 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.
2. 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.
3. 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.

### 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 Jensen, 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
AuthLDAPSubGroupDepth 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=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.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`

- 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            "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.

## AuthLDAPAuthorizePrefix Directive

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
AllowOverride: | 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`.

## AuthLDAPBindAuthoritative Directive

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: | `AuthLDAPBindAuthoritativeoff|on`
Défaut: | `AuthLDAPBindAuthoritative on`
Contexte: | répertoire, .htaccess
AllowOverride: | 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`

## AuthLDAPBindDN Directive

Description: | Un DN optionnel pour se connecter au serveur LDAP
Syntaxe: | `AuthLDAPBindDN dn`
Contexte: | répertoire, .htaccess
AllowOverride: | 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.

## AuthLDAPBindPassword Directive

Description: | Mot de passe à utiliser en conjonction avec le DN de connexion
Syntaxe: | `AuthLDAPBindPassword mot-de-passe`
Contexte: | répertoire, .htaccess
AllowOverride: | AuthConfig
Statut: | Extension
Module: | mod_authnz_ldap

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 Directive

Description: | Chemin du fichier de configuration de la correspondance langage/jeu de caractères
Syntaxe: | `AuthLDAPCharsetConfig chemin-fichier`
Contexte: | configuration du serveur
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.

## AuthLDAPCompareAsUser Directive

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
AllowOverride: | 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`.

### Voir aussi

- `AuthLDAPInitialBindAsUser`
- `AuthLDAPSearchAsUser`

## AuthLDAPCompareDNOnServer Directive

Description: | Utilise le serveur LDAP pour comparer les DNs
Syntaxe: | `AuthLDAPCompareDNOnServer on|off`
Défaut: | `AuthLDAPCompareDNOnServer on`
Contexte: | répertoire, .htaccess
AllowOverride: | 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.

## AuthLDAPDereferenceAliases Directive

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
AllowOverride: | 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`.

## AuthLDAPGroupAttribute Directive

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
AllowOverride: | 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`.

## AuthLDAPGroupAttributeIsDN Directive

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
AllowOverride: | 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.

## AuthLDAPInitialBindAsUser Directive

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
AllowOverride: | 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`.

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`.

### 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`

## AuthLDAPInitialBindPattern Directive

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: | `AuthLDAPInitialBindPatternregex substitution`
Défaut: | `AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur distant utilisé tel quel)`
Contexte: | répertoire, .htaccess
AllowOverride: | 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.

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`.

`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`

## AuthLDAPMaxSubGroupDepth Directive

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
AllowOverride: | 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é.

## AuthLDAPRemoteUserAttribute Directive

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
AllowOverride: | 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.

## AuthLDAPRemoteUserIsDN Directive

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
AllowOverride: | 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.

## AuthLDAPSearchAsUser Directive

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
AllowOverride: | 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.

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`.

### Voir aussi

- `AuthLDAPInitialBindAsUser`
- `AuthLDAPCompareAsUser`

## AuthLDAPSubGroupAttribute Directive

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
AllowOverride: | 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`.

## AuthLDAPSubGroupClass Directive

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
AllowOverride: | 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`.

## AuthLDAPUrl Directive

Description: | L'URL permettant de spécifier les paramètres de la recherche LDAP
Syntaxe: | `AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]`
Contexte: | répertoire, .htaccess
AllowOverride: | AuthConfig
Statut: | Extension
Module: | mod_authnz_ldap

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=..."`

Mise en garde : Si vous spécifiez plusieurs serveurs, vous devez en entourer la liste avec des guillemets ; dans le cas contraire, vous générerez une erreur : "AuthLDAPURL takes one argument, URL to define LDAP connection..". Vous pouvez bien entendu ajouter des paramètres de recherche à chacun des serveurs spécifiés.

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. Notez qu'en cas de multiples serveurs LDAP, l'ensemble de l'URL LDAP doit être entourée de guillemets.

  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-base
  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. Tous les attributs spécifiés seront enregistrés dans des variables d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir être utilisés par d'autres modules.
portée
  Il s'agit de la portée 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.example.com/o=Example?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
  Établit une connexion non sécurisée sur le port LDAP par défaut, ce qui est équivalent à `ldap://` sur le port 389.
SSL
  Établit une connexion sécurisée sur le port LDAP sécurisé par défaut, ce qui est équivalent à `ldaps://`.
TLS | STARTTLS
  Établit 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`.

Langues Disponibles: en | fr