Ce module permet aux frontaux d'authentification comme
Lorsqu'on utilise ldap
à la directive
Ce module effectue une mise en cache des résultats du processus
d'authentification et d'autorisation en fonction de la configuration du
module
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
ldap
à la directive
ldap-user
, ldap-dn
et
ldap-group
.
Au cours de la phase d'authentification,
Les directives utilisées durant la phase de recherche/connexion sont les suivantes :
Spécifie le serveur LDAP, le DN de base, l'attribut à utiliser pour la recherche, ainsi que les filtres de recherche supplémentaires. | |
Un DN optionnel pour se connecter durant la phase de recherche. | |
Un mot de passe optionnel pour se connecter durant la phase de recherche. |
Les directives 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.
A partir de la version 2.4.8, les directives require LDAP supportent les expressions.
La directive Require ldap-user
permet de spécifier
les noms des utilisateurs autorisés à accéder à la ressource.
Lorsque 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 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
:
De par la manière dont 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 :
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 :
Les membres peuvent aussi se trouver dans les sous-groupes du
groupe LDAP spécifié si la directive
dn: cn=Employees, o=Example objectClass: groupOfUniqueNames uniqueMember: cn=Managers, o=Example uniqueMember: cn=Administrators, o=Example uniqueMember: cn=Users, o=Example dn: cn=Managers, o=Example objectClass: groupOfUniqueNames uniqueMember: cn=Bob Ellis, o=Example uniqueMember: cn=Tom Jackson, o=Example dn: cn=Administrators, o=Example objectClass: groupOfUniqueNames uniqueMember: cn=Barbara Jenson, o=Example uniqueMember: cn=Fred User, o=Example dn: cn=Users, o=Example objectClass: groupOfUniqueNames uniqueMember: cn=Allan Jefferson, o=Example uniqueMember: cn=Paul Tilley, o=Example uniqueMember: cn=Temporary Employees, o=Example dn: cn=Temporary Employees, o=Example objectClass: groupOfUniqueNames uniqueMember: cn=Jim Swenson, o=Example uniqueMember: cn=Elliot Rhodes, o=Example
Les directives suivantes autoriseraient alors l'accès à Bob Ellis, Tom Jackson, Barbara Jenson, Fred User, Allan Jefferson, et Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes (car ils sont situés dans un sous-groupe de niveau de profondeur 2) :
Le comportement de cette directive est modifié par les directives
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 :
Le comportement ce cette directive est modifié par la directive
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" :
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" :
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" :
Alors que la directive Require ldap-attribute
se
contente d'une simple comparaison d'attributs, la directive
Require ldap-filter
effectue une opération de recherche
dans l'annuaire LDAP en utilisant le filtre de recherche spécifié.
Si une simple comparaison d'attributs suffit, l'opération de
comparaison effectuée par ldap-attribute
sera plus
rapide que l'opération de recherche effectuée par
ldap-filter
, en particulier dans le cas d'un annuaire
LDAP de grande taille.
Lorsqu'on utilise une expression rationnelle au sein d'un filtre, il faut bien s'assurer que les filtres LDAP sont correctement échappés afin de se prémunir contre toute injection LDAP. A cet effet, il est possible d'utiliser la fonction ldap.
La directive Require ldap-search
permet à
l'administrateur d'autoriser l'accès en fonction d'un filtre de
recherche LDAP générique contenant une expression rationnelle. Si le filtre de
recherche renvoie une et une seule correspondance, l'accès est
accordé sans tenir compte du DN.
La directive suivante accorderait l'accès aux URLs correspondant aux objets spécifiés dans le serveur LDAP :
Note : il faut bien s'assurer que les expressions sont correctement échappés afin de se prémunir contre toute injection LDAP. A cet effet, il est possible d'utiliser la fonction ldap comme dans l'exemple ci-dessus.
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
.
qpagePagerID
. Seuls ces utilisateurs
(authentifiés via leur UID) se verront accorder l'autorisation
d'accès :
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 :
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 à :
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 à :
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
Un second paramètre optionnel peut être ajouté à la directive
Pour l'utilisation de SSL, voir les directives du module
Pour spécifier un serveur LDAP sécurisé, utilisez
ldaps:// au lieu de
ldap:// dans la directive
Au cours du processus d'authentification, les attributs LDAP
spécifiés par la directive
Au cours du processus d'autorisation, les attributs LDAP
spécifiés par la directive
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
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 :
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
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 :
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.
.htaccess
. Elles ne fonctionneront pas si vous les
placez dans une section .htaccess
de FrontPage. Si les directives
de .htaccess
que les directives FrontPage,
la configuration ne fonctionnera pas, car
.htaccess
, et par conséquent ne
pourra jamais trouver le fichier des utilisateurs géré par
FrontPage.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
.
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
Ceci permet aux utilisateurs présent à la fois dans l'annuaire
LDAP et dans un fichier
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
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
Si la directive
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
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é,
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
Si la valeur commence par exec:, la commande résultante sera exécutée, et la première ligne renvoyée sur la sortie standard sera utilisée comme mot de passe.
La directive charset.conv
fourni qui associe les extensions de
langage courantes à leurs jeux de caractères.
Le fichier contient des lignes au format suivant :
L'extension est insensible à la casse. Les lignes vides et les
lignes commençant par un dièse (#
) sont ignorées.
Lorsque cette directive est définie, et si
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
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
Lorsque cette directive est définie à on,
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,
Cette directive permet de spécifier à quel moment
always
.
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,
member
et uniqueMember
.
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
, cn=Babs Jenson, o=Example
est un membre du
groupe. Dans le cas contraire, bjenson
est un membre du groupe.
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é.
Lorsque les directives
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
Cette directive n'a d'effet que si l'on utilise ce module pour l'authentification.
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.
Cette directive n'a d'effet que si l'on utilise ce module pour l'authentification.
Lorsque cette directive est définie, et si
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
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
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
member
et uniqueMember
.
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
groupOfNames
et groupOfUniqueNames
.
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 :
Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs LDAP, la syntaxe sera :
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.
lorsqu'une connection a été établie avec un serveur, elle
reste active pendant toute la durée de vie du processus
Si le serveur LDAP cesse de fonctionner, et ainsi
interrompt une
connexion existante,
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. A partir de la version 2.4.10 du serveur HTTP Apache, le
mot-clé none
permet de désactiver
l'utilisation des filtres, ce qui peut s'avérer nécessaire avec
certains serveurs LDAP primitifs.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