Ce module permet aux frontaux d'authentification comme
Lorsqu'on utilise ldap à la directive
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.
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 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) :
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.
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.
#Mot de passe utilisé tel quel AuthLDAPBindPassword secret #Exécute /path/to/program pour obtenir le mot de passe AuthLDAPBindPassword exec:/path/to/program #Exécute /path/to/otherProgram avec un argument pour obtenir le mot de passe AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
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 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.
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.
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
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, 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
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, 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. 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