LDAP

Acest articol sau secțiune are mai multe probleme. Puteți să contribuiți la rezolvarea lor sau să le comentați pe pagina de discuție. Pentru ajutor, consultați pagina de îndrumări. Trebuie pus(ă) în formatul standard. Marcat din aprilie 2010. Are bibliografia incompletă sau inexistentă. Marcat din aprilie 2010.  Nu ștergeți etichetele înainte de rezolvarea problemelor.

Lightweight Directory Access Protocol (LDAP; /ˈɛldæp/) este un protocol folosit pentru interogarea și modificarea serviciilor de directoare prin intermediul TCP/IP.^[1] Un directory este un set de obiecte cu atribute organizate într-o structura ierarhică. Un exemplu simplu este cartea de telefoane, care conține o listă cu nume (de persoane sau de organizații) organizată alfabetic, unde fiecare nume are asociată o adresă și un număr de telefon. Un arbore director LDAP de cele mai multe ori reflectă limite politice, geografice sau alte organizații, depinzând de modelul ales. Utilizatorii de LDAP din momentul de față preferă folosirea DNS pentru structurarea nivelelor unei ierarhii. Înăuntrul directorului pot apărea mai multe intrări reprezentând persoane, organizații, imprimante, documente, grupuri sau orice altceva care reprezintă o intrare arborescentă. Versiunea curentă pentru LDAP este v3, specificațiile pentru aceasta se pot găsi în RFC 4510.

Un client inițiază o sesiune LDAP prin conectarea la un server LDAP, numit DSA (Directory System Agent), standard pe portul TCP 389. După aceea clientul trimite o cerere de operare către server, iar serverul trimite înapoi un răspuns. În afara câtorva excepții, clientul nu trebuie să aștepte un răspuns înainte de a trimite următoarea cerere, iar serverul poate trimite răspunsurile în orice ordine.

Clientul poate solicita următoarele operații: Start TLS – folosește extensia securității la nivel transport (TLS) a LDAPv3 pentru o conexiune sigură Bind – autentificarea și specificarea versiunii protocolului LDAP Search – caută și/sau returnează intrările din directoare Compare – testează dacă o anumită intrare conține o valoare atribuită Adaugă o nouă intrare Șterge o intrare Modifică o intrare Modify Distinguished Name (DN) – mută sau redenumește o intrare Abandon – abandonează o cerere anterioară Extended Operation – operație generică folosită la definirea altor operații Unbind – închiderea conexiunii (nu este inversul lui Bind).

În plus serverul poate trimite „notificări nesolicitate” care nu sunt răspunsuri la cereri. O metodă alternativă des folosită pentru securizarea comunicațiilor LDAP este folosirea unui tunnel SSL. Portul standard folosit pentru SSL este 636. Folosirea SSL-ului pentru LDAP a fost o practică des întâlnită pentru versiunea 2, dar nu a fost niciodată standardizată într-o specificație. Această practică s-a depreciat împreună cu LDAPv2, care a fost oficial retras în 2003. LDAP este definit cu ajutorul ASN.1, iar mesajele protocol sunt codate în formatul binary BER. Totuși, folosește reprezentarea textuală pentru un număr ASN.1 câmpuri/tipuri.

Protocolul accesează directoarele LDAP, care urmăresc ediția din 1993 a modelului X.500:

• un director este un arbore de intrări;
• o intrare conține un set de atribute;
• un atribut are un nume (un tip de atribut sau o descriere a atributului) și una sau mai multe valori. Atributele sunt definite într-o „schemă”.
• fiecare intrare are un identificator unic: DN-ul său. Acesta este compus din Relative Distinguished Name (RDN) format din anumite atribute din intrare, urmat de DN-ul intrării părinte. Imaginați-vă DN un întreg nume de fișier, iar RDN un nume relativ de fișier dintr-un director.

Atenție la faptul că un DN se poate schimba pe parcursul existenței unei intrări, de exemplu, atunci când intrările sunt mutate într-o structură arborescentă. Pentru o identificare sigură a unei intrări , se poate aloca un UUID atributelor operaționale.

O intrare poate arăta în felul următor atunci când e reprezentată în LDAP Data Interchange Format (LDIF) (LDAP însuși este un protocol binary):

 dn: cn=John Doe,dc=example,dc=com  cn: John Doe  givenName: John  sn: Doe  telephoneNumber: +1 888 555 6789  telephoneNumber: +1 888 555 1232  mail: john@example.com  manager: cn=Barbara Doe,dc=example,dc=com  objectClass: inetOrgPerson  objectClass: organizationalPerson  objectClass: person  objectClass: top 

"dn" este numele intrării; nu este un atribut și nici parte a intrării. „cn=John Doe” este RDN-ul intrării, iar „dc=example,dc=com” este DN-ul intrării părinte, unde dc înseamnă Domain Component. Celelalte linii sunt atribute ale intrării. Numele atributelor sunt șiruri mnemonice tipice, cum ar fi „cn” pentru nume comun (common name), „dc” pentru component de domeniu, „mail” pentru adresa de e-mail și „sn” pentru prenume (surname).

Un server conține un sub-arbore începând cu o anumită intrare, de exemplu „dc=example,dc=com” și fii acestuia. Serverele pot, de asemenea, să conțină referințe către alte servere, astfel o încercare de a accesa „ou=department,dc=example,dc=com” ar putea returna o „referință” sau „referința de continuare” către un server care conține acea parte a arborelui director. În acel moment clientul poate contacta celălalt server. Unele servere suportă înlănțuirea („chaining”), ceea ce înseamnă că serverul contactează alt server și returnează rezultatul către client. LDAP de puține ori definește o anumită ordine: serverul poate returna valoarea unui atribut, atributele dintr-o intrare și intrările găsite de operațiile de căutare în orice ordine. Acest mod de operare derivă din definițiile – o intrare este definită ca un set de atribute iar un atribut este un set de valori, iar seturile nu necesită ordonare.

Clientul acordă fiecărei cereri un ID de mesaj pozitiv și răspunsul serverului are același ID de mesaj. Răspunsul include un cod numeric care indică succesul, eroarea sau alt fel de caz. Înaintea răspunsului, serverul poate trimite alte mesaje cu alte date – de exemplu fiecare intrare găsită de operațiunea de Căutare este returnată într-un astfel de mesaj.

Operațiunea StartTLS stabilește securitatea la nivelul transport la conectare. Acest lucru poate oferi confidențialitatea datelor (pentru a preveni observarea datelor de către o terță persoană) și/sau protecția integrității datelor (care protejează conținutul). În timpul negocierii TLS serverul trimite certificatul X.509 pentru a se legitima. Clientul poate de asemenea trimite un astfel de certificat. După aceea, clientul poate folosi SASL/EXTERNAL. Folosind SASL/EXTERNAL clientul cere serverului să își declare identitatea la un nivel inferior. Cu toate că, din punct de vedere tehnic, serverul poate folosi o informație de identitate stabilită la un nivel inferior, de obicei serverul va folosi informația de identitate stabilită de TLS. Serverele suportă de cele mai multe ori non-standardul „LDAPS” („Secure LDAP”, cunoscut și sub numele de „LDAP over SSL”) protocolul pe un port separat, prestabilit 636. LDAPS diferă de LDAP în două moduri: 1) la conectare clientul și serverul stabilesc TLS înainte ca transferul de mesaje LDAP să aibă loc (fără o operația Start TLS) 2) conexiunea LDAPS trebuie închisă la închiderea TLS. LDAPS a fost folosit cu LDAPv2, pentru ca operațiunea de StartTLS nu era definită încă. Utilizarea LDAPS-ului este din ce în ce mai rară și software-urile moderne ar trebui să folosească doar StartTLS.

Operația Bind autentifică clientul către server. Bind simplu poate trimite DN-ul și parola user-ului necriptată, din acest motiv conexiunea ar trebui protejată folosind Transport Layer Security (TLS). Serverul verifică parola cu atributul userPassword în intrarea numită. Bind anonim (fără DN și parolă) resetează conexiunea în starea de anonim. Bind SASL (Simple Authentication and Security Layer) asigură servicii de autentificare printr-o gamă largă de moduri cum ar fi Kerberos sau certificarea trimisă de client cu TLS. Bind setează versiunea protocolului LDAP. De obicei clienții ar trebui să folosească LDAPv3, care este presetat pentru acest protocol dar nu întotdeauna în biblioteca LDAP. Bind trebuie să fie prima operație într-o sesiune în LDAPv2, dar nu este obligatoriu în LDAPv3 (versiunea curentă de LDAP).

Operațiunea de căutare este folosită atât pentru căutare cât și pentru citirea intrărilor. Parametrii săi sunt:

• baseObject – DN-ul intrării de unde să înceapă căutarea;
• scope – elementele care trebuie căutate. Acestea pot fi BaseObject (să caute doar intrarea indicată, opțiune folosită pentru citirea unei singure intrări), singleLevel (intrări sub DN de bază) sau wholeSubtree (întregul sub-arbore începând de la DN-ul de bază).
• Filter – criteriul folosit în selectarea elementelor din „scope”. De exemplu, filtrul (&(objectClass=person) (| (givenName=John) (mail=john*))) va selecta persoanele (elementele clasei person) care au numele „John” sau au o adresă de e-mail care începe cu șirul „john”.
• DerefAliases – dacă și cum să urmărească intrările alias (intrările care au referința către alte intrări);
• attributes – ce atribute să returneze în intrările rezultat;
• sizeLimit, timeLimit – numărul maxim de intrări de returnat și timpul maxim alocat căutării;
• typesOnly – returnează doar tipuri atribute, nu returnează valori ale atributelor.

Serverul returnează intrările care se potrivesc căutării și potențialele referințe. Acestea pot fi returnate în orice ordine, rezultatul final va include codul rezultatului. Operația de comparare ia un DN, un nume al atributului, o valoare a atributului și verifică dacă acea intrare conține acel atribut cu acea valoare.

Adăugare, Ștergere și Modificare de DN – toate necesită DN-ul intrării care va fi modificată. Modificarea ia o listă de atribute de modificat și modificările care trebuie făcute pentru fiecare dintre ele: ștergerea atributelor sau unor valori, adăugarea de valori noi, înlocuirea valorilor curente cu unele noi. Operațiile de adăugare pot avea atribute adiționale și valori pentru acele atribute. Modificare DN (mutare/redenumire intrare) ia noul RDN (Relative Distinguished Name), opțional noul DN al părintelui și un flag care va determina dacă se va șterge valoarea pentru vechiul RDN. Serverul poate suporta redenumirea unui întreg director de sub-arbore.

O operație de actualizare este atomică: alte operații vor vedea noua intrare sau cea veche. Pe de altă parte, LDAP nu definește tranzacția operațiilor multiple: dacă se citește o intrare și pe urmă se modifică, alt client ar fi putut să actualizeze intrarea în acest timp. Serverele pot implementa extensii care suportă acest lucru.

Operația de extindere este o operație generică LDAP care poate fi folosită la definirea unor noi operații. Exemple: Cancel, Password Modify și Start TLS operations.

Operația de abandonare trimite o cerere serverului de terminare a unei operații identificată de ID-ul de mesaj. Serverul poate să nu îndeplinească cererea. Din păcate, nici cererea de terminare, nici terminarea cu succes a unei operații nu trimit un răspuns. Din acest motiv a fost definită operația extinsă Cancel care trimite răspunsuri, dar nu toate implementările o suportă.

Operația Unbind sfârșește orice operații în desfășurare și închide conexiunea. Nu trimite răspuns. Numele acestei operații are origini istorice și nu este opusul operației Bind. Clienții pot termina o sesiune prin închiderea conexiunii, dar ar trebui sa folosească Unbind. Unbind permite serverului să închidă conexiunea într-un mod mai grațios și să elibereze resursele care altfel ar fi încă folosite o perioada de timp până când s-ar descoperi că clientul a abandonat conexiunea. De asemenea instruiește serverul să închidă operațiile care pot fi închise și să nu trimită răspunsuri pentru operațiile care nu pot fi închise.

Exista un format de URL LDAP pe care clienții îl suportă într-un mod variabil și care este returnat de către server și referințe (vezi RFC 4516):

ldap://host:port/DN?attributes?scope?filter?extensions

Majoritatea componentelor care sunt descrise mai jos sunt opționale.

1. host – FQDN sau adresa IP a serverului LDAP de căutat
2. port – este portul de rețea al serverului LDAP
3. DN – este numele folosit pentru căutări
4. attributes – este o listă de atribute care trebuie returnate separate prin virgulă
5. scope – specifică scopul căutării și poate fi „base” (default), „one”, „sub”
6. filter – este un filtru de căutare. De exemplu (objectClass=*) cum este definit în RFC 4515
7. extensions – extensii la formatul LDAP

De exemplu, „ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com” se referă la toate atributele de utilizator în intrarea John Doe în ldap.example.com, în timp ce „ldap:///dc=example,dc=com??sub?(givenName=John)” caută intrarea în serverul default (a se observa triplu slash, omiterea host-ului, dublu semn de întrebare și omiterea atributelor). În alte URL-uri caracterele speciale trebuie să fie codate în procente. Mai există un LDAP non-standard: schema URL pentru LDAP peste SSL. Aceasta nu ar trebui confundată cu TLS, care este obținută prin folosirea operației StartTLS folosind schema standard de LDAP.

Conținutul intrărilor dintr-un sub-arbore sunt determinate de o schemă cunoscută sub numele de DIT (Directory Information Tree). Schema unui server director definește un set de reguli care guvernează genul informațiilor ce pot fi stocate de server. Schema directorului este comprimată într-un număr de elemente diferite cum ar fi: - Attribute Syntaxes – oferă informații despre tipul informațiilor care pot fi stocate într-un atribut.

1. Matching Rules – oferă informații despre cum să se facă comparațiile valorilor atributelor.
2. Matching Rule Uses – indică care tipuri de atribute pot fi utilizate în conjuncție cu o regulă de potrivire specifică.
3. Attribute Types – definește un OID și un set de nume care pot fi folosite când se face referință la un anumit atribut, și asociază atributul cu o sintaxă și un set de reguli de potrivire.
4. Object Classes – definește colecțiile numite de atribute și le clasifică într-un set de atribute opționale și obligatorii.
5. Name Forms – definește reguli pentru un set de atribute care ar trebui incluse în RDN pentru o intrare.
6. Content Rules – definește constrângeri adiționale despre clasele de obiecte și atribute ce pot fi folosite în conjuncție cu o intrare.
7. Structure Rule – definește reguli care guvernează tipul de intrări subordonate pe care le poate avea o anumita intrare.

Atributele sunt elementele responsabile pentru stocarea informațiilor într-un director și schema definește regulile pentru care atributele pot fi folosite într-o intrare, tipul valorilor pe care le pot lua acele atribute și felul în care clienții pot interacționa cu acele valori.

Clienții pot învăța despre elementele schemei suportate de server prin returnarea sub-intrării sub-schemei adecvate. Schema definește clasele de obiecte. Fiecare intrare trebuie sa conțină un atribut objectClass, care să conțină clasele numite definite în schemă. Definiția schemei a unei clase a unei intrări definește ce tip de obiect poate reprezenta acea intrare - ex: o persoana, organizație sau domeniu.

De exemplu, o intrare care reprezintă o persoană poate să aparțină claselor „top” și „person”. Apartenența la clasa „person” necesită ca intrarea să conțină atributele „sn” si „cn” și permite intrării să conțină „userPassword”, „telephoneNumber” și alte atribute. Din moment ce intrările pot avea valori multiple de ObjectClasses, fiecare intrare conține un complex de atribute opționale și obligatorii, format din uniunea claselor de obiecte pe care le reprezintă. ObjectClasses poate fi moștenit și o singură intrare poate avea valori multiple ObjectClasses care definesc atributele obligatorii și posibile ale intrării. Paralel cu schema unui objectClass este definiția clasei și o instanță în programarea orientată pe obiecte, reprezentând objectClass LDAP și intrarea LDAP respectivă.

Serverele de directoare pot publica schema directorului controlând o intrare la o bază DN dată de atributul operațional al sub-intrării sub-schemei. Administratorii de servere pot adăuga alte scheme de intrări, în completare la elementele schemei oferite. O schemă care reprezintă indivizi într-o organizație se numește o schemă cu pagini albe.

Multe dintre operațiile serverului sunt lăsate la latitudinea administratorului. Din acest motiv, serverele pot fi programate să suporte o varietate largă de scenarii. De exemplu, stocarea datelor pe un server nu este specificată – serverul poate folosi fișiere, baze de date sau poate fi doar un gateway către alte servere. Controlul accesului nu este standardizat, cu toate că s-a lucrat la el și există modele mai răspândite. Parolele utilizatorilor pot fi stocate în intrările lor sau în alt loc. Serverul poate refuza să execute anumite operații și să stabilească anumite limite. Majoritatea părților din LDAP sunt extensibile. Exemple: Se pot defini operații noi. Controalele pot modifica cererile și răspunsurile, cum ar fi să se solicite ca rezultatele căutării sa fie sortate. Se pot defini noi metode de Bind. Atributele pot avea opțiuni care să le modifice semantica.

Din moment ce LDAP a câștigat teren, producătorii l-au folosit pe post de protocol de acces pentru alte servicii. Pe urmă s-a încercat imitarea modelului LDAP/X.500, dar asemănările cu acesta diferă. De exemplu se folosește software pentru accesarea bazelor de date SQL prin LDAP chiar dacă LDAP nu este conceput pentru așa ceva. Serverele X.500 pot suporta LDAP. Similar, datele care erau înainte stocate altundeva sunt uneori mutate în directoare LDAP. De exemplu informații despre utilizatori Unix și informații despre grupuri pot fi stocate în LDAP și accesate via modulele PAM și NSS. LDAP este des utilizat de către alte servicii pentru autentificare.

Din moment ce un server LDAP poate returna referințe către alte servere la cereri, serverul nu va putea, este necesară o structură de denumire pentru intrările LDAP pentru a putea fi găsit serverul care conține un anumit DN. Pentru că o astfel de structură deja există în DNS, numele de nivel ridicat ale serverelor de multe ori imită numele DNS, cum se întâmpla și în cazul X.500. Dacă o organizație are numele de domeniu example.org, intrarea LDAP de nivel înalt va avea DN-ul dc=example,dc=org. Dacă serverul LDAP este de asemenea numit ldap.example.org, URL-ul LDAP-ului de nivel înalt al organizației devine ldap://ldap.example.org/dc=example,dc=org Sub nivelul de top, numele intrării va reflecta structura internă a organizației mai degrabă decât numele DNS.

Terminologia LDAP pe care o putem întâlni este relativ copleșitoare. Acest lucru se datorează neînțelegerilor, originii istorice sau când se folosește împreună cu servicii non-X.500 care folosesc o terminologie diferită. De exemplu „LDAP” este folosit atât pentru referința la protocol cât și la protocol și date. „Directorul LDAP” poate însemna atât date cât și punct de acces. Un „atribut” poate fi tipul atributului sau conținutul unui atribut într-un director sau descrierea unui atribut. Bind „anonim” sau „neautentificat” sunt diferite metode de Bind care produc starea de autentificare anonimă, deci ambii termeni sunt folosiți pentru ambele variante. Atributul „uid” ar trebui să conțină nume de utilizatori în loc de ID-uri numerice de utilizatori.^{[necesită citare]}

Acest articol include informații din articolul echivalent din Wikipedia în limba engleză.

• Arkills, B (2003). LDAP Directories Explained: An Introduction and Analysis. Addison-Wesley Professional. ISBN 0-201-78792-X. 
• Carter, G (2003). LDAP System Administration. O'Reilly Media. ISBN 1-56592-491-6. 
• Donley, C (2002). LDAP Programming, Management, and Integration. Manning Publications. ISBN 1-930110-40-5. 
• Howes, T; Smith, M; Good, G (2003). Understanding and Deploying LDAP Directory Services. Addison-Wesley Professional. ISBN 0-672-32316-8. 
• Rhoton, J (1999). Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. Elsevier. ISBN 1-55558-212-5. 
• Voglmaier, R (2003). The ABCs of LDAP: How to Install, Run, and Administer LDAP Services. Auerbach Publications. ISBN 0-8493-1346-5. 

• Devshed.com, Understanding LDAP, A simple, light introductory tutorial for LDAP.
• Skills-1st.co.uk, LDAP schema design
• Capitalhead.com, Troubleshooting LDAP SSL connection issues between Microsoft ILM/MIIS & Novell eDirectory 8.7.3
• Prasannatech.com, LDAP schema design - A Case Study