Module Apache mod_authnz_ldap

Sommaire

• Mode op�ratoire
  • La phase d'authentification
  • La phase d'autorisation
• Les directives requises
  • Require ldap-user
  • Require ldap-group
  • Require ldap-dn
  • Require ldap-attribute
  • Require ldap-filter
• Exemples
• Utilisation de TLS
• Utilisation de SSL
• Mise � disposition des informations de connexion
• Utilisation d'Active Directory
• Utilisation de Microsoft FrontPage avec mod_authnz_ldap
  • Comment �a marche
  • Mises en garde

Mode op�ratoire

L'utilisateur se voit accorder l'acc�s selon un processus en deux phases. La premi�re phase est l'authentification, au cours de laquelle le fournisseur d'authentification mod_authnz_ldap v�rifie que les informations de connexion de l'utilisateur sont valides. Elle est aussi connue sous le nom de phase de recherche/connexion (NdT : en anglais ou dans le code source : search/bind). La deuxi�me phase est l'autorisation, au cours de laquelle mod_authnz_ldap d�termine si l'utilisateur authentifi� a la permission d'acc�der � la ressource consid�r�e. Elle est aussi connue sous le nom de phase de comparaison (compare).

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

La phase d'authentification

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

1. Confection d'un filtre de recherche en combinant les attribut et filtre d�finis par la directive AuthLDAPURL avec le nom d'utilisateur et le mot de passe fournis par le client HTTP.
2. Recherche dans l'annuaire LDAP en utilisant le filtre confectionn� pr�c�demment. Si le r�sultat de la recherche est n�gatif ou comporte plusieurs entr�es, refus ou restriction de l'acc�s.
3. Extraction du DN (distinguished name) de l'entr�e issue du r�sultat de la recherche, et tentative de connexion au serveur LDAP en utilisant ce DN et le mot de passe fournis par le client HTTP. Si la connexion �choue, refus ou restriction de l'acc�s.

Les directives utilis�es durant la phase de recherche/connexion sont les suivantes :

La phase d'autorisation

Au cours de la phase d'autorisation, mod_authnz_ldap tente de d�terminer si l'utilisateur est autoris� � acc�der � la ressource consid�r�e. Une grande partie de cette v�rification consiste pour mod_authnz_ldap en des op�rations de comparaison au niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue sous le nom de phase de comparaison. mod_authnz_ldap accepte les directives Require suivantes pour d�terminer si les informations de connexion permettent d'accorder l'acc�s � l'utilisateur :

• Avec la directive Require ldap-user, l'autorisation d'acc�s est accord�e si le nom d'utilisateur sp�cifi� par la directive correspond au nom d'utilisateur fourni par le client.
• Avec la directive Require ldap-dn, l'autorisation d'acc�s est accord�e si le DN sp�cifi� par la directive correspond au DN extrait du r�sultat de la recherche dans l'annuaire LDAP.
• Avec la directive Require ldap-group, l'autorisation d'acc�s est accord�e si le DN extrait du r�sultat de la recherche dans l'annuaire LDAP (ou le nom d'utilisateur fourni par le client) appartient au groupe LDAP sp�cifi� par la directive, ou �ventuellement � un de ses sous-groupes.
• Avec la directive Require ldap-attribute, l'autorisation d'acc�s est accord�e si la valeur de l'attribut extraite de la recherche dans l'annuaire LDAP correspond � la valeur sp�cifi�e par la directive.
• Avec la directive Require ldap-filter, l'autorisation d'acc�s est accord�e si le filtre de recherche renvoie un objet utilisateur unique qui corresponde au DN de l'utilisateur authentifi�.
• dans tous les autres cas, refus ou restriction de l'acc�s.

Sous r�serve du chargement de modules d'autorisation suppl�mentaires, d'autres valeurs de la directive Require peuvent �tre sp�cifi�es.

• L'acc�s est accord� � tous les utilisateurs authentifi�s si une directive Require valid-user est pr�sente (n�cessite le module mod_authz_user).
• Avec la directive Require group, l'autorisation d'acc�s est accord�e si le module mod_authz_groupfile a �t� charg� et si la directive AuthGroupFile a �t� d�finie.
• etc...

Durant la phase de comparaison, mod_authnz_ldap utilise les directives suivantes :

Les directives requises

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

Require ldap-user

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

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

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

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

Require ldap-user bjenson fuser jmanager

Require ldap-group

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

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

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

Require ldap-group cn=Administrators, o=Example

Les membres peuvent aussi se trouver dans les sous-groupes du groupe LDAP sp�cifi� si la directive AuthLDAPMaxSubGroupDepth a �t� d�finie � une valeur sup�rieure � 0. Par exemple, supposons que les entr�es suivantes existent dans l'annuaire LDAP :

dn: cn=Employees, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Managers, o=Example
uniqueMember: cn=Administrators, o=Example
uniqueMember: cn=Users, o=Example

dn: cn=Managers, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Bob Ellis, o=Example
uniqueMember: cn=Tom Jackson, o=Example

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

dn: cn=Users, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Allan Jefferson, o=Example
uniqueMember: cn=Paul Tilley, o=Example
uniqueMember: cn=Temporary Employees, o=Example

dn: cn=Temporary Employees, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Jim Swenson, o=Example
uniqueMember: cn=Elliot Rhodes, o=Example

Les directives suivantes autoriseraient alors l'acc�s � Bob Ellis, Tom Jackson, Barbara Jensen, Fred User, Allan Jefferson, et Paul Tilley, mais l'interdiraient � Jim Swenson, ou Elliot Rhodes (car ils sont situ�s dans un sous-groupe de niveau de profondeur 2) :

Require ldap-group cn=Employees, o-Example
AuthLDAPMaxSubGroupDepth 1

Le comportement de cette directive est modifi� par les directives AuthLDAPGroupAttribute, AuthLDAPGroupAttributeIsDN, AuthLDAPMaxSubGroupDepth, AuthLDAPSubGroupAttribute, et AuthLDAPSubGroupClass.

Require ldap-dn

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

La directive suivante accorderait l'acc�s � un DN sp�cifique :

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

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

Require ldap-attribute

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

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

Require ldap-attribute employeeType=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

Require ldap-filter

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

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

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

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

Exemples

• Accorde l'autorisation d'acc�s � tout utilisateur pr�sent dans l'annuaire LDAP, en utilisant son UID pour effectuer la recherche :

  AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
  Require valid-user
  

• L'exemple suivant est similaire au pr�c�dent, mais les champs dont les valeurs par d�faut conviennent sont omis. Notez aussi la pr�sence d'un annuaire LDAP redondant :

  AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
  Require valid-user
  

• Encore un exemple similaire aux pr�c�dents, mais cette fois, c'est l'attribut cn qui est utilis� pour la recherche � la place de l'UID. Notez que ceci peut poser probl�me si plusieurs utilisateurs de l'annuaire partagent le m�me cn, car une recherche sur le cn doit retourner une entr�e et une seule. C'est pourquoi cette approche n'est pas recommand�e : il est pr�f�rable de choisir un attribut de votre annuaire dont l'unicit� soit garantie, comme uid.

  AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
  Require valid-user
  

• Accorde l'autorisation d'acc�s � tout utilisateur appartenant au groupe Administrateurs. Les utilisateurs doivent s'authentifier en utilisant leur UID :

  AuthLDAPURL ldap://ldap.example.com/o=Example?uid
  Require ldap-group cn=Administrators, o=Example
  

• Pour l'exemple suivant, on suppose que tout utilisateur de chez Example qui dispose d'un bippeur alphanum�rique poss�dera un attribut LDAP qpagePagerID. Seuls ces utilisateurs (authentifi�s via leur UID) se verront accorder l'autorisation d'acc�s :

  AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
  Require valid-user
  

• L'exemple suivant illustre la puissance des filtres pour effectuer des requ�tes complexes. Sans les filtres, il aurait �t� n�cessaire de cr�er un nouveau groupe LDAP et de s'assurer de la synchronisation des membres du groupe avec les utilisateurs poss�dant un bippeur. Tout devient limpide avec les filtres. Nous avons pour but d'accorder l'autorisation d'acc�s � tout utilisateur disposant d'un bippeur ainsi qu'� Joe Manager qui ne poss�de pas de bippeur, mais doit tout de m�me pouvoir acc�der � la ressource :

  AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
  Require valid-user
  

  Ce dernier exemple peut sembler confus au premier abord ; en fait, il permet de mieux comprendre � quoi doit ressembler le filtre en fonction de l'utilisateur qui se connecte. Si Fred User se connecte en tant que fuser, le filtre devra ressembler � :

  (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))

  Un recherche avec le filtre ci-dessus ne retournera un r�sultat positif que si fuser dispose d'un bippeur. Si Joe Manager se connecte en tant que jmanager, le filtre devra ressembler � :

  (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))

  Un recherche avec le filtre ci-dessus retournera un r�sultat positif que jmanager dispose d'un bippeur ou non

Utilisation de TLS

Pour l'utilisation de TLS, voir les directives du module mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

Un second param�tre optionnel peut �tre ajout� � la directive AuthLDAPURL pour remplacer le type de connexion par d�faut d�fini par la directive LDAPTrustedMode. Ceci permettra de promouvoir la connexion �tablie via une URL du type ldap:// au statut de connection s�curis�e sur le m�me port.

Utilisation de SSL

Pour l'utilisation de SSL, voir les directives du module mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.

Pour sp�cifier un serveur LDAP s�curis�, utilisez ldaps:// au lieu de ldap:// dans la directive AuthLDAPURL.

Mise � disposition des informations de connexion

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

Au cours du processus d'autorisation, les attributs LDAP sp�cifi�s par la directive authldapurl sont enregistr�s dans des variables d'environnement pr�fix�es par la cha�ne "AUTHORIZE_".

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

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

Utilisation d'Active Directory

Active Directory peut supporter plusieurs domaines � la fois. Pour faire la distinction entre les utilisateurs de plusieurs domaines, on peut ajouter � l'entr�e de l'utilisateur dans l'annuaire un identifiant appel� Nom Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se compose en g�n�ral du nom de compte de l'utilisateur, suivi du nom du domaine consid�r�, par exemple [email protected].

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, [email protected] et [email protected] 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 [email protected]
AuthLDAPBindPassword password
AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub

Les utilisateurs devront s'authentifier en entrant leur UPN, de la forme[email protected].

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       "the url"
AuthGroupFile     mygroupfile
Require group     mygroupfile

Comment �a marche

FrontPage restreint l'acc�s � un site web en ajoutant la directive Require valid-user aux fichiers .htaccess. La directive Require valid-user permettra l'acc�s � tout utilisateur valide du point de vue LDAP. Cela signifie que tout utilisateur poss�dant une entr�e dans l'annuaire LDAP sera consid�r� comme valide, alors que FrontPage ne consid�re comme valides que les utilisateurs enregistr�s dans le fichier des utilisateurs local. En rempla�ant l'autorisation par groupe LDAP par une autorisation par fichier de groupe, Apache sera en mesure de consulter le fichier des utilisateurs local (g�r� par FrontPage) - au lieu de l'annuaire LDAP - lors du processus d'autorisation des utilisateurs.

Une fois les directives ajout�es selon ce qui pr�c�de, les utilisateurs FrontPage pourront effectuer toutes les op�rations de gestion � partir du client FrontPage.

Avertissements

• Lors du choix de l'URL LDAP, l'attribut � utiliser pour l'authentification doit aussi �tre valide pour le fichier des utilisateurs de mod_authn_file. A cette fin, l'UID est id�al.
• Lorsqu'ils ajoutent des utilisateurs via FrontPage, les administrateurs de FrontPage doivent choisir des noms d'utilisateurs qui existent d�j� dans l'annuaire LDAP (pour des raisons �videntes). De m�me, le mot de passe que l'administrateur entre dans le formulaire est ignor�, car pour l'authentification, Apache utilise le mot de passe de l'annuaire LDAP, et non le mot de passe enregistr� dans le fichier des utilisateurs, ce qui peut semer la confusion parmi les administrateurs web.
• Pour supporter FrontPage, Apache doit �tre compil� avec mod_auth_basic, mod_authn_file et mod_authz_groupfile. Ceci est d� au fait qu'Apache doit utiliser le fichier de groupes de mod_authz_groupfile pour d�terminer le niveau d'acc�s d'un utilisateur au site web FrontPage.
• Les directives doivent �tre plac�es dans les fichiers .htaccess. Elles ne fonctionneront pas si vous les placez dans une section <Location> ou <Directory>. Ceci est d� au fait que pour savoir o� se trouve la liste des utilisateurs valides, mod_authnz_ldap doit �tre en mesure d'atteindre la directive AuthGroupFile qui se trouve dans les fichiers .htaccess de FrontPage. Si les directives de mod_authnz_ldap ne sont pas situ�es dans le m�me fichier .htaccess que les directives FrontPage, la configuration ne fonctionnera pas, car mod_authnz_ldap ne sera jamais en mesure de traiter le fichier .htaccess, et par cons�quent ne pourra jamais trouver le fichier des utilisateurs g�r� par FrontPage.