<-
Apache > Serveur HTTP > Documentation > Version 2.2 > 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 :

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

Directives

Sujets

Voir aussi

top

Sommaire

top

Mode opératoire

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

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

La phase d'authentification

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

  1. Construction d'un filtre de recherche en combinant les attribut et filtre définis par la directive AuthLDAPURL avec le nom d'utilisateur et le mot de passe fournis par le client HTTP.
  2. Recherche dans l'annuaire LDAP en utilisant le filtre construit précédemment. Si le résultat de la recherche est négatif ou comporte plusieurs entrées, refus ou restriction de l'accès.
  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 :

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

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

Les directives requises

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

Require ldap-user

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

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

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

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

Require ldap-user bjenson fuser jmanager

Require ldap-group

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

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

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

Require ldap-group cn=Administrators, o=Airius

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

Require ldap-dn

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

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

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

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

Require ldap-attribute

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

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

Require ldap-attribute employeeType=actif

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

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

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

Require ldap-filter

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

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

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

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

top

Exemples

top

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.

top

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.

top

Mise à disposition des informations de connexion

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

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

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

top

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

top

AuthLDAPBindAuthoritative Directive

Description:Détermine si d'autres fournisseurs d'authentification doivent être utilisés lorsqu'un utilisateur correspond à un DN, alors que le serveur ne parvient pas à se connecter avec les données d'authentification.
Syntaxe:AuthLDAPBindAuthoritativeoff|on
Défaut:AuthLDAPBindAuhtoritative on
Contexte:répertoire, .htaccess
AllowOverride:AuthConfig
Statut:Extension
Module:mod_authnz_ldap
Compatibilité:Disponible dans les versions supérieures à 2.2.14

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

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

Voir aussi

top

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.

top

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.

top

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.

top

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 de faux négatifs, mais elle est beaucoup plus rapide. Notez cependant que le cache de mod_ldap peut accélérer la comparaison de DNs dans la plupart des situations.

top

AuthLDAPDereferenceAliases Directive

Description:A 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.

top

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.

top

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

top

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.

top

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.

top

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

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

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

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

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

DN-de-
Le DN de la branche de l'annuaire à partir de laquelle toutes les recherches seront lancées. Il doit au moins correspondre à la racine de votre annuaire, mais vous pouvez aussi indiquer une branche plus spécifique.
attribut
Il s'agit de l'attribut à utiliser pour la recherche. Bien que la RFC 2255 autorise une liste d'attributs séparés par des virgules, seul le premier sera retenu, sans tenir compte des autres attributs fournis. Si aucun attribut n'est fourni, l'attribut par défaut est uid. Il est judicieux de choisir un attribut dont la valeur sera unique parmi toutes les entrées de la branche de l'annuaire que vous aurez définie.
portée
Il s'agit de la portée (scope) de la recherche. Elle peut prendre les valeurs one ou sub. Notez que la RFC 2255 supporte aussi une portée de valeur base, mais cette dernière n'est pas supportée par le module. Si la portée n'est pas définie, ou si elle est définie à base, c'est la valeur de portée par défaut sub qui sera utilisée.
filtre
Il s'agit d'un filtre de recherche LDAP valide. Si aucun filtre n'est spécifié, le filtre par défaut (objectClass=*) sera utilisé, ce qui corrspond à une recherche de tous les types d'objets de l'arborescence. La taille des filtres est limitée à environ 8000 caractères (valeur de la macro MAX_STRING_LEN dans le code source d'Apache), ce qui s'avère plus que suffisant pour la plupart des applications.

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

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

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

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

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

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

top

AuthzLDAPAuthoritative Directive

Description:Empêche tout autre module d'authentification d'authentifier l'utilisateur si le module courant échoue.
Syntaxe:AuthzLDAPAuthoritative on|off
Défaut:AuthzLDAPAuthoritative on
Contexte:répertoire, .htaccess
AllowOverride:AuthConfig
Statut:Extension
Module:mod_authnz_ldap

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

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

Langues Disponibles:  en  |  fr