Serviciul de LDAP poate fi folosit ca mod centralizat de a permite autentificarea altor servicii. În laboratorul 1, am configurat DokuWiki și MediaWiki pentru a folosi serviciul de LDAP pentru autentificare. O formă frecventă, mai ales în mediile care folosesc Active Directory, este autentificare utilizatorilor locali prin LDAP.

În cele ce urmează vom configura sistemul client pentru a folosi back-end-ul LDAP server pentru autentificarea utilizatorilor. Adică să fie folosite numele de utilizator și parola din baza de date LDAP pentru autentificarea unui utilizator local în Unix. Pentru aceasta vom configura PAM (Pluggable Authentication Module) și NSS (Name Service Switch) pentru a permite autentificarea prin LDAP. În baza de date LDAP sunt deja configurați utilizatori, fiecare cu parola student. Pentru a vedea utilizatorii rulăm, pe stația client, comanda:

root@ldap-client:~# ldapsearch -x -LLL dn
dn: dc=labs,dc=cs,dc=pub,dc=ro
 
dn: cn=admin,dc=labs,dc=cs,dc=pub,dc=ro
 
[...]

Configurarea autentificării Unix prin LDAP o vom face pe stația client. Utilizatorii de pe stația client vor fi autentificați folosind datele din cadrul serverului de LDAP. Vom configura întâi NSS și apoi vom configura PAM.

Pentru configurarea NSS cu suport LDAP instalăm pe stația client pachetul libnss-ldap și răspundem la întrebări cu datele de conectare la serverul de LDAP, ca mai jos:

• LDAP server Uniform Resource Identifier: ldaps://192.168.0.2
• Distinguished name of the search base: dc=labs,dc=cs,dc=pub,dc=ro
• LDAP version to use: 3
• LDAP account for root: cn=admin,dc=labs,dc=cs,dc=pub,dc=ro
• LDAP root account password: student
• Configuring nslcd, LDAP server URI: ldaps://192.168.0.2 (valoarea implicită)
• Configuring nslcd, LDAP server search base: dc=labs,dc=cs,dc=pub,dc=ro (valoarea implicită)
• Check server's SSL certificate: never

După acest proces de instalare și configurare a fost instalat și pornit Name Service Caching Daemon. Acesta cache-uiește informații transmise de NSS (Name Service Switch) pentru a evita overhead-ul cauzat de interogări continue.

Pentru a valida configurarea inspectăm pe stația client fișierele /etc/libnss-ldap.conf și /etc/libnss-ldap.secret:

root@ldap-client:/etc/ldap/ldif# cat /etc/libnss-ldap.conf | grep -v '^#' | grep -v '^[ \t]*$'
base dc=labs,dc=cs,dc=pub,dc=ro
uri ldaps://192.168.0.2
ldap_version 3
rootbinddn cn=admin,dc=labs,dc=cs,dc=pub,dc=ro
 
root@ldap-client:~# cat /etc/libnss-ldap.secret 
student

Pentru a activa suportul LDAP în NSS, configurăm fișierul /etc/nsswitch.conf. Folosim un editor și edităm liniile aferente categoriilor passwd, group și shadow, ca mai jos:

nsswitch.conf

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
 
passwd:         files ldap
group:          files ldap
shadow:         files ldap
 
hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files
 
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
 
netgroup:       nis

După configurarea NSS în fișierul /etc/nsswitch.conf, repornim nscd:

root@ldap-client:~# service nscd restart
[ ok ] Restarting Name Service Cache Daemon: nscd.

și apoi verificăm servirea datelor prin LDAP folosind comenzi precum getent, id și finger:

root@ldap-client:~# getent passwd amengsk
amengsk:x:1001:1000:Arcturus Mengsk,,,:/home/amengsk:/bin/bash
 
root@ldap-client:~# id amengsk
uid=1001(amengsk) gid=1000(student) groups=1000(student)
 
root@ldap-client:~# finger amengsk
Login: amengsk        			Name: Arcturus Mengsk
Directory: /home/amengsk            	Shell: /bin/bash
Never logged in.
No mail.
No Plan.

Observăm că acum sistemul furnizează informații despre utilizatori din baza de date LDAP. Întrucât a fost instalat și configurat simultan pachetul libpam-ldap, vom putea sa ne și autentificăm la utilizatorul amengsk. Putem face acest lucru folosind comanda ssh de pe sistemul fizic:

student@mjolnir:~/vm/kvm$ ssh -l amengsk 192.168.0.3
amengsk@192.168.0.3's password: 
[...]
Could not chdir to home directory /home/amengsk: No such file or directory
amengsk@ldap-client:/$

Observăm că nu a fost creat directorul home pentru utilizator pe stația client. Pentru aceasta cel mai simplu este să activăm modulul pam_mkhomedir prin editarea fișierului /etc/pam.d/common-session și adăugarea liniei:

session required        pam_mkhomedir.so skel=/etc/skel/ umask=0022

După configurarea liniei de mai sus va funcționa conectarea la stația client și crearea directorului home al utilizatorului cu care a fost realizată autentificarea:

razvan@einherjar:~/vm/kvm$ ssh -l amengsk 192.168.0.3
amengsk@192.168.0.3's password: 
Creating directory '/home/amengsk'.
[...]
amengsk@ldap-client:~$ 

Mai sus apare mesajul creării directorului home al utilizatorului amengsk. Sistemul funcționează corespunzător cu autentificarea utilizatorilor prin intermediul LDAP.

Pentru a avea granularitate la oferirea de drepturi, putem folosi grupuri POSIX în LDAP. Un grup POSIX este identificat în LDAP de un atribut cn și necesită un identificator de grup, adică atributul gidNumber.

Creați două fișiere LDIF denumite cn-fighters.ldif și cn-politicians.ldif în care creați două grupuri:

• grupul politicians identificat de cn=politicians,dc=labs,dc=cs,dc=pub,dc=ro, cu gidNumber la valoarea 1500 și având în componență pe amengsk și vmengsk;
• grupul fighters identificat de cn=fighters,dc=labs,dc=cs,dc=pub,dc=ro, cu gidNumber la valoarea 1501 și având în componență pe raynor, horner, zeratul și artanis.

După ce creați cele două fișiere LDIF încărcați-le în LDAP și verificați prezența noilor grupuri folosind comanda getent și a apartenței utilizatorilor la grupuri folosind comanda id.

memberUid: <uid>

Ne propunem ca pe stația client să se autentifice doar utilizatorii din grupul POSIX politicians stocat în baza de date LDAP. Realizați această configurare și testați-o. Urmăriți și mesajele de jurnalizare din fișierul /var/log/auth.log pentru verificare.

Modul în care se face interogarea numelor de stații (hostname) este descris în /etc/nsswitch.conf, componenta hosts. De obicei se întâmplă prin DNS și prin intermediul fișierului /etc/hosts. Putem adăuga intrări și prin LDAP.

Configurați suport de LDAP în NSS (Name Service Switch) pe stația client astfel încât serverul LDAP să fie accesibil prin numele server, clientul prin numele client iar sistemul fizic prin numele host. Pentru validare folosiți getent și ping.

Folosiți pe post de dn valorile:

• cn=server,dc=labs,dc=cs,dc=pub,dc=ro
• cn=client,dc=labs,dc=cs,dc=pub,dc=ro
• cn=host,dc=labs,dc=cs,dc=pub,dc=ro

Va trebui sa creati fisiere ldif care sa descrie valorile de mai sus, iar apoi sa adaugati intrarile respective in baza de date LDAP.

Serverul de LDAP are două tipuri de baze de date. O bază de date internă, pentru configuare, și o bază de date cu informații LDAP. Baza de date internă permite serverului de LDAP configurarea acestuia tot prin comenzi LDAP; se asigură astfel o interfață unificată și, mai mult, posibilitatea de a realiza configurații fără a fi nevoie de repornirea serverului.

Pentru a urmări și configura întreaga bază de date de internă a serverului rulăm, pe stația de tip server, comanda

root@ldap-server:~# ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config"
[...]

Sunt afișate foarte multe informații, practic toată baza de date internă a serverului LDAP. Dacă vrem să afișăm doar informațiile ce țin de configurarea informațiilor, vom investiga intrarea olcDatabase={1}hdb,cn=config:

root@ldap-server:~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "olcDatabase={1}hdb,cn=config"
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=labs,dc=cs,dc=pub,dc=ro
[...]

Dacă vrem să afișăm informații legate strict de configurarea serverului LDAP (număr de thread-uri folosite, nivel de jurnalizare, certificat) vom investiga doar baza intrării cn=config:

root@ldap-server:~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "cn=config" -s base
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcTLSCACertificateFile: /etc/ssl/certs/cacert.org_root.pem
olcTLSCertificateFile: /etc/ssl/certs/slapd-cert.pem
olcTLSCertificateKeyFile: /etc/ssl/private/slapd-key.pem
olcToolThreads: 1

Directivele de configurare în serverul LDAP sunt atribute în intrările cu dn-uri care se termină în cn=config. Atributele încep cu prefixul olc însemnând OpenLDAP Configuration.

Dorim să configurăm nivelul de jurnalizare al serverului LDAP. Directiva de configurare se numește olcLogLevel, așa cum este documentată aici. Observăm că area valoarea none. Vrem să-i schimbăm valoarea la stats.

Pentru aceasta construim un fișier LDIF:

change-log-level.ldif

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats

apoi încărcăm fișierul în baza de date LDAP:

root@ldap-server:~# ldapadd -Y EXTERNAL -H ldapi:/// -f change-log-level.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

și verificăm faptul că a fost încărcat corespunzător:

root@ldap-server:~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "cn=config" -s base olcLogLevel
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
olcLogLevel: stats

În exemplul de mai sus am creat un fișier LDIF care a modificat valoarea atributului olcLogLevel la valoarea stats. Putem observa informațiile de jurnalizare generate de serverul de LDAP în fișierul /var/log/syslog de pe stația server; eventual facem niște cereri de interogare LDAP (folosind ldapsearch) de pe stația client.

Exercițiu: Modificați nivelul de jurnalizare al serverului LDAP astfel încât să jurnalizeze și mesaje de tipul stats și mesaje de tipul stats2. E ceva simplu

Ne propunem să urmărim pașii instalării unui server de LDAP. Pentru aceasta o să instalăm un server LDAP pe stația client. Nu este util să existe două servere de LDAP, dar este mai ușor să instalăm un server de la zero decât să dezinstalăm și apoi să reinstalăm pe stația server.

Pachetul pentru serverul de LDAP se numește slapd; îl instalăm

root@ldap-client:~# apt-get install slapd

O să fie cerută parola serverului de LDAP. Introduceți o parolă dorită; recomandăm parola student pentru “unformitate”.

După ce am instalat serverul urmărim că ascultă conexiuni pe portul LDAP 389

root@ldap-client:/etc/ldap/ldif/lab-02-solution# netstat -tlpn | grep slapd
tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN      5985/slapd      
tcp6       0      0 :::389                  :::*                    LISTEN      5985/slapd 

Nu ni s-au cerut alte opțiuni pentru configurare. Asta pentru că serverul LDAP consideră că base dn-ul este FQDN-ul stației. În cazul de față este vorba de FQDN-ul tasks.cs.pub.ro, deci base dn-ul va fi dc=tasks,dc=cs,dc=pub,dc=ro. Putem urmări aceste lucru prin interograrea serverului LDAP local:

root@ldap-client:~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -s base -b "olcDatabase={1}hdb,cn=config"
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=tasks,dc=cs,dc=pub,dc=ro
[...]
 
root@ldap-client:~# ldapsearch -x -LLL -H ldap://localhost -b "dc=tasks,dc=cs,dc=pub,dc=ro" dn
dn: dc=tasks,dc=cs,dc=pub,dc=ro
 
dn: cn=admin,dc=tasks,dc=cs,dc=pub,dc=ro

Pe moment, la nivel de date, baza de date LDAP conține doar intrarea pentru base dn și pentru contul de administrator (cn=admin).

Dacă dorim să facem configurări în cadrul serverului de LDAP, vom crea fișiere LDIF și apoi le vom încărca în baza de date LDAP folosind comanda ldapadd.

Pentru a securiza comunicația cu serverul de LDAP avem două opțiuni

1. configurarea suportului SSL, adică LDAPS
2. configurarea suportului de TLS

Pentru configurarea suportului de SSL, edităm în fișierul /etc/default/slapd linia care conține directiva SLAPD_SERVICES. Linia trebuie să ajungă la forma:

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

Apoi repornim serverul de LDAP

root@ldap-client:~# service slapd restart
[ ok ] Stopping OpenLDAP: slapd.
[ ok ] Starting OpenLDAP: slapd.

și urmărim dacă acum ascultă conexiuni LDAPS (pe portul 636):

root@ldap-client:~# netstat -tlpn | grep slapd
tcp        0      0 0.0.0.0:636             0.0.0.0:*               LISTEN      3620/slapd      
tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN      3620/slapd      
tcp6       0      0 :::636                  :::*                    LISTEN      3620/slapd      
tcp6       0      0 :::389                  :::*                    LISTEN      3620/slapd 

Cu toate acestea, dacă încercăm să ne conectăm la server folosind LDAPS obținem eroare:

root@ldap-client:~# ldapsearch -x -LLL -H ldaps://localhost -b "dc=tasks,dc=cs,dc=pub,dc=ro" dn
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Acest lucru este datorat absenței certificatelor SSL. Ca să rezolvăm acest lucru, generăm un certificat SSL self-signed, urmărind indicațiile de aici. Vom rula comanda:

root@ldap-client:~# openssl req -new -x509 -days 365 -nodes -out /etc/ssl/certs/slapd-cert.pem -keyout /etc/ssl/private/slapd-key.pem
[...]

Introduceți în cadrul comenzii de mai sus opțiunile utile. Acum cheia privată este generată în fișierul /etc/ssl/private/slapd-key.pem, iar cheia publică este generată în fișierul /etc/ssl/certs/slapd-cert.pem.

Acum trebuie să configurăm serverul de LDAP pentru a folosi certificatele. Vom urmări indicațiile de aici. Vom crea un fișier LDIF și în cadrul acestuia vom preciza directivele olcTLSCertificateKeyFile respectiv olcTLSCertificateFile:

slapd-config-tls.ldif

dn: cn=config
changetype: modify
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/slapd-key.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/slapd-cert.pem

Încărcăm apoi acest fișier în baza de date de configurare internă a serverului LDAP:

root@ldap-client:~# ldapmodify -Y EXTERNAL -H ldapi:/// -f slapd-config-tls.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

și verificăm informațiile prezente acum în baza de date

root@ldap-client:~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -s base -b "cn=config"
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
olcTLSCertificateKeyFile: /etc/ssl/private/slapd-key.pem
olcTLSCertificateFile: /etc/ssl/certs/slapd-cert.pem

În baza de date internă de configurare sunt prezente acum cheia privată și certificatul SSL utile pentru funcționarea LDAPS și LDAP+TLS. Va trebui să acordăm serverului LDAP acces la cheia privată folosind comanda

root@ldap-client:~# adduser openldap ssl-cert

și apoi să repornim serviciul:

root@ldap-client:~# service slapd restart
[ ok ] Stopping OpenLDAP: slapd.
[ ok ] Starting OpenLDAP: slapd.

După aceasta vom putea folosi URI de tipul LDAPS pentru a interoga serverul de LDAP local:

root@ldap-client:~# ldapsearch -x -LLL -H ldaps://localhost -b dc=tasks,dc=cs,dc=pub,dc=ro dn
dn: dc=tasks,dc=cs,dc=pub,dc=ro
 
dn: cn=admin,dc=tasks,dc=cs,dc=pub,dc=ro

Pe această configurație putem verifica și conexiunea folosind TLS. URI-ul de conectare la server este același ca în cazul nesecurizat, dar folosim opțiunea -Z pentru a activa suportul TLS:

root@ldap-client:~# ldapsearch -x -Z -LLL -H ldap://localhost -b dc=tasks,dc=cs,dc=pub,dc=ro dn
dn: dc=tasks,dc=cs,dc=pub,dc=ro
 
dn: cn=admin,dc=tasks,dc=cs,dc=pub,dc=ro

Acum serverul funcționează corespunzător cu suport SSL (LDAPS) și TLS.

Pentru a securiza operațiile către serverul de LDAP acesta folosește liste de control al accesului (ACL – Access Control Lists). Acestea oferă administratorului posibilitatea de a alege ce operații pot fi realizate de un utilizator.

În cadrul serverului OpenLDAP configurarea ACL-urilor se realizează în cadrul bazei de date olcDatabase={1}hdb,cn=config. Pentru a observa ACL-urile configurate implicit folosim, pe stația server, comanda

root@ldap-server:~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "olcDatabase={1}hdb,cn=config"  olcAccess
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=labs,dc=cs,dc=pub,dc=ro" write by * none
olcAccess: {1}to attrs=loginShell,gecos by dn="cn=admin,dc=example,dc=com" write by self write by * read
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to * by self write by dn="cn=admin,dc=labs,dc=cs,dc=pub,dc=ro" write by * read

Fiecare intrare este prefixată de un index care înseamnă ordinea în care sunt prelucrate: {0}, {1}, {2}, {3}. Cele patru reguli au următorul efect:

1. Atributele userPassword, respectiv shadowLastChange pot fi
   • scrise de deținător (self)
   • folosite pentru autentificare de anonim
   • scrise de admin
   • fără drepturi pentru ceilați
2. Atributul loginShell poate fi modificat de admin și de deținător și citit de oricine.
3. Oricine poate citi intrările din întreaga bază de date LDAP.
4. Celelalte atribute pot fi modificate de deținător și de admin și pot fi citite de oricine.

Dorim să ascundem adresa de e-mail a oricărui utilizator și să facem să fie modificată chiar de acesta. Pentru aceasta va trebui să adăugăm o regulă de forma:

access to mail
   by self write
   by dn="cn=admin,dc=labs,dc=cs,dc=pub,dc=ro" write
   by * none

Pentru aceasta vom crea un fișier LDIF care să conțină informațiile de mai jos:

acl-mail-hidden.ldif

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {1}to attrs=mail by dn="cn=admin,dc=labs,dc=cs,dc=pub,dc=ro" write by self write by * none

Apoi încărcăm fișierul de configurare LDIF în LDAP:

root@ldap-server:~# ldapadd -Y EXTERNAL -H ldapi:/// -f acl-mail-hidden.ldif 
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}hdb,cn=config"

și validăm noua configurație:

root@ldap-server:~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "olcDatabase={1}hdb,cn=config"  olcAccess
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou
 s auth by dn="cn=admin,dc=labs,dc=cs,dc=pub,dc=ro" write by * none
olcAccess: {1}to attrs=mail by dn="cn=admin,dc=labs,dc=cs,dc=pub,dc=ro" write 
 by self write by * none
olcAccess: {2}to attrs=loginShell,gecos by dn="cn=admin,dc=example,dc=com" wri
 te by self write by * read
olcAccess: {3}to dn.base="" by * read
olcAccess: {4}to * by self write by dn="cn=admin,dc=labs,dc=cs,dc=pub,dc=ro" w
 rite by * read

Am inserat astfel o nouă regulă pe poziția {1}, celelalte reguli deplasându-se o poziție în jos.

De pe stația client validăm regula: interogăm intrarea aferentă uid=zeratul făcând bind cu uid=raynor și cu uid=zeratul.

root@ldap-client:~# ldapsearch -x -LLL -D uid=raynor,ou=Raiders,o=Terran,dc=labs,dc=cs,dc=pub,dc=ro -w student uid=zeratul mail
dn: uid=zeratul,ou=Nerazim,o=Protoss,dc=labs,dc=cs,dc=pub,dc=ro
 
root@ldap-client:~# ldapsearch -x -LLL -D uid=zeratul,ou=Nerazim,o=Protoss,dc=labs,dc=cs,dc=pub,dc=ro -w student uid=zeratul mail
dn: uid=zeratul,ou=Nerazim,o=Protoss,dc=labs,dc=cs,dc=pub,dc=ro
mail: zeratul@void.protoss.mil

Observăm că dacă facem bind cu uid=raynor nu avem acces la adresa de e-mail a uid=zeratul, dar avem la bind cu uid=zeratul; o intrare are acces la propria adresă de e-mail.

Actualizați ACL-urile din serverul de LDAP cu următoarele reguli:

1. Intrarea cu uid=zeratul să poată vizualiza adresele de mail ale tuturor utilizatorilor, iar intrarea cu uid=amengsk să le poată și modifica.
2. Doar utilizatorii autentificați (bind) să poată vizualiza orice intrare din baza de date LDAP.