AddEdit
az ADD operation beszúr egy új bejegyzést a directory-server adatbázisba. Ha az Add kérés megkülönböztetett neve már létezik a könyvtárban, akkor a kiszolgáló nem ad hozzá ismétlődő bejegyzést, hanem beállítja az eredménykódot az add eredményben a decimális 68-hoz, “entryAlreadyExists”.
- LDAP-kompatibilis szerverek soha nem dereference a megkülönböztetett név továbbított add kérés, amikor megpróbálja megtalálni a bejegyzést, azaz megkülönböztetett nevek soha nem de-aliased.,
- LDAP-kompatibilis szerverek biztosítják, hogy a megkülönböztetett név és minden attribútum megfeleljen az elnevezési szabványoknak.
- a hozzáadandó bejegyzés nem létezhet, és a közvetlen felettesnek léteznie kell.
a fenti példában uid=user,ou=people,dc=example,dc=comnem létezhet, és ou=people,dc=example,dc=com léteznie kell.
Bind (authenticate)Edit
LDAP munkamenet létrehozásakor, azaz amikor egy LDAP kliens csatlakozik a kiszolgálóhoz, a sessionis hitelesítési állapota anonymous értékre van állítva. A kötési művelet létrehozza a munkamenet hitelesítési állapotát.,
Simple BIND és SASL PLAIN küldheti a felhasználó DN és jelszó plaintext, így a kapcsolatok felhasználásával akár egyszerű vagy SASL PLAINshould titkosítva Transport Layer Security (TLS). A szerver általában ellenőrzi a jelszót a userPasswordattribútummal szemben a megnevezett bejegyzésben. Anonymous BIND (üres DN és jelszó) visszaállítja a kapcsolatot anonymous állam.
SASL (Simple Authentication and Security Layer) a BIND számos mechanizmuson keresztül nyújt hitelesítési szolgáltatásokat, pl. Kerberos vagy a withTLS által küldött kliens tanúsítvány.,
a BIND az LDAP protokoll verzióját is beállítja egy Verziószám egész szám formájában történő elküldésével. Ha az ügyfél olyan verziót kér, amelyet a kiszolgáló nem támogat, akkor a kiszolgálónak be kell állítania az eredménykódot a PROTOKOLLHIBA kódjára adott kötési válaszban. Általában a klienseknek LDAPv3-At kell használniuk, ami a protokollban a default, de nem mindig az LDAP könyvtárakban.
a kötésnek az LDAPv2-ben végzett munkamenet első műveletének kellett lennie, de az LDAPv3-tól kezdve nem szükséges., Az LDAPv3-ban minden sikeres kötési kérés megváltoztatja a munkamenet hitelesítési állapotát, és minden sikertelen kötési kérés visszaállítja a munkamenet hitelesítési állapotát.
DeleteEdit
egy bejegyzés törléséhez egy LDAP kliens egy megfelelően kialakított törlési kérést továbbít a kiszolgálónak.,
- a törlési kérelemnek tartalmaznia kell a törlendő bejegyzés megkülönböztetett nevét
- Kérésvezérlők is csatolhatók a törlési kéréshez
- szerverek nem dereference álnevek a törlési kérelem feldolgozása során
- csak a levélbejegyzések (alárendelt nélküli bejegyzések) törölhetők törlési kéréssel., Néhány szerver támogatja a
hasSubordinatesoperációs attribútumot, amelynek értéke azt jelzi, hogy egy bejegyzésnek van-e alárendelt bejegyzése, néhány szerver pedig támogatja anumSubordinatesműködési attribútumot, jelezve anumSubordinatesattribútumot tartalmazó bejegyzésnek alárendelt bejegyzések számát. - egyes kiszolgálók támogatják a Delete request control részfajtát, amely lehetővé teszi a DN és a DN alá tartozó összes objektum törlését, a hozzáférési vezérlők függvényében., A kérések törlése hozzáférés-vezérlők hatálya alá tartozik, vagyis az, hogy egy adott hitelesítési állapothoz való kapcsolat engedélyezett-e egy adott bejegyzés törlésére, a szerverspecifikus hozzáférés-ellenőrzési mechanizmusok szabályozzák.
Search and CompareEdit
a keresési művelet mind a bejegyzések keresésére, mind az olvasásra szolgál. Paraméterei a következők:
baseObject az alapobjektum-bejegyzés (vagy esetleg a gyökér) nevét, amelyhez a keresést végre kell hajtani. hatály milyen elemeket tartalmaz az alap alattkeresés tárgya., Ez lehetBaseObject(keresés csak a megnevezett bejegyzés, jellemzően olvastam egy bejegyzést),singleLevel(bejegyzés alatt közvetlenül a base DN), vagy awholeSubtree(a teljes részfa kezdve a base DN). szűrési kritériumok az elemek kiválasztásánál a hatókörön belül., Például a(&(objectClass=person)(|(givenName=John)(mail=john*)))szűrő a “személyek” (objectClasspersonelemei) lehetőséget választja, ahol agivenNameésmail> > > értékei megegyeznek a szűrő állításával. Vegye figyelembe, hogy általános tévhit, hogy az LDAP adatok eset-érzékeny, mivel valójában megfelelő szabályok és rendelési szabályok határozzák meg a megfelelőséget, összehasonlítások, és relatív érték kapcsolatok., Ha a példaszűrőknek meg kellett felelniük az attribútumérték esetének, akkor egy bővíthető egyezési szűrőt kell használni, például:(&(objectClass=person)(|(givenName:caseExactMatch:=John)(mail:caseExactSubstringsMatch:=john*)))derefAliases, hogy követni kell-e az alias bejegyzéseket (más bejegyzésekre hivatkozó bejegyzések), attribútumokat, amelyek az eredménybejegyzésekben való visszatéréshez kapcsolódnak. sizeLimit, timeLimit a visszatérendő bejegyzések maximális száma, valamint a keresés futtatásához szükséges maximális idő. Ezek az értékek azonban nem tudják felülírni azokat a korlátozásokat, amelyeket a szerver a méretkorlát és a határidő tekintetében helyez el. typesOnly Return attribútum típusok csak, nem attribútum értékeket.,
a kiszolgáló visszaadja a megfelelő bejegyzéseket és a lehetséges folytatási hivatkozásokat. Ezeket bármilyen sorrendben vissza lehet küldeni. A végeredmény tartalmazza az eredménykódot.
az összehasonlítási művelet egy DN, egy attribútumnév és egy attribútumértéket vesz fel, és ellenőrzi, hogy a megnevezett bejegyzés tartalmazza-e az adott értékkel rendelkező attribútumot.
ModifyEdit
a módosítási műveletet az LDAP kliensek használják annak kérésére, hogy az LDAP szerver módosítsa a meglévő bejegyzéseket. A nem létező bejegyzések módosítására irányuló kísérletek meghiúsulnak. A kérelmek módosítása a kiszolgáló által végrehajtott hozzáférési vezérlők függvénye.,
a módosítási művelet megköveteli a bejegyzés megkülönböztetett nevének (DN) megadását, valamint a változások sorrendjét. Minden változás a sorrend biztos:
- add (hozzáadás egy új értéket, amely nem létezik az attribútum)
- delete (törlés meglévő érték)
- cserélni (replace meglévő érték új érték)
LDIF példa, hozzátéve, hogy egy érték egy attribútum:
dn: dc=example,dc=comchangetype: modifyadd: cncn: the-new-cn-value-to-be-added-
cserélje ki az értéket, a meglévő attribútum, Használd a csere kulcsszó., Ha az attribútum többértékű, az ügyfélnek meg kell adnia a frissítendő attribútum értékét.
egy attribútum bejegyzésből való törléséhez használja a delete kulcsszót, majd módosítsa a changetype jelölőt. Ha az attribútum többértékű, az ügyfélnek meg kell adnia a törölni kívánt attribútum értékét.
van egy módosítási növekmény kiterjesztés is, amely lehetővé teszi egy növekményes attribútumérték növelését egy meghatározott összeggel., A következő példa az LDIF lépésekben employeeNumber by 5:
dn: uid=user.0,ou=people,dc=example,dc=comchangetype: modifyincrement: employeeNumberemployeeNumber: 5-
Ha az LDAP szerverek replikált topológiában vannak, az LDAP klienseknek fontolóra kell venniük a post-read vezérlő használatát a frissítések ellenőrzéséhez a frissítés utáni keresés helyett. Az olvasást követő vezérlés úgy van kialakítva, hogy az alkalmazásoknak ne kelljen keresési kérelmet kiadniuk frissítés után – rossz forma egy bejegyzés lekérése kizárólag annak ellenőrzésére, hogy a frissítés a replikációs esetleges konzisztencia modell miatt működött-e., Az LDAP kliensnek nem szabad azt feltételeznie, hogy minden kéréshez ugyanahhoz a könyvtárszerverhez csatlakozik, mivel az építészek terhelésmérőket vagy LDAP proxykat helyezhettek el, vagy mindkettő LDAP kliensek és szerverek között.
módosítása Dnedit
módosítása DN (move / rename entry) veszi az új RDN (Relative Distinguished Name), opcionálisan az új szülő DN, és egy zászló, amely jelzi, hogy törölje az érték(ek) a bejegyzés, amely megfelel a régi RDN. A kiszolgáló támogathatja a teljes könyvtár alfajok átnevezését.,
egy frissítési művelet atomic: más műveletek az új bejegyzést vagy a régit fogják látni. Másrészt az LDAP nem határozza meg a több művelet tranzakcióit: ha egy bejegyzést olvas, majd módosítja, akkor egy másik ügyfél időközben frissítheti a bejegyzést. A kiszolgálók azonban végrehajthatják az ezt támogató kiterjesztéseket.
Extended operationsEdit
a kiterjesztett művelet egy általános LDAP művelet, amely olyan új műveleteket határozhat meg, amelyek nem részei az eredeti protokoll specifikációnak. A StartTLS az egyik legjelentősebb kiterjesztés., További példák a Mégse és a Jelszó módosítása.
StartTLSEdit
a StartTLS művelet Transport Layer biztonságot (az SSL leszármazottja) hoz létre a kapcsolaton. Az adatok bizalmas kezelését (az adatok harmadik felek általi megfigyeléstől való védelme érdekében) és/vagy az adatok integritásának védelmét (amely megvédi az adatokat a manipulációtól). A TLS tárgyalás során a szerver elküldi X. 509 tanúsítványát, hogy igazolja személyazonosságát. Az ügyfél igazolást is küldhet személyazonosságának igazolására. Ezt követően az ügyfél használhatja a SASL/EXTERNAL alkalmazást., A SASL / EXTERNAL használatával az ügyfél kéri, hogy a kiszolgáló azonosítóját alacsonyabb szinten (például TLS) megadott hitelesítő adatokból származtassa. Bár technikailag a szerver bármilyen alacsonyabb szinten létrehozott személyazonossági információt felhasználhat, általában a kiszolgáló a TLS által létrehozott személyazonossági információkat fogja használni.
A kiszolgálók gyakran támogatják a nem szabványos “LDAPS” (“Secure LDAP”, közismert nevén “LDAP over SSL”) protokollt egy külön porton, alapértelmezés szerint 636., Az LDAP-K kétféleképpen térnek el az LDAP-tól:1) csatlakozáskor az ügyfél és a kiszolgáló TLS-t hoz létre, mielőtt bármilyen LDAP-üzenetet továbbítanak (StartTLS-művelet nélkül) és2) az LDAPS-kapcsolatot a TLS-lezárás után le kell zárni.
néhány “LDAPS” kliens könyvtár csak titkosítja a kommunikációt; nem ellenőrzik a gazdagép nevét a mellékelt tanúsítványban szereplő névvel.
AbandonEdit
az elhagyási művelet azt kéri, hogy a kiszolgáló szüntesse meg az üzenetazonosító által megnevezett műveletet. A szervernek nem kell tiszteletben tartania a kérést. Sem az elhagyás, sem a sikeresen elhagyott művelet nem küld választ., Egy hasonló mégsem kiterjesztett művelet válaszokat küld, de nem minden megvalósítás támogatja ezt.
UnbindEdit
az Unbind művelet felhagy minden kiemelkedő művelettel, és lezárja a kapcsolatot. Nincs válasz. A név történelmi eredetű, és nem a kötési művelet ellentéte.
az ügyfelek megszakíthatják a munkamenetet a kapcsolat egyszerű lezárásával, de az Unbind-et kell használniuk. Az Unbind lehetővé teszi a szerver számára, hogy kecsesen bezárja a kapcsolatot, valamint olyan ingyenes erőforrásokat, amelyeket egyébként egy ideig megtartana, amíg az ügyfél felfedezi a kapcsolatot., Azt is utasítja a kiszolgálót, hogy törölje a törölhető műveleteket, és ne küldjön válaszokat olyan műveletekre, amelyeket nem lehet törölni.