LDAP

De la Wikipedia, enciclopedia liberă
Salt la: Navigare, căutare

Lightweight Directory Access Protocol, sau LDAP, este un protocol aplicatie folosit pentru interogarea si modificarea serviciilor de directoare prin intermediul TCP/IP. Un director este un set de obiecte cu attribute organizate intr-o structura ierarhica. Un exemplu simplu este cartea de telefoane, care contine o lista cu nume (de persoane sau de organizatii) organizata alfabetic, unde fiecare nume are asociata o adresa si un numar de telefon. Un arbore director LDAP de cele mai multe ori reflecta limite politice, geografice sau alte organizatii, depinzand de modelul ales. Utilizatorii de LDAP din momentul de fata prefera folosirea DNS pentru structurarea nivelelor unei ierarhi. Inauntrul directorului pot aparea mai multe intrari reprezentand persoane, organizatii, imprimante, documente, grupuri sau orice altceva care reprezinta o intrare arborescenta. Versiunea curenta pentru LDAP este v3, specificatiile pentru aceasta se pot gasi in RFC 4510.

Consideratii generale Un client initiaza o sesiune LDAP prin conectarea la un server LDAP, numit DSA (Directory System Agent), standard pe portul TCP 389. Dupa aceea clientul trimite o cerere de operare catre server, iar serverul trimite inapoi un raspuns. In afara catorva exceptii, clientul nu trebuie sa astepte un raspuns inainte de a trimite urmatoarea cerere, iar serverul poate trimite raspunsurile in orice ordine.

Clientul poate solicita urmatoarele operatii: Start TLS – foloseste extensia securitatii la nivel transport (TLS) a LDAPv3 pentru o conexiune sigura Bind – autentificarea si specificarea versiunii protocolului LDAP Search – cauta si/sau returneaza intrarile din directoare Compare – testeaza daca o anumita intrare contine o valoare atribuita Adauga a noua intrare Sterge o intrare Modifica o intrare Modify Distinguished Name (DN) – muta sau redenumeste o intrare Abandon – abandoneaza o cerere anterioara Extended Operation – operatie generica folosita la definirea altor operatii Unbind – inchiderea conexiunii (nu este inversul lui Bind)

In plus serverul poate trimite “notificari nesolicitate” care nu sunt raspunsuri la cereri. O metoda alternativa des folosita pentru securizarea comunicatiilor LDAP este folosirea unui tunnel SSL. Portul standard folosit pentru SSL este 636. Folosirea SSL-ului pentru LDAP a fost o practica des intalnita pentru versiunea 2, dar nu a fost niciodata standardizata intr-o specificatie. Aceasta practica s-a depreciat impreuna cu LDAPv2, care a fost oficial retras in 2003. LDAP este definit cu ajutorul ASN.1, iar mesajele protocol sunt codate in formatul binary BER. Totusi, foloseste reprezentarea textuala pentru un numar ASN.1 campuri/tipuri.

Structura directorului Protocolul aceseaza directoarele LDAP, care urmaresc editia din 1993 a modelului X.500: - un director este un arbore de intrari - o intrare contine un set de attribute - un atribut are un nume (un tip de atribut sau o descriere a atributului) si una sau mai multe valori. Atributele sunt definite intr-o “schema”. - fiecare intrare are un identificator unic: DN-ul sau. Acesta este compus din Relative Distinguished Name (RDN) format din anumite atribute din intrare, urmat de DN-ul intrarii parinte. Imaginati-va DN un intreg nume de fisier, iar RDN un nume relativ de fisier dintr-un director.

Atentie la faptul ca un DN se poate schimba pe parcursul existentei unei intrari, de exemplu, atunci cand intrarile sunt mutate intr-o structura arborescenta. Pentru o identificare sigura a unei intrari , se poate aloca un UUID atributelor operationale.

O intrare poate arata in felul urmator atunci cand e reprezentata in LDAP Data Interchange Format (LDIF) (LDAP insusi 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: organizational Person objectClass: person objectClass: top

dn este numele intrarii; nu este un atribut si nici parte a intrarii. “cn=John Doe” este RDN-ul intrarii, iar “dc=example,dc=com” este DN-ul intrarii parinte, unde dc inseamna Domain Component. Celelalte linii sunt atribute ale intrarii. Numele atributelor sunt siruri mnemonice tipice, cum ar fi “cn” pentru nume comun (common name), “dc” pentru component de domeniu, “mail” pentru adresa de e-mail si “sn” pentru prenume (surname).

Un server contine un subarbore incepand cu o anumita intrare, de exemplu “dc=example,dc=com” si fii acestuia. Serverele pot, de asemenea, sa contina referinte catre alte servere, astfel o incercare de a accesa “ou=department,dc=example,dc=com” ar putea returna o “referinta” sau “referinta de continuare” catre un server care contine acea parte a arborelui director. In acel moment clientul poate contacta celalalt server. Unele servere suporta inlantuirea (“chaining”), ceea ce inseamna ca serverul contacteaza alt server si returneaza rezultatul catre client. LDAP de putine ori defineste o anumita ordine: serverul poate returna valoarea unui atribut, atributele dintr-o intrare si intrarile gasite de operatiile de cautare in orice ordine. Acest mod de operare deriva din definitiile – o intrare este definite ca un set de atribute iar un atribut este un set de valori, iar seturile nu necesita ordonare.

Operatii Clientul acorda fiecarei cereri un ID de mesaj pozitiv si raspunsul serverului are acelasi ID de mesaj. Raspunsul include un cod numeric care indica succesul, eroarea sau alt fel de caz. Inaintea raspunsului, serverul poate trimite alte mesaje cu alte date – de exemplu fiecare intrare gasita de operatiunea de Cautare este returnata intr-un astfel de mesaj.

StartTLS Operatiunea StartTLS stabileste securitatea la nivelul transport la conectare. Acest lucru poate oferi confidentialitatea datelor (pentru a preveni observarea datelor de catre o terta persoana) si/sau protectia integritatii datelor (care protejeaza continutul). In timpul negocierii TLS serverul trimite certificatul X.509 pentru a se legitima. Clientul poate de asemenea trimite un astfel de certificat. Dupa aceea, clientul poate folosi SASL/EXTERNAL. Folosind SASL/EXTERNAL clientul cere serverului sa isi declare identitatea la un nivel inferior. Cu toate ca, din punct de vedere tehnic, serverul poate folosi o informatie de identitate stabilita la un nivel inferior, de obicei serverul va folosi informatia de identitate stabilita de TLS. Serverele suporta de cele mai multe ori non-standardul “LDAPS” (“Secure LDAP”, cunoscut si sub numele de “LDAP over SSL”) protocolul pe un port separat, prestabilit 636. LDAPS difera de LDAP in doua moduri: 1) la conectare clientul si serverul stabilesc TLS inainte ca transferul de mesaje LDAP sa aiba loc (fara o operatia Start TLS) 2) conexiunea LDAPS trebuie inchisa la inchiderea TLS. LDAPS a fost folosit cu LDAPv2, pentru ca operatiunea de StartTLS nu era definita inca. Utilizarea LDAPS-ului este din ce in ce mai rara si software-urile moderne ar trebui sa foloseasca doar StartTLS.

Bind (autentificare) Operatia Bind autentifica clientul catre server. Bind simplu poate trimite DN-ul si parola user-ului necriptata, din acest motiv conexiunea ar trebui protejata folosind Transport Layer Security (TLS). Serverul verifica parola cu atributul userPassword in intrarea numita. Bind anonim (fara DN si parola) reseteaza conexiunea in starea de anonim. Bind SASL (Simple Authentication and Security Layer) asigura servicii de autentificare printr-o gama larga de moduri cum ar fi Berberos sau certificarea trimisa de client cu TLS. Bind seteaza versiunea protocolului LDAP. De obicei clientii ar trebui sa foloseasca LDAPv3, care este presetat pentru acest protocol dar nu intotdeauna in biblioteca LDAP. Bind trebuie sa fie prima operatie intr-o sesiune in LDAPv2, dar nu este obligatoriu in LDAPv3 (versiunea curenta de LDAP).

Cauta si compara Operatiunea de cautare este folosita atat pentru cautare cat si pentru citirea intrarilor. Parametrii sai sunt: baseObject – DN-ul inrarii de unde sa inceapa cautarea scope – elementele care trebuie cautate. Acestea pot fi BaseObject (sa caute doar intrarea indicata, optiune folosita pentru citirea unei singure intrari), singleLevel (intrari sub DN de baza) sau wholeSubtree (intregul subarbore incepand de la DN-ul de baza). Filter – criteriul folosit in selectareaelementelor din “scope”. De exemplu, filtrul (&(objectClass=person) (| (givenName=John) (mail=john*))) va selecta persoanele (elementele clasei person) care au numele “John” sau au o adresa de e-mail care incepe cu sirul “john”. DerefAliases – daca si cum sa urmareasca intrarile alias (intrarile care au referinta catre alte intrari) attributes – ce atribute sa returneze in intrarile rezultat sizeLimit, timeLimit – numarul maxim de intrari de returnat si timpul maxim alocat cautarii typesOnly – returneaza doar tipuri atribute, nu returneaza valori ale atributelor

Serverul returneaza intrarile care se potrivesc cautarii si potentialele referinte. Acestea pot fi returnate in orice ordine, rezultatul final va include codul rezultatului. Operatia de comparare ia un DN, un nume al atributului, o valoare a atributului si verifica daca acea intrare contine acel atribut cu acea valoare.

Updatarea datelor Adaugare, Stergere si Modificare de DN – toate necesita DN-ul intrarii care va fi modificate. Modificarea ia o lista de atribute de modificat si modificarile care trebuie facute pentru fiecare dintre ele: stergerea atributelor sau unor valori, adaugarea de valori noi, inlocuirea valorilor curente cu unele noi. Operatiile de adaugare pot avea atribute aditionale si valori pentru acele atribute. Modificare DN (mutare/redenumire intrare) ia noul RDN (Relative Distinguished Name), optional noul DN al parintelui si un flag care va determina daca se va sterge valoarea pentru vechiul RDN. Serverul poate suporta redenumirea unui intreg director de subarbore. O operatie de updatare este atomica: alte operatii vor vedea noua intrare sau cea veche. Pe de alta parte, LDAP nu defineste tranzactia operatiilor multiple: daca se citeste o intrare si pe urma se modifica, alt client ar fi putut sa updateze intrarea in acest timp. Serverele pot implementa extensii care suporta acest lucru.

Operatii extinse Operatia de extindere este o operatie generica LDAP care poate fi folosita la definirea unor noi operatii. Exemple: Cancel, Password Modify si Start TLS operations.

Abandon Operatia de abandonare trimite o cerere serverului de terminare a unei operatii identificata de ID-ul de mesaj. Serverul poate sa nu indeplineasca cererea. Din pacate, nici cererea de terminare, nici terminarea cu succes a unei operatii nu trimit un raspuns. Din acest motiv a fost definita operatia extinsa Cancel care trimite raspunsuri, dar nu toate implementarile o suporta.

Unbind Operatia Unbind sfarseste orice operatii in desfasurare si inchide conexiunea. Nu trimite raspuns. Numele acestei operatii are origini istorice si nu este opusul operatiei Bind. Clientii pot termina o sesiune prin inchiderea conexiunii, dar ar trebui sa foloseasca Unbind. Unbind permite serverului sa inchida conexiunea intr-un mod mai gratios si sa elibereze resursele care altfel ar fi inca folosite o perioada de timp pana cand s-ar descoperi ca clientul a abandonat conexiunea. De asemenea instruieste serverul sa inchida operatiile care pot fi inchise si sa nu trimita raspunsuri pentru operatiile care nu pot fi inchise.

URL-uri LDAP Exista un format de URL LDAP pe care clientii il suporta intr-un mod variabil si care este returnat de catre server si referinte (vezi RFC 4516):

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

Majoritatea componetelor care sunt descrise mai jos sunt optionale.

  1. host – FQDN sau adresa IP a serverului LDAP de cautat
  2. port – este portul de retea al serverului LDAP
  3. DN – este numele folosit pentru cautari
  4. attributes – este o lista de atribute care trebuie returnate separate prin virgula
  5. scope – specifica scopul cautarii si poate fi “base” (default), “one”, “sub”
  6. filter – este un filtru de cautare. De exemplu (objectClass=*) cum este definit in RFC 4515
  7. extensions – extensii la formatul LDAP

De exemplu, “ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com” se refera la toate atributele de utilizator in intrarea John Doe in ldap.example.com, in timp ce “ldap:///dc=example,dc=com??sub?(givenName=John)” cauta intrarea in serverul default (a se observa triplu slash, omiterea host-ului, dublu semn de intrebare si omiterea atributelor). In alte URL-uri caracterele speciale trebuie sa fie codate in procente. Mai exista un LDAP non-standard: schema URL pentru LDAP peste SSL. Aceasta nu ar trebui confundata cu TLS, care este obtinuta prin folosirea operatiei StartTLS folosind schema standard de LDAP.

Schema Continutul intrarilor dintr-un subarbore sunt determinate de o schema cunoscuta sub numele de DIT (Directory Information Tree). Schema unui server director defineste un set de reguli care guverneaza genul informatiilor ce pot fi stocate de server. Schema directorului este comprimata intr-un numar de elemente diferite cum ar fi: - Attribute Syntaxes – ofera informatii despre tipul informatiilor care pot fi stocate intr-un atribut.

  1. Matching Rules – ofera informatii despre cum sa se faca comparatiile valorilor atributelor.
  2. Matching Rule Uses – indica care tipuri de atribute pot fi utilizate in conjunctie cu o regula de potrivire specifica.
  3. Attribute Types – defineste un OID si un set de nume care pot fi folosite cand se face referinta la un anumit atribut, si asociaza atributul cu o sintaxa si un set de reguli de potrivire.
  4. Object Classes – defineste colectiile numite de atribute si le clasifica intr-un set de atribute optinale si obligatorii.
  5. Name Forms – defineste reguli pentru un set de atribute care ar trebui incluse in RDN pentru o intrare.
  6. Content Rules – defineste constrangeri aditionale despre clasele de obiecte si atribute ce pot fi folosite in conjunctie cu o intrare.
  7. Structure Rule – defineste reguli care guverneaza tipul de intrari subordonate pe care le poate avea o anumita intrare.

Atributele sunt elementele responsabile pentru stocarea informatiilor intr-un director si schema defineste regulile pentru care atributele pot fi folosite intr-o intrare, tipul valorilor pe care le pot lua acele atribute si felul in care clientii pot interactiona cu acele valori. Clientii pot invata despre elementele schemei suportate de server prin returnarea subintrarii subschemei adecvate. Schema defineste clasele de obiecte. Fiecare intrare trebuie sa contina un atribut objectClass, care sa contina clasele numite definite in schema. Definitia schemei a unei clase a unei intrari defineste ce tip de obiect poate reprezenta acea intrare- ex: o persoana, organizatie sau domeniu. De exemplu, o intrare care reprezinta o persoana poate sa apartina claselor “top” si “person”. Apartenenta la clasa “person” necesita ca intrarea sa contina atributele “sn” si “cn” si permite intrarii sa contina “userPassword”, “telephoneNumber” si alte atribute. Din moment ce intrarile pot avea valori multiple de ObjectClasses, fiecare intrare contine un complex de atribute optionale si obligatorii, format din uniunea claselor de obiecte pe care le reprezinta. ObjectClasses poate fi mostenit si o singura intrare poate avea valori multiple ObjectClasses care definesc atributele obligatorii si posibile ale intrarii. Paralel cu schema unui objectClass este definitia clasei si o instanta in programarea orientata pe obiecte, reprezentand objectClass LDAP si intrarea LDAP respectiva. Serverele de directoare pot publica schema directorului controland o intrare la o baza DN data de atributul operational al subintrarii subschemei. Administratorii de servere pot adauga alte scheme de intrari, in completare la elementele schemei oferite. O schema care reprezinta indivizi intr-o organizatie se numeste o schema cu pagini albe.

Variatii Multe dintre operatiile serverului sunt lasate la latitudinea administratorului. Din acest motiv, serverele pot fi programate sa suporte o varietate larga de scenarii. De exemplu, stocarea datelor pe un server nu este specificata – serverul poate folosi fisiere, baze de date sau poate fi doar un gateway catre alte servere. Controlul accesului nu este standardizat, cu toate ca s-a lucrat la el si exista modele mai raspandite. Parolele utilizatorilor pot fi stocate in intrarile lor sau in alt loc. Serverul poate refuza sa execute anumite operatii si sa stabileasca anumite limite. Majoritatea partilor din LDAP sunt extensibile. Exemple: Se pot defini operatii noi. Controalele pot modifica cererile si raspunsurile, cum ar fi sa se solicite ca rezultatele cautarii sa fie sortate. Se pot defini noi metode de Bind. Atributele pot avea optiuni care sa le modifice semantica.

Alte modele de date Din moment ce LDAP a castigat teren, producatorii l-au folosit pe post de protocol de acces pentru alte servicii. Pe urma s-a incercat imitarea modelului LDAP/X.500, dar asemanarile cu acesta difera. De exemplu se foloseste software pentru accesarea bazelor de date SQL prin LDAP chiar daca LDAP nu este conceput pentru asa ceva. Serverele X.500 pot suporta LDAP. Similar, datele care erau inainte stocate altundeva sunt uneori mutate in directoare LDAP. De exemplu informatii despre utilizatori Unix si informatii despre grupuri pot fi stocate in LDAP si accesate via modulele PAM si NSS. LDAP este des utilizat de catre alte servicii pentru autentificare.

Folosire Structura de denumire Din moment ce un server LDAP poate returna referinte catre alte servere la cereri, serverul nu va putea, este necesara o structura de denumire pentru intrarile LDAP pentru a putea fi gasit serverul care contine un anumit DN. Pentru ca o astfel de structura deja exista in DNS, numele de nivel ridicat ale serverelor de multe ori imita numele DNS, cum se intampla si in cazul X.500. Daca o organizatie are numele de domeniu example.org, intrarea LDAP de nivel inalt va avea DN-ul dc=example,dc=org. Daca serverul LDAP este de asemenea numit ldap.example.org, URL-ul LDAP-ului de nivel inalt al organizatiei devine ldap://ldap.example.org/dc=example,dc=org Sub nivelul de top, numele intrarii va reflecta structura interna a organizatiei mai degraba decat numele DNS.

Terminologie Terminologia LDAP pe care o putem intalni este relativ coplesitoare. Acest lucru se datoreaza neintelegerilor, originii istorice sau cand se foloseste impreuna cu servicii non-X.500 care folosesc o terminologie diferita. De exemplu “LDAP” este folosit atat pentru referinta la protocol cat si la protocol si date. “Directorul LDAP” poate insemna atat date cat si punct de acces. Un “atribut” poate fi tipul atributului sau continutul unui atribut intr-un director sau descrierea unui atribut. Bind “anonim” sau “neautentificat” sunt diferite metode de Bind care amandoua produc starea de autentificare anonima, deci ambii termeni sunt folositi pentru ambele variante. Atributul “uid” ar trebui sa contina nume de utilizatori in loc de ID-uri numerice de utilizatori.