1 <?xml version="1.0" encoding="UTF-8" ?>
2 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
4 <!-- English Revision: 1736705 -->
5 <!-- French translation : Lucien GENTIS -->
6 <!-- Reviewed by : Vincent Deffontaines -->
9 Licensed to the Apache Software Foundation (ASF) under one or more
10 contributor license agreements. See the NOTICE file distributed with
11 this work for additional information regarding copyright ownership.
12 The ASF licenses this file to You under the Apache License, Version 2.0
13 (the "License"); you may not use this file except in compliance with
14 the License. You may obtain a copy of the License at
16 http://www.apache.org/licenses/LICENSE-2.0
18 Unless required by applicable law or agreed to in writing, software
19 distributed under the License is distributed on an "AS IS" BASIS,
20 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
21 See the License for the specific language governing permissions and
22 limitations under the License.
25 <modulesynopsis metafile="mod_authnz_ldap.xml.meta">
27 <name>mod_authnz_ldap</name>
28 <description>Permet d'utiliser un annuaire LDAP pour l'authentification
29 HTTP de base.</description>
30 <status>Extension</status>
31 <sourcefile>mod_authnz_ldap.c</sourcefile>
32 <identifier>authnz_ldap_module</identifier>
35 <p>Ce module permet aux frontaux d'authentification comme
36 <module>mod_auth_basic</module> d'authentifier les utilisateurs via
39 <p><module>mod_authnz_ldap</module> supporte les fonctionnalités
43 <li>Support vérifié du <a
44 href="http://www.openldap.org/">OpenLDAP SDK</a> (versions 1.x et
45 2.x), du <a href="http://developer.novell.com/ndk/cldap.htm">
46 Novell LDAP SDK</a> et du SDK <a
47 href="http://www.iplanet.com/downloads/developer/">iPlanet
50 <li>Implémentation de politiques d'autorisation complexes en les
51 définissant via des filtres LDAP.</li>
53 <li>Mise en oeuvre d'une mise en cache des opérations LDAP
54 élaborée via <a href="mod_ldap.html">mod_ldap</a>.</li>
56 <li>Support de LDAP via SSL (nécessite le SDK Netscape) ou TLS
57 (nécessite le SDK OpenLDAP 2.x ou le SDK LDAP Novell).</li>
60 <p>Lorsqu'on utilise <module>mod_auth_basic</module>, ce module est
61 invoqué en affectant la valeur <code>ldap</code> à la directive
62 <directive module="mod_auth_basic">AuthBasicProvider</directive>.</p>
65 <seealso><module>mod_ldap</module></seealso>
66 <seealso><module>mod_auth_basic</module></seealso>
67 <seealso><module>mod_authz_user</module></seealso>
68 <seealso><module>mod_authz_groupfile</module></seealso>
70 <section id="contents"><title>Sommaire</title>
73 <li> <a href="#gcaveats">Mises en garde à caractère général</a> </li>
74 <li> <a href="#operation">Mode opératoire</a>
77 <li><a href="#authenphase">La phase
78 d'authentification</a></li>
80 <li><a href="#authorphase">La phase d'autorisation</a></li>
85 <a href="#requiredirectives">Les directives requises</a>
88 <li><a href="#requser">Require ldap-user</a></li>
89 <li><a href="#reqgroup">Require ldap-group</a></li>
90 <li><a href="#reqdn">Require ldap-dn</a></li>
91 <li><a href="#reqattribute">Require ldap-attribute</a></li>
92 <li><a href="#reqfilter">Require ldap-filter</a></li>
93 <li><a href="#reqsearch">Require ldap-search</a></li>
97 <li><a href="#examples">Exemples</a></li>
98 <li><a href="#usingtls">Utilisation de TLS</a></li>
99 <li><a href="#usingssl">Utilisation de SSL</a></li>
100 <li><a href="#exposed">Mise à disposition des informations de
102 <li><a href="#activedirectory">Utilisation d'Active Directory</a></li>
104 <a href="#frontpage">Utilisation de Microsoft FrontPage avec
105 <module>mod_authnz_ldap</module></a>
108 <li><a href="#howitworks">Comment ça marche</a></li>
109 <li><a href="#fpcaveats">Mises en garde</a></li>
115 <section id="gcaveats"><title>Mises en garde à caractère général</title>
116 <p>Ce module effectue une mise en cache des résultats du processus
117 d'authentification et d'autorisation en fonction de la configuration du
118 module <module>mod_ldap</module>. Les modifications effectuées au niveau
119 du serveur LDAP d'arrière-plan comme les
120 verrouillages ou révocations d'utilisateurs, les changements de mot de
121 passe, ou les changements d'appartenance à un groupe (et cette liste
122 n'est pas exhaustive), ne seront pas immédiatement propagées jusqu'au
123 serveur HTTP. Consultez les directives du module
124 <module>mod_ldap</module> pour plus de détails à propos de la
125 configuration de la mise en cache.
129 <section id="operation"><title>Mode opératoire</title>
131 <p>L'utilisateur se voit accorder l'accès selon un processus en deux
132 phases. La première phase est l'authentification, au cours de
133 laquelle le fournisseur d'authentification
134 <module>mod_authnz_ldap</module> vérifie que les informations de
135 connexion de l'utilisateur sont valides. Elle est aussi connue sous
136 le nom de phase de <em>recherche/connexion</em> (NdT : en anglais ou
137 dans le code source : <em>search/bind</em>). La deuxième
138 phase est l'autorisation, au cours de laquelle
139 <module>mod_authnz_ldap</module> détermine si l'utilisateur
140 authentifié a la permission d'accéder à la ressource considérée.
141 Elle est aussi connue sous le nom de phase de
142 <em>comparaison</em> (<em>compare</em>).</p>
144 <p><module>mod_authnz_ldap</module> comporte un fournisseur
145 d'authentification authn_ldap et un gestionnaire d'autorisation
146 authz_ldap. Le fournisseur d'authentification authn_ldap peut être
147 invoqué en affectant la valeur <code>ldap</code> à la directive
148 <directive module="mod_auth_basic">AuthBasicProvider</directive>. Le
149 gestionnaire d'autorisation authz_ldap enrichit la liste des types
150 d'autorisations de la directive <directive
151 module="mod_authz_core">Require</directive> en y ajoutant les
152 valeurs <code>ldap-user</code>, <code>ldap-dn</code> et
153 <code>ldap-group</code>.</p>
155 <section id="authenphase"><title>La phase d'authentification</title>
157 <p>Au cours de la phase d'authentification,
158 <module>mod_authnz_ldap</module> recherche une entrée de l'annuaire
159 LDAP qui correspond au nom d'utilisateur fourni par le client HTTP.
160 Si une correspondance unique est trouvée,
161 <module>mod_authnz_ldap</module> tente de se connecter au serveur
162 hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot
163 de passe fourni par le client HTTP. Comme ce processus effectue tout
164 d'abord une recherche, puis une connexion, il est aussi connu sous
165 le nom de phase de recherche/connexion. Voici le détail des étapes
166 constituant la phase de recherche/connexion :</p>
169 <li>Confection d'un filtre de recherche en combinant les attribut
170 et filtre définis par la directive <directive module="mod_authnz_ldap"
171 >AuthLDAPURL</directive> avec le nom d'utilisateur et le mot de
172 passe fournis par le client HTTP.</li>
174 <li>Recherche dans l'annuaire LDAP en utilisant le filtre
175 confectionné précédemment. Si le résultat de la recherche est
176 négatif ou comporte plusieurs entrées, refus ou restriction de
179 <li>Extraction du DN (distinguished name) de l'entrée issue du
180 résultat de la recherche, et tentative de connexion au serveur
181 LDAP en utilisant ce DN et le mot de passe fournis par le client
182 HTTP. Si la connexion échoue, refus ou restriction de
186 <p>Les directives utilisées durant la phase de recherche/connexion
187 sont les suivantes :</p>
190 <columnspec><column width=".3"/><column width=".7"/></columnspec>
193 module="mod_authnz_ldap">AuthLDAPURL</directive></td>
195 <td>Spécifie le serveur LDAP, le DN de base, l'attribut à
196 utiliser pour la recherche, ainsi que les filtres de recherche
197 supplémentaires.</td>
202 module="mod_authnz_ldap">AuthLDAPBindDN</directive></td>
204 <td>Un DN optionnel pour se connecter durant la phase de
210 module="mod_authnz_ldap">AuthLDAPBindPassword</directive></td>
212 <td>Un mot de passe optionnel pour se connecter durant la phase
218 <section id="authorphase"><title>La phase d'autorisation</title>
220 <p>Au cours de la phase d'autorisation,
221 <module>mod_authnz_ldap</module> tente de déterminer si
222 l'utilisateur est autorisé à accéder à la ressource considérée. Une
223 grande partie de cette vérification consiste pour
224 <module>mod_authnz_ldap</module> en des opérations de comparaison au
225 niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue
226 sous le nom de phase de comparaison.
227 <module>mod_authnz_ldap</module> accepte les directives <directive
228 module="mod_authz_core">Require</directive> suivantes pour
229 déterminer si les informations de connexion permettent d'accorder
230 l'accès à l'utilisateur :</p>
233 <li>Avec la directive <a
234 href="#reqgroup"><code>Require ldap-user</code></a>,
235 l'autorisation d'accès est accordée si le nom d'utilisateur
236 spécifié par la directive correspond au nom d'utilisateur fourni
239 <li>Avec la directive <a href="#reqdn"><code>Require
240 ldap-dn</code></a>, l'autorisation d'accès est accordée si le DN
241 spécifié par la directive correspond au DN extrait du résultat de
242 la recherche dans l'annuaire LDAP.</li>
244 <li>Avec la directive <a
245 href="#reqgroup"><code>Require ldap-group</code></a>,
246 l'autorisation d'accès est accordée si le DN extrait du résultat de
247 la recherche dans l'annuaire LDAP (ou le nom d'utilisateur fourni
248 par le client) appartient au groupe LDAP spécifié par la
249 directive, ou éventuellement à un de ses sous-groupes.</li>
251 <li>Avec la directive <a href="#reqattribute">
252 <code>Require ldap-attribute</code></a>, l'autorisation d'accès
253 est accordée si la valeur de l'attribut extraite de la recherche
254 dans l'annuaire LDAP correspond à la valeur spécifiée par la
257 <li>Avec la directive <a href="#reqfilter">
258 <code>Require ldap-filter</code></a>, l'autorisation d'accès
259 est accordée si le filtre de recherche renvoie un objet
260 utilisateur unique qui corresponde au DN de l'utilisateur
263 <li>Avec la directive <a href="#reqsearch">
264 <code>Require ldap-search</code></a>, l'autorisation d'accès
265 est accordée si le filtre de recherche renvoie avec succès
266 un seul objet correspondant aux critères avec tout nom distinctif
269 <li>dans tous les autres cas, refus ou restriction de
273 <p>Sous réserve du chargement de modules d'autorisation
274 supplémentaires, d'autres valeurs de la directive <directive
275 module="mod_authz_core">Require</directive> peuvent être
279 <li>L'accès est accordé à tous les utilisateurs authentifiés si
280 une directive <a href="#requser"><code>Require
281 valid-user</code></a> est présente (nécessite le module
282 <module>mod_authz_user</module>).</li>
284 <li>Avec la directive <a
285 href="#reqgroup"><code>Require group</code></a>, l'autorisation
286 d'accès est accordée si le module
287 <module>mod_authz_groupfile</module> a été chargé et si la
289 module="mod_authz_groupfile">AuthGroupFile</directive> a été
296 <p>Durant la phase de comparaison, <module>mod_authnz_ldap</module>
297 utilise les directives suivantes :</p>
300 <columnspec><column width=".4"/><column width=".6"/></columnspec>
302 <td><directive module="mod_authnz_ldap">AuthLDAPURL</directive>
305 <td>On utilise l'attribut spécifié dans l'URL pour les
306 opérations de comparaison initiées par la directive
307 <code>Require ldap-user</code>.</td>
312 module="mod_authnz_ldap">AuthLDAPCompareDNOnServer</directive></td>
314 <td>Détermine le comportement de la directive <code>Require
320 module="mod_authnz_ldap">AuthLDAPGroupAttribute</directive></td>
322 <td>Détermine l'attribut utilisé pour les opérations de
323 comparaison initiées par la directive <code>Require
324 ldap-group</code>.</td>
329 module="mod_authnz_ldap">AuthLDAPGroupAttributeIsDN</directive></td>
331 <td>Spécifie si l'on doit utiliser le DN ou le nom de
332 l'utilisateur lors des opérations de comparaison initiées par la
333 directive <code>Require ldap-group</code>.</td>
338 module="mod_authnz_ldap">AuthLDAPMaxSubGroupDepth</directive></td>
340 <td>Détermine la profondeur maximale de l'arborescence des
341 sous-groupes qui seront évalués au cours des opérations de
342 comparaisons initiées par la directive <code>Require
343 ldap-group</code>.</td>
348 module="mod_authnz_ldap">AuthLDAPSubGroupAttribute</directive></td>
350 <td>Détermine l'attribut à utiliser lors de l'extraction de
351 membres de sous-groupes du groupe courant au cours des
352 opérations de comparaison initiées par la directive
353 <code>Require ldap-group</code>.</td>
358 module="mod_authnz_ldap">AuthLDAPSubGroupClass</directive></td>
360 <td>Spécifie les valeurs de classe d'objet LDAP à utiliser pour
361 déterminer si les objets extraits de l'annuaire sont bien des
362 objets de type groupe (et non des objets de type utilisateur),
363 au cours du traitement des sous-groupes initié par la directive
364 <code>Require ldap-group</code>.</td>
370 <section id="requiredirectives"><title>Les directives requises</title>
372 <p>Les directives <directive
373 module="mod_authz_core">Require</directive> d'Apache sont utilisées
374 au cours de la phase d'autorisation afin de s'assurer que
375 l'utilisateur est autorisé à accéder à une ressource.
376 mod_authnz_ldap enrichit la liste des types d'autorisations avec les
377 valeurs <code>ldap-user</code>, <code>ldap-dn</code>,
378 <code>ldap-group</code>, <code>ldap-attribute</code> et
379 <code>ldap-filter</code>. D'autres types d'autorisations sont
380 disponibles, sous réserve du chargement de modules d'autorisation
383 <p>A partir de la version 2.4.8, les directives require LDAP
384 supportent les <a href="../expr.html">expressions</a>.</p>
386 <section id="requser"><title>Require ldap-user</title>
388 <p>La directive <code>Require ldap-user</code> permet de spécifier
389 les noms des utilisateurs autorisés à accéder à la ressource.
390 Lorsque <module>mod_authnz_ldap</module> a extrait un DN unique de
391 l'annuaire LDAP, il effectue une opération de comparaison LDAP en
392 utilisant le nom d'utilisateur spécifié par la directive
393 <code>Require ldap-user</code>, pour vérifier si ce nom
394 d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder
395 l'accès à plusieurs utilisateurs en plaçant plusieurs nom
396 d'utilisateurs sur la même ligne séparés par des espaces. Si un nom
397 d'utilisateur contient des espaces, il doit être entouré de
398 guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs
399 en utilisant une directive <code>Require ldap-user</code> par
400 utilisateur. Par exemple, avec la directive <directive
401 module="mod_authnz_ldap">AuthLDAPURL</directive> définie à
402 <code>ldap://ldap/o=Example?cn</code> (spécifiant donc que l'attribut
403 <code>cn</code> sera utilisé pour les recherches), on pourra
404 utiliser les directives Require suivantes pour restreindre l'accès
406 <highlight language="config">
407 Require ldap-user "Barbara Jenson"
408 Require ldap-user "Fred User"
409 Require ldap-user "Joe Manager"
412 <p>De par la manière dont <module>mod_authnz_ldap</module> traite
413 cette directive, Barbara Jenson peut s'authentifier comme
414 <em>Barbara Jenson</em>, <em>Babs Jenson</em> ou tout autre
415 <code>cn</code> sous lequel elle est enregistrée dans l'annuaire
416 LDAP. Une seule ligne <code>Require ldap-user</code> suffit pour
417 toutes les valeurs de l'attribut dans l'entrée LDAP de
420 <p>Si l'attribut <code>uid</code> avait été spécifié à la place de
421 l'attribut <code>cn</code> dans l'URL précédente, les trois lignes
422 ci-dessus auraient pû être condensées en une seule ligne :</p>
423 <highlight language="config">Require ldap-user bjenson fuser jmanager</highlight>
426 <section id="reqgroup"><title>Require ldap-group</title>
428 <p>Cette directive permet de spécifier un groupe LDAP dont les
429 membres auront l'autorisation d'accès. Elle prend comme argument le
430 DN du groupe LDAP. Note : n'entourez pas le nom du groupe avec des
431 guillemets. Par exemple, supposons que l'entrée suivante existe dans
432 l'annuaire LDAP :</p>
434 dn: cn=Administrators, o=Example
435 objectClass: groupOfUniqueNames
436 uniqueMember: cn=Barbara Jenson, o=Example
437 uniqueMember: cn=Fred User, o=Example
440 <p>La directive suivante autoriserait alors l'accès à Fred et
442 <highlight language="config">Require ldap-group cn=Administrators, o=Example</highlight>
444 <p>Les membres peuvent aussi se trouver dans les sous-groupes du
445 groupe LDAP spécifié si la directive <directive
446 module="mod_authnz_ldap">AuthLDAPMaxSubGroupDepth</directive> a été
447 définie à une valeur supérieure à 0. Par exemple, supposons que les
448 entrées suivantes existent dans l'annuaire LDAP :</p>
450 dn: cn=Employees, o=Example
451 objectClass: groupOfUniqueNames
452 uniqueMember: cn=Managers, o=Example
453 uniqueMember: cn=Administrators, o=Example
454 uniqueMember: cn=Users, o=Example
456 dn: cn=Managers, o=Example
457 objectClass: groupOfUniqueNames
458 uniqueMember: cn=Bob Ellis, o=Example
459 uniqueMember: cn=Tom Jackson, o=Example
461 dn: cn=Administrators, o=Example
462 objectClass: groupOfUniqueNames
463 uniqueMember: cn=Barbara Jenson, o=Example
464 uniqueMember: cn=Fred User, o=Example
466 dn: cn=Users, o=Example
467 objectClass: groupOfUniqueNames
468 uniqueMember: cn=Allan Jefferson, o=Example
469 uniqueMember: cn=Paul Tilley, o=Example
470 uniqueMember: cn=Temporary Employees, o=Example
472 dn: cn=Temporary Employees, o=Example
473 objectClass: groupOfUniqueNames
474 uniqueMember: cn=Jim Swenson, o=Example
475 uniqueMember: cn=Elliot Rhodes, o=Example
478 <p>Les directives suivantes autoriseraient alors l'accès à Bob
479 Ellis, Tom Jackson, Barbara Jenson, Fred User, Allan Jefferson, et
480 Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes
481 (car ils sont situés dans un sous-groupe de niveau de profondeur 2)
483 <highlight language="config">
484 Require ldap-group cn=Employees, o=Example
485 AuthLDAPMaxSubGroupDepth 1
488 <p>Le comportement de cette directive est modifié par les directives
490 module="mod_authnz_ldap">AuthLDAPGroupAttribute</directive>,
492 module="mod_authnz_ldap">AuthLDAPGroupAttributeIsDN</directive>,
494 module="mod_authnz_ldap">AuthLDAPMaxSubGroupDepth</directive>,
496 module="mod_authnz_ldap">AuthLDAPSubGroupAttribute</directive>, et
498 module="mod_authnz_ldap">AuthLDAPSubGroupClass</directive>.</p>
501 <section id="reqdn"><title>Require ldap-dn</title>
503 <p>La directive <code>Require ldap-dn</code> permet à
504 l'administrateur d'accorder l'utorisation d'accès en fonction du DN.
505 Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si
507 l'annuaire correspond au DN spécifié par la directive <code>Require
508 ldap-dn</code>, l'autorisation d'accès est accordée. Note :
509 n'entourez pas Le DN de guillemets.</p>
511 <p>La directive suivante accorderait l'accès à un DN spécifique
513 <highlight language="config">Require ldap-dn cn=Barbara Jenson, o=Example</highlight>
515 <p>Le comportement ce cette directive est modifié par la directive
517 module="mod_authnz_ldap">AuthLDAPCompareDNOnServer</directive>.</p>
520 <section id="reqattribute"><title>Require ldap-attribute</title>
522 <p>La directive <code>Require ldap-attribute</code> permet à
523 l'administrateur d'accorder l'autorisation d'accès en fonction des
524 attributs de l'utilisateur authentifié dans l'annuaire LDAP. Si la
525 valeur de l'attribut dans l'annuaire correspond à la valeur
526 spécifiée par la directive, l'autorisation d'accès est accordée.</p>
528 <p>La directive suivante accorderait l'autorisation d'accès à tout
529 utilisateur dont l'attribut employeeType a pour valeur "actif" :</p>
531 <highlight language="config">Require ldap-attribute
532 "employeeType=active"</highlight>
534 <p>Plusieurs paires attribut/valeur peuvent être spécifiées par une
535 même directive en les séparant par des espaces, ou en définissant
536 plusieurs directives <code>Require ldap-attribute</code>. La logique
537 sous-jacente à une liste de paires attribut/valeur est une opération
538 OU. L'autorisation d'accès sera accordée si au moins une paire
539 attribut/valeur de la liste spécifiée correspond à la paire
540 attribut/valeur de l'utilisateur authentifié. Si elle contient des
541 espaces, la valeur, et seulement la valeur, doit être entourée de
544 <p>La directive suivante accorderait l'autorisation d'accès à tout
545 utilisateur dont l'attribut city aurait pour valeur "San Jose", ou
546 donc l'attribut status aurait pour valeur "actif" :</p>
548 <highlight language="config">Require ldap-attribute city="San Jose"
549 "status=active"</highlight>
553 <section id="reqfilter"><title>Require ldap-filter</title>
555 <p>La directive <code>Require ldap-filter</code> permet à
556 l'administrateur d'accorder l'autorisation d'accès en fonction d'un
557 filtre de recherche LDAP complexe. L'autorisation d'accès est
558 accordée si le DN renvoyé par le filtre de recherche correspond au
559 DN de l'utilisateur authentifié.</p>
561 <p>La directive suivante accorderait l'autorisation d'accès à tout
562 utilisateur possédant un téléphone cellulaire et faisant partie du
563 département "marketing" :</p>
565 <highlight language="config">Require ldap-filter
566 "&(cell=*)(department=marketing)"</highlight>
568 <p>Alors que la directive <code>Require ldap-attribute</code> se
569 contente d'une simple comparaison d'attributs, la directive
570 <code>Require ldap-filter</code> effectue une opération de recherche
571 dans l'annuaire LDAP en utilisant le filtre de recherche spécifié.
572 Si une simple comparaison d'attributs suffit, l'opération de
573 comparaison effectuée par <code>ldap-attribute</code> sera plus
574 rapide que l'opération de recherche effectuée par
575 <code>ldap-filter</code>, en particulier dans le cas d'un annuaire
576 LDAP de grande taille.</p>
578 <p>Lorsqu'on utilise une <a href="../expr.html">expression
579 rationnelle</a> au sein d'un filtre, il faut bien s'assurer que les
580 filtres LDAP sont correctement échappés afin de se prémunir contre
581 toute injection LDAP. A cet effet, il est possible d'utiliser la
584 <highlight language="config">
585 <LocationMatch "^/dav/(?<SITENAME>[^/]+)/">
587 "(memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)"
588 </LocationMatch>
593 <section id="reqsearch"><title>Require ldap-search</title>
595 <p>La directive <code>Require ldap-search</code> permet à
596 l'administrateur d'autoriser l'accès en fonction d'un filtre de
597 recherche LDAP générique contenant une <a
598 href="../expr.html">expression rationnelle</a>. Si le filtre de
599 recherche renvoie une et une seule correspondance, l'accès est
600 accordé sans tenir compte du DN.</p>
602 <p>La directive suivante accorderait l'accès aux URLs correspondant
603 aux objets spécifiés dans le serveur LDAP :</p>
605 <highlight language="config">
606 <LocationMatch "^/dav/(?<SITENAME>[^/]+)/">
607 Require ldap-search "(cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}}
609 </LocationMatch>
612 <p>Note : il faut bien s'assurer que les
613 expressions sont correctement échappés afin de se prémunir contre
614 toute injection LDAP. A cet effet, il est possible d'utiliser la
615 fonction <strong>ldap</strong> comme dans l'exemple ci-dessus.</p>
621 <section id="examples"><title>Exemples</title>
625 Accorde l'autorisation d'accès à tout utilisateur présent dans
626 l'annuaire LDAP, en utilisant son UID pour effectuer la
628 <highlight language="config">
629 AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
635 L'exemple suivant est similaire au précédent, mais les champs
636 dont les valeurs par défaut conviennent sont omis. Notez aussi
637 la présence d'un annuaire LDAP redondant :
638 <highlight language="config">AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
644 Encore un exemple similaire aux précédents, mais cette fois,
645 c'est l'attribut cn qui est utilisé pour la recherche à la place
646 de l'UID. Notez que ceci peut poser problème si plusieurs
647 utilisateurs de l'annuaire partagent le même <code>cn</code>,
648 car une recherche sur le <code>cn</code> <strong>doit</strong>
649 retourner une entrée et une seule. C'est pourquoi cette
650 approche n'est pas recommandée : il est préférable de choisir un
651 attribut de votre annuaire dont l'unicité soit garantie, comme
653 <highlight language="config">
654 AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
660 Accorde l'autorisation d'accès à tout utilisateur appartenant au
661 groupe Administrateurs. Les utilisateurs doivent s'authentifier
662 en utilisant leur UID :
663 <highlight language="config">
664 AuthLDAPURL ldap://ldap.example.com/o=Example?uid
665 Require ldap-group cn=Administrators, o=Example
670 Accorde l'accès à tout utilisateur appartenant au groupe dont le
671 nom correspond au nom d'hôte du serveur virtuel. Dans cet exemple,
672 on utilise une <a href="../expr.html">expression</a> pour
673 construire le filtre.
674 <highlight language="config">
675 AuthLDAPURL ldap://ldap.example.com/o=Example?uid
676 Require ldap-group cn=%{SERVER_NAME}, o=Example
681 Pour l'exemple suivant, on suppose que tout utilisateur de chez
682 Example qui dispose d'un bippeur alphanumérique possèdera un
683 attribut LDAP <code>qpagePagerID</code>. Seuls ces utilisateurs
684 (authentifiés via leur UID) se verront accorder l'autorisation
686 <highlight language="config">
687 AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
693 <p>L'exemple suivant illustre la puissance des filtres pour
694 effectuer des requêtes complexes. Sans les filtres, il aurait
695 été nécessaire de créer un nouveau groupe LDAP et de s'assurer
696 de la synchronisation des membres du groupe avec les
697 utilisateurs possédant un bippeur. Tout devient limpide avec les
698 filtres. Nous avons pour but d'accorder l'autorisation d'accès à
699 tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager
700 qui ne possède pas de bippeur, mais doit tout de même pouvoir
701 accéder à la ressource :</p>
702 <highlight language="config">
703 AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
707 <p>Ce dernier exemple peut sembler confus au premier abord ; en
708 fait, il permet de mieux comprendre à quoi doit ressembler le
709 filtre en fonction de l'utilisateur qui se connecte. Si Fred
710 User se connecte en tant que <code>fuser</code>, le filtre devra
713 <example>(&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))</example>
715 <p>Un recherche avec le filtre ci-dessus ne retournera un
716 résultat positif que si <em>fuser</em> dispose d'un bippeur. Si
717 Joe Manager se connecte en tant que <em>jmanager</em>, le filtre
718 devra ressembler à :</p>
720 <example>(&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))</example>
722 <p>Un recherche avec le filtre ci-dessus retournera un
723 résultat positif que <em>jmanager</em> dispose d'un
729 <section id="usingtls"><title>Utilisation de TLS</title>
731 <p>Pour l'utilisation de TLS, voir les directives du module
732 <module>mod_ldap</module> <directive
733 module="mod_ldap">LDAPTrustedClientCert</directive>, <directive
734 module="mod_ldap">LDAPTrustedGlobalCert</directive> et <directive
735 module="mod_ldap">LDAPTrustedMode</directive>.</p>
737 <p>Un second paramètre optionnel peut être ajouté à la directive
738 <directive module="mod_authnz_ldap">AuthLDAPURL</directive> pour
739 remplacer le type de connexion par défaut défini par la directive
740 <directive module="mod_ldap">LDAPTrustedMode</directive>. Ceci
741 permettra de promouvoir la connexion établie via une URL du type
742 <em>ldap://</em> au statut de connection sécurisée sur le même
746 <section id="usingssl"><title>Utilisation de SSL</title>
748 <p>Pour l'utilisation de SSL, voir les directives du module
749 <module>mod_ldap</module> <directive
750 module="mod_ldap">LDAPTrustedClientCert</directive>, <directive
751 module="mod_ldap">LDAPTrustedGlobalCert</directive> et <directive
752 module="mod_ldap">LDAPTrustedMode</directive>.</p>
754 <p>Pour spécifier un serveur LDAP sécurisé, utilisez
755 <em>ldaps://</em> au lieu de
756 <em>ldap://</em> dans la directive <directive
757 module="mod_authnz_ldap">AuthLDAPURL</directive>.</p>
760 <section id="exposed"><title>Mise à disposition des informations de
763 <p>Au cours du processus d'<em>authentification</em>, les attributs LDAP
764 spécifiés par la directive <directive
765 module="mod_authnz_ldap">authldapurl</directive> sont enregistrés
766 dans des variables d'environnement préfixées par la chaîne
769 <p>Au cours du processus d'<em>autorisation</em>, les attributs LDAP
770 spécifiés par la directive <directive
771 module="mod_authnz_ldap">authldapurl</directive> sont enregistrés
772 dans des variables d'environnement préfixées par la chaîne
775 <p>Si les champs attribut contiennent le nom, le CN et le numéro de
776 téléphone d'un utilisateur, un programme CGI pourra accéder à ces
777 informations sans devoir effectuer une autre requête LDAP pour
778 les extraire de l'annuaire.</p>
780 <p>Ceci a pour effet de simplifier considérablement le code et la
781 configuration nécessaire de certaines applications web.</p>
785 <section id="activedirectory"><title>Utilisation d'Active
788 <p>Active Directory peut supporter plusieurs domaines à la fois.
789 Pour faire la distinction entre les utilisateurs de plusieurs
790 domaines, on peut ajouter à l'entrée de l'utilisateur dans
791 l'annuaire un identifiant appelé Nom
792 Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se
793 compose en général du nom de compte de l'utilisateur, suivi du nom
794 du domaine considéré, par exemple <em>untel@nz.example.com</em>.</p>
796 <p>Vous voudrez probablement configurer le module
797 <module>mod_authnz_ldap</module> afin de pouvoir authentifier les
798 utilisateurs de n'importe quel domaine de la forêt Active Directory.
799 Ainsi, <em>untel@nz.example.com</em> et
800 <em>untel@au.example.com</em> pourront être authentifiés en une
801 seule fois par la même requête.</p>
803 <p>Pour y parvenir, on utilise le concept de Catalogue Global
804 d'Active Directory. Ce Catalogue Global est une copie en lecture
805 seule des attributs sélectionnés de tous les serveurs de la forêt
806 Active Directory. Une requête vers le
807 Catalogue Global permet donc d'atteindre tous les domaines en une
808 seule fois, sans avoir à se connecter aux différents serveurs, via
809 des liaisons dont certaines peuvent être lentes.</p>
811 <p>Lorsqu'il est activé, la Catalogue Global est un serveur
812 d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL).
813 Pour rechercher un utilisateur, effectuez une recherche sur
814 l'attribut <em>userPrincipalName</em>, avec une base de recherche
815 vide, comme suit :</p>
817 <highlight language="config">
818 AuthLDAPBindDN apache@example.com
819 AuthLDAPBindPassword password
820 AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
823 <p>Les utilisateurs devront s'authentifier en entrant leur UPN, de
824 la forme<em>untel@nz.example.com</em>.</p>
828 <section id="frontpage"><title>Utilisation de Microsoft
829 FrontPage avec mod_authnz_ldap</title>
831 <p>Normalement, FrontPage utilise des fichiers utilisateur/groupe
832 spécifiques à FrontPage-web (c'est à dire les modules
833 <module>mod_authn_file</module> et
834 <module>mod_authz_groupfile</module>) pour effectuer toute
835 l'authentification. Malheureusement, il ne suffit pas de modifier
836 l'authentification LDAP en ajoutant les directives appropriées, car
837 ceci corromprait les formulaires de <em>Permissions</em> dans le
838 client FrontPage, qui sont censés modifier les fichiers
839 d'autorisation standards au format texte.</p>
841 <p>Lorsqu'un site web FrontPage a été créé, lui adjoindre
842 l'authentification LDAP consiste à ajouter les directives suivantes
843 à <em>chaque</em> fichier <code>.htaccess</code> qui sera créé dans
845 <highlight language="config">
846 AuthLDAPURL "the url"
847 AuthGroupFile "mygroupfile"
848 Require group "mygroupfile"
851 <section id="howitworks"><title>Comment ça marche</title>
853 <p>FrontPage restreint l'accès à un site web en ajoutant la
854 directive <code>Require valid-user</code> aux fichiers
855 <code>.htaccess</code>. La directive <code>Require valid-user</code>
856 permettra l'accès à tout utilisateur valide <em>du point de vue
857 LDAP</em>. Cela signifie que tout utilisateur possédant une entrée
858 dans l'annuaire LDAP sera considéré comme valide, alors que
859 FrontPage ne considère comme valides que les utilisateurs
860 enregistrés dans le fichier des utilisateurs local. En remplaçant
861 l'autorisation par groupe LDAP par une autorisation par fichier de
862 groupe, Apache sera en mesure de consulter le fichier des
863 utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP
864 - lors du processus d'autorisation des utilisateurs.</p>
866 <p>Une fois les directives ajoutées selon ce qui précède, les
867 utilisateurs FrontPage pourront effectuer toutes les opérations de
868 gestion à partir du client FrontPage.</p>
871 <section id="fpcaveats"><title>Avertissements</title>
874 <li>Lors du choix de l'URL LDAP, l'attribut à utiliser pour
875 l'authentification doit aussi être valide pour le fichier des
876 utilisateurs de <module>mod_authn_file</module>. A cette fin,
877 l'UID est idéal.</li>
879 <li>Lorsqu'ils ajoutent des utilisateurs via FrontPage, les
880 administrateurs de FrontPage doivent choisir des noms
881 d'utilisateurs qui existent déjà dans l'annuaire LDAP (pour des
882 raisons évidentes). De même, le mot de passe que l'administrateur
883 entre dans le formulaire est ignoré, car pour l'authentification,
884 Apache utilise le mot de passe de l'annuaire LDAP, et non le mot
885 de passe enregistré dans le fichier des utilisateurs, ce qui peut
886 semer la confusion parmi les administrateurs web.</li>
888 <!-- XXX is that true? was mod_auth before the aaa change -->
889 <li>Pour supporter FrontPage, Apache doit être compilé avec
890 <module>mod_auth_basic</module>, <module>mod_authn_file</module>
891 et <module>mod_authz_groupfile</module>. Ceci est dû au fait
892 qu'Apache doit utiliser le fichier de groupes de
893 <module>mod_authz_groupfile</module> pour déterminer le niveau
894 d'accès d'un utilisateur au site web FrontPage.</li>
896 <li>Les directives doivent être placées dans les fichiers
897 <code>.htaccess</code>. Elles ne fonctionneront pas si vous les
898 placez dans une section <directive module="core"
899 type="section">Location</directive> ou <directive module="core"
900 type="section">Directory</directive>. Ceci est dû au fait que pour savoir
901 où se trouve la liste des utilisateurs valides,
902 <module>mod_authnz_ldap</module> doit être en mesure d'atteindre
903 la directive <directive
904 module="mod_authz_groupfile">AuthGroupFile</directive> qui se trouve
905 dans les fichiers <code>.htaccess</code> de FrontPage. Si les directives
906 de <module>mod_authnz_ldap</module> ne sont pas situées dans le
907 même fichier <code>.htaccess</code> que les directives FrontPage,
908 la configuration ne fonctionnera pas, car
909 <module>mod_authnz_ldap</module> ne sera jamais en mesure de
910 traiter le fichier <code>.htaccess</code>, et par conséquent ne
911 pourra jamais trouver le fichier des utilisateurs géré par
918 <name>AuthLDAPAuthorizePrefix</name>
919 <description>Spécifie le préfixe ajouté aux variables d'environnement
920 durant la phase d'autorisation</description>
921 <syntax>AuthLDAPAuthorizePrefix <em>préfixe</em></syntax>
922 <default>AuthLDAPAuthorizePrefix AUTHORIZE_</default>
923 <contextlist><context>directory</context><context>.htaccess</context>
925 <override>AuthConfig</override>
926 <compatibility>Disponible depuis la version 2.3.6</compatibility>
928 <p>Cette directive permet de spécifier le préfixe ajouté aux
929 variables d'environnement durant la phase d'autorisation. Si la
930 valeur spécifiée est <em>AUTHENTICATE_</em>, les utilisateurs de ces
931 variables d'environnement verront les mêmes informations, que le
932 serveur effectue une authentification, une autorisation, ou les
935 <note><title>Note</title>
936 Aucune variable d'autorisation n'est définie lorsqu'un utilisateur
937 s'est vu autoriser l'accès via la directive <code>Require
944 <name>AuthLDAPBindAuthoritative</name>
945 <description>Détermine si l'on doit utiliser d'autres fournisseurs
946 d'authentification lorsque le serveur ne peut pas valider les données
947 d'authentification de l'utilisateur, alors que ce dernier possède un
949 <syntax>AuthLDAPBindAuthoritative off|on</syntax>
950 <default>AuthLDAPBindAuthoritative on</default>
951 <contextlist><context>directory</context><context>.htaccess</context>
953 <override>AuthConfig</override>
955 <p>Par défaut, des fournisseurs d'authentification sont appelés
956 si un utilisateur ne possède pas de DN, mais ne le sont pas si
957 l'utilisateur possède un DN et si son mot de passe ne peut pas être
958 vérifié lors d'une connexion au serveur LDAP. Si la directive
959 <directive>AuthLDAPBindAuthoritative</directive> est
960 définie à <em>off</em>, d'autres modules d'authentification
961 configurés auront une chance de valider le mot de passe de
962 l'utilisateur si la tentative de connexion au serveur LDAP échoue
963 pour une raison quelconque (avec les données d'authentification
965 <p>Ceci permet aux utilisateurs présent à la fois dans l'annuaire
966 LDAP et dans un fichier <directive
967 module="mod_authn_file">AuthUserFile</directive> de s'authentifier
968 lorsque le serveur LDAP est disponible, alors que le compte de
969 l'utilisateur est verrouillé ou que son mot de passe est
970 inutilisable pour une raison quelconque.</p>
972 <seealso><directive module="mod_authn_file">AuthUserFile</directive></seealso>
973 <seealso><directive module="mod_auth_basic">AuthBasicProvider</directive></seealso>
977 <name>AuthLDAPInitialBindAsUser</name>
978 <description>Détermine si le serveur effectue la recherche initiale du
979 DN en utilisant le nom propre de l'utilisateur pour l'authentification
981 et non de manière anonyme, ou en utilisant des données d'authentification
982 codées en dur pour le serveur</description>
983 <syntax>AuthLDAPInitialBindAsUser off|on</syntax>
984 <default>AuthLDAPInitialBindAsUser off</default>
985 <contextlist><context>directory</context><context>.htaccess</context>
987 <override>AuthConfig</override>
988 <compatibility>Disponible depuis la version 2.3.6</compatibility>
990 <p>Par défaut, le serveur convertit le nom d'utilisateur pour
991 l'authentification de base en nom distinctif LDAP (DN) soit de
992 manière anonyme, soit avec un couple nom/mot de passe dédié. Cette
993 directive permet de forcer le serveur à utiliser les véritables nom
994 d'utilisateur et mot de passe fournis par l'utilisateur pour
995 effectuer la recherche initiale du DN.</p>
997 <p>Si le nom d'utilisateur ne peut pas s'authentifier directement
998 et nécessite de légères modifications, voir la directive <directive
999 module="mod_authnz_ldap">AuthLDAPInitialBindPattern</directive>.</p>
1001 <p>Cette directive ne doit être utilisée que si votre serveur LDAP
1002 n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
1003 utiliser de nom d'utilisateur dédié via la directive <directive
1004 module="mod_authnz_ldap">AuthLDAPBindDN</directive>.
1007 <note><title>Non disponible dans la cas d'une autorisation seule</title>
1008 On ne peut utiliser cette directive que si ce module
1009 effectue une authentification, et n'a aucun effet si ce module
1010 n'est utilisé que pour les processus d'autorisation.
1013 <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindPattern</directive></seealso>
1014 <seealso><directive module="mod_authnz_ldap">AuthLDAPBindDN</directive></seealso>
1015 <seealso><directive module="mod_authnz_ldap">AuthLDAPCompareAsUser</directive></seealso>
1016 <seealso><directive module="mod_authnz_ldap">AuthLDAPSearchAsUser</directive></seealso>
1017 </directivesynopsis>
1020 <name>AuthLDAPInitialBindPattern</name>
1021 <description>Spécifie la modification a apporter au nom d'utilisateur
1022 pour l'authentification de base lors de l'authentification auprès du
1023 serveur LDAP pour effectuer une recherche de DN</description>
1024 <syntax>AuthLDAPInitialBindPattern <em><var>regex</var> <var>substitution</var></em></syntax>
1025 <default>AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur
1026 distant utilisé tel quel)</default>
1027 <contextlist><context>directory</context><context>.htaccess</context>
1029 <override>AuthConfig</override>
1030 <compatibility>Disponible depuis la version 2.3.6</compatibility>
1032 <p>Si la directive <directive
1033 module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive> est
1034 définie à <em>ON</em>, le nom utilisateur pour l'authentification de
1035 base sera transformé selon l'expression rationnelle
1036 <var>regex</var> et l'argument <var>substitution</var> spécifiés.</p>
1038 <p>L'expression rationnelle est comparée au nom d'utilisateur pour
1039 l'authentification de base courant. L'argument
1040 <var>substitution</var> peut contenir des références arrières, mais
1041 n'effectue aucune autre interpolation de variable.</p>
1043 <p>Cette directive ne doit être utilisée que si votre serveur LDAP
1044 n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
1045 utiliser de nom d'utilisateur dédié via la directive <directive
1046 module="mod_authnz_ldap">AuthLDAPBindDN</directive>.
1049 <highlight language="config"> AuthLDAPInitialBindPattern (.+) $1@example.com </highlight>
1050 <highlight language="config"> AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com</highlight>
1052 <note><title>Non disponible dans la cas d'une autorisation seule</title>
1053 On ne peut utiliser cette directive que si ce module
1054 effectue une authentification, et n'a aucun effet si ce module
1055 n'est utilisé que pour les processus d'autorisation.
1057 <note><title>Débogage</title>
1058 Le DN de substitution est enregistré dans la variable
1059 d'environnement <em>LDAP_BINDASUSER</em>. Si l'expression
1060 rationnelle ne convient pas, le nom d'utilisateur est utilisé
1064 <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive></seealso>
1065 <seealso><directive module="mod_authnz_ldap">AuthLDAPBindDN</directive></seealso>
1066 </directivesynopsis>
1069 <name>AuthLDAPBindDN</name>
1070 <description>Un DN optionnel pour se connecter au serveur
1072 <syntax>AuthLDAPBindDN <em>dn</em></syntax>
1073 <contextlist><context>directory</context><context>.htaccess</context>
1075 <override>AuthConfig</override>
1078 <p>Cette directive permet de définir un DN optionnel pour se
1079 connecter au serveur afin d'y rechercher des entrées. Si aucun DN
1080 n'est spécifié, <module>mod_authnz_ldap</module> tentera une
1081 connexion anonyme.</p>
1083 </directivesynopsis>
1086 <name>AuthLDAPBindPassword</name>
1087 <description>Mot de passe à utiliser en conjonction avec le DN de
1088 connexion</description>
1089 <syntax>AuthLDAPBindPassword <em>mot-de-passe</em></syntax>
1090 <contextlist><context>directory</context><context>.htaccess</context>
1092 <override>AuthConfig</override>
1093 <compatibility><em>exec:</em> est disponible depuis la version 2.4.5 du
1094 serveur HTTP Apache.</compatibility>
1097 <p>Cette directive permet de spécifier un mot de passe à utiliser en
1098 conjonction avec le DN de connexion. Notez que ce mot de passe
1099 constitue en général une donnée sensible, et doit donc être protégé
1100 de manière appropriée. Vous ne devez utiliser les directives
1102 module="mod_authnz_ldap">AuthLDAPBindDN</directive> et
1103 <directive>AuthLDAPBindPassword</directive> que si
1104 vous en avez vraiment besoin pour effectuer une recherche dans
1107 <p>Si la valeur commence par exec:, la commande résultante sera
1108 exécutée, et la première ligne renvoyée sur la sortie standard sera
1109 utilisée comme mot de passe.</p>
1110 <highlight language="config">
1111 #Mot de passe utilisé tel quel
1112 AuthLDAPBindPassword secret
1114 #Exécute /path/to/program pour obtenir le mot de passe
1115 AuthLDAPBindPassword exec:/path/to/program
1117 #Exécute /path/to/otherProgram avec un argument pour obtenir le mot de passe
1118 AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"
1122 </directivesynopsis>
1125 <name>AuthLDAPCharsetConfig</name>
1126 <description>Chemin du fichier de configuration de la correspondance
1127 langage/jeu de caractères</description>
1128 <syntax>AuthLDAPCharsetConfig <em>chemin-fichier</em></syntax>
1129 <contextlist><context>server config</context>
1133 <p>La directive <directive>AuthLDAPCharsetConfig</directive> permet
1134 de définir le chemin du fichier de configuration de la
1135 correspondance langage/jeu de caractères. <var>chemin-fichier</var>
1136 est un chemin relatif au répertoire défini par la directive
1138 module="core">ServerRoot</directive>. Ce fichier contient une liste
1139 de correspondances extension de langage/jeu de caractères. La
1140 plupart des administrateurs utilisent le fichier
1141 <code>charset.conv</code> fourni qui associe les extensions de
1142 langage courantes à leurs jeux de caractères.</p>
1144 <p>Le fichier contient des lignes au format suivant :</p>
1147 <var>extension de langage</var> <var>jeu de caractères</var>
1148 [<var>Nom du langage</var>] ...
1151 <p>L'extension est insensible à la casse. Les lignes vides et les
1152 lignes commençant par un dièse (<code>#</code>) sont ignorées.</p>
1154 </directivesynopsis>
1157 <name>AuthLDAPCompareAsUser</name>
1158 <description>Utilisation des données d'authentification de l'utilisateur
1159 pour effectuer les comparaisons pour l'attribution des autorisations</description>
1160 <syntax>AuthLDAPCompareAsUser on|off</syntax>
1161 <default>AuthLDAPCompareAsUser off</default>
1162 <contextlist><context>directory</context><context>.htaccess</context>
1164 <override>AuthConfig</override>
1165 <compatibility>Disponible depuis la version version 2.3.6</compatibility>
1168 <p>Lorsque cette directive est définie, et si
1169 <module>mod_authnz_ldap</module> a authentifié l'utilisateur, les
1170 recherches LDAP pour les autorisations utilisent le nom distinctif
1171 trouvé (DN) et le mot de passe d'authentification basique HTTP de
1172 l'utilisateur authentifié au lieu des données d'authentification
1173 configurées au niveau du serveur.</p>
1175 <p>Les vérifications d'autorisation <em>ldap-attribute</em>,
1176 <em>ldap-user</em>, et <em>ldap-group</em> (niveau simple seulement)
1177 utilisent des comparaisons.</p>
1179 <p>Cette directive n'a d'effet sur les comparaisons effectuées au
1180 cours des traitements de groupe imbriqués, et lorsque la directive
1181 <directive module="mod_authnz_ldap">AuthLDAPSearchAsUser</directive>
1182 est aussi activée.</p>
1184 <p>Cette directive ne doit être utilisée que si votre serveur LDAP
1185 n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
1186 utiliser de nom d'utilisateur dédié via la directive <directive
1187 module="mod_authnz_ldap">AuthLDAPBindDN</directive>.
1190 <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive></seealso>
1191 <seealso><directive module="mod_authnz_ldap">AuthLDAPSearchAsUser</directive></seealso>
1192 </directivesynopsis>
1195 <name>AuthLDAPCompareDNOnServer</name>
1196 <description>Utilise le serveur LDAP pour comparer les DNs</description>
1197 <syntax>AuthLDAPCompareDNOnServer on|off</syntax>
1198 <default>AuthLDAPCompareDNOnServer on</default>
1199 <contextlist><context>directory</context><context>.htaccess</context>
1201 <override>AuthConfig</override>
1204 <p>Lorsque cette directive est définie à on,
1205 <module>mod_authnz_ldap</module> utilise le serveur LDAP pour
1206 comparer les DNs. Il s'agit de la seule méthode infaillible pour
1207 comparer les DNs. <module>mod_authnz_ldap</module> va rechercher
1208 dans l'annuaire le DN spécifié par la directive <a
1209 href="#reqdn"><code>Require dn</code></a>, puis extraire ce DN et le
1210 comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette
1211 directive est à off, <module>mod_authnz_ldap</module> effectue une
1212 simple comparaison de chaînes. Cette dernière approche peut produire
1213 des faux négatifs, mais elle est beaucoup plus rapide. Notez
1214 cependant que le cache de <module>mod_ldap</module> peut accélérer
1215 la comparaison de DNs dans la plupart des situations.</p>
1217 </directivesynopsis>
1220 <name>AuthLDAPDereferenceAliases</name>
1221 <description>À quel moment le module va déréférencer les
1223 <syntax>AuthLDAPDereferenceAliases never|searching|finding|always</syntax>
1224 <default>AuthLDAPDereferenceAliases always</default>
1225 <contextlist><context>directory</context><context>.htaccess</context>
1227 <override>AuthConfig</override>
1230 <p>Cette directive permet de spécifier à quel moment
1231 <module>mod_authnz_ldap</module> va déréférencer les alias au cours
1232 des opérations liées à LDAP. La valeur par défaut est
1233 <code>always</code>.</p>
1235 </directivesynopsis>
1238 <name>AuthLDAPGroupAttribute</name>
1239 <description>L'attribut LDAP utilisé pour vérifier l'appartenance d'un
1240 utilisateur à un groupe.</description>
1241 <syntax>AuthLDAPGroupAttribute <em>attribut</em></syntax>
1242 <default>AuthLDAPGroupAttribute member uniquemember</default>
1243 <contextlist><context>directory</context><context>.htaccess</context>
1245 <override>AuthConfig</override>
1248 <p>Cette directive permet de spécifier quel attribut LDAP est
1249 utilisé pour vérifier l'appartenance d'un utilisateur à un
1250 groupe. On peut spécifier plusieurs attributs en répétant cette
1251 directive plusieurs fois. Si la directive n'est pas définie,
1252 <module>mod_authnz_ldap</module> utilise les attributs
1253 <code>member</code> et <code>uniquemember</code>.</p>
1255 </directivesynopsis>
1258 <name>AuthLDAPGroupAttributeIsDN</name>
1259 <description>Utilise le DN de l'utilisateur pour vérifier son
1260 appartenance à un groupe</description>
1261 <syntax>AuthLDAPGroupAttributeIsDN on|off</syntax>
1262 <default>AuthLDAPGroupAttributeIsDN on</default>
1263 <contextlist><context>directory</context><context>.htaccess</context>
1265 <override>AuthConfig</override>
1268 <p>Lorsqu'elle est définie à <code>on</code>, cette directive
1269 indique que c'est le DN de l'utilisateur qui doit être utilisé pour
1270 vérifier son appartenance à un groupe. Dans le cas contraire, c'est
1271 le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que
1272 le client envoie le nom d'utilisateur <code>bjenson</code>, qui
1273 correspond au DN LDAP <code>cn=Babs Jenson,o=Example</code>. Si la
1274 directive est à <code>on</code>, <module>mod_authnz_ldap</module> va
1275 vérifier si <code>cn=Babs Jenson, o=Example</code> est un membre du
1276 groupe. Dans le cas contraire, <module>mod_authnz_ldap</module>
1277 vérifiera si <code>bjenson</code> est un membre du groupe.</p>
1279 </directivesynopsis>
1282 <name>AuthLDAPMaxSubGroupDepth</name>
1283 <description>Spécifie la profondeur d'imbrication des sous-groupes
1284 maximale prise en compte avant l'abandon de la recherche de
1285 l'utilisateur.</description>
1286 <syntax>AuthLDAPMaxSubGroupDepth <var>Nombre</var></syntax>
1287 <default>AuthLDAPMaxSubGroupDepth 0</default>
1288 <contextlist><context>directory</context><context>.htaccess</context>
1290 <override>AuthConfig</override>
1291 <compatibility>Disponible à partir de la version 2.3.0 du serveur HTTP
1292 Apache ; la valeur par défaut était 10 dans les versions 2.4.x et les
1293 premières versions 2.5</compatibility>
1296 <p>Lorsque cette directive est définie à une valeur <code>X</code>
1297 non nulle, en combinaison avec l'utilisation de la directive
1298 <code>Require ldap-group DN-groupe</code>, les données de connexion
1299 fournies seront utilisées pour vérifier l'appartenance de
1300 l'utilisateur à l'objet de l'annuaire <code>DN-groupe</code> ou à
1301 tout sous-groupe du groupe courant en tenant compte de la profondeur
1302 d'imbrication maximale <code>X</code> spécifiée par la directive.</p>
1303 <p>Se référer à la section <a href="#reqgroup"><code>Require
1304 ldap-group</code></a> pour un exemple plus détaillé.</p>
1306 <note><title>Performances dans le cas des groupes imbriqués</title>
1307 <p>Lorsque les directives
1308 <directive>AuthLDAPSubGroupAttribute</directive> et
1309 <directive>AuthLDAPGroupAttribute</directive> se recouvrent (comme
1310 c'est le cas par défaut et requis par les schémas LDAP courants), la
1311 recherche de sous-groupes au sein de grands groupes peut être très
1312 longue. Si vos groupes sont très grands et non imbriqués, définissez
1313 la directive <directive>AuthLDAPMaxSubGroupDepth</directive> à 0.</p>
1317 </directivesynopsis>
1320 <name>AuthLDAPRemoteUserAttribute</name>
1321 <description>Spécifie l'attribut dont la valeur renvoyée au cours de la
1322 requête de l'utilisateur sera utilisée pour définir la variable
1323 d'environnement REMOTE_USER</description>
1324 <syntax>AuthLDAPRemoteUserAttribute uid</syntax>
1325 <default>none</default>
1326 <contextlist><context>directory</context><context>.htaccess</context>
1328 <override>AuthConfig</override>
1331 <p>Lorsque cette directive est définie, la variable d'environnement
1332 <code>REMOTE_USER</code> sera définie à la valeur de l'attribut
1333 spécifié. Assurez-vous que cet attribut soit bien inclus dans la
1334 liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans
1335 le cas contraire, cette directive n'aurait aucun effet. Si elle est
1336 présente, cette directive l'emporte sur <directive
1337 module="mod_authnz_ldap">AuthLDAPRemoteUserIsDN</directive>. Elle
1338 peut s'avérer utile par exemple, si vous souhaitez que les
1339 utilisateurs se connectent à un site web en utilisant leur adresse
1340 email, alors qu'une application sous-jacente nécessite un nom
1341 d'utilisateur comme identifiant.</p>
1342 <p>Cette directive n'a d'effet que si l'on utilise ce module pour
1343 l'authentification.</p>
1345 </directivesynopsis>
1348 <name>AuthLDAPRemoteUserIsDN</name>
1349 <description>Utilise le DN de l'utilisateur pour définir la variable
1350 d'environnement REMOTE_USER</description>
1351 <syntax>AuthLDAPRemoteUserIsDN on|off</syntax>
1352 <default>AuthLDAPRemoteUserIsDN off</default>
1353 <contextlist><context>directory</context><context>.htaccess</context>
1355 <override>AuthConfig</override>
1358 <p>Lorsque cette directive est à on, la variable d'environnement
1359 <code>REMOTE_USER</code> sera définie avec la valeur du DN complet
1360 de l'utilisateur authentifié, et non plus avec simplement le nom
1361 d'utilisateur fourni par le client. Elle est définie à off par
1363 <p>Cette directive n'a d'effet que si l'on utilise ce module pour
1364 l'authentification.</p>
1366 </directivesynopsis>
1369 <name>AuthLDAPSearchAsUser</name>
1370 <description>Utilise les données d'authentification de l'utilisateur
1371 pour la recherche des autorisations</description>
1372 <syntax>AuthLDAPSearchAsUser on|off</syntax>
1373 <default>AuthLDAPSearchAsUser off</default>
1374 <contextlist><context>directory</context><context>.htaccess</context>
1376 <override>AuthConfig</override>
1377 <compatibility>Disponible depuis la version 2.3.6</compatibility>
1380 <p>Lorsque cette directive est définie, et si
1381 <module>mod_authnz_ldap</module> a authentifié l'utilisateur, les
1382 recherches LDAP pour définir les autorisations utilisent le nom
1383 distinctif (DN) trouvé et le mot de passe pour l'authentification de
1384 base HTTP de l'utilisateur authentifié, au lieu des données
1385 d'authentification configurées au niveau du serveur.</p>
1387 <p>Les vérifications d'autorisation <em>ldap-filter</em> et
1388 <em>ldap-dn</em> utilisent des recherches.</p>
1390 <p>Cette directive n'a d'effet sur les comparaisons effectuées au
1391 cours des traitements de groupe imbriqués, et lorsque la directive
1393 module="mod_authnz_ldap">AuthLDAPCompareAsUser</directive>
1394 est aussi activée.</p>
1396 <p>Cette directive ne doit être utilisée que si votre serveur LDAP
1397 n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
1398 utiliser de nom d'utilisateur dédié via la directive <directive
1399 module="mod_authnz_ldap">AuthLDAPBindDN</directive>.
1403 <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive></seealso>
1404 <seealso><directive module="mod_authnz_ldap">AuthLDAPCompareAsUser</directive></seealso>
1405 </directivesynopsis>
1408 <name>AuthLDAPSubGroupAttribute</name>
1409 <description>Spécifie les noms d'attribut, un par directive, utilisés
1410 pour différencier les membres du groupe courant qui sont eux-mêmes des
1411 groupes.</description>
1412 <syntax>AuthLDAPSubGroupAttribute <em>attribut</em></syntax>
1413 <default>AuthLDAPSubgroupAttribute member uniquemember</default>
1414 <contextlist><context>directory</context><context>.htaccess</context>
1416 <override>AuthConfig</override>
1417 <compatibility>Disponible à partir de la version 2.3.0 du serveur HTTP
1418 Apache</compatibility>
1421 <p>Un objet groupe LDAP peut contenir des membres qui sont des
1422 utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
1423 sous-groupes ou groupes imbriqués). La directive
1424 <directive>AuthLDAPSubGroupAttribute</directive> spécifie l'attribut utilisé
1425 pour identifier les groupes, alors que la directive <directive
1426 module="mod_authnz_ldap">AuthLDAPGroupAttribute</directive> spécifie
1427 l'attribut utilisé pour identifier les utilisateurs. On peut spécifier
1428 plusieurs attributs en répétant la directive plusieurs fois. Si elle n'est
1429 pas définie, <module>mod_authnz_ldap</module> utilise les attributs
1430 <code>member</code> et <code>uniqueMember</code>.</p>
1432 </directivesynopsis>
1435 <name>AuthLDAPSubGroupClass</name>
1436 <description>Spécifie quelles valeurs d'objectClass LDAP identifient les
1437 objets de l'annuaire qui sont des groupes au cours du traitement des
1438 sous-groupes.</description>
1439 <syntax>AuthLDAPSubGroupClass <em>ObjectClass-LDAP</em></syntax>
1440 <default>AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames</default>
1441 <contextlist><context>directory</context><context>.htaccess</context>
1443 <override>AuthConfig</override>
1444 <compatibility>Disponible à partir de la version 2.3.0 du serveur HTTP
1445 Apache</compatibility>
1448 <p>Un objet groupe LDAP peut contenir des membres qui sont des
1449 utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
1450 sous-groupes ou groupes imbriqués). La directive
1451 <directive module="mod_authnz_ldap">AuthLDAPSubGroupAttribute</directive>
1452 permet d'identifier les
1453 membres qui sont des sous-groupes du groupe courant (à l'opposé des
1454 membres utilisateurs). La directive
1455 <directive>AuthLDAPSubGroupClass</directive> permet de spécifier les valeurs
1456 d'objectClass LDAP utilisées pour vérifier que certains membres sont
1457 en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent
1458 alors faire l'objet d'une recherche d'autres membres utilisateurs ou
1459 sous-groupes. On peut spécifier plusieurs attributs en répétant
1460 cette directive plusieurs fois. Si cette directive n'est pas
1461 définie, <module>mod_authnz_ldap</module> utilise les attributs
1462 <code>groupOfNames</code> et <code>groupOfUniqueNames</code>.</p>
1464 </directivesynopsis>
1467 <name>AuthLDAPUrl</name>
1468 <description>L'URL permettant de spécifier les paramètres de la
1469 recherche LDAP</description>
1470 <syntax>AuthLDAPUrl <em>url [NONE|SSL|TLS|STARTTLS]</em></syntax>
1471 <contextlist><context>directory</context><context>.htaccess</context>
1473 <override>AuthConfig</override>
1476 <p>Une URL conforme à la RFC 2255 qui permet de spécifier les
1477 paramètres à utiliser pour la recherche dans l'annuaire LDAP. La
1478 syntaxe de l'URL est :</p>
1479 <example>ldap://hôte:port/DN-de-base?attribut?portée?filtre</example>
1480 <p>Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs
1481 LDAP, la syntaxe sera :</p>
1482 <highlight language="config">AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."</highlight>
1483 <p><em><strong>Mise en garde : </strong>Si vous spécifiez plusieurs
1484 serveurs, vous devez en entourer la liste avec des guillemets ; dans le
1485 cas contraire, vous générerez une erreur : "AuthLDAPURL takes one
1486 argument, URL to define LDAP connection..".</em> Vous pouvez bien
1487 entendu ajouter des paramètres de recherche à chacun des serveurs
1493 <dd>Pour ldap non sécurisé, utilisez la chaîne
1494 <code>ldap</code>. Pour ldap sécurisé, utilisez à la place la
1495 chaîne <code>ldaps</code>. LDAP sécurisé n'est disponible que si
1496 Apache a été lié avec une bibliothèque LDAP supportant SSL.</dd>
1501 <p>Il s'agit du nom/port du serveur ldap
1502 (dont la valeur par défaut est
1503 <code>localhost:389</code> pour <code>ldap</code>, et
1504 <code>localhost:636</code> pour <code>ldaps</code>). Pour
1505 spécifier plusieurs serveurs LDAP redondants, indiquez
1506 simplement leur liste en les séparant par des espaces.
1507 <module>mod_authnz_ldap</module> tentera alors de se connecter
1508 à chacun des serveurs jusqu'à ce qu'il parvienne à se
1509 connecter avec succès. Notez qu'en cas de multiples serveurs
1510 LDAP, l'ensemble de l'URL LDAP doit être entourée de
1513 <p>lorsqu'une connection a été établie avec un serveur, elle
1514 reste active pendant toute la durée de vie du processus
1515 <program>httpd</program>, ou jusqu'à ce que le serveur LDAP
1516 cesse de fonctionner.</p>
1518 <p>Si le serveur LDAP cesse de fonctionner, et ainsi
1520 connexion existante, <module>mod_authnz_ldap</module> tentera
1521 de se reconnecter en commençant par le premier serveur de la
1522 liste, et ainsi de suite avec les serveurs redondants
1523 suivants. Notez que ce processus n'a rien à voir avec une
1524 véritable recherche de type round-robin.</p>
1528 <dd>Le DN de la branche de l'annuaire à partir de laquelle
1529 toutes les recherches seront lancées. Il doit au moins
1530 correspondre à la racine de votre annuaire, mais vous pouvez
1531 aussi indiquer une branche plus spécifique.</dd>
1535 <dd>Il s'agit de l'attribut à utiliser pour la recherche.
1537 2255 autorise une liste d'attributs séparés par des virgules,
1538 seul le premier sera retenu, sans tenir compte des autres
1539 attributs fournis. Si aucun attribut n'est fourni, l'attribut
1540 par défaut est <code>uid</code>. Il est judicieux de choisir un
1541 attribut dont la valeur sera unique parmi toutes les entrées de
1542 la branche de l'annuaire que vous aurez définie. Tous les
1543 attributs spécifiés seront enregistrés dans des variables
1544 d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir
1545 être utilisés par d'autres modules.</dd>
1549 <dd>Il s'agit de la portée de la recherche. Elle peut prendre
1550 les valeurs <code>one</code> ou <code>sub</code>. Notez que la
1551 RFC 2255 supporte aussi une portée de valeur <code>base</code>,
1552 mais cette dernière n'est pas supportée par le module. Si la
1553 portée n'est pas définie, ou si elle est définie à
1554 <code>base</code>, c'est la valeur de portée par défaut
1555 <code>sub</code> qui sera utilisée.</dd>
1559 <dd>Il s'agit d'un filtre de recherche LDAP valide. Si aucun
1560 filtre n'est spécifié, le filtre par défaut
1561 <code>(objectClass=*)</code> sera utilisé, ce qui corrspond à
1562 une recherche de tous les types d'objets de l'arborescence. La
1563 taille des filtres est limitée à environ 8000 caractères (valeur
1564 de la macro <code>MAX_STRING_LEN</code> dans le code source
1565 d'Apache), ce qui s'avère plus que suffisant pour la plupart des
1566 applications. A partir de la version 2.4.10 du serveur HTTP Apache, le
1567 mot-clé <code>none</code> permet de désactiver
1568 l'utilisation des filtres, ce qui peut s'avérer nécessaire avec
1569 certains serveurs LDAP primitifs.</dd>
1572 <p>Pour une recherche, les attribut, filtre et nom d'utilisateur
1573 fournis par le client HTTP sont combinés pour créer un filtre de
1574 recherche du style :
1575 <code>(&(<em>filtre</em>)(<em>attribut</em>
1576 =<em>nom-utilisateur</em>))</code>.</p>
1578 <p>Par exemple, considérons l'URL
1579 <code>ldap://ldap.example.com/o=Example?cn?sub?(posixid=*)</code>.
1580 Lorsqu'un client tentera de se connecter en utilisant le nom
1581 d'utilisateur <code>Babs Jenson</code>, le filtre de recherche sera
1582 : <code>(&(posixid=*)(cn=Babs Jenson))</code>.</p>
1584 <p>On peut encore ajouter un paramètre optionnel pour permettre à
1585 l'URL LDAP de surcharger le type de connexion. Ce paramètre peut
1586 prendre l'une des valeurs suivantes :</p>
1590 <dd>Établit une connexion non sécurisée sur le port LDAP par
1591 défaut, ce qui est équivalent à <code>ldap://</code> sur le port
1594 <dd>Établit une connexion sécurisée sur le port LDAP sécurisé
1595 par défaut, ce qui est équivalent à <code>ldaps://</code>.</dd>
1596 <dt>TLS | STARTTLS</dt>
1597 <dd>Établit une connexion sécurisée par élévation de niveau sur
1598 le port LDAP par défaut. Cette connexion sera initialisée sur le
1599 port 389 par défaut, puis élevée à un niveau de connexion
1600 sécurisée sur le même port.</dd>
1603 <p>Voir plus haut pour des exemples d'URLs définies par la directive
1604 <directive module="mod_authnz_ldap">AuthLDAPUrl</directive>.</p>
1606 </directivesynopsis>