This is an old revision of the document!
Pentru a pregăti configurația de laborator va trebui să descărcați pe mașina fizică (mjolnir
), în directorul saisp/
, arhiva laboratorului:
student@mjolnir:~/saisp$ wget --user=user-curs --ask-password http://repository.grid.pub.ro/cs/saisp/laboratoare/lab-02.zip student@mjolnir:~/saisp$ unzip lab-02.zip
În urma dezarhivării rezultă două fișiere imagine KVM (format qcow2
, ldap-client.qcow2
și ldap-server.qcow2
) și un script de pornire a mașinilor virtuale (ldap-start-kvm
). Imaginea de bază base.qcow2
este deja în directorul saisp/
și este baza pentru celelalte două fișiere: ldap-client.qcow2
și ldap-server.qcow2
.
Puteți urma pașii de mai sus pentru a descărca infrastructura KVM pentru laborator pentru lucru acasă.
Pentru pornirea celor două mașini virtuale (clientul de LDAP și serverul de LDAP) rulați scriptul de pornire:
student@mjolnir:~/saisp$ ./ldap-start-kvm
Vor porni cele două mașini virtuale KVM pentru laborator.
Pentru accesarea celor două mașini folosiți SSH către adresele IP aferente fiecăreia. Pentru conectarea la mașina virtuală pentru serverul de LDAP folosiți comanda
student@mjolnir:~/saisp$ ssh -l root 192.168.0.2
iar pentru conectarea la clientul de LDAP folosiți comanda
student@mjolnir:~/saisp$ ssh -l root 192.168.0.3
Parola pe cele două mașini virtuale este student
atât pentru utilizatorul root
cât și pentru utilizatorul student
.
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:
ldaps://192.168.0.2
dc=labs,dc=cs,dc=pub,dc=ro
3
cn=admin,dc=labs,dc=cs,dc=pub,dc=ro
student
ldaps://192.168.0.2
(valoarea implicită)dc=labs,dc=cs,dc=pub,dc=ro
(valoarea implicită)never
never
pentru verificarea certificatului serverului nu este recomandată în mediile de producție. O folosim aici pentru simplitate.
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:
# /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.
amengsk
trebuie setata folosind ldappasswd
.
Revedeti Laboratorul 1: http://ocw.cs.pub.ro/courses/saisp/labs/01/contents/06
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:
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
;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>
unde <uid>
este identificatorul literal al utilizatorului care face parte din grup. De exemplu, amengsk
sau artanis
.
Clasa LDAP folosită pentru grupuri este posixGroup
. Consultați schema acesteia pe stația server în fișierul /etc/ldap/schema/nis.schema
; căutați în fișier după posixGroup
.
Reporniți NSCD pentru a încărca noile configurații.
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.
raynor
trebuie setata folosind ldappasswd
.
Revedeti Laboratorul 1: http://ocw.cs.pub.ro/courses/saisp/labs/01/contents/06
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.
ipHost
descrisă în fișierul /etc/ldap/schema/nis.schema
de pe stația server.
Urmăriți exemplul de configurare de aici: https://wiki.archlinux.org/index.php/LDAP_Hosts
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:
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
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
:
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:
userPassword
, respectiv shadowLastChange
pot fiself
)loginShell
poate fi modificat de admin și de deținător și citit 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:
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
.
zeratul
trebuie setata folosind ldappasswd
.
Revedeti Laboratorul 1: http://ocw.cs.pub.ro/courses/saisp/labs/01/contents/06
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:
uid=zeratul
să poată vizualiza adresele de mail ale tuturor utilizatorilor, iar intrarea cu uid=amengsk
să le poată și modifica.