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 indrum?ri . Trebuie pus(?) in formatul standard . Marcat din aprilie 2010. Are bibliografia incomplet? sau inexistent?. Marcat din aprilie 2010.  Nu ?terge?i etichetele  inainte de rezolvarea problemelor.

Lightweight Directory Access Protocol ( LDAP ; / ? ? l d æ 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 intr-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, depinzand de modelul ales. Utilizatorii de LDAP din momentul de fa?? prefer? folosirea DNS pentru structurarea nivelelor unei ierarhii. In?untrul directorului pot ap?rea mai multe intr?ri reprezentand 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 in RFC 4510 .

Considera?ii generale [ modificare | modificare surs? ]

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 inapoi un r?spuns. In afara catorva excep?ii, clientul nu trebuie s? a?tepte un r?spuns inainte de a trimite urm?toarea cerere, iar serverul poate trimite r?spunsurile in 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 ? inchiderea conexiunii (nu este inversul lui Bind).

In 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 intalnit? pentru versiunea 2, dar nu a fost niciodat? standardizat? intr-o specifica?ie. Aceast? practic? s-a depreciat impreun? 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. Totu?i, folose?te reprezentarea textual? pentru un num?r ASN.1 campuri/tipuri.

Structura directorului [ modificare | modificare surs? ]

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 intr-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 intreg 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 cand intr?rile sunt mutate intr-o structur? arborescent?. Pentru o identificare sigur? a unei intr?ri , se poate aloca un UUID atributelor opera?ionale.

O intrare poate ar?ta in felul urm?tor atunci cand e reprezentat? in LDAP Data Interchange Format (LDIF) (LDAP insu?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 inseamn? 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 incepand 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 incercare 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. In acel moment clientul poate contacta cel?lalt server. Unele servere suport? inl?n?uirea (?chaining”), ceea ce inseamn? 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 in 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.

Opera?ii [ modificare | modificare surs? ]

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. Inaintea r?spunsului, serverul poate trimite alte mesaje cu alte date ? de exemplu fiecare intrare g?sit? de opera?iunea de C?utare este returnat? intr-un astfel de mesaj.

StartTLS [ modificare | modificare surs? ]

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). In 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?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 in dou? moduri: 1) la conectare clientul ?i serverul stabilesc TLS inainte ca transferul de mesaje LDAP s? aib? loc (f?r? o opera?ia Start TLS) 2) conexiunea LDAPS trebuie inchis? la inchiderea TLS. LDAPS a fost folosit cu LDAPv2, pentru ca opera?iunea de StartTLS nu era definit? inc?. Utilizarea LDAPS-ului este din ce in ce mai rar? ?i software-urile moderne ar trebui s? foloseasc? doar StartTLS.

Bind (autentificare) [ modificare | modificare surs? ]

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 in intrarea numit?. Bind anonim (f?r? DN ?i parol?) reseteaz? conexiunea in 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 intotdeauna in biblioteca LDAP. Bind trebuie s? fie prima opera?ie intr-o sesiune in LDAPv2, dar nu este obligatoriu in LDAPv3 (versiunea curent? de LDAP).

Caut? ?i compar? [ modificare | modificare surs? ]

Opera?iunea de c?utare este folosit? atat pentru c?utare cat ?i pentru citirea intr?rilor. Parametrii s?i sunt:

• baseObject ? DN-ul intr?rii de unde s? inceap? 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 (intregul sub-arbore incepand de la DN-ul de baz?).
• Filter ? criteriul folosit in 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 incepe 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 in 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 in 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.

Actualizarea datelor [ modificare | modificare surs? ]

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, inlocuirea 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 intreg 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 in acest timp. Serverele pot implementa extensii care suport? acest lucru.

Opera?ii extinse [ modificare | modificare surs? ]

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.

Abandon [ modificare | modificare surs? ]

Opera?ia de abandonare trimite o cerere serverului de terminare a unei opera?ii identificat? de ID-ul de mesaj. Serverul poate s? nu indeplineasc? 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?.

Unbind [ modificare | modificare surs? ]

Opera?ia Unbind sfar?e?te orice opera?ii in desf??urare ?i inchide 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 inchiderea conexiunii, dar ar trebui sa foloseasc? Unbind. Unbind permite serverului s? inchid? conexiunea intr-un mod mai gra?ios ?i s? elibereze resursele care altfel ar fi inc? folosite o perioada de timp pan? cand s-ar descoperi c? clientul a abandonat conexiunea. De asemenea instruie?te serverul s? inchid? opera?iile care pot fi inchise ?i s? nu trimit? r?spunsuri pentru opera?iile care nu pot fi inchise.

URL-uri LDAP [ modificare | modificare surs? ]

Exista un format de URL LDAP pe care clien?ii il suport? intr-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 in 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 in intrarea John Doe in ldap.example.com, in timp ce ?ldap:///dc=example,dc=com??sub?(givenName=John)” caut? intrarea in serverul default (a se observa triplu slash, omiterea host-ului, dublu semn de intrebare ?i omiterea atributelor). In alte URL-uri caracterele speciale trebuie s? fie codate in 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.

Schema [ modificare | modificare surs? ]

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? intr-un num?r de elemente diferite cum ar fi: - Attribute Syntaxes ? ofer? informa?ii despre tipul informa?iilor care pot fi stocate intr-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 in conjunc?ie cu o regul? de potrivire specific?.
3. Attribute Types ? define?te un OID ?i un set de nume care pot fi folosite cand 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? intr-un set de atribute op?ionale ?i obligatorii.
5. Name Forms ? define?te reguli pentru un set de atribute care ar trebui incluse in RDN pentru o intrare.
6. Content Rules ? define?te constrangeri adi?ionale despre clasele de obiecte ?i atribute ce pot fi folosite in 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 intr-un director ?i schema define?te regulile pentru care atributele pot fi folosite intr-o intrare, tipul valorilor pe care le pot lua acele atribute ?i felul in care clien?ii pot interac?iona cu acele valori.

Clien?ii pot inv??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 in 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?? in programarea orientat? pe obiecte, reprezentand objectClass LDAP ?i intrarea LDAP respectiv?.

Serverele de directoare pot publica schema directorului controland 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, in completare la elementele schemei oferite. O schem? care reprezint? indivizi intr-o organiza?ie se nume?te o schem? cu pagini albe.

Varia?ii [ modificare | modificare surs? ]

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?spandite. Parolele utilizatorilor pot fi stocate in intr?rile lor sau in 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.

Alte modele de date [ modificare | modificare surs? ]

Din moment ce LDAP a ca?tigat teren, produc?torii l-au folosit pe post de protocol de acces pentru alte servicii. Pe urm? s-a incercat 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 inainte stocate altundeva sunt uneori mutate in directoare LDAP. De exemplu informa?ii despre utilizatori Unix ?i informa?ii despre grupuri pot fi stocate in LDAP ?i accesate via modulele PAM ?i NSS. LDAP este des utilizat de c?tre alte servicii pentru autentificare.

Folosire [ modificare | modificare surs? ]

Structura de denumire [ modificare | modificare surs? ]

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? in DNS, numele de nivel ridicat ale serverelor de multe ori imit? numele DNS, cum se intampla ?i in cazul X.500. Dac? o organiza?ie are numele de domeniu example.org, intrarea LDAP de nivel inalt va avea DN-ul dc=example,dc=org. Dac? serverul LDAP este de asemenea numit ldap.example.org, URL-ul LDAP-ului de nivel inalt 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? decat numele DNS.

Terminologie [ modificare | modificare surs? ]

Terminologia LDAP pe care o putem intalni este relativ cople?itoare. Acest lucru se datoreaz? nein?elegerilor, originii istorice sau cand se folose?te impreun? cu servicii non-X.500 care folosesc o terminologie diferit?. De exemplu ?LDAP” este folosit atat pentru referin?a la protocol cat ?i la protocol ?i date. ?Directorul LDAP” poate insemna atat date cat ?i punct de acces. Un ?atribut” poate fi tipul atributului sau con?inutul unui atribut intr-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 in loc de ID-uri numerice de utilizatori. ^{[ necesit? citare ]}

Note [ modificare | modificare surs? ]

Acest articol include informa?ii din articolul echivalent din Wikipedia in limba englez? .

Note [ modificare | modificare surs? ]

Lectur? suplimentar? [ modificare | modificare surs? ]

• 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 .  

Leg?turi externe [ modificare | modificare surs? ]

• 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