Serveur Apache HTTP Version 2.4
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 |
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
.
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
.
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 :
AuthLDAPURL
avec le nom d'utilisateur et le mot de
passe fournis par le client HTTP.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. |
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 :
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.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.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.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.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é.Sous réserve du chargement de modules d'autorisation
supplémentaires, d'autres valeurs de la directive Require
peuvent être
spécifiées.
Require
valid-user
est présente (nécessite le module
mod_authz_user
).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.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 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.
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
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 AuthLDAPMaxSubGroupDepth 1
Le comportement de cette directive est modifié par les directives
AuthLDAPGroupAttribute
,
AuthLDAPGroupAttributeIsDN
,
AuthLDAPMaxSubGroupDepth
,
AuthLDAPSubGroupAttribute
, et
AuthLDAPSubGroupClass
.
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
.
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
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.
AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)" Require valid-user
AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example" Require valid-user
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
AuthLDAPURL ldap://ldap.example.com/o=Example?uid Require ldap-group cn=Administrators, o=Example
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
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.
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
.
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.
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.
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
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.
mod_authn_file
. A cette fin,
l'UID est idéal.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..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.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.
Require
valid-user
.
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.
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.
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.
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.
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
.
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.
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
.
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
.
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.
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
.
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
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é.
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.
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.
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
.
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
.
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
.
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 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.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.
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.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.(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 :
ldap://
sur le port
389.ldaps://
.Voir plus haut pour des exemples d'URLs définies par la directive
AuthLDAPURL
.