Apache Module mod_authnz_ldap

Available Languages: en

Available Languages: en | + fr

@@ -1121,7 +1122,8 @@ You can of course use search parameters on each of these.

Available Languages: en

Available Languages: en | + fr

diff --git a/docs/manual/mod/mod_authnz_ldap.html.fr b/docs/manual/mod/mod_authnz_ldap.html.fr new file mode 100644 index 0000000000..05b920c252 --- /dev/null +++ b/docs/manual/mod/mod_authnz_ldap.html.fr @@ -0,0 +1,1248 @@ + + + +mod_authnz_ldap - Serveur Apache HTTP + + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3 > Modules

Module Apache mod_authnz_ldap

Langues Disponibles: en | + fr

Description:	Allows an LDAP directory to be used to store the database for HTTP Basic authentication.

+ + + +

Description:	Permet d'utiliser un annuaire LDAP pour l'authentification +HTTP de base.
Statut:	Extension
Identificateur de Module:	authnz_ldap_module
Fichier Source:	mod_authnz_ldap.c
Compatibilité:	Dosponible depuis les versions 2.1 et supérieures +d'Apache

Sommaire

+ +

Ce module permet aux frontaux d'authentification comme + mod_auth_basic d'authentifier les utilisateurs via + un annuaire ldap.

+ +

mod_authnz_ldap supporte les fonctionnalités + suivantes :

+ +

Support vérifié du OpenLDAP SDK (versions 1.x et + 2.x), du + Novell LDAP SDK et du SDK iPlanet + (Netscape).
Implémentation de politiques d'autorisation complexes en les + définissant via des filtres LDAP.
Mise en oeuvre d'une mise en cache des opérations LDAP + élaborée via mod_ldap.
Support de LDAP via SSL (nécessite le SDK Netscape) ou TLS + (nécessite le SDK OpenLDAP 2.x ou le SDK LDAP Novell).

+ +

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

+ +

Sommaire

+ +

+ Mode opératoire + +
- La phase + d'authentification
- La phase d'autorisation
+
+ Les directives requises + +
+
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 :

+ +

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.
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.
Extraction du DN (distinguished name) de l'entrée issue du + résultat de la recherche, et tentative de connexion au serveur + LDAP en utilisant ce DN et le mot de passe fournis par le client + HTTP. Si la connexion échoue, refus ou restriction de + l'accès.

+ +

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

+ + + + + + + + + + + + + + + + + + + + +

`AuthLDAPURL`	Spécifie le serveur LDAP, le DN de base, l'attribut à + utiliser pour la recherche, ainsi que les filtres de recherche + supplémentaires.
`AuthLDAPBindDN`	Un DN optionnel pour se connecter durant la phase de + recherche.
`AuthLDAPBindPassword`	Un mot de passe optionnel pour se connecter durant la phase + de recherche.

+ + +

La phase d'autorisation

+ +

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

+ +

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 :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

`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 requises

+ +

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

+ +

Require ldap-user

+ +

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

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

+ +

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

+ +

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

Require ldap-user bjenson fuser jmanager

+ + +

Require ldap-group

+ +

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

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

+ +

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

Require ldap-group cn=Administrators, o=Airius

+ +

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=Airius +objectClass: groupOfUniqueNames +uniqueMember: cn=Managers, o=Airius +uniqueMember: cn=Administrators, o=Airius +uniqueMember: cn=Users, o=Airius + +dn: cn=Managers, o=Airius +objectClass: groupOfUniqueNames +uniqueMember: cn=Bob Ellis, o=Airius +uniqueMember: cn=Tom Jackson, o=Airius + +dn: cn=Administrators, o=Airius +objectClass: groupOfUniqueNames +uniqueMember: cn=Barbara Jenson, o=Airius +uniqueMember: cn=Fred User, o=Airius + +dn: cn=Users, o=Airius +objectClass: groupOfUniqueNames +uniqueMember: cn=Allan Jefferson, o=Airius +uniqueMember: cn=Paul Tilley, o=Airius +uniqueMember: cn=Temporary Employees, o=Airius + +dn: cn=Temporary Employees, o=Airius +objectClass: groupOfUniqueNames +uniqueMember: cn=Jim Swenson, o=Airius +uniqueMember: cn=Elliot Rhodes, o=Airius +

+ +

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-Airius +AuthLDAPSubGroupDepth 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=Airius

+ +

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

+ + +

Require ldap-attribute

+ +

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

+ +

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

+ +

Require ldap-attribute employeeType=actif

+ +

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

+ +

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

+ +

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

+ + + +

Require ldap-filter

+ +

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

+ +

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

+ +

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

+ +

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

+ + + +

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.airius.com:389/ou=People, o=Airius?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.airius.com ldap2.airius.com/ou=People, o=Airius" +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.airius.com/ou=People, o=Airius?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.airius.com/o=Airius?uid +Require ldap-group cn=Administrators, o=Airius +
+
+ Pour l'exemple suivant, on suppose que tout utilisateur de chez + Airius 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.airius.com/o=Airius?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.airius.com/o=Airius?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_".

+ +

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 untel@nz.exemple.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.exemple.com et + untel@au.exemple.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@exemple.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.exemple.com.

+ +

Utilisation de Microsoft + FrontPage avec mod_authnz_ldap

+ +

Normalement, FrontPage utilise des fichiers utilisateur/groupe + spécifiques à FrontPage-web (c'est à dire les modules + mod_authn_file et + mod_authz_groupfile) pour effectuer toute + l'authentification. Malheureusement, il ne suffit pas de modifier + l'authentification LDAP en ajoutant les directives appropriées, car + ceci corromprait les formulaires de Permissions dans le + client FrontPage, qui sont censés modifier les fichiers + d'autorisation standards au format texte.

+ +

Lorsqu'un site web FrontPage a été créé, lui adjoindre + l'authentification LDAP consiste à ajouter les directives suivantes + à chaque fichier .htaccess qui sera créé dans + le site web :

+AuthLDAPURL            "l'url"
+AuthGroupFile mon-fichier-de-groupes
+Require group mon-fichier-de-groupes
+

+ +

Comment ça marche

+ +

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

+ +

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

+ + +

Avertissements

+ +

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.

+ +

AuthLDAPBindDN Directive

+ + + + + + + +

Description:	Un DN optionnel pour se connecter au serveur +LDAP
Syntaxe:	`AuthLDAPBindDN dn`
Contexte:	répertoire, .htaccess
Annuler:	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.

+ +

AuthLDAPBindPassword Directive

+ + + + + + + +

Description:	Mot de passe à utiliser en conjonction avec le DN de +connexion
Syntaxe:	`AuthLDAPBindPassword mot-de-passe`
Contexte:	répertoire, .htaccess
Annuler:	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.

+ +

AuthLDAPCharsetConfig Directive

+ + + + + + +

Description:	Chemin du fichier de configuration de la correspondance +langage/jeu de caractères
Syntaxe:	`AuthLDAPCharsetConfig chemin-fichier`
Contexte:	configuration du serveur
Statut:	Extension
Module:	mod_authnz_ldap

La directive AuthLDAPCharsetConfig permet + de définir le chemin du fichier de configuration de la + correspondance langage/jeu de caractères. chemin-fichier + est un chemin relatif au répertoire défini par la directive + ServerRoot. Ce fichier contient une liste + de correspondances extension de langage/jeu de caractères. La + plupart des administrateurs utilisent le fichier + charset.conv fourni qui associe les extensions de + langage courantes à leurs jeux de caractères.

+ +

Le fichier contient des lignes au format suivant :

+ +

+ extension de langage jeu de caractères + [Nom du langage] ... +

+ +

L'extension est insensible à la casse. Les lignes vides et les + lignes commençant par un dièse (#) sont ignorées.

+ +

AuthLDAPCompareDNOnServer Directive

+ + + + + + + + +

Description:	Utilise le serveur LDAP pour comparer les DNs
Syntaxe:	`AuthLDAPCompareDNOnServer on\|off`
Défaut:	`AuthLDAPCompareDNOnServer on`
Contexte:	répertoire, .htaccess
Annuler:	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.

+ +

AuthLDAPDereferenceAliases Directive

+ + + + + + + + +

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
Annuler:	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.

+ +

AuthLDAPGroupAttribute Directive

+ + + + + + + +

Description:	L'attribut LDAP utilisé pour vérifier l'appartenance d'un +utilisateur à un groupe.
Syntaxe:	`AuthLDAPGroupAttribute attribut`
Contexte:	répertoire, .htaccess
Annuler:	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.

+ +

AuthLDAPGroupAttributeIsDN Directive

+ + + + + + + + +

Description:	Utilise le DN de l'utilisateur pour vérifier son +appartenance à un groupe
Syntaxe:	`AuthLDAPGroupAttributeIsDN on\|off`
Défaut:	`AuthLDAPGroupAttributeIsDN on`
Contexte:	répertoire, .htaccess
Annuler:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

Lorsqu'elle est définie à on, cette directive + indique que c'est le DN de l'utilisateur qui doit être utilisé pour + vérifier son appartenance à un groupe. Dans le cas contraire, c'est + le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que + le client envoie le nom d'utilisateur bjenson, qui + correspond au DN LDAP cn=Babs Jenson,o=Airius. Si la + directive est à on, mod_authnz_ldap va + vérifier si cn=Babs Jenson, o=Airius est un membre du + groupe. Dans le cas contraire, mod_authnz_ldap + vérifiera si bjenson est un membre du groupe.

+ +

AuthLDAPMaxSubGroupDepth Directive

+ + + + + + + + +

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
Annuler:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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

+ +

AuthLDAPRemoteUserAttribute Directive

+ + + + + + + + +

Description:	Spécifie l'attribut dont la valeur renvoyée au cours de la +requête de l'utilisateur sera utilisée pour définir la variable +d'environnement REMOTE_USER
Syntaxe:	`AuthLDAPRemoteUserAttribute uid`
Défaut:	`none`
Contexte:	répertoire, .htaccess
Annuler:	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.

+ +

AuthLDAPRemoteUserIsDN Directive

+ + + + + + + + +

Description:	Utilise le DN de l'utilisateur pour définir la variable +d'environnement REMOTE_USER
Syntaxe:	`AuthLDAPRemoteUserIsDN on\|off`
Défaut:	`AuthLDAPRemoteUserIsDN off`
Contexte:	répertoire, .htaccess
Annuler:	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.

+ +

AuthLDAPSubGroupAttribute Directive

+ + + + + + + +

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`
Contexte:	répertoire, .htaccess
Annuler:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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.

+ +

AuthLDAPSubGroupClass Directive

+ + + + + + + +

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`
Contexte:	répertoire, .htaccess
Annuler:	AuthConfig
Statut:	Extension
Module:	mod_authnz_ldap

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.

+ +

AuthLDAPUrl Directive

+ + + + + + + +

Description:	L'URL permettant de spécifier les paramètres de la +recherche LDAP
Syntaxe:	`AuthLDAPUrl url [NONE\|SSL\|TLS\|STARTTLS]`
Contexte:	répertoire, .htaccess
Annuler:	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.exemple.com +ldap2.exemple.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 non sécurisé, utilisez la chaîne + ldap. Pour ldap sécurisé, utilisez à la place la + chaîne ldaps. LDAP sécurisé n'est disponible que si + Apache a été lié avec une bibliothèque LDAP supportant SSL.

hôte:port

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

DN-de-base

Le DN de la branche de l'annuaire à partir de laquelle + toutes les recherches seront lancées. Il doit au moins + correspondre à la racine de votre annuaire, mais vous pouvez + aussi indiquer une branche plus spécifique.

attribut

Il s'agit de l'attribut à utiliser pour la recherche. + Bien que la RFC + 2255 autorise une liste d'attributs séparés par des virgules, + seul le premier sera retenu, sans tenir compte des autres + attributs fournis. Si aucun attribut n'est fourni, l'attribut + par défaut est uid. Il est judicieux de choisir un + attribut dont la valeur sera unique parmi toutes les entrées de + la branche de l'annuaire que vous aurez définie. 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.

portée

Il s'agit de la portée de la recherche. Elle peut prendre + les valeurs one ou sub. Notez que la + RFC 2255 supporte aussi une portée de valeur base, + mais cette dernière n'est pas supportée par le module. Si la + portée n'est pas définie, ou si elle est définie à + base, c'est la valeur de portée par défaut + sub qui sera utilisée.

filtre

Il s'agit d'un filtre de recherche LDAP valide. Si aucun + filtre n'est spécifié, le filtre par défaut + (objectClass=*) sera utilisé, ce qui corrspond à + une recherche de tous les types d'objets de l'arborescence. La + taille des filtres est limitée à environ 8000 caractères (valeur + de la macro MAX_STRING_LEN dans le code source + d'Apache), ce qui s'avère plus que suffisant pour la plupart des + applications.

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

Apache Module mod_setenvif

Available Languages: en | + fr | ja | ko | tr

@@ -296,6 +297,7 @@ without respect to case

Available Languages: en | + fr | ja | ko | tr

diff --git a/docs/manual/mod/mod_setenvif.html.fr b/docs/manual/mod/mod_setenvif.html.fr new file mode 100644 index 0000000000..bbf463b54f --- /dev/null +++ b/docs/manual/mod/mod_setenvif.html.fr @@ -0,0 +1,317 @@ + + + +mod_setenvif - Serveur Apache HTTP + + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.3 > Modules

Module Apache mod_setenvif

Langues Disponibles: en | + fr | + ja | + ko | + tr

+ + + +

Description:	Permet de définir des variables d'environnement en fonction +de caractéristiques de la requête
Statut:	Base
Identificateur de Module:	setenvif_module
Fichier Source:	mod_setenvif.c

Sommaire

+ + +

Le module mod_setenvif vous permet de définir + des variables d'environnement en fonction du fait que telle ou telle + caractéristique de la requête correspond ou non aux expressions + rationnelles que vous spécifiez. Ces variables d'environnement + peuvent être utilisées par d'autres parties du serveur pour prendre + des décisions quant aux actions à entreprendre.

+ +

Les directives sont interprétées selon l'ordre dans lequel elles + apparaîssent dans les fichiers de configuration. Ainsi, des + séquences plus complexes peuvent être utilisées, comme dans cet + exemple qui définit netscape si le navigateur est Mozilla et non + MSIE.

+ +

+ BrowserMatch ^Mozilla netscape + BrowserMatch MSIE !netscape +

Voir aussi

Les variables d'environnement dans +Apache

+ +

BrowserMatch Directive

+ + + + + + + +

Description:	Définit des variables d'environnement en fonction du +contenu de l'en-tête HTTP User-Agent
Syntaxe:	`BrowserMatch regex [!]env-variable[=valeur] +[[!]env-variable[=valeur]] ...`
Contexte:	configuration du serveur, serveur virtuel, répertoire, .htaccess
Annuler:	FileInfo
Statut:	Base
Module:	mod_setenvif

La directive BrowserMatch est un cas + particulier de la directive SetEnvIf, qui définit des variables + d'environnement en fonction du contenu de l'en-tête de requête HTTP + User-Agent. Les deux lignes suivantes produisent le même + effet :

+ BrowserMatchNoCase Robot est_un_robot + SetEnvIfNoCase User-Agent Robot est_un_robot +

+ +

Quelques exemples supplémentaires :

+ BrowserMatch ^Mozilla forms jpeg=yes browser=netscape + BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript + BrowserMatch MSIE !javascript +

+ +

BrowserMatchNoCase Directive

+ + + + + + + + +

Description:	Définit des variables d'environnement en fonction du +contenu de l'en-tête HTTP User-Agent sans tenir compte de la +casse
Syntaxe:	`BrowserMatchNoCase regex [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ...`
Contexte:	configuration du serveur, serveur virtuel, répertoire, .htaccess
Annuler:	FileInfo
Statut:	Base
Module:	mod_setenvif
Compatibilité:	Versions 1.2 d'Apache et supérieures (dans Apache 1.2, +cette directive se trouvait dans le module mod_browser devenu depuis +obsolète)

+ +

La directive BrowserMatchNoCase est + identique sur le plan sémantique à la directive BrowserMatch. Elle permet + cependant une comparaison insensible à la casse. Par exemple :

+ BrowserMatchNoCase mac platform=macintosh + BrowserMatchNoCase win platform=windows +

+ +

Les directives BrowserMatch et + BrowserMatchNoCase sont des cas particuliers + des directives SetEnvIf + et SetEnvIfNoCase. + Ainsi, les deux lignes suivantes produisent le même effet :

+ BrowserMatchNoCase Robot est_un_robot + SetEnvIfNoCase User-Agent Robot est_un_robot +

+ +

SetEnvIf Directive

+ + + + + + + +

Description:	Définit des variables d'environnement en fonction des +attributs de la requête
Syntaxe:	`SetEnvIf attribut + regex [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ...`
Contexte:	configuration du serveur, serveur virtuel, répertoire, .htaccess
Annuler:	FileInfo
Statut:	Base
Module:	mod_setenvif

La directive SetEnvIf permet de définir + des variables d'environnement en fonction des attributs de la + requête. L'attribut spécifié comme premier argument peut + se présenter sous l'une des quatre formes suivantes :

+ +

Un champ d'en-tête de requête HTTP (voir la RFC2616 pour + plus d'information à leur propos) ; par exemple : Host, + User-Agent, Referer, ou + Accept-Language. Il est possible d'utiliser une + expression rationnelle pour spécifier un jeu d'en-têtes de + requête.
Une des caractéristiques de la requête suivantes : +
- Remote_Host - le nom d'hôte (s'il est disponible) + du client qui effectue la requête
- Remote_Addr - l'adresse IP du client qui effectue + la requête
- Server_Addr - l'adresse IP du serveur qui a reçu + la requête (uniquement à partir des versions supérieures à + 2.0.43)
- Request_Method - Le nom de la méthode HTTP + utilisée (GET, POST, et + cetera...)
- Request_Protocol - le nom et la version du + protocole utilisé pour la requête (par exemple "HTTP/0.9", + "HTTP/1.1", etc...)
- Request_URI - la ressource demandée dans la ligne + de requête HTTP -- en général la partie de l'URL suivant le + protocole et le nom du serveur, sans la chaîne d'arguments. Voir + la directive RewriteCond du module + mod_rewrite pour plus d'informations sur la + manière de mettre en correspondance votre chaîne d'arguments.
+
Le nom d'une variable d'environnement parmi la liste de celles qui +sont associées à la requête. Ceci permet à la directive +SetEnvIf d'effectuer des tests en fonction du +résultat de comparaisons précédentes. Seules les variables +d'environnement définies par des directives +SetEnvIf[NoCase] précédentes sont disponibles pour +effectuer des tests de cette manière. 'Précédentes' signifie qu'elles se +trouvent à un niveau plus global de la configuration (par exemple au +niveau du serveur principal), ou plus haut chronologiquement dans le +contexte de la directive. Les variables d'environnement ne seront prises +en compte que si aucune correspondance n'a été trouvée parmi les +caractéristiques de la requête, et si attribut n'a pas été +spécifié sous la forme d'une expression rationnelle.
La référence à une extension d'un certificat client SSL, localisé +par son identifiant objet oid. Dans le cas d'une requête non +SSL, ou en l'absence d'oid configuré, aucune variable ne sera +définie. Si l'oid est trouvé plusieurs fois, les chaînes +individuelles seront concaténées, en les séparant par des virgules +','. L'oid doit faire référence à une extension +sous forme de chaîne. +

+ +

Le second argument (regex) est une expression rationnelle. Si regex +correspond à l'attribut, les arguments suivants sont évalués.

+ +

Le reste des arguments constitue les noms des variables à définir, +ainsi que les valeurs optionnelles qui doivent leur être affectées. Ils +peuvent se présenter sous les formes suivantes :

+ +

nom-variable, or
!nom-variable, or
nom-variable=valeur

+ +

Dans la première forme, la valeur sera définie à "1". Dans la + seconde forme, la variable sera supprimée si elle a été définie au + préalable, et dans la troisième forme, la variable sera définie à la + valeur littérale spécifiée par valeur. Depuis + la version 2.0.51, Apache reconnaît les occurrences de variables + $1..$9 à l'intérieur de + valeur, et les remplace par les + sous-expressions entre parenthèses correspondantes de + regex.

+ +

Example:

+ + SetEnvIf Request_URI "\.gif$" objet_est_une_image=gif + SetEnvIf Request_URI "\.jpg$" objet_est_une_image=jpg + SetEnvIf Request_URI "\.xbm$" objet_est_une_image=xbm + : + SetEnvIf Referer www\.mon-domaine\.exemple\.com référant_intra_site + : + SetEnvIf objet_est_une_image xbm XBIT_PROCESSING=1 + : + SetEnvIf OID("2.16.840.1.113730.1.13") "(.*)" commentaire-netscape=$1 + : + SetEnvIf ^TS* ^[a-z].* HAVE_TS +

+ +

Les trois premières lignes définissent la variable + d'environnement objet_est_une_image si l'objet de la + requête est un fichier image, et la quatrième définit la variable + référant_intra_site si la page référante se trouve + quelque part dans le site web + www.mon-domaine.exemple.com.

+ +

La sixième ligne définit la variable d'environnement + commentaire-netscape avec la chaîne trouvée dans le + champ du certificat client SSL correspondant.

+ +

La dernière ligne définit la variable d'environnement + HAVE_TS si la requête contient un en-tête dont le nom + commence par "TS" et dont la valeur commence par tout caractère du + jeu [a-z].

+ +

Voir aussi

Les variables d'environnement dans +Apache pour des exemples supplémentaires. +

SetEnvIfNoCase Directive

+ + + + + + + + +

Description:	Définit des variables d'environnement en fonction des +attributs de la requête sans tenir compte de la casse
Syntaxe:	`SetEnvIfNoCase attribut regex + [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ...`
Contexte:	configuration du serveur, serveur virtuel, répertoire, .htaccess
Annuler:	FileInfo
Statut:	Base
Module:	mod_setenvif
Compatibilité:	Versions 1.3 d'Apache et supérieures

+ +

La directive SetEnvIfNoCase est identique + d'un point de vue sémantique à la directive SetEnvIf, et ne s'en distingue que + par le fait que la comparaison des expressions rationnelles est + effectuée sans tenir compte de la casse. Par exemple :

+ SetEnvIfNoCase Host Apache\.Org site=apache +

+ +

Cette ligne va définir la variable d'environnement + site avec la valeur "apache" si le champ + d'en-tête de requête HTTP Host: est présent et contient + Apache.Org, apache.org, ou une autre + combinaison des mêmes caractères, sans tenir compte de la casse.

+ +

Langues Disponibles: en | + fr | + ja | + ko | + tr

+ \ No newline at end of file diff --git a/docs/manual/mod/mod_setenvif.xml.fr b/docs/manual/mod/mod_setenvif.xml.fr new file mode 100644 index 0000000000..ef3d48c852 --- /dev/null +++ b/docs/manual/mod/mod_setenvif.xml.fr @@ -0,0 +1,303 @@ + + + + + + + + + + + +mod_setenvif +Permet de définir des variables d'environnement en fonction +de caractéristiques de la requête +Base +mod_setenvif.c +setenvif_module + +

+ +

Le module mod_setenvif vous permet de définir + des variables d'environnement en fonction du fait que telle ou telle + caractéristique de la requête correspond ou non aux expressions + rationnelles que vous spécifiez. Ces variables d'environnement + peuvent être utilisées par d'autres parties du serveur pour prendre + des décisions quant aux actions à entreprendre.

+ +

+ + + BrowserMatch ^Mozilla netscape
+ BrowserMatch MSIE !netscape
+ +

+ +Les variables d'environnement dans +Apache + + +BrowserMatch +Définit des variables d'environnement en fonction du +contenu de l'en-tête HTTP User-Agent +BrowserMatch regex [!]env-variable[=valeur] +[[!]env-variable[=valeur]] ... +server config +virtual hostdirectory +.htaccess +FileInfo + + +

La directive BrowserMatch est un cas + particulier de la directive SetEnvIf, qui définit des variables + d'environnement en fonction du contenu de l'en-tête de requête HTTP + User-Agent. Les deux lignes suivantes produisent le même + effet :

+ + BrowserMatchNoCase Robot est_un_robot
+ SetEnvIfNoCase User-Agent Robot est_un_robot
+ + +

Quelques exemples supplémentaires :

+ + BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
+ BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
+ BrowserMatch MSIE !javascript
+ + + + + +BrowserMatchNoCase +Définit des variables d'environnement en fonction du +contenu de l'en-tête HTTP User-Agent sans tenir compte de la +casse +BrowserMatchNoCase regex [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ... +server config +virtual hostdirectory +.htaccess +FileInfo +Versions 1.2 d'Apache et supérieures (dans Apache 1.2, +cette directive se trouvait dans le module mod_browser devenu depuis +obsolète) + + + +

La directive BrowserMatchNoCase est + identique sur le plan sémantique à la directive BrowserMatch. Elle permet + cependant une comparaison insensible à la casse. Par exemple :

+ + BrowserMatchNoCase mac platform=macintosh
+ BrowserMatchNoCase win platform=windows
+ + +

Les directives BrowserMatch et + BrowserMatchNoCase sont des cas particuliers + des directives SetEnvIf + et SetEnvIfNoCase. + Ainsi, les deux lignes suivantes produisent le même effet :

+ + BrowserMatchNoCase Robot est_un_robot
+ SetEnvIfNoCase User-Agent Robot est_un_robot
+ + + + + +SetEnvIf +Définit des variables d'environnement en fonction des +attributs de la requête +SetEnvIf attribut + regex [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ... +server config +virtual hostdirectory +.htaccess +FileInfo + + +

La directive SetEnvIf permet de définir + des variables d'environnement en fonction des attributs de la + requête. L'attribut spécifié comme premier argument peut + se présenter sous l'une des quatre formes suivantes :

+ +

Un champ d'en-tête de requête HTTP (voir la RFC2616 pour + plus d'information à leur propos) ; par exemple : Host, + User-Agent, Referer, ou + Accept-Language. Il est possible d'utiliser une + expression rationnelle pour spécifier un jeu d'en-têtes de + requête.
Une des caractéristiques de la requête suivantes : +
- Remote_Host - le nom d'hôte (s'il est disponible) + du client qui effectue la requête
- Remote_Addr - l'adresse IP du client qui effectue + la requête
- Server_Addr - l'adresse IP du serveur qui a reçu + la requête (uniquement à partir des versions supérieures à + 2.0.43)
- Request_Method - Le nom de la méthode HTTP + utilisée (GET, POST, et + cetera...)
- Request_Protocol - le nom et la version du + protocole utilisé pour la requête (par exemple "HTTP/0.9", + "HTTP/1.1", etc...)
- Request_URI - la ressource demandée dans la ligne + de requête HTTP -- en général la partie de l'URL suivant le + protocole et le nom du serveur, sans la chaîne d'arguments. Voir + la directive RewriteCond du module + mod_rewrite pour plus d'informations sur la + manière de mettre en correspondance votre chaîne d'arguments.
+
Le nom d'une variable d'environnement parmi la liste de celles qui +sont associées à la requête. Ceci permet à la directive +SetEnvIf d'effectuer des tests en fonction du +résultat de comparaisons précédentes. Seules les variables +d'environnement définies par des directives +SetEnvIf[NoCase] précédentes sont disponibles pour +effectuer des tests de cette manière. 'Précédentes' signifie qu'elles se +trouvent à un niveau plus global de la configuration (par exemple au +niveau du serveur principal), ou plus haut chronologiquement dans le +contexte de la directive. Les variables d'environnement ne seront prises +en compte que si aucune correspondance n'a été trouvée parmi les +caractéristiques de la requête, et si attribut n'a pas été +spécifié sous la forme d'une expression rationnelle.
La référence à une extension d'un certificat client SSL, localisé +par son identifiant objet oid. Dans le cas d'une requête non +SSL, ou en l'absence d'oid configuré, aucune variable ne sera +définie. Si l'oid est trouvé plusieurs fois, les chaînes +individuelles seront concaténées, en les séparant par des virgules +','. L'oid doit faire référence à une extension +sous forme de chaîne. +

+ +

Le second argument (regex) est une expression rationnelle. Si regex +correspond à l'attribut, les arguments suivants sont évalués.

+ +

Le reste des arguments constitue les noms des variables à définir, +ainsi que les valeurs optionnelles qui doivent leur être affectées. Ils +peuvent se présenter sous les formes suivantes :

+ +

nom-variable, or
!nom-variable, or
nom-variable=valeur

+ +

+ + +Example: + SetEnvIf Request_URI "\.gif$" objet_est_une_image=gif
+ SetEnvIf Request_URI "\.jpg$" objet_est_une_image=jpg
+ SetEnvIf Request_URI "\.xbm$" objet_est_une_image=xbm
+ :
+ SetEnvIf Referer www\.mon-domaine\.exemple\.com référant_intra_site
+ :
+ SetEnvIf objet_est_une_image xbm XBIT_PROCESSING=1
+ :
+ SetEnvIf OID("2.16.840.1.113730.1.13") "(.*)" commentaire-netscape=$1
+ :
+ SetEnvIf ^TS* ^[a-z].* HAVE_TS
+ + +

+ +

La sixième ligne définit la variable d'environnement + commentaire-netscape avec la chaîne trouvée dans le + champ du certificat client SSL correspondant.

+ +

La dernière ligne définit la variable d'environnement + HAVE_TS si la requête contient un en-tête dont le nom + commence par "TS" et dont la valeur commence par tout caractère du + jeu [a-z].

+ + +Les variables d'environnement dans +Apache pour des exemples supplémentaires. + + + + +SetEnvIfNoCase +Définit des variables d'environnement en fonction des +attributs de la requête sans tenir compte de la casse +SetEnvIfNoCase attribut regex + [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ... +server config +virtual hostdirectory +.htaccess +FileInfo +Versions 1.3 d'Apache et supérieures + + + +

La directive SetEnvIfNoCase est identique + d'un point de vue sémantique à la directive SetEnvIf, et ne s'en distingue que + par le fait que la comparaison des expressions rationnelles est + effectuée sans tenir compte de la casse. Par exemple :

+ + SetEnvIfNoCase Host Apache\.Org site=apache + + +

+ + + diff --git a/docs/manual/mod/mod_setenvif.xml.meta b/docs/manual/mod/mod_setenvif.xml.meta index 3da6990bad..7486caae19 100644 --- a/docs/manual/mod/mod_setenvif.xml.meta +++ b/docs/manual/mod/mod_setenvif.xml.meta @@ -8,6 +8,7 @@ en + fr ja ko tr -- 2.40.0

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.

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

Apache Module mod_authnz_ldap

Module Apache mod_authnz_ldap

Sommaire

Directives

Sujets

Voir aussi

Apache Module mod_setenvif

Module Apache mod_setenvif

Sommaire

Directives

Voir aussi

Example:

Voir aussi