Projet

Général

Profil

Ldap » Historique » Version 1

Pierre-Arnaud Poudret, 05/06/2013 15:36

1 1 Pierre-Arnaud Poudret
{{>toc}}
2
3
h1. Annuaire LDAP
4
5
*Installation d'OpenLDAP*
6
7
Documentation:
8
http://www.openldap.org/doc/admin24 (la doc de référence openldap en anglais)
9
http://www.zytrax.com/books/ldap/ (en anglais mais très bien pour apprendre)
10
http://www.vogelweith.com/debian_server/050_openldap.php (pas forcément très à jour)
11
http://doc.ubuntu-fr.org/openldap-server
12
13
Versions utilisées dans le cadre de cette documentation:
14
Ubuntu 11.04 Natty Narwal / Debian Wheezy
15
openldap 2.4.23
16
17
Approche choisie pour l'installation:
18
* utilisation de debconf pour générer un début de conf
19
* le strict minimum de configuration à la main dans /etc/ldap/slapd.d
20
* utilisation du client lourd Apache Directory Studio pour terminer la configuration et administrer le serveur
21
22
L'intérêt d'utiliser précocement un client ldap lourd pour faire la conf est de donner le plus tôt possible à l'utilisateur néophyte une vision globale de l'arborescence ldap, de rendre celle-ci un peu plus facile à appréhender. Les autres docs en ligne exploitent davantage les outils ldap de base en ligne de commande (slapadd, fichiers ldif, etc), et peuvent sembler encore plus absconses quand on a pas l'habitude d'OpenLDAP.
23
24
Note:
25
* dans openldap, SHA signifie SHA1
26
* dans openldap, SSHA signifie _Seeded_ SHA1 (un _salt_ en plus)
27
28
h1. Installation du package / debconf
29
30
+Note+: il semble raisonnable de ne pas ouvrir le LDAP sur l'extérieur tant que l'on a pas terminé son installation, la configuration des ACL et celle de TLS.
31
32
<pre>
33
sudo apt-get install slapd ldap-utils
34
</pre>
35
36
Debconf:
37
* Please enter the password for the admin entry in your LDAP directory.
38
-> saisir n'importe quoi à ce stade. ce mdp sera écrasé par le suite
39
40
41
Debconf a créé un début de configuration pour openldap, ainsi qu'un annuaire basé sur le fqdn du système, qui ne va pas convenir à nos besoins.
42
43
h1. Configuration d'openldap
44
45
http://www.openldap.org/doc/admin24/slapdconf2.html
46
47
h2. Description
48
49
Le LDAP a une structure arborescente.
50
La racine s'appelle le root DSE (root directory specific entry).
51
52
Juste en dessous du DSE, deux sous-arbres identifiés par leur Distinguished Name:
53
54
* +DN="cn=config"+: la configuration d'OpenLDAP, organisée de manière arborescente, avec la conf des backends de données, avec les schémas de données installés, la réplication, etc. *Problème: l'install debian n'a pas défini de compte admin pour cette branche du LDAP. On ne peut donc pas encore y accéder avec un client LDAP.* Par contre, cette branche de l'annuaire est stockée au format ldif dans /etc/ldap/slapd.d et elle est modifiable à froid.
55
56
* +DN="o=ILLYSE,l=Villeurbanne,st=RHA,c=FR"+: l'annuaire d'Illyse. Les données, avec les comptes d'utilisateurs, les groupes, etc. Cette branche de l'annuaire est stockée dans une base HDB sous /var/lib/ldap. *Problème: debconf n'a pas généré un "contexte de nommage" convenable pour cette branche: les objets ont des noms (DN) se terminant en "dc=xxx,dc=yyy" (en fonction du fqdn du serveur) au lieu de "o=ILLYSE,l=Villeurbanne,st=RHA,c=FR"*. Il faut corriger cela sous /etc/ldap/slapd.d également.
57
58
+Note+: le choix du contexte de nommage en o=ILLYSE,l=Villeurbanne,st=RHA,c=FR permet d'avoir une cohérence entre les noms (DN) des objets du ldap et les noms (DN) des certificats issus de la [[PKI]]. Cela facilite l'utilisation conjointe du ldap et de la [[PKI]] pour faire de l'authentification forte. (Pour en savoir plus: http://en.wikipedia.org/wiki/Directory_information_tree - ici, on a fait le choix de tout aligner sur la structure par défaut des DN dans openssl. On aurait à priori pu choisir une autre structure et adapter la configuration d'openssl.)
59
60
h2. Configuration de base dans /etc/ldap/slapd.d
61
62
*Permettre l'accès à cn=config*
63
64
Il faut ajouter un DN de login et un mot de passe dans le fichier ldif définissant le backend pour la branche cn=config. On utilise slappasswd pour calculer un hachage.
65
66
<pre>
67
sudo /etc/init.d/slapd stop
68
</pre>
69
70
<pre>
71
lemur@rigel:/etc/ldap/slapd.d$ slappasswd
72
New password:
73
Re-enter new password:
74
{SSHA}foobarEbUllsH1tolnl8CXbUllsH1tFi
75
</pre>
76
77
<pre>
78
sudo vi /etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif
79
</pre>
80
81
Modifier la ligne olcRootDN et ajouter la ligne olcRootPW, avec le hachage produit par slappasswd:
82
<pre>
83
olcRootDN: cn=admin,cn=config
84
olcRootPW: {SSHA}foobarEbUllsH1tolnl8CXbUllsH1tFi
85
</pre>
86
87
<pre>
88
sudo /etc/init.d/slapd start
89
</pre>
90
91
Il est maintenant possible de se connecter au LDAP en tant que cn=admin,cn=config et de modifier la configuration du serveur.
92
93
*Correction du contexte de nommage*
94
95
Le fichier slapd.d/cn=config/olcDatabase={1}hdb.ldif définit le backend pour la branche du ldap contenant les données. Il est nécessaire de le corriger pour passer au contexte de nommage o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
96
<pre>
97
sudo /etc/init.d/slapd stop
98
sudo vi /etc/ldap/slapd.d/cn=config/olcDatabase\=\{1\}hdb.ldif
99
</pre>
100
101
Modifier les lignes suivantes (il s'agit essentiellement de remplacer les occurrences de dc=xxx,dc=yyy par o=ILLYSE,l=Villeurbanne,st=RHA,c=FR et de définir un mot de passe admin)
102
<pre>
103
olcSuffix: o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
104
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by cn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by * none
105
olcAccess: {2}to * by self write by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by * read
106
olcRootDN: cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
107
olcRootPW: {SSHA}foobarEbUllsH1tolnl8CXbUllsH1tFi
108
</pre>
109
110
Utiliser le même hachage de mot de passe que précédemment pour olcRootPW.
111
112
+Note+: les lignes sont coupées à 78 caractères par défaut dans les fichiers LDIF. Pour faciliter l'édition, il n'est pas gênant de joindre les lignes fractionnées (pour les olcAccess, notamment). slapd saura quand même les lire.
113
114
+Note+: on pourrait avoir des mdp différents pour l'administrateur de la configuration (cn=admin,cn=config) et pour celui des données (cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR). En pratique, sur un serveur en prod, on peut même ne pas définir du tout les comptes administrateurs, et faire les modifs en ligne de commande.
115
116
Purger la base HDB initialement créée par debconf. Openldap recréera une base vierge au redémarrage de slapd.
117
<pre>
118
sudo rm /var/lib/ldap/*
119
</pre>
120
121
<pre>
122
sudo /etc/init.d/slapd start
123
</pre>
124
125
h2. Connexion avec Apache Directory Studio
126
127
http://directory.apache.org/studio/downloads.html
128
129
+Note+: pour le moment, la branche o=ILLYSE,l=Villeurbanne,st=RHA,c=FR est encore vide.
130
131
A ce stade, avec les ACL par défaut (stockées sous cn=admin), il existe trois niveaux d'accès:
132
133
* +anonyme+: accès en consultation à tout o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, à l'exception des attributs sensibles (hachages de mots de passe). Dans DS, choisir _Pas d'authentification_ sur l'onglet Authentification de la fenêtre de connexion.
134
135
* +admin o=ILLYSE,l=Villeurbanne,st=RHA,c=FR+: accès complet à o=ILLYSE,l=Villeurbanne,st=RHA,c=FR. Dans DS, choisir _Authentification simple_ et se connecter en tant que cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR avec le mdp.
136
137
* +admin cn=config+: accès complet à la configuration d'openldap, ainsi qu'à o=ILLYSE,l=Villeurbanne,st=RHA,c=FR. Dans DS, choisir _Authentification simple_, se connecter en tant que cn=admin,cn=config avec le mdp, _et sur l'onglet Options du navigateur, *choisir cn=config comme DN de base_.*
138
139
Maintenant qu'on dispose d'un accès facile à cn=config, on peut commencer la configuration proprement dite.
140
141
h2. Configuration
142
143
_Se connecter en tant que cn=admin,cn=config._
144
145
!http://www.illyse.org/attachments/download/24/dirstudio-ldap-install1.PNG!
146
147
*Interdiction des connexions anonymes / restriction des droits des users authentifiés*
148
149
_En tant que cn=admin,cn=config._
150
151
http://www.openldap.org/doc/admin24/access-control.html
152
153
L'objet qui définit le backend de stockage pour la branche o=ILLYSE,l=Villeurbanne,st=RHA,c=FR est olcDatabase={1}hdb,cn=config. 
154
155
Les ACL de base régissant l'accès à la branche o=ILLYSE,l=Villeurbanne,st=RHA,c=FR se trouvent dans les attributs _olcAccess_ de cet objet.
156
157
+Valeur par défaut des attributs olcAccess de olcDatabase={1}hdb,cn=config+
158
<pre>
159
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by * none
160
olcAccess: {1}to dn.base="" by * read
161
olcAccess: {2}to * by self write by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by * read
162
</pre>
163
164
Un minimum d'explication de texte s'impose:
165
166
+Première ligne+: concerne spécifiquement les attributs d'authentification ("to attrs=userPassword,shadowLastChange")
167
* by self write: un user authentifié a le droit de changer son propre mot de passe
168
* by anonymous auth: une connexion non authentifiée peut y accéder, mais uniquement dans le cadre du process d'authentification (permet le login)
169
* by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write: droit en écriture pour l'administrateur de la branche o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
170
* by * none: aucun accès pour le reste du monde
171
172
+Deuxième ligne+: je ne suis pas encore certain de la signification de _dn.base=""_ mais cette ligne est nécessaire à l'authentification SASL.
173
174
+Troisième ligne+: concerne l'ensemble de l'annuaire o=ILLYSE,l=Villeurbanne,st=RHA,c=FR ("to *")
175
* by self write: un user authentifié peut modifier sa propre entrée dans l'annuaire
176
* by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write: l'admin accède à tout en écriture
177
* by * read: accès en lecture à tout le monde (y compris les connexions non authentifiées). On va changer ça tout de suite.
178
179
Les clauses des ACL sont évaluées dans l'ordre. L'évaluation s'arrête à la première clause qui matche.
180
181
On modifie ces ACL pour interdire la consultation anonyme et limiter les droits des utilisateurs authentifiés.
182
183
+Configuration modifiée+
184
<pre>
185
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR" write by users none by * none
186
olcAccess: {1}to dn.base="" by * read
187
olcAccess: {2}to * by self write by users none by * none
188
</pre>
189
190
Désormais, les connexions anonymes (by anonymous, by *) n'ont plus accès qu'à la procédure d'authentification.
191
Les utilisateurs authentifiés n'ont accès (en lecture/écriture) qu'à leur propre entrée dans le ldap (by self write / by users none).
192
193
*Indexation*
194
195
_En tant que cn=admin,cn=config._
196
197
Certains attributs sont indexés pour accélérer les recherches dans l'annuaire. On spécifie les attributs habituellement indexés dans olcDatabase={1}hdb,cn=config.
198
=>modifier l'attribut olcDbIndex de olcDatabase={1}hdb,cn=config:
199
<pre>
200
olcDbIndex: objectclass,entryCSN,uid,cn,entryUUID eq
201
</pre>
202
Cette ligne signifie que les attributs objectclass, entryCSN, uid, cn et entryUUID seront indexés pour l'opérateur d'égalité.
203
204
+Note+: *attributs indexés au 17/1/2012* (pour référence - nécessite des schémas de données qui ne sont pas installés à ce stade)
205
<pre>
206
olcDbIndex: objectclass,entryCSN,uid,cn,entryUUID,mail,dlzType eq
207
</pre>
208
209
Il faut maintenant exécuter slapindex (à froid) en tant que openldap pour mettre à jour l'indexation.
210
<pre>
211
sudo /etc/init.d/slapd stop
212
su - openldap -s /bin/bash
213
/usr/sbin/slapindex
214
# ou sudo -u openldap slapindex -v
215
#indexing id=00000001
216
#indexing id=00000002
217
#indexing id=00000003
218
# ...
219
220
sudo /etc/init.d/slapd start
221
</pre>
222
223
224
*StartTLS*
225
226
_En tant que cn=admin,cn=config._
227
228
http://www.openldap.org/doc/admin24/tls.html
229
230
Produire un certificat pour le serveur LDAP en utilisant la [[PKI]].
231
Spécificités concernant la génération des certificats LDAP: [[ldap-pki]]
232
233
+Note+: la clé privée du certificat du serveur LDAP ne doit pas être protégée par mot de passe. Openldap ne le gère pas.
234
235
Stockage des certificats (CA+serveur LDAP) et de la clé:
236
<pre>
237
lemur@rigel:/etc/ldap$ ls -al *.crt *.key
238
-rw-r--r-- 1 openldap openldap 1797 2011-10-16 23:05 ca.crt
239
-rw-r--r-- 1 openldap openldap 5649 2011-10-17 11:21 ldap0.illyse.org.crt
240
-rw------- 1 openldap openldap 1679 2011-10-17 11:21 ldap0.illyse.org.key
241
</pre>
242
243
Note/FIXME: on doit pouvoir faire mieux pour les droits sur la clé, en ajoutant openldap au groupe ssl-cert.
244
245
Se connecter cn=admin,cn=config, afficher l'objet cn=config (et non plus olcDatabase={1}hdb), et ajouter les attributs suivants:
246
<pre>
247
olcTLSCACertificateFile: /etc/ldap/ca.crt
248
olcTLSCertificateFile: /etc/ldap/ldap0.illyse.org.crt
249
olcTLSCertificateKeyFile: /etc/ldap/ldap0.illyse.org.key
250
olcTLSVerifyClient: allow
251
</pre>
252
253
<pre>
254
sudo /etc/init.d/slapd restart
255
</pre>
256
257
On peut maintenant se connecter à l'annuaire avec StartTLS sur le port 389.
258
=> modifier les connexions dans Apache Directory Studio
259
260
l'attribut _olcTLSVerifyClient=allow_ signifie que l'on peut s'authentifier en utilisant un certificat client, mais que ce n'est pas exigé par le serveur. Les connexions avec du simple chiffrement TLS restent autorisées. Forcer l'authentification forte rendrait le ldap difficile à exploiter depuis la plupart des clients/services. Elle sera toutefois employée dans le cadre de la réplication entre serveurs LDAP, entre autres pour éviter de laisser des mots de passe en clair dans la configuration.
261
262
*ldaps* (optionnel)
263
264
_En tant que cn=admin,cn=config._
265
266
Certains services n'implémentent pas le chiffrement StartTLS, mais plutôt ldaps (SSL).
267
268
Il faut l'activer dans /etc/default/slapd en ajoutant ldaps:/// à la ligne SLAPD_SERVICES:
269
<pre>
270
sudo vi /etc/default/slapd
271
</pre>
272
273
<pre>
274
# slapd normally serves ldap only on all TCP-ports 389. slapd can also
275
# service requests on TCP-port 636 (ldaps) and requests via unix
276
# sockets.
277
# Example usage:
278
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
279
SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"
280
</pre>
281
282
<pre>
283
sudo /etc/init.d/slapd restart
284
</pre>
285
286
On peut maintenant se connecter à l'annuaire avec ldaps sur le port 636.
287
288
*Copies d'écran dans ADS*
289
290
!http://www.illyse.org/attachments/download/25/dirstudio-ldap-install2.PNG!
291
292
!http://www.illyse.org/attachments/download/26/dirstudio-ldap-install3.PNG!
293
294
*Modification des ACL*
295
296
On va maintenant modifier les ACL pour forcer les connexions chiffrées. (On ne peut empêcher complètement les connexions sans chiffrement/authentification, mais on fait en sorte que ces connexions n'aient aucun droit sur l'annuaire, pas même en consultation.)
297
Pour cela, on utilise le Security Strength Factor (SSF) en ajoutant "ssf=128" devant les portions des ACL indiquant à qui s'applique tel ou tel droit.
298
299
Au passage, on supprime les références à cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR: ce dn étant défini dans olcDatabase={1}hdb,cn=config par l'attribut olcRootDN, ses droits administrateur sont implicites.
300
301
+Configuration modifiée+
302
<pre>
303
olcAccess: {0}to attrs=userPassword,shadowLastChange by ssf=128 self write by anonymous auth by users none by * none
304
olcAccess: {1}to dn.base="" by * read
305
olcAccess: {2}to * by ssf=128 self write by users none by * none
306
</pre>
307
308
FIXME: passer à ssf=256 si possible. A ce jour, lorsqu'on se connecte avec un certificat client, on obtient seulement ssf=128, ce qui suggère que l'on pourrait utiliser de meilleurs algos de chiffrement (au niveau de la [[PKI]]?). A creuser.
309
310
h1. Peuplement de l'annuaire
311
312
La configuration terminée, on peut maintenant se consacrer aux données.
313
On privilégiera désormais les connexions TLS.
314
315
*Création de la racine des données*
316
317
_Se connecter en tant que cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR._
318
319
Pour l'instant, la branche de données de l'annuaire est encore vide. On va maintenant créer sa première entrée, o=ILLYSE,l=Villeurbanne,st=RHA,c=FR. Cette entrée est dite _context entry_. Elle définit le contexte de nommage de la branche des données, dont elle est la racine.
320
321
Dans Apache Directory Studio, clic-droit sur l'objet Root DSE / Nouveau / Nouvelle context entry.
322
Une boite de dialogue apparaît. Choisir:
323
* créer l'entrée à partir de zéro
324
* object class: organization (la classe top est ajoutée automatiquement au passage)
325
* DN de la context entry: o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
326
327
*Unités organisationnelles*
328
329
_En tant que cn=admin,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR._
330
331
Habituellement, les données sont organisée en plusieurs _Organizational Units_. Ce sont les branches principales de l'annuaire. Cette organisation peut posséder plusieurs niveaux.
332
333
Pour créer une structure classique, nous allons créer dans l'arborescence, sous l'objet parent o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, deux nouveaux objets de classe organizationalUnit.
334
335
Pour créer ces deux objets dans Apache Directory Studio, clic-droit sur o=ILLYSE,l=Villeurbanne,st=RHA,c=FR / Nouveau / Nouvelle entrée.
336
* créer l'entrée à partir de zéro
337
* classe organizationalUnit. La classe parente top est automatiquement ajoutée.
338
* RDN=ou. Cela définit la "clé" de l'objet qui fera partie de son nom complet, le DN (Distinguished Name, par exemple "ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR").
339
* ou: groups ou users, voir ci-dessous
340
341
Exports LDIF:
342
343
* Comptes d'utilisateurs
344
<pre>
345
dn: ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
346
objectClass: organizationalUnit
347
objectClass: top
348
ou: users
349
</pre>
350
351
Une fois la première unité organisationnelle créée, ADS offre la possibilité de l'utiliser comme modèle pour créer la suivante.
352
On peut aussi faire un simple copier-coller dans l'arborescence. ADS proposera de renommer l'objet collé.
353
354
* Groupes
355
<pre>
356
dn: ou=groups,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
357
objectClass: organizationalUnit
358
objectClass: top
359
ou: groups
360
</pre>
361
362
Ultérieurement, on pourra créer d'autres unités organisationnelles à la racine de l'annuaire, pour stocker les zones DNS, le routage du courrier électronique, la config DHCP, etc.
363
364
_Note/nomenclature: j'ai arbitrairement et unilatéralement décidé de bannir les majuscules des DN de l'annuaire. P.-A._
365
366
*Premier utilisateur*
367
Sous ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, on crée un nouvel objet:
368
* classes inetOrgPerson -et shadowAccount- (les autres sont ajoutées automatiquement)
369
* RDN=cn (la clé)
370
* uid=jdupont
371
* cn=jdupont
372
* sn=Dupont
373
(clic-droit/nouvel attribut)
374
* givenName=Jean
375
(clic-droit/nouvel attribut)
376
* displayName=Jean Dupont
377
(clic-droit/nouvel attribut)
378
* userPassword: l'interface de DS permet de générer un hachage (équivalent de slappasswd en ligne de commande). On utilisera l'algorithme SSHA.
379
380
Cet objet est laissé intentionnellement minimaliste. Il sera possible d'ajouter ultérieurement d'autres attributs et classes, selon les besoins.
381
382
LDIF
383
<pre>
384
dn: cn=jdupont,ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
385
objectClass: inetOrgPerson
386
objectClass: organizationalPerson
387
objectClass: person
388
objectClass: top
389
cn: jdupont
390
sn: Dupont
391
uid: jdupont
392
displayName: Jean Dupont
393
givenName: Jean
394
userPassword:: e1A5Eb8...
395
</pre>
396
397
*Premier groupe*
398
Sous ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, on crée un nouvel objet:
399
* classe posixGroup
400
* RDN=cn
401
* cn=admin
402
* gidNumber=99 (peu importe, pour l'instant on ne cherche pas a créer des utilisateurs unix)
403
404
Pour ajouter l'utilisateur au groupe, afficher l'entrée que l'on vient de créer (cn=admin,ou=groups,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR) et ajouter un nouvel attribut (clic-droit...) memberUid=jdupont.
405
406
LDIF
407
<pre>
408
dn: cn=admin,ou=groups,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR
409
objectClass: posixGroup
410
objectClass: top
411
cn: admin
412
gidNumber: 99
413
memberUid: jdupont
414
</pre>
415
416
*Test*
417
418
Il est maintenant possible de se connecter en tant que uid=jdupont,ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, (fabs : j'ai utilisé cn=jdupont,ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR car ca ne marchait pas avec uid) avec le mot de passe saisi, et le contrôle d'accès est bien appliqué:
419
420
* on peut modifier ses propres données personnelles (nom, prénom, mdp, etc...) (nécessite de forcer le DN de base à cn=jdupont,ou=users,o=ILLYSE,l=Villeurbanne,st=RHA,c=FR, dans la fenêtre de connexion d'ADS, onglet Options du navigateur).
421
* on ne voit pas le reste de l'annuaire
422
423
*Copie d'écran dans ADS*
424
425
!http://www.illyse.org/attachments/download/27/dirstudio-ldap-install4.PNG!