2 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
4 <!-- English Revision : 1337035 -->
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>
33 <compatibility>Dosponible depuis les versions 2.1 et supérieures
34 d'Apache</compatibility>
37 <p>Ce module permet aux frontaux d'authentification comme
38 <module>mod_auth_basic</module> d'authentifier les utilisateurs via
41 <p><module>mod_authnz_ldap</module> supporte les fonctionnalités
45 <li>Support vérifié du <a
46 href="http://www.openldap.org/">OpenLDAP SDK</a> (versions 1.x et
47 2.x), du <a href="http://developer.novell.com/ndk/cldap.htm">
48 Novell LDAP SDK</a> et du SDK <a
49 href="http://www.iplanet.com/downloads/developer/">iPlanet
52 <li>Implémentation de politiques d'autorisation complexes en les
53 définissant via des filtres LDAP.</li>
55 <li>Mise en oeuvre d'une mise en cache des opérations LDAP
56 élaborée via <a href="mod_ldap.html">mod_ldap</a>.</li>
58 <li>Support de LDAP via SSL (nécessite le SDK Netscape) ou TLS
59 (nécessite le SDK OpenLDAP 2.x ou le SDK LDAP Novell).</li>
62 <p>Lorsqu'on utilise <module>mod_auth_basic</module>, ce module est
63 invoqué en affectant la valeur <code>ldap</code> à la directive
64 <directive module="mod_auth_basic">AuthBasicProvider</directive>.</p>
67 <seealso><module>mod_ldap</module></seealso>
68 <seealso><module>mod_auth_basic</module></seealso>
69 <seealso><module>mod_authz_user</module></seealso>
70 <seealso><module>mod_authz_groupfile</module></seealso>
72 <section id="contents"><title>Sommaire</title>
76 <a href="#operation">Mode opératoire</a>
79 <li><a href="#authenphase">La phase
80 d'authentification</a></li>
82 <li><a href="#authorphase">La phase d'autorisation</a></li>
87 <a href="#requiredirectives">Les directives requises</a>
90 <li><a href="#requser">Require ldap-user</a></li>
91 <li><a href="#reqgroup">Require ldap-group</a></li>
92 <li><a href="#reqdn">Require ldap-dn</a></li>
93 <li><a href="#reqattribute">Require ldap-attribute</a></li>
94 <li><a href="#reqfilter">Require ldap-filter</a></li>
98 <li><a href="#examples">Exemples</a></li>
99 <li><a href="#usingtls">Utilisation de TLS</a></li>
100 <li><a href="#usingssl">Utilisation de SSL</a></li>
101 <li><a href="#exposed">Mise à disposition des informations de
103 <li><a href="#activedirectory">Utilisation d'Active Directory</a></li>
105 <a href="#frontpage">Utilisation de Microsoft FrontPage avec
106 <module>mod_authnz_ldap</module></a>
109 <li><a href="#howitworks">Comment ça marche</a></li>
110 <li><a href="#fpcaveats">Mises en garde</a></li>
116 <section id="operation"><title>Mode opératoire</title>
118 <p>L'utilisateur se voit accorder l'accès selon un processus en deux
119 phases. La première phase est l'authentification, au cours de
120 laquelle le fournisseur d'authentification
121 <module>mod_authnz_ldap</module> vérifie que les informations de
122 connexion de l'utilisateur sont valides. Elle est aussi connue sous
123 le nom de phase de <em>recherche/connexion</em> (NdT : en anglais ou
124 dans le code source : <em>search/bind</em>). La deuxième
125 phase est l'autorisation, au cours de laquelle
126 <module>mod_authnz_ldap</module> détermine si l'utilisateur
127 authentifié a la permission d'accéder à la ressource considérée.
128 Elle est aussi connue sous le nom de phase de
129 <em>comparaison</em> (<em>compare</em>).</p>
131 <p><module>mod_authnz_ldap</module> comporte un fournisseur
132 d'authentification authn_ldap et un gestionnaire d'autorisation
133 authz_ldap. Le fournisseur d'authentification authn_ldap peut être
134 invoqué en affectant la valeur <code>ldap</code> à la directive
135 <directive module="mod_auth_basic">AuthBasicProvider</directive>. Le
136 gestionnaire d'autorisation authz_ldap enrichit la liste des types
137 d'autorisations de la directive <directive
138 module="mod_authz_core">Require</directive> en y ajoutant les
139 valeurs <code>ldap-user</code>, <code>ldap-dn</code> et
140 <code>ldap-group</code>.</p>
142 <section id="authenphase"><title>La phase d'authentification</title>
144 <p>Au cours de la phase d'authentification,
145 <module>mod_authnz_ldap</module> recherche une entrée de l'annuaire
146 LDAP qui correspond au nom d'utilisateur fourni par le client HTTP.
147 Si une correspondance unique est trouvée,
148 <module>mod_authnz_ldap</module> tente de se connecter au serveur
149 hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot
150 de passe fourni par le client HTTP. Comme ce processus effectue tout
151 d'abord une recherche, puis une connexion, il est aussi connu sous
152 le nom de phase de recherche/connexion. Voici le détail des étapes
153 constituant la phase de recherche/connexion :</p>
156 <li>Confection d'un filtre de recherche en combinant les attribut
157 et filtre définis par la directive <directive module="mod_authnz_ldap"
158 >AuthLDAPURL</directive> avec le nom d'utilisateur et le mot de
159 passe fournis par le client HTTP.</li>
161 <li>Recherche dans l'annuaire LDAP en utilisant le filtre
162 confectionné précédemment. Si le résultat de la recherche est
163 négatif ou comporte plusieurs entrées, refus ou restriction de
166 <li>Extraction du DN (distinguished name) de l'entrée issue du
167 résultat de la recherche, et tentative de connexion au serveur
168 LDAP en utilisant ce DN et le mot de passe fournis par le client
169 HTTP. Si la connexion échoue, refus ou restriction de
173 <p>Les directives utilisées durant la phase de recherche/connexion
174 sont les suivantes :</p>
177 <columnspec><column width=".3"/><column width=".7"/></columnspec>
180 module="mod_authnz_ldap">AuthLDAPURL</directive></td>
182 <td>Spécifie le serveur LDAP, le DN de base, l'attribut à
183 utiliser pour la recherche, ainsi que les filtres de recherche
184 supplémentaires.</td>
189 module="mod_authnz_ldap">AuthLDAPBindDN</directive></td>
191 <td>Un DN optionnel pour se connecter durant la phase de
197 module="mod_authnz_ldap">AuthLDAPBindPassword</directive></td>
199 <td>Un mot de passe optionnel pour se connecter durant la phase
205 <section id="authorphase"><title>La phase d'autorisation</title>
207 <p>Au cours de la phase d'autorisation,
208 <module>mod_authnz_ldap</module> tente de déterminer si
209 l'utilisateur est autorisé à accéder à la ressource considérée. Une
210 grande partie de cette vérification consiste pour
211 <module>mod_authnz_ldap</module> en des opérations de comparaison au
212 niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue
213 sous le nom de phase de comparaison.
214 <module>mod_authnz_ldap</module> accepte les directives <directive
215 module="mod_authz_core">Require</directive> suivantes pour
216 déterminer si les informations de connexion permettent d'accorder
217 l'accès à l'utilisateur :</p>
220 <li>Avec la directive <a
221 href="#reqgroup"><code>Require ldap-user</code></a>,
222 l'autorisation d'accès est accordée si le nom d'utilisateur
223 spécifié par la directive correspond au nom d'utilisateur fourni
226 <li>Avec la directive <a href="#reqdn"><code>Require
227 ldap-dn</code></a>, l'autorisation d'accès est accordée si le DN
228 spécifié par la directive correspond au DN extrait du résultat de
229 la recherche dans l'annuaire LDAP.</li>
231 <li>Avec la directive <a
232 href="#reqgroup"><code>Require ldap-group</code></a>,
233 l'autorisation d'accès est accordée si le DN extrait du résultat de
234 la recherche dans l'annuaire LDAP (ou le nom d'utilisateur fourni
235 par le client) appartient au groupe LDAP spécifié par la
236 directive, ou éventuellement à un de ses sous-groupes.</li>
238 <li>Avec la directive <a href="#reqattribute">
239 <code>Require ldap-attribute</code></a>, l'autorisation d'accès
240 est accordée si la valeur de l'attribut extraite de la recherche
241 dans l'annuaire LDAP correspond à la valeur spécifiée par la
244 <li>Avec la directive <a href="#reqfilter">
245 <code>Require ldap-filter</code></a>, l'autorisation d'accès
246 est accordée si le filtre de recherche renvoie un objet
247 utilisateur unique qui corresponde au DN de l'utilisateur
250 <li>dans tous les autres cas, refus ou restriction de
254 <p>Sous réserve du chargement de modules d'autorisation
255 supplémentaires, d'autres valeurs de la directive <directive
256 module="mod_authz_core">Require</directive> peuvent être
260 <li>L'accès est accordé à tous les utilisateurs authentifiés si
261 une directive <a href="#requser"><code>Require
262 valid-user</code></a> est présente (nécessite le module
263 <module>mod_authz_user</module>).</li>
265 <li>Avec la directive <a
266 href="#reqgroup"><code>Require group</code></a>, l'autorisation
267 d'accès est accordée si le module
268 <module>mod_authz_groupfile</module> a été chargé et si la
270 module="mod_authz_groupfile">AuthGroupFile</directive> a été
277 <p>Durant la phase de comparaison, <module>mod_authnz_ldap</module>
278 utilise les directives suivantes :</p>
281 <columnspec><column width=".4"/><column width=".6"/></columnspec>
283 <td><directive module="mod_authnz_ldap">AuthLDAPURL</directive>
286 <td>On utilise l'attribut spécifié dans l'URL pour les
287 opérations de comparaison initiées par la directive
288 <code>Require ldap-user</code>.</td>
293 module="mod_authnz_ldap">AuthLDAPCompareDNOnServer</directive></td>
295 <td>Détermine le comportement de la directive <code>Require
301 module="mod_authnz_ldap">AuthLDAPGroupAttribute</directive></td>
303 <td>Détermine l'attribut utilisé pour les opérations de
304 comparaison initiées par la directive <code>Require
305 ldap-group</code>.</td>
310 module="mod_authnz_ldap">AuthLDAPGroupAttributeIsDN</directive></td>
312 <td>Spécifie si l'on doit utiliser le DN ou le nom de
313 l'utilisateur lors des opérations de comparaison initiées par la
314 directive <code>Require ldap-group</code>.</td>
319 module="mod_authnz_ldap">AuthLDAPMaxSubGroupDepth</directive></td>
321 <td>Détermine la profondeur maximale de l'arborescence des
322 sous-groupes qui seront évalués au cours des opérations de
323 comparaisons initiées par la directive <code>Require
324 ldap-group</code>.</td>
329 module="mod_authnz_ldap">AuthLDAPSubGroupAttribute</directive></td>
331 <td>Détermine l'attribut à utiliser lors de l'extraction de
332 membres de sous-groupes du groupe courant au cours des
333 opérations de comparaison initiées par la directive
334 <code>Require ldap-group</code>.</td>
339 module="mod_authnz_ldap">AuthLDAPSubGroupClass</directive></td>
341 <td>Spécifie les valeurs de classe d'objet LDAP à utiliser pour
342 déterminer si les objets extraits de l'annuaire sont bien des
343 objets de type groupe (et non des objets de type utilisateur),
344 au cours du traitement des sous-groupes initié par la directive
345 <code>Require ldap-group</code>.</td>
351 <section id="requiredirectives"><title>Les directives requises</title>
353 <p>Les directives <directive
354 module="mod_authz_core">Require</directive> d'Apache sont utilisées
355 au cours de la phase d'autorisation afin de s'assurer que
356 l'utilisateur est autorisé à accéder à une ressource.
357 mod_authnz_ldap enrichit la liste des types d'autorisations avec les
358 valeurs <code>ldap-user</code>, <code>ldap-dn</code>,
359 <code>ldap-group</code>, <code>ldap-attribute</code> et
360 <code>ldap-filter</code>. D'autres types d'autorisations sont
361 disponibles, sous réserve du chargement de modules d'autorisation
364 <section id="requser"><title>Require ldap-user</title>
366 <p>La directive <code>Require ldap-user</code> permet de spécifier
367 les noms des utilisateurs autorisés à accéder à la ressource.
368 Lorsque <module>mod_authnz_ldap</module> a extrait un DN unique de
369 l'annuaire LDAP, il effectue une opération de comparaison LDAP en
370 utilisant le nom d'utilisateur spécifié par la directive
371 <code>Require ldap-user</code>, pour vérifier si ce nom
372 d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder
373 l'accès à plusieurs utilisateurs en plaçant plusieurs nom
374 d'utilisateurs sur la même ligne séparés par des espaces. Si un nom
375 d'utilisateur contient des espaces, il doit être entouré de
376 guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs
377 en utilisant une directive <code>Require ldap-user</code> par
378 utilisateur. Par exemple, avec la directive <directive
379 module="mod_authnz_ldap">AuthLDAPURL</directive> définie à
380 <code>ldap://ldap/o=Example?cn</code> (spécifiant donc que l'attribut
381 <code>cn</code> sera utilisé pour les recherches), on pourra
382 utiliser les directives Require suivantes pour restreindre l'accès
384 <highlight language="config">
385 Require ldap-user "Barbara Jenson"
386 Require ldap-user "Fred User"
387 Require ldap-user "Joe Manager"
390 <p>De par la manière dont <module>mod_authnz_ldap</module> traite
391 cette directive, Barbara Jenson peut s'authentifier comme
392 <em>Barbara Jenson</em>, <em>Babs Jenson</em> ou tout autre
393 <code>cn</code> sous lequel elle est enregistrée dans l'annuaire
394 LDAP. Une seule ligne <code>Require ldap-user</code> suffit pour
395 toutes les valeurs de l'attribut dans l'entrée LDAP de
398 <p>Si l'attribut <code>uid</code> avait été spécifié à la place de
399 l'attribut <code>cn</code> dans l'URL précédente, les trois lignes
400 ci-dessus auraient pû être condensées en une seule ligne :</p>
401 <highlight language="config">Require ldap-user bjenson fuser jmanager</highlight>
404 <section id="reqgroup"><title>Require ldap-group</title>
406 <p>Cette directive permet de spécifier un groupe LDAP dont les
407 membres auront l'autorisation d'accès. Elle prend comme argument le
408 DN du groupe LDAP. Note : n'entourez pas le nom du groupe avec des
409 guillemets. Par exemple, supposons que l'entrée suivante existe dans
410 l'annuaire LDAP :</p>
412 dn: cn=Administrators, o=Example
413 objectClass: groupOfUniqueNames
414 uniqueMember: cn=Barbara Jenson, o=Example
415 uniqueMember: cn=Fred User, o=Example
418 <p>La directive suivante autoriserait alors l'accès à Fred et
420 <highlight language="config">Require ldap-group cn=Administrators, o=Example</highlight>
422 <p>Les membres peuvent aussi se trouver dans les sous-groupes du
423 groupe LDAP spécifié si la directive <directive
424 module="mod_authnz_ldap">AuthLDAPMaxSubGroupDepth</directive> a été
425 définie à une valeur supérieure à 0. Par exemple, supposons que les
426 entrées suivantes existent dans l'annuaire LDAP :</p>
428 dn: cn=Employees, o=Example
429 objectClass: groupOfUniqueNames
430 uniqueMember: cn=Managers, o=Example
431 uniqueMember: cn=Administrators, o=Example
432 uniqueMember: cn=Users, o=Example
434 dn: cn=Managers, o=Example
435 objectClass: groupOfUniqueNames
436 uniqueMember: cn=Bob Ellis, o=Example
437 uniqueMember: cn=Tom Jackson, o=Example
439 dn: cn=Administrators, o=Example
440 objectClass: groupOfUniqueNames
441 uniqueMember: cn=Barbara Jenson, o=Example
442 uniqueMember: cn=Fred User, o=Example
444 dn: cn=Users, o=Example
445 objectClass: groupOfUniqueNames
446 uniqueMember: cn=Allan Jefferson, o=Example
447 uniqueMember: cn=Paul Tilley, o=Example
448 uniqueMember: cn=Temporary Employees, o=Example
450 dn: cn=Temporary Employees, o=Example
451 objectClass: groupOfUniqueNames
452 uniqueMember: cn=Jim Swenson, o=Example
453 uniqueMember: cn=Elliot Rhodes, o=Example
456 <p>Les directives suivantes autoriseraient alors l'accès à Bob
457 Ellis, Tom Jackson, Barbara Jensen, Fred User, Allan Jefferson, et
458 Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes
459 (car ils sont situés dans un sous-groupe de niveau de profondeur 2)
461 <highlight language="config">
462 Require ldap-group cn=Employees, o-Example
463 AuthLDAPMaxSubGroupDepth 1
466 <p>Le comportement de cette directive est modifié par les directives
468 module="mod_authnz_ldap">AuthLDAPGroupAttribute</directive>,
470 module="mod_authnz_ldap">AuthLDAPGroupAttributeIsDN</directive>,
472 module="mod_authnz_ldap">AuthLDAPMaxSubGroupDepth</directive>,
474 module="mod_authnz_ldap">AuthLDAPSubGroupAttribute</directive>, et
476 module="mod_authnz_ldap">AuthLDAPSubGroupClass</directive>.</p>
479 <section id="reqdn"><title>Require ldap-dn</title>
481 <p>La directive <code>Require ldap-dn</code> permet à
482 l'administrateur d'accorder l'utorisation d'accès en fonction du DN.
483 Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si
485 l'annuaire correspond au DN spécifié par la directive <code>Require
486 ldap-dn</code>, l'autorisation d'accès est accordée. Note :
487 n'entourez pas Le DN de guillemets.</p>
489 <p>La directive suivante accorderait l'accès à un DN spécifique
491 <highlight language="config">Require ldap-dn cn=Barbara Jenson, o=Example</highlight>
493 <p>Le comportement ce cette directive est modifié par la directive
495 module="mod_authnz_ldap">AuthLDAPCompareDNOnServer</directive>.</p>
498 <section id="reqattribute"><title>Require ldap-attribute</title>
500 <p>La directive <code>Require ldap-attribute</code> permet à
501 l'administrateur d'accorder l'autorisation d'accès en fonction des
502 attributs de l'utilisateur authentifié dans l'annuaire LDAP. Si la
503 valeur de l'attribut dans l'annuaire correspond à la valeur
504 spécifiée par la directive, l'autorisation d'accès est accordée.</p>
506 <p>La directive suivante accorderait l'autorisation d'accès à tout
507 utilisateur dont l'attribut employeeType a pour valeur "actif" :</p>
509 <highlight language="config">Require ldap-attribute employeeType=active</highlight>
511 <p>Plusieurs paires attribut/valeur peuvent être spécifiées par une
512 même directive en les séparant par des espaces, ou en définissant
513 plusieurs directives <code>Require ldap-attribute</code>. La logique
514 sous-jacente à une liste de paires attribut/valeur est une opération
515 OU. L'autorisation d'accès sera accordée si au moins une paire
516 attribut/valeur de la liste spécifiée correspond à la paire
517 attribut/valeur de l'utilisateur authentifié. Si elle contient des
518 espaces, la valeur, et seulement la valeur, doit être entourée de
521 <p>La directive suivante accorderait l'autorisation d'accès à tout
522 utilisateur dont l'attribut city aurait pour valeur "San Jose", ou
523 donc l'attribut status aurait pour valeur "actif" :</p>
525 <highlight language="config">Require ldap-attribute city="San Jose" status=active</highlight>
529 <section id="reqfilter"><title>Require ldap-filter</title>
531 <p>La directive <code>Require ldap-filter</code> permet à
532 l'administrateur d'accorder l'autorisation d'accès en fonction d'un
533 filtre de recherche LDAP complexe. L'autorisation d'accès est
534 accordée si le DN renvoyé par le filtre de recherche correspond au
535 DN de l'utilisateur authentifié.</p>
537 <p>La directive suivante accorderait l'autorisation d'accès à tout
538 utilisateur possédant un téléphone cellulaire et faisant partie du
539 département "marketing" :</p>
541 <highlight language="config">Require ldap-filter &(cell=*)(department=marketing)</highlight>
543 <p>Alors que la directive <code>Require ldap-attribute</code> se
544 contente d'une simple comparaison d'attributs, la directive
545 <code>Require ldap-filter</code> effectue une opération de recherche
546 dans l'annuaire LDAP en utilisant le filtre de recherche spécifié.
547 Si une simple comparaison d'attributs suffit, l'opération de
548 comparaison effectuée par <code>ldap-attribute</code> sera plus
549 rapide que l'opération de recherche effectuée par
550 <code>ldap-filter</code>, en particulier dans le cas d'un annuaire
551 LDAP de grande taille.</p>
557 <section id="examples"><title>Exemples</title>
561 Accorde l'autorisation d'accès à tout utilisateur présent dans
562 l'annuaire LDAP, en utilisant son UID pour effectuer la
564 <highlight language="config">
565 AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
571 L'exemple suivant est similaire au précédent, mais les champs
572 dont les valeurs par défaut conviennent sont omis. Notez aussi
573 la présence d'un annuaire LDAP redondant :
574 <highlight language="config">AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
580 Encore un exemple similaire aux précédents, mais cette fois,
581 c'est l'attribut cn qui est utilisé pour la recherche à la place
582 de l'UID. Notez que ceci peut poser problème si plusieurs
583 utilisateurs de l'annuaire partagent le même <code>cn</code>,
584 car une recherche sur le <code>cn</code> <strong>doit</strong>
585 retourner une entrée et une seule. C'est pourquoi cette
586 approche n'est pas recommandée : il est préférable de choisir un
587 attribut de votre annuaire dont l'unicité soit garantie, comme
589 <highlight language="config">
590 AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
596 Accorde l'autorisation d'accès à tout utilisateur appartenant au
597 groupe Administrateurs. Les utilisateurs doivent s'authentifier
598 en utilisant leur UID :
599 <highlight language="config">
600 AuthLDAPURL ldap://ldap.example.com/o=Example?uid
601 Require ldap-group cn=Administrators, o=Example
606 Pour l'exemple suivant, on suppose que tout utilisateur de chez
607 Example qui dispose d'un bippeur alphanumérique possèdera un
608 attribut LDAP <code>qpagePagerID</code>. Seuls ces utilisateurs
609 (authentifiés via leur UID) se verront accorder l'autorisation
611 <highlight language="config">
612 AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
618 <p>L'exemple suivant illustre la puissance des filtres pour
619 effectuer des requêtes complexes. Sans les filtres, il aurait
620 été nécessaire de créer un nouveau groupe LDAP et de s'assurer
621 de la synchronisation des membres du groupe avec les
622 utilisateurs possédant un bippeur. Tout devient limpide avec les
623 filtres. Nous avons pour but d'accorder l'autorisation d'accès à
624 tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager
625 qui ne possède pas de bippeur, mais doit tout de même pouvoir
626 accéder à la ressource :</p>
627 <highlight language="config">
628 AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
632 <p>Ce dernier exemple peut sembler confus au premier abord ; en
633 fait, il permet de mieux comprendre à quoi doit ressembler le
634 filtre en fonction de l'utilisateur qui se connecte. Si Fred
635 User se connecte en tant que <code>fuser</code>, le filtre devra
638 <example>(&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))</example>
640 <p>Un recherche avec le filtre ci-dessus ne retournera un
641 résultat positif que si <em>fuser</em> dispose d'un bippeur. Si
642 Joe Manager se connecte en tant que <em>jmanager</em>, le filtre
643 devra ressembler à :</p>
645 <example>(&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))</example>
647 <p>Un recherche avec le filtre ci-dessus retournera un
648 résultat positif que <em>jmanager</em> dispose d'un
654 <section id="usingtls"><title>Utilisation de TLS</title>
656 <p>Pour l'utilisation de TLS, voir les directives du module
657 <module>mod_ldap</module> <directive
658 module="mod_ldap">LDAPTrustedClientCert</directive>, <directive
659 module="mod_ldap">LDAPTrustedGlobalCert</directive> et <directive
660 module="mod_ldap">LDAPTrustedMode</directive>.</p>
662 <p>Un second paramètre optionnel peut être ajouté à la directive
663 <directive module="mod_authnz_ldap">AuthLDAPURL</directive> pour
664 remplacer le type de connexion par défaut défini par la directive
665 <directive module="mod_ldap">LDAPTrustedMode</directive>. Ceci
666 permettra de promouvoir la connexion établie via une URL du type
667 <em>ldap://</em> au statut de connection sécurisée sur le même
671 <section id="usingssl"><title>Utilisation de SSL</title>
673 <p>Pour l'utilisation de SSL, voir les directives du module
674 <module>mod_ldap</module> <directive
675 module="mod_ldap">LDAPTrustedClientCert</directive>, <directive
676 module="mod_ldap">LDAPTrustedGlobalCert</directive> et <directive
677 module="mod_ldap">LDAPTrustedMode</directive>.</p>
679 <p>Pour spécifier un serveur LDAP sécurisé, utilisez
680 <em>ldaps://</em> au lieu de
681 <em>ldap://</em> dans la directive <directive
682 module="mod_authnz_ldap">AuthLDAPURL</directive>.</p>
685 <section id="exposed"><title>Mise à disposition des informations de
688 <p>Au cours du processus d'<em>authentification</em>, les attributs LDAP
689 spécifiés par la directive <directive
690 module="mod_authnz_ldap">authldapurl</directive> sont enregistrés
691 dans des variables d'environnement préfixées par la chaîne
694 <p>Au cours du processus d'<em>autorisation</em>, les attributs LDAP
695 spécifiés par la directive <directive
696 module="mod_authnz_ldap">authldapurl</directive> sont enregistrés
697 dans des variables d'environnement préfixées par la chaîne
700 <p>Si les champs attribut contiennent le nom, le CN et le numéro de
701 téléphone d'un utilisateur, un programme CGI pourra accéder à ces
702 informations sans devoir effectuer une autre requête LDAP pour
703 les extraire de l'annuaire.</p>
705 <p>Ceci a pour effet de simplifier considérablement le code et la
706 configuration nécessaire de certaines applications web.</p>
710 <section id="activedirectory"><title>Utilisation d'Active
713 <p>Active Directory peut supporter plusieurs domaines à la fois.
714 Pour faire la distinction entre les utilisateurs de plusieurs
715 domaines, on peut ajouter à l'entrée de l'utilisateur dans
716 l'annuaire un identifiant appelé Nom
717 Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se
718 compose en général du nom de compte de l'utilisateur, suivi du nom
719 du domaine considéré, par exemple <em>untel@nz.example.com</em>.</p>
721 <p>Vous voudrez probablement configurer le module
722 <module>mod_authnz_ldap</module> afin de pouvoir authentifier les
723 utilisateurs de n'importe quel domaine de la forêt Active Directory.
724 Ainsi, <em>untel@nz.example.com</em> et
725 <em>untel@au.example.com</em> pourront être authentifiés en une
726 seule fois par la même requête.</p>
728 <p>Pour y parvenir, on utilise le concept de Catalogue Global
729 d'Active Directory. Ce Catalogue Global est une copie en lecture
730 seule des attributs sélectionnés de tous les serveurs de la forêt
731 Active Directory. Une requête vers le
732 Catalogue Global permet donc d'atteindre tous les domaines en une
733 seule fois, sans avoir à se connecter aux différents serveurs, via
734 des liaisons dont certaines peuvent être lentes.</p>
736 <p>Lorsqu'il est activé, la Catalogue Global est un serveur
737 d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL).
738 Pour rechercher un utilisateur, effectuez une recherche sur
739 l'attribut <em>userPrincipalName</em>, avec une base de recherche
740 vide, comme suit :</p>
742 <highlight language="config">
743 AuthLDAPBindDN apache@example.com
744 AuthLDAPBindPassword password
745 AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub
748 <p>Les utilisateurs devront s'authentifier en entrant leur UPN, de
749 la forme<em>untel@nz.example.com</em>.</p>
753 <section id="frontpage"><title>Utilisation de Microsoft
754 FrontPage avec mod_authnz_ldap</title>
756 <p>Normalement, FrontPage utilise des fichiers utilisateur/groupe
757 spécifiques à FrontPage-web (c'est à dire les modules
758 <module>mod_authn_file</module> et
759 <module>mod_authz_groupfile</module>) pour effectuer toute
760 l'authentification. Malheureusement, il ne suffit pas de modifier
761 l'authentification LDAP en ajoutant les directives appropriées, car
762 ceci corromprait les formulaires de <em>Permissions</em> dans le
763 client FrontPage, qui sont censés modifier les fichiers
764 d'autorisation standards au format texte.</p>
766 <p>Lorsqu'un site web FrontPage a été créé, lui adjoindre
767 l'authentification LDAP consiste à ajouter les directives suivantes
768 à <em>chaque</em> fichier <code>.htaccess</code> qui sera créé dans
770 <highlight language="config">
771 AuthLDAPURL "the url"
772 AuthGroupFile mygroupfile
773 Require group mygroupfile
776 <section id="howitworks"><title>Comment ça marche</title>
778 <p>FrontPage restreint l'accès à un site web en ajoutant la
779 directive <code>Require valid-user</code> aux fichiers
780 <code>.htaccess</code>. La directive <code>Require valid-user</code>
781 permettra l'accès à tout utilisateur valide <em>du point de vue
782 LDAP</em>. Cela signifie que tout utilisateur possédant une entrée
783 dans l'annuaire LDAP sera considéré comme valide, alors que
784 FrontPage ne considère comme valides que les utilisateurs
785 enregistrés dans le fichier des utilisateurs local. En remplaçant
786 l'autorisation par groupe LDAP par une autorisation par fichier de
787 groupe, Apache sera en mesure de consulter le fichier des
788 utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP
789 - lors du processus d'autorisation des utilisateurs.</p>
791 <p>Une fois les directives ajoutées selon ce qui précède, les
792 utilisateurs FrontPage pourront effectuer toutes les opérations de
793 gestion à partir du client FrontPage.</p>
796 <section id="fpcaveats"><title>Avertissements</title>
799 <li>Lors du choix de l'URL LDAP, l'attribut à utiliser pour
800 l'authentification doit aussi être valide pour le fichier des
801 utilisateurs de <module>mod_authn_file</module>. A cette fin,
802 l'UID est idéal.</li>
804 <li>Lorsqu'ils ajoutent des utilisateurs via FrontPage, les
805 administrateurs de FrontPage doivent choisir des noms
806 d'utilisateurs qui existent déjà dans l'annuaire LDAP (pour des
807 raisons évidentes). De même, le mot de passe que l'administrateur
808 entre dans le formulaire est ignoré, car pour l'authentification,
809 Apache utilise le mot de passe de l'annuaire LDAP, et non le mot
810 de passe enregistré dans le fichier des utilisateurs, ce qui peut
811 semer la confusion parmi les administrateurs web.</li>
813 <!-- XXX is that true? was mod_auth before the aaa change -->
814 <li>Pour supporter FrontPage, Apache doit être compilé avec
815 <module>mod_auth_basic</module>, <module>mod_authn_file</module>
816 et <module>mod_authz_groupfile</module>. Ceci est dû au fait
817 qu'Apache doit utiliser le fichier de groupes de
818 <module>mod_authz_groupfile</module> pour déterminer le niveau
819 d'accès d'un utilisateur au site web FrontPage.</li>
821 <li>Les directives doivent être placées dans les fichiers
822 <code>.htaccess</code>. Elles ne fonctionneront pas si vous les
823 placez dans une section <directive module="core"
824 type="section">Location</directive> ou <directive module="core"
825 type="section">Directory</directive>. Ceci est dû au fait que pour savoir
826 où se trouve la liste des utilisateurs valides,
827 <module>mod_authnz_ldap</module> doit être en mesure d'atteindre
828 la directive <directive
829 module="mod_authz_groupfile">AuthGroupFile</directive> qui se trouve
830 dans les fichiers <code>.htaccess</code> de FrontPage. Si les directives
831 de <module>mod_authnz_ldap</module> ne sont pas situées dans le
832 même fichier <code>.htaccess</code> que les directives FrontPage,
833 la configuration ne fonctionnera pas, car
834 <module>mod_authnz_ldap</module> ne sera jamais en mesure de
835 traiter le fichier <code>.htaccess</code>, et par conséquent ne
836 pourra jamais trouver le fichier des utilisateurs géré par
843 <name>AuthLDAPAuthorizePrefix</name>
844 <description>Spécifie le préfixe ajouté aux variables d'environnement
845 durant la phase d'autorisation</description>
846 <syntax>AuthLDAPAuthorizePrefix <em>préfixe</em></syntax>
847 <default>AuthLDAPAuthorizePrefix AUTHORIZE_</default>
848 <contextlist><context>directory</context><context>.htaccess</context>
850 <override>AuthConfig</override>
851 <compatibility>Disponible depuis la version 2.3.6</compatibility>
853 <p>Cette directive permet de spécifier le préfixe ajouté aux
854 variables d'environnement durant la phase d'autorisation. Si la
855 valeur spécifiée est <em>AUTHENTICATE_</em>, les utilisateurs de ces
856 variables d'environnement verront les mêmes informations, que le
857 serveur effectue une authentification, une autorisation, ou les
860 <note><title>Note</title>
861 Aucune variable d'autorisation n'est définie lorsqu'un utilisateur
862 s'est vu autoriser l'accès via la directive <code>Require
869 <name>AuthLDAPBindAuthoritative</name>
870 <description>Détermine si l'on doit utiliser d'autres fournisseurs
871 d'authentification lorsque le serveur ne peut pas valider les données
872 d'authentification de l'utilisateur, alors que ce dernier possède un
874 <syntax>AuthLDAPBindAuthoritative<em>off|on</em></syntax>
875 <default>AuthLDAPBindAuthoritative on</default>
876 <contextlist><context>directory</context><context>.htaccess</context>
878 <override>AuthConfig</override>
880 <p>Par défaut, des fournisseurs d'authentification sont appelés
881 si un utilisateur ne possède pas de DN, mais ne le sont pas si
882 l'utilisateur possède un DN et si son mot de passe ne peut pas être
883 vérifié lors d'une connexion au serveur LDAP. Si la directive
885 module="mod_authnz_ldap">AuthLDAPBindAuthoritative</directive> est
886 définie à <em>off</em>, d'autres modules d'authentification
887 configurés auront une chance de valider le mot de passe de
888 l'utilisateur si la tentative de connexion au serveur LDAP échoue
889 pour une raison quelconque (avec les données d'authentification
891 <p>Ceci permet aux utilisateurs présent à la fois dans l'annuaire
892 LDAP et dans un fichier <directive
893 module="mod_authn_file">AuthUserFile</directive> de s'authentifier
894 lorsque le serveur LDAP est disponible, alors que le compte de
895 l'utilisateur est verrouillé ou que son mot de passe est
896 inutilisable pour une raison quelconque.</p>
898 <seealso><directive module="mod_authn_file">AuthUserFile</directive></seealso>
899 <seealso><directive module="mod_auth_basic">AuthBasicProvider</directive></seealso>
903 <name>AuthLDAPInitialBindAsUser</name>
904 <description>Détermine si le serveur effectue la recherche initiale du
905 DN en utilisant le nom propre de l'utilisateur pour l'authentification
907 et non de manière anonyme, ou en utilisant des données d'authentification
908 codées en dur pour le serveur</description>
909 <syntax>AuthLDAPInitialBindAsUser <em>off|on</em></syntax>
910 <default>AuthLDAPInitialBindAsUser off</default>
911 <contextlist><context>directory</context><context>.htaccess</context>
913 <override>AuthConfig</override>
914 <compatibility>Disponible depuis la version 2.3.6</compatibility>
916 <p>Par défaut, le serveur convertit le nom d'utilisateur pour
917 l'authentification de base en nom distinctif LDAP (DN) soit de
918 manière anonyme, soit avec un couple nom/mot de passe dédié. Cette
919 directive permet de forcer le serveur à utiliser les véritables nom
920 d'utilisateur et mot de passe fournis par l'utilisateur pour
921 effectuer la recherche initiale du DN.</p>
923 <p>Si le nom d'utilisateur ne peut pas s'authentifier directement
924 et nécessite de légères modifications, voir la directive <directive
925 module="mod_authnz_ldap">AuthLDAPInitialBindPattern</directive>.</p>
927 <p>Cette directive ne doit être utilisée que si votre serveur LDAP
928 n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
929 utiliser de nom d'utilisateur dédié via la directive <directive
930 module="mod_authnz_ldap">AuthLDAPBindDN</directive>.
933 <note><title>Non disponible dans la cas d'une autorisation seule</title>
934 On ne peut utiliser cette directive que si ce module
935 effectue une authentification, et n'a aucun effet si ce module
936 n'est utilisé que pour les processus d'autorisation.
939 <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindPattern</directive></seealso>
940 <seealso><directive module="mod_authnz_ldap">AuthLDAPBindDN</directive></seealso>
941 <seealso><directive module="mod_authnz_ldap">AuthLDAPCompareAsUser</directive></seealso>
942 <seealso><directive module="mod_authnz_ldap">AuthLDAPSearchAsUser</directive></seealso>
946 <name>AuthLDAPInitialBindPattern</name>
947 <description>Spécifie la modification a apporter au nom d'utilisateur
948 pour l'authentification de base lors de l'authentification auprès du
949 serveur LDAP pour effectuer une recherche de DN</description>
950 <syntax>AuthLDAPInitialBindPattern<em><var>regex</var> <var>substitution</var></em></syntax>
951 <default>AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur
952 distant utilisé tel quel)</default>
953 <contextlist><context>directory</context><context>.htaccess</context>
955 <override>AuthConfig</override>
956 <compatibility>Disponible depuis la version 2.3.6</compatibility>
958 <p>Si la directive <directive
959 module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive> est
960 définie à <em>ON</em>, le nom utilisateur pour l'authentification de
961 base sera transformé selon l'expression rationnelle
962 <var>regex</var> et l'argument <var>substitution</var> spécifiés.</p>
964 <p>L'expression rationnelle est comparée au nom d'utilisateur pour
965 l'authentification de base courant. L'argument
966 <var>substitution</var> peut contenir des références arrières, mais
967 n'effectue aucune autre interpolation de variable.</p>
969 <p>Cette directive ne doit être utilisée que si votre serveur LDAP
970 n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
971 utiliser de nom d'utilisateur dédié via la directive <directive
972 module="mod_authnz_ldap">AuthLDAPBindDN</directive>.
975 <highlight language="config"> AuthLDAPInitialBindPattern (.+) $1@example.com </highlight>
976 <highlight language="config"> AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com</highlight>
978 <note><title>Non disponible dans la cas d'une autorisation seule</title>
979 On ne peut utiliser cette directive que si ce module
980 effectue une authentification, et n'a aucun effet si ce module
981 n'est utilisé que pour les processus d'autorisation.
983 <note><title>Débogage</title>
984 Le DN de substitution est enregistré dans la variable
985 d'environnement <em>LDAP_BINDASUSER</em>. Si l'expression
986 rationnelle ne convient pas, le nom d'utilisateur est utilisé
990 <seealso><directive module="mod_authnnz_ldap">AuthLDAPInitialBindAsUser</directive></seealso>
991 <seealso><directive module="mod_authnnz_ldap">AuthLDAPBindDN</directive></seealso>
995 <name>AuthLDAPBindDN</name>
996 <description>Un DN optionnel pour se connecter au serveur
998 <syntax>AuthLDAPBindDN <em>dn</em></syntax>
999 <contextlist><context>directory</context><context>.htaccess</context>
1001 <override>AuthConfig</override>
1004 <p>Cette directive permet de définir un DN optionnel pour se
1005 connecter au serveur afin d'y rechercher des entrées. Si aucun DN
1006 n'est spécifié, <module>mod_authnz_ldap</module> tentera une
1007 connexion anonyme.</p>
1009 </directivesynopsis>
1012 <name>AuthLDAPBindPassword</name>
1013 <description>Mot de passe à utiliser en conjonction avec le DN de
1014 connexion</description>
1015 <syntax>AuthLDAPBindPassword <em>mot-de-passe</em></syntax>
1016 <contextlist><context>directory</context><context>.htaccess</context>
1018 <override>AuthConfig</override>
1021 <p>Cette directive permet de spécifier un mot de passe à utiliser en
1022 conjonction avec le DN de connexion. Notez que ce mot de passe
1023 constitue en général une donnée sensible, et doit donc être protégé
1024 de manière appropriée. Vous ne devez utiliser les directives
1026 module="mod_authnz_ldap">AuthLDAPBindDN</directive> et <directive
1027 module="mod_authnz_ldap">AuthLDAPBindPassword</directive> que si
1028 vous en avez vraiment besoin pour effectuer une recherche dans
1031 </directivesynopsis>
1034 <name>AuthLDAPCharsetConfig</name>
1035 <description>Chemin du fichier de configuration de la correspondance
1036 langage/jeu de caractères</description>
1037 <syntax>AuthLDAPCharsetConfig <em>chemin-fichier</em></syntax>
1038 <contextlist><context>server config</context>
1042 <p>La directive <directive>AuthLDAPCharsetConfig</directive> permet
1043 de définir le chemin du fichier de configuration de la
1044 correspondance langage/jeu de caractères. <var>chemin-fichier</var>
1045 est un chemin relatif au répertoire défini par la directive
1047 module="core">ServerRoot</directive>. Ce fichier contient une liste
1048 de correspondances extension de langage/jeu de caractères. La
1049 plupart des administrateurs utilisent le fichier
1050 <code>charset.conv</code> fourni qui associe les extensions de
1051 langage courantes à leurs jeux de caractères.</p>
1053 <p>Le fichier contient des lignes au format suivant :</p>
1056 <var>extension de langage</var> <var>jeu de caractères</var>
1057 [<var>Nom du langage</var>] ...
1060 <p>L'extension est insensible à la casse. Les lignes vides et les
1061 lignes commençant par un dièse (<code>#</code>) sont ignorées.</p>
1063 </directivesynopsis>
1066 <name>AuthLDAPCompareAsUser</name>
1067 <description>Utilisation des données d'authentification de l'utilisateur
1068 pour effectuer les comparaisons pour l'attribution des autorisations</description>
1069 <syntax>AuthLDAPCompareAsUser on|off</syntax>
1070 <default>AuthLDAPCompareAsUser off</default>
1071 <contextlist><context>directory</context><context>.htaccess</context>
1073 <override>AuthConfig</override>
1074 <compatibility>Disponible depuis la version version 2.3.6</compatibility>
1077 <p>Lorsque cette directive est définie, et si
1078 <module>mod_authnz_ldap</module> a authentifié l'utilisateur, les
1079 recherches LDAP pour les autorisations utilisent le nom distinctif
1080 trouvé (DN) et le mot de passe d'authentification basique HTTP de
1081 l'utilisateur authentifié au lieu des données d'authentification
1082 configurées au niveau du serveur.</p>
1084 <p>Les vérifications d'autorisation <em>ldap-attribute</em>,
1085 <em>ldap-user</em>, et <em>ldap-group</em> (niveau simple seulement)
1086 utilisent des comparaisons.</p>
1088 <p>Cette directive n'a d'effet sur les comparaisons effectuées au
1089 cours des traitements de groupe imbriqués, et lorsque la directive
1090 <directive module="mod_authnz_ldap">AuthLDAPSearchAsUser</directive>
1091 est aussi activée.</p>
1093 <p>Cette directive ne doit être utilisée que si votre serveur LDAP
1094 n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
1095 utiliser de nom d'utilisateur dédié via la directive <directive
1096 module="mod_authnz_ldap">AuthLDAPBindDN</directive>.
1099 <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive></seealso>
1100 <seealso><directive module="mod_authnz_ldap">AuthLDAPSearchAsUser</directive></seealso>
1101 </directivesynopsis>
1104 <name>AuthLDAPCompareDNOnServer</name>
1105 <description>Utilise le serveur LDAP pour comparer les DNs</description>
1106 <syntax>AuthLDAPCompareDNOnServer on|off</syntax>
1107 <default>AuthLDAPCompareDNOnServer on</default>
1108 <contextlist><context>directory</context><context>.htaccess</context>
1110 <override>AuthConfig</override>
1113 <p>Lorsque cette directive est définie à on,
1114 <module>mod_authnz_ldap</module> utilise le serveur LDAP pour
1115 comparer les DNs. Il s'agit de la seule méthode infaillible pour
1116 comparer les DNs. <module>mod_authnz_ldap</module> va rechercher
1117 dans l'annuaire le DN spécifié par la directive <a
1118 href="#reqdn"><code>Require dn</code></a>, puis extraire ce DN et le
1119 comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette
1120 directive est à off, <module>mod_authnz_ldap</module> effectue une
1121 simple comparaison de chaînes. Cette dernière approche peut produire
1122 des faux négatifs, mais elle est beaucoup plus rapide. Notez
1123 cependant que le cache de <module>mod_ldap</module> peut accélérer
1124 la comparaison de DNs dans la plupart des situations.</p>
1126 </directivesynopsis>
1129 <name>AuthLDAPDereferenceAliases</name>
1130 <description>À quel moment le module va déréférencer les
1132 <syntax>AuthLDAPDereferenceAliases never|searching|finding|always</syntax>
1133 <default>AuthLDAPDereferenceAliases always</default>
1134 <contextlist><context>directory</context><context>.htaccess</context>
1136 <override>AuthConfig</override>
1139 <p>Cette directive permet de spécifier à quel moment
1140 <module>mod_authnz_ldap</module> va déréférencer les alias au cours
1141 des opérations liées à LDAP. La valeur par défaut est
1142 <code>always</code>.</p>
1144 </directivesynopsis>
1147 <name>AuthLDAPGroupAttribute</name>
1148 <description>L'attribut LDAP utilisé pour vérifier l'appartenance d'un
1149 utilisateur à un groupe.</description>
1150 <syntax>AuthLDAPGroupAttribute <em>attribut</em></syntax>
1151 <default>AuthLDAPGroupAttribute member uniquemember</default>
1152 <contextlist><context>directory</context><context>.htaccess</context>
1154 <override>AuthConfig</override>
1157 <p>Cette directive permet de spécifier quel attribut LDAP est
1158 utilisé pour vérifier l'appartenance d'un utilisateur à un
1159 groupe. On peut spécifier plusieurs attributs en répétant cette
1160 directive plusieurs fois. Si la directive n'est pas définie,
1161 <module>mod_authnz_ldap</module> utilise les attributs
1162 <code>member</code> et <code>uniquemember</code>.</p>
1164 </directivesynopsis>
1167 <name>AuthLDAPGroupAttributeIsDN</name>
1168 <description>Utilise le DN de l'utilisateur pour vérifier son
1169 appartenance à un groupe</description>
1170 <syntax>AuthLDAPGroupAttributeIsDN on|off</syntax>
1171 <default>AuthLDAPGroupAttributeIsDN on</default>
1172 <contextlist><context>directory</context><context>.htaccess</context>
1174 <override>AuthConfig</override>
1177 <p>Lorsqu'elle est définie à <code>on</code>, cette directive
1178 indique que c'est le DN de l'utilisateur qui doit être utilisé pour
1179 vérifier son appartenance à un groupe. Dans le cas contraire, c'est
1180 le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que
1181 le client envoie le nom d'utilisateur <code>bjenson</code>, qui
1182 correspond au DN LDAP <code>cn=Babs Jenson,o=Example</code>. Si la
1183 directive est à <code>on</code>, <module>mod_authnz_ldap</module> va
1184 vérifier si <code>cn=Babs Jenson, o=Example</code> est un membre du
1185 groupe. Dans le cas contraire, <module>mod_authnz_ldap</module>
1186 vérifiera si <code>bjenson</code> est un membre du groupe.</p>
1188 </directivesynopsis>
1191 <name>AuthLDAPMaxSubGroupDepth</name>
1192 <description>Spécifie la profondeur d'imbrication des sous-groupes
1193 maximale prise en compte avant l'abandon de la recherche de
1194 l'utilisateur.</description>
1195 <syntax>AuthLDAPMaxSubGroupDepth <var>Nombre</var></syntax>
1196 <default>AuthLDAPMaxSubGroupDepth 10</default>
1197 <contextlist><context>directory</context><context>.htaccess</context>
1199 <override>AuthConfig</override>
1200 <compatibility>Disponible à partir de la version 2.3.0 du serveur HTTP
1201 Apache</compatibility>
1204 <p>Lorsque cette directive est définie à une valeur <code>X</code>
1205 non nulle, en combinaison avec l'utilisation de la directive
1206 <code>Require ldap-group DN-groupe</code>, les données de connexion
1207 fournies seront utilisées pour vérifier l'appartenance de
1208 l'utilisateur à l'objet de l'annuaire <code>DN-groupe</code> ou à
1209 tout sous-groupe du groupe courant en tenant compte de la profondeur
1210 d'imbrication maximale <code>X</code> spécifiée par la directive.</p>
1211 <p>Se référer à la section <a href="#reqgroup"><code>Require
1212 ldap-group</code></a> pour un exemple plus détaillé.</p>
1214 </directivesynopsis>
1217 <name>AuthLDAPRemoteUserAttribute</name>
1218 <description>Spécifie l'attribut dont la valeur renvoyée au cours de la
1219 requête de l'utilisateur sera utilisée pour définir la variable
1220 d'environnement REMOTE_USER</description>
1221 <syntax>AuthLDAPRemoteUserAttribute uid</syntax>
1222 <default>none</default>
1223 <contextlist><context>directory</context><context>.htaccess</context>
1225 <override>AuthConfig</override>
1228 <p>Lorsque cette directive est définie, la variable d'environnement
1229 <code>REMOTE_USER</code> sera définie à la valeur de l'attribut
1230 spécifié. Assurez-vous que cet attribut soit bien inclus dans la
1231 liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans
1232 le cas contraire, cette directive n'aurait aucun effet. Si elle est
1233 présente, cette directive l'emporte sur AuthLDAPRemoteUserIsDN. Elle
1234 peut s'avérer utile par exemple, si vous souhaitez que les
1235 utilisateurs se connectent à un site web en utilisant leur adresse
1236 email, alors qu'une application sous-jacente nécessite un nom
1237 d'utilisateur comme identifiant.</p>
1239 </directivesynopsis>
1242 <name>AuthLDAPRemoteUserIsDN</name>
1243 <description>Utilise le DN de l'utilisateur pour définir la variable
1244 d'environnement REMOTE_USER</description>
1245 <syntax>AuthLDAPRemoteUserIsDN on|off</syntax>
1246 <default>AuthLDAPRemoteUserIsDN off</default>
1247 <contextlist><context>directory</context><context>.htaccess</context>
1249 <override>AuthConfig</override>
1252 <p>Lorsque cette directive est à on, la variable d'environnement
1253 <code>REMOTE_USER</code> sera définie avec la valeur du DN complet
1254 de l'utilisateur authentifié, et non plus avec simplement le nom
1255 d'utilisateur fourni par le client. Elle est définie à off par
1258 </directivesynopsis>
1261 <name>AuthLDAPSearchAsUser</name>
1262 <description>Utilise les données d'authentification de l'utilisateur
1263 pour la recherche des autorisations</description>
1264 <syntax>AuthLDAPSearchAsUser on|off</syntax>
1265 <default>AuthLDAPSearchAsUser off</default>
1266 <contextlist><context>directory</context><context>.htaccess</context>
1268 <override>AuthConfig</override>
1269 <compatibility>Disponible depuis la version 2.3.6</compatibility>
1272 <p>Lorsque cette directive est définie, et si
1273 <module>mod_authnz_ldap</module> a authentifié l'utilisateur, les
1274 recherches LDAP pour définir les autorisations utilisent le nom
1275 distinctif (DN) trouvé et le mot de passe pour l'authentification de
1276 base HTTP de l'utilisateur authentifié, au lieu des données
1277 d'authentification configurées au niveau du serveur.</p>
1279 <p>Les vérifications d'autorisation <em>ldap-filter</em> et
1280 <em>ldap-dn</em> utilisent des recherches.</p>
1282 <p>Cette directive n'a d'effet sur les comparaisons effectuées au
1283 cours des traitements de groupe imbriqués, et lorsque la directive
1285 module="mod_authnz_ldap">AuthLDAPCompareAsUser</directive>
1286 est aussi activée.</p>
1288 <p>Cette directive ne doit être utilisée que si votre serveur LDAP
1289 n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
1290 utiliser de nom d'utilisateur dédié via la directive <directive
1291 module="mod_authnz_ldap">AuthLDAPBindDN</directive>.
1295 <seealso><directive module="mod_authnz_ldap">AuthLDAPInitialBindAsUser</directive></seealso>
1296 <seealso><directive module="mod_authnz_ldap">AuthLDAPCompareAsUser</directive></seealso>
1297 </directivesynopsis>
1300 <name>AuthLDAPSubGroupAttribute</name>
1301 <description>Spécifie les noms d'attribut, un par directive, utilisés
1302 pour différencier les membres du groupe courant qui sont eux-mêmes des
1303 groupes.</description>
1304 <syntax>AuthLDAPSubGroupAttribute <em>attribut</em></syntax>
1305 <default>AuthLDAPSubgroupAttribute member uniquemember</default>
1306 <contextlist><context>directory</context><context>.htaccess</context>
1308 <override>AuthConfig</override>
1309 <compatibility>Disponible à partir de la version 2.3.0 du serveur HTTP
1310 Apache</compatibility>
1313 <p>Un objet groupe LDAP peut contenir des membres qui sont des
1314 utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
1315 sous-groupes ou groupes imbriqués). La directive
1316 <code>AuthLDAPSubGroupAttribute</code> spécifie l'attribut utilisé
1317 pour identifier les groupes, alors que la directive
1318 <code>AuthLDAPGroupAttribute</code> spécifie l'attribut utilisé
1319 pour identifier les utilisateurs. On peut spécifier plusieurs
1320 attributs en répétant la directive plusieurs fois. Si elle n'est pas
1321 définie, <module>mod_authnz_ldap</module> utilise les attributs
1322 <code>member</code> et <code>uniqueMember</code>.</p>
1324 </directivesynopsis>
1327 <name>AuthLDAPSubGroupClass</name>
1328 <description>Spécifie quelles valeurs d'objectClass LDAP identifient les
1329 objets de l'annuaire qui sont des groupes au cours du traitement des
1330 sous-groupes.</description>
1331 <syntax>AuthLDAPSubGroupClass <em>ObjectClass-LDAP</em></syntax>
1332 <default>AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames</default>
1333 <contextlist><context>directory</context><context>.htaccess</context>
1335 <override>AuthConfig</override>
1336 <compatibility>Disponible à partir de la version 2.3.0 du serveur HTTP
1337 Apache</compatibility>
1340 <p>Un objet groupe LDAP peut contenir des membres qui sont des
1341 utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
1342 sous-groupes ou groupes imbriqués). La directive
1343 <code>AuthLDAPSubGroupAttribute</code> permet d'identifier les
1344 membres qui sont des sous-groupes du groupe courant (à l'opposé des
1345 membres utilisateurs). La directive
1346 <code>AuthLDAPSubGroupClass</code> permet de spécifier les valeurs
1347 d'objectClass LDAP utilisées pour vérifier que certains membres sont
1348 en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent
1349 alors faire l'objet d'une recherche d'autres membres utilisateurs ou
1350 sous-groupes. On peut spécifier plusieurs attributs en répétant
1351 cette directive plusieurs fois. Si cette directive n'est pas
1352 définie, <module>mod_authnz_ldap</module> utilise les attributs
1353 <code>groupOfNames</code> et <code>groupOfUniqueNames</code>.</p>
1355 </directivesynopsis>
1358 <name>AuthLDAPUrl</name>
1359 <description>L'URL permettant de spécifier les paramètres de la
1360 recherche LDAP</description>
1361 <syntax>AuthLDAPUrl <em>url [NONE|SSL|TLS|STARTTLS]</em></syntax>
1362 <contextlist><context>directory</context><context>.htaccess</context>
1364 <override>AuthConfig</override>
1367 <p>Une URL conforme à la RFC 2255 qui permet de spécifier les
1368 paramètres à utiliser pour la recherche dans l'annuaire LDAP. La
1369 syntaxe de l'URL est :</p>
1370 <example>ldap://hôte:port/DN-de-base?attribut?portée?filtre</example>
1371 <p>Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs
1372 LDAP, la syntaxe sera :</p>
1373 <highlight language="config">AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."</highlight>
1374 <p><em><strong>Mise en garde : </strong>Si vous spécifiez plusieurs
1375 serveurs, vous devez en entourer la liste avec des guillemets ; dans le
1376 cas contraire, vous générerez une erreur : "AuthLDAPURL takes one
1377 argument, URL to define LDAP connection..".</em> Vous pouvez bien
1378 entendu ajouter des paramètres de recherche à chacun des serveurs
1384 <dd>Pour ldap non sécurisé, utilisez la chaîne
1385 <code>ldap</code>. Pour ldap sécurisé, utilisez à la place la
1386 chaîne <code>ldaps</code>. LDAP sécurisé n'est disponible que si
1387 Apache a été lié avec une bibliothèque LDAP supportant SSL.</dd>
1392 <p>Il s'agit du nom/port du serveur ldap
1393 (dont la valeur par défaut est
1394 <code>localhost:389</code> pour <code>ldap</code>, et
1395 <code>localhost:636</code> pour <code>ldaps</code>). Pour
1396 spécifier plusieurs serveurs LDAP redondants, indiquez
1397 simplement leur liste en les séparant par des espaces.
1398 <module>mod_authnz_ldap</module> tentera alors de se connecter
1399 à chacun des serveurs jusqu'à ce qu'il parvienne à se
1400 connecter avec succès. Notez qu'en cas de multiples serveurs
1401 LDAP, l'ensemble de l'URL LDAP doit être entourée de
1404 <p>lorsqu'une connection a été établie avec un serveur, elle
1405 reste active pendant toute la durée de vie du processus
1406 <program>httpd</program>, ou jusqu'à ce que le serveur LDAP
1407 cesse de fonctionner.</p>
1409 <p>Si le serveur LDAP cesse de fonctionner, et ainsi
1411 connexion existante, <module>mod_authnz_ldap</module> tentera
1412 de se reconnecter en commençant par le premier serveur de la
1413 liste, et ainsi de suite avec les serveurs redondants
1414 suivants. Notez que ce processus n'a rien à voir avec une
1415 véritable recherche de type round-robin.</p>
1419 <dd>Le DN de la branche de l'annuaire à partir de laquelle
1420 toutes les recherches seront lancées. Il doit au moins
1421 correspondre à la racine de votre annuaire, mais vous pouvez
1422 aussi indiquer une branche plus spécifique.</dd>
1426 <dd>Il s'agit de l'attribut à utiliser pour la recherche.
1428 2255 autorise une liste d'attributs séparés par des virgules,
1429 seul le premier sera retenu, sans tenir compte des autres
1430 attributs fournis. Si aucun attribut n'est fourni, l'attribut
1431 par défaut est <code>uid</code>. Il est judicieux de choisir un
1432 attribut dont la valeur sera unique parmi toutes les entrées de
1433 la branche de l'annuaire que vous aurez définie. Tous les
1434 attributs spécifiés seront enregistrés dans des variables
1435 d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir
1436 être utilisés par d'autres modules.</dd>
1440 <dd>Il s'agit de la portée de la recherche. Elle peut prendre
1441 les valeurs <code>one</code> ou <code>sub</code>. Notez que la
1442 RFC 2255 supporte aussi une portée de valeur <code>base</code>,
1443 mais cette dernière n'est pas supportée par le module. Si la
1444 portée n'est pas définie, ou si elle est définie à
1445 <code>base</code>, c'est la valeur de portée par défaut
1446 <code>sub</code> qui sera utilisée.</dd>
1450 <dd>Il s'agit d'un filtre de recherche LDAP valide. Si aucun
1451 filtre n'est spécifié, le filtre par défaut
1452 <code>(objectClass=*)</code> sera utilisé, ce qui corrspond à
1453 une recherche de tous les types d'objets de l'arborescence. La
1454 taille des filtres est limitée à environ 8000 caractères (valeur
1455 de la macro <code>MAX_STRING_LEN</code> dans le code source
1456 d'Apache), ce qui s'avère plus que suffisant pour la plupart des
1460 <p>Pour une recherche, les attribut, filtre et nom d'utilisateur
1461 fournis par le client HTTP sont combinés pour créer un filtre de
1462 recherche du style :
1463 <code>(&(<em>filtre</em>)(<em>attribut</em>
1464 =<em>nom-utilisateur</em>))</code>.</p>
1466 <p>Par exemple, considérons l'URL
1467 <code>ldap://ldap.example.com/o=Example?cn?sub?(posixid=*)</code>.
1468 Lorsqu'un client tentera de se connecter en utilisant le nom
1469 d'utilisateur <code>Babs Jenson</code>, le filtre de recherche sera
1470 : <code>(&(posixid=*)(cn=Babs Jenson))</code>.</p>
1472 <p>On peut encore ajouter un paramètre optionnel pour permettre à
1473 l'URL LDAP de surcharger le type de connexion. Ce paramètre peut
1474 prendre l'une des valeurs suivantes :</p>
1478 <dd>Établit une connexion non sécurisée sur le port LDAP par
1479 défaut, ce qui est équivalent à <code>ldap://</code> sur le port
1482 <dd>Établit une connexion sécurisée sur le port LDAP sécurisé
1483 par défaut, ce qui est équivalent à <code>ldaps://</code>.</dd>
1484 <dt>TLS | STARTTLS</dt>
1485 <dd>Établit une connexion sécurisée par élévation de niveau sur
1486 le port LDAP par défaut. Cette connexion sera initialisée sur le
1487 port 389 par défaut, puis élevée à un niveau de connexion
1488 sécurisée sur le même port.</dd>
1491 <p>Voir plus haut pour des exemples d'URLs définies par la directive
1492 <directive module="mod_authnz_ldap">AuthLDAPURL</directive>.</p>
1494 </directivesynopsis>