S ekspanzijom World Wide Weba (WWW) kroz prošlo desetljeće, umrežavanje je postalo poprilično rasprostranjeno. Uskoro su sve tvrtke postale prisutne i ostvarile pristup na Internet. Pored toga, broj intranetova, ekstranetova i privatnih mreža se također počeo eksponencijalno pojavljivati. „Biti spojen“ je postala rutina, kao što je rutina imati mobilni telefon. Sjetimo se kako je postalo uobičajeno, prilikom razmjene telefona, spomenuti i e-mail adresu kao sredstvo komunikacije. Danas čak i djeca dobi osnovne škole komuniciraju putem Interneta i služe se s njim kao sastavnim dijelom života. Logičan zaključak je kako je Internet ušao u sve strukture i pore života.

Kako su se distribuirana računalna okruženja počela brzo razvijati, paralelno s njima se razvijaju i skladišta podataka, što predstavlja pravi izazov u potrazi za informacijama. Pojavila se potreba za kreiranjem sofisticiranih sustava za pretragu informacija kako bi nam olakšalo pristup istima. Neki od ovih sustava su specijalizirani za osiguravanje informacija prema određenim temama. Za lociranje osobe na Internetu ili intranetu na brz i jednostavan način, koriste se specijalni alati slični telefonskim imenicima, poznati pod nazivom „white pages“. Ovaj „alat“ se naziva imenički servis.

Ukoliko želite pristupiti web sadržaju, jednostavno se spojite na Internet, i u web pretraživaču upišete adresu te dohvaćate sadržaj pomoću HTTP protokola. Kada želite nekome poslati e-mail, tada ga šaljete iz mail klijenta uz pomoć SMTP protokola. Kada želite pretraživati informacije nad imeničkim poslužiteljem, tada komunicirate s imenikom putem LDAP (Lightweight Directory Access Protocol) protokola.

Ovaj seminar se bavi kratkim pregledom i proučavanjem LDAP imeničkog servisa. Na početku ćemo se ukratko upoznati s pojmom imenički servis, potom ćemo se detaljno upoznati s LDAPom i na kraju, vidjeti kako instalirati, upogoniti i koristiti OpenLDAP.

1. IMENIČKI SERVIS

Imenički servis je skup softvera, hardvera, procesa, pravila i administrativnih procedura koji omogućuju korištenje informacija iz imenika svim korisnicima. Svaki imenički servis uključuje najmanje:

informacije sačuvane u imeniku
softversku podršku čuvanja informacija
softversko pristupanje informacijama u ime korisnika
hardversku podršku poslužitelj
mrežnu infrastrukturu za vezu klijent – poslužitelj i poslužitelj – poslužitelj
sigurnosna pravila pristupa imeničkom servisu

1.1 Što je imenik?

Većina ljudi je upoznata s velikim brojem imenika u svakodnevnom životu poput telefonskog imenika, TV vodiča, shopping kataloga, itd. Jasno je kako nam imenici služe za pronalazak informacija prema ključnim riječima radi brzog i jednostavnog dohvata.

U računalnom svijetu, imenici su slični imenicima iz svakodnevnog života, ali s nekoliko bitnih razlika. Računalne imenike zovemo online imenike. Online imenici se razlikuju od offline imenika po tome što:

su dinamični
fleksibilni
po sigurnosti/privatnosti imenika
osobnosti imenika

Također je bitno uvidjeti razliku među vrstama imenika. Njih dijelimo u slijedeće kategorije:

Aplikacijski ugrađeni imenici. Ova vrsta imenika dolazi kao paket ili je ugrađena u aplikaciju. U mnogim slučajevima, o njima se ne razmišlja kao o imenicima jer su vrlo vješto integrirani u aplikaciju. Primjer je IBM/Lotus Notes Name i Address book, Microsoft Exchange Directory i alias dokumenti korišteni prilikom transfera e-mail poruka(MTA)

Mrežno operativni sustav (NOS) bazirani imenici. Imenici poput Novell eDirectory, Microsoft Active Directory itd., su direktoriji koji su kreirani za ispunjanavanje potreba NOS-a.
Imenici specifične svrhe. Ovo su imenici koji nisu usko vezani uz neku aplikaciju ali su dizajnirani za specifične prilike. Pravi predstavnik ove grupe imenika je Domain Name System ili poznatiji pod kraticom DNS.
Standardni, za generalnu namjenu imenici. Ovi imenici su kreirani za usluživanje velikog broja i raznolikih vrsta aplikacija. Jedan od predstavnika je i LDAP s kojim se bavimo u ovom seminarskom radu i X.500 orijentirani imenici.

Idemo se detaljnije upoznati s odrednicama online imenika.

1.1.1 Dinamičnost imenika

Imenici s kojima smo se već susreli u svakodnevnom životu su relativno statični, odnosno podaci u njima se ne mijenjaju često. Za primjer, jednom godišnje se izdaje telefonski imenik s ažuriranim podacima. U međuvremenu, za dobivanje nove, aktivne, informacije moramo zvati službu za korisnike. Što se tiče online imenika, oni su u pravilu češće izmjenjivani i može ih se smatrati pouzdanim i ažuriranim izvorom informacija koje tražimo. No, i njihovo ažuriranje ovisi o administratoru imenika. Što je imenik svježe ažuriran, to će njegova svrha biti ispunjenja. Za primjer, zamislimo imenik koji bilježi lokaciju zaposlenika u svakom trenutku (prelazak iz sobe u sobu, s kata na kat...). Ovaj imenik se može iskoristiti za preusmjeravanje telefonskih poziva, faxeva, poruka gdjegod bili. Tradicionalni način prenošenja informacija papirom je ovdje u potpunosti neunčikovit i nepouzdan.

Ažuriranje imenika nije samo bitno zbog čuvanja svježih informacija; ono može također biti iskorišteno u raspodjeljivanju odgovornosti prilikom ažuriranja. Što je mogućnost izmjene informacija bliža izvoru informacije, to će informacija biti točnija i pouzdanija. Tri su razloga za to:

izvor informacije je, u pravilu, gotovo uvijek točan u prenošenju novih informacija
pogreška u prijenosu informacija između izvora i imenika putem treće osobe se zaobilazi ukoliko izvor sam izvrši promjenu
izvor informacije je najčešće motiviraniji nego treća osoba za izmjenu informacija

Na primjer, pretpostavimo da ste vlasnik web stranice i da vam se posao temelji na Internet komunikaciji. Izvršena je promjena e-mail adrese firme a njena promjena može utjecati na posao. Vi, da biste bili sigurni, sami izvršavate promjenu na web stranici jer ste izvor nove informacije i jer želite biti sigurni da se neće dogoditi pogreška prilikom njenog objavljivanja na Internetu. Što se tiče motiviranosti, nju nije potrebno specijalno naglašavati; zbog posla ste vjerojatno još više motiviraniji za izvršiti promjenu nego vaš web održavatelj.

1.1.2 Fleksibilnost imenika

Offline imenici su statični kad se razmatra njihov sadržaj. Pod time smatramo da offline imenici sadrže točno određene informacije. Pogledajmo primjer telefonskog imenika. Oni najčešće sadrže samo prezime, ime, adresu i telefonski broj. Što ukoliko bi mi htjeli doznati, npr. e-mail adresu osobe ili vidjeti sliku ili kratku biografiju tražene osobe? Definitivno ćemo ostati kratkih rukava. Kako bismo uključili e-mail adresu na telefonskim imenicima, morali bi raditi novi dizajn imenika, te ga, nakon prikupljanja podataka, ponovno tiskati što bi nam oduzelo veliku količinu resursa. Online direktoriji su kreirani za jednostavnu nadogradnju bez redizajniranja imenika. Promjene koje se izvrše su odmah vidljive i dostupne korisnicima imenika te nije potrebno izvršiti redistribuciju jer se sadržaj dohvaća putem mreže. Ekonomski gledajući, redizajni telefonskog imenika (ili bilo kojeg offline) će se napraviti tek na zahtjev velike većine korisnika. Posebno se možemo osvrnuti na povećanje veličine imenika kada se povećava dostupnost informacija što se direktno reflektira na korisnika i njegovo zadovoljstvo korištenjem istog. S druge strane, online imenici se mogu proširiti bez veće ekonomske investicije. Dodavanje informacija na zahtjev manjeg dijela korisnika postaje isplativo (potrebno je npr. povećati diskovni prostor te neznatno više čekati na arhiviranje,...).

Drugi vid fleksibilnosti kod online imenika je kako omogućavaju organiziranje informacija. Pogledajmo još malo primjer telefonskog imenika. Pretraga u njima se vrši putem prezimena, te dodatno imena i adrese. Što ukoliko želimo pretraživati informacije po telefonskom broju? Kod telefonskog imenika je to uzaludan posao. S druge strane, online imenici omogućuju razne varijante organizacije informacija. Oni omogućuju (ako gledamo analogiju s telefonskim imenikom) pretragu po imenu, prezimenu, adresi, telefonskom broju ili nekom drugom podatku. Još bitnije je da nudi mogućnost napredne pretrage informacija što ne može bili nikako slučaj kod offline imenika (npr. ime osobe čiji telefon tražimo počinje na S; prve tri znamenke broja korisnika kojeg tražimo su 345, itd...). Svi ovi navedeni razlozi fleksibilnosti su bitna odrednica online imenika.

1.1.3 Sigurnost/privatnost imenika

Offline imenici nude gotovo nikakvu razinu sigurnosti. Telefonski imenik je javan. Ukoliko želite da vam telefonski broj bude tajan, vaša želja će vas i koštati, a nemate mogućnost prikazivanja informacija osobama kojima želite omogućiti dostupnost vaših podataka. Ili je vaš broj pristupačan svima tko ima imenik ili je broj kao podatak sakriven od svih korisnika. Online imenici mogu riješiti ovaj problem. Pristup informacijama se može kontrolirati. Pristup informacijama iz imenika se može osigurati u procesu koji se zove autentikacija. Svaki korisnik se provjerava u listi pristupa, te, ukoliko posjeduje dozvolu, može pristupiti informacijama nakon izvršene autorizacije. Vraćajući se na analogiju s telefonskim imenikom, možete postojati u imeniku, ali informacija može biti dostupna samo dijelu korisnika koju se može osobno uređivati. Bitno je naglasiti, kako i s ovom razinom izolacije informacija, uvijek postoji opasnost od ljudskog faktora koji može u bilo kojem trenutku iznijeti informacije onima od kojih smo ih željeli zaštititi. No, bez obzira na sve, sigurnosna razina online imenika je bitno veća i naprednija od offline imenika.

1.1.4 Osobnost imenika

Još jedna razlika uspoređujući s offline imenicima je u stupnju prilagodbe imenika svakom korisniku. Postoje dva aspekta osobnosti imenika. Bilo bi svrsi shodno kada bi mogli prilikom pretrage uključivati specifične interese svakog korisnika ili vršiti pretragu telefonskog imenika na način kako bi mi to htjeli. Dakle, bitno je dobiti informacije koje su usklađene s potrebama, željama korisnika informacija. S druge strane, bitno je određenje tko ima mogućnosti pristupa vašim, ili nečijim drugim, informacijama. Ovo je odrednica vas kao pružatelja informacija. Već smo vidjeli kako kod telefonskog imenika postoje dvije mogućnosti: da se telefonski broj nalazi ili ne nalazi u imeniku. Online imenici nude, prema pravima pristupa, mogućnost prikaza informacija. Unčikovitost ovakve organizacije informacija je vidljiva radi izbjegavanja doticaja s informacijama korisnika koje ga ne interesiraju, ali također jednostavnijeg dohvata svježih interesnih informacija.

1.2 Opis imenika

Do sada smo se bavili razumijevanjem pojma imenik, a sada je potrebno iznijeti karakteristike online imenika kako bismo ga pobliže opisali. Imenik se često smatra kao specijalna baza podataka. Zanimljivo je izvršiti usporedbu relacijskih baza podataka s imenicima radi boljeg prepoznavanja svrhe i razlika među navedenim pojmovima. Nekoliko je kategorija po kojima se razlikuju imenici i baze podataka:

odnos čitanja/pisanja
fleksibilnost
mjera raspodijeljenosti podataka
mjera preslikavanja podataka
izvođenje
standardi

1.2.1 Odnos čitanja/pisanja

Jedna od bitnih definicijskih karakteristika imenika jest iznimno veći broj čitanja i pretraga u odnosu na pisanje što nije pravilo kod baza podataka. Na primjer, posjedujemo bazu podataka u kojoj upisujemo podatke i do tisuću puta dnevno, ali učinimo samo dnevni/tjedni/mjesečni ispis stanja. S druge strane, informacije u imeniku se, uobičajeno, više čitaju nego što se pišu. Primjerice, ne događa se česta izmjena telefonskog broja ili adrese prebivanja uspoređujući s brojem primljenih poziva. Zbog čega je ova karakteristika bitna? Dizajneri imenika su svjesni odnosa između čitanja i pisanja te će stoga kreirati takav imenik da, prilikom pretrage, ima što veću učinkovitost i brzinu. Kod baza podataka, slučaj je takav da se one dizajniraju kako bi podjednako podržale odnos čitanja/pisanja.

1.2.2 Fleksibilnost

Još jedna bitna odrednica imenika je fleksibilnost podataka, odnosno imenici nisu ograničeni na jedinstven dizajn, već se on može prilagođavati organizacijskim ili aplikativnim potrebama. Moguće je kreirati vlastite tipove podataka i unositi ih unutar postojećeg dizajna imenika bez utjecaja na postojeće podatke. Kod baza podataka, podaci su ograničeni na već postojeće tipove podataka, a neke od njih teško je naknadno prilagoditi dodavanjem novih atributa. Rijetkost je vidjeti baze podataka kako dozvoljavaju kreiranje novih, primitivnih tipova podataka.

1.2.3 Raspodijeljenost podataka

Raspodijeljenost podataka je također jedno od područja gdje se uočava bitna razlika s bazama podataka. Kod imenika, podaci mogu biti centralizirani na jednom poslužitelju ili raspodijeljeni na više poslužitelja. Moguće je susresti se s distribuiranim bazama podataka čiji tipični sustav za upravljanjem dozvoljava raspodjelu tablica na različitim mjestima. Ovakva distribucija je ograničena na nekoliko mjesta. Iako postoji mogućnost postavljanja upita nad nekoliko mjesta, ono umanjuje njenu unčikovitost te se ovakav slučaj rijetko primjenjuje. Raspodijeljenost podataka kod imenika je fundamentalni faktor. Omogućava da dio imenika bude distribuiran na mjesto njenog održavatelja (administratora) čime se povećava njegova unčikovitost. Još jedna prednost distribucije podataka je u tome što je jeftinije i unčikovitije udružiti više poslužitelja nego stvarati jedan veliki čisto zbog opasnosti od gubitka podataka. Raspodijeljenost omogućuje spremanje informacija blizu aplikacija koje ih koriste čime se također povećava efikasnost primjene imenika za pohranjivanje informacija.

1.2.4 Preslikavanje podataka

Preslikavanje je proces održavanja višestrukih kopija podataka imenika na različitim lokacijama. Nekoliko je razloga za to:

Pouzdanost. Ako je jedna kopija imenika nedostupna zbog hardverske ili softverske pogreške, ostale kopije su pouzdane i spremne na korištenje.
Dostupnost. Moguće je dohvatiti dostupnu kopiju imenika bez obzira na privremenu nedostupnost mreže.
Lokacija. Vrijeme čekanja i varijacije u izvedbi su umanjene ako su korisnici bliži kopiji imenika.
Izvedba. Moguće je podržati veći broj upita s dodavanjem dodatnih kopija te se pri tome poboljšava opća zalihost (propusna moć) imeničkih servisa.

Baze podataka, s druge strane, podržavaju preslikavanje podataka ali samo ukoliko se radi o malom broju kopija. Inače, poznato je kako je unčikovitost implementiranja preslikavanja kod baza podataka teško izvediva zbog strogih pravila konzistentnosti baza podataka kako se sve kopije moraju sinkronizirati u istom trenutku. Što se tiče imenika, on dozvoljava privremenu nekozinstentnost podataka što omogućava jednostavnu implementaciju preslikavanja.

1.2.5 Izvođenje

Kao što je prethodno rečeno, visok stupanj izvođenja je također bitna karakteristika imenika u odnosu na baze podataka. Unčikovitost baza podataka se mjeri u broju obavljenih transakcija u jednoj sekundi. Tipične velike baze mogu podržati stotine transakcija u sekundi. Tipični imenik može podržati i nekoliko tisuća upita u jednoj sekundi zbog toga što su upiti nad imenikom jednostavniji od transakcija u bazi podataka. Kao što je i prethodno opisano, odnos čitanja-pisanja je kod imenika puno veći nego kod baza podataka. Stoga je uspješnost ažuriranja nešto lošija nego kod baza. Kod nekih imenika je povećana unčikovitost čitanja podataka zbog nepoznatog povećavanja broja aplikacija koje ih koriste radi bržeg odgovaranja. Dakako, ovo ne dozvoljava da razina unčikovitosti upisivanja/ažuriranja podataka može biti niska, već mora biti na dovoljno zadovoljavajućoj razini za potrebe za koje je imenik kreiran.

1.2.6 Standardi i uzajamna funkcionalnost

Poznat je kako postoje standardi za relacijske baze podataka. Ti standardi su sadržani u SQL-u (Structured Query Language), ali i u njegovim varijantama. Ovi standardi omogućuju jednostavnu migraciju (preseljenje) podataka iz jedne baze u drugu, ali i snalaženje u novoj bazi nakon naučenog korištenja stare. Realno govoreći, ovi standardi ne predstavljaju pojam uzajamne funkcionalnosti. U imeničkom svijetu realnost uzajamne funkcionalnosti je kritična jer aplikacije bilo kojeg proizvođača moraju biti sposobne koristiti bilo koji imenik. Ovdje je mjesto gdje LDAP uskače. LDAP nudi standardne modele i protokole koje se koriste u današnjim modernim imenicima. LDAP dozvoljava Microsoftovom korisniku rad sa serverom koji je pod Linuxom, i obratno. LDAP također dozvoljava razvijanje aplikacije za bilo koji operativni sustav, što nije slučaj kod baza podataka. Ova dobra strana imenika omogućava da se ne dogodi slučaj, kako je to prije bilo, da sa svakim imenikom dođe njegova vlastita aplikacija te da na računalu postoje 24 aplikacije za 24 različita imenika.

1.3 Čemu nam služi imenik?

1.3.1 Pronalazak informacija

Kao što smo se prethodno upoznali, tipičan predstavnik imenika je takav da su u njemu informacije pohranjene za brz i jednostavan dohvat. Na primjer, poznato nam je pretraživanje informacija iz telefonskog imenika. No, svjesni smo kako pretraživanje po prezimenu nije unčikovito. Imenici dozvoljavaju pretragu po bilo kojoj informaciji koju sadrži unutar sebe, pa čak i pretraživanje po nepotpunoj informaciji. Fleksibilnost koja proizlazi iz pretrage imenika jasno prikazuje imeničku sposobnost višestruke organizacije informacija istovremeno.

1.3.2 Upravljanje sadržajem

Online imenici zauzimaju središnju ulogu u menadžmentskoj slici kod distribuiranih okruženja, osiguravajući centralno mjesto za izmjenu i čuvanje podataka. Zbog velikog broja korisnika, ovakav način upravljanja čini sustav jeftinijim i unčikovitijim. Razmotrimo distribuirani imenički sustav. Zamislimo kako korisnik mora pristupiti svim aplikacijama koje postoje instalirane na mreži. Korisnik mora biti dodan u imenike svih aplikacija posebno. Ukoliko se bilo koja informacija o korisniku promijeni, mora biti promijenjena nad svim imenicima aplikacija koje koristi. Ovo je poznato pod nazivom N+1 imenički problem, što hoće reći kako svaka nova aplikacija gura svoj imenik za upravljanje istim. Pretpostavimo da se radi o centraliziranom sustavu. Kada bi postojao samo jedan imenik za sve aplikacije unutar mreže, dovoljno je jednom promijeniti podatke o korisniku kako bi one bile primjenjive za sve aplikacije.

1.3.3 Sigurnosni pristup

Još jedno zanimljivo područje primjene imenika je sigurnost. Specifično, interesantni su sigurnosni sustavi bazirani na infrastrukturi javnog ključa (PKI, Public Key Infrastructure). PKI zahtjeva sigurnu distribuciju certifikata klijentima i poslužiteljima, čuvanje što svježijim sigurnosne atribute, povlačenje istih kad isteknu, itd. Bez imenika, ove funkcije bi bilo teško implementirati. Imenici pomažu riješiti dva problema koja se javljaju kod PKI-a:

1. Upravljanje PKI životnim ciklusom. Ovaj problem se odnosi na kreiranje, održavanje i gašenje certifikata. Bez direktorija, cijeli ovaj ciklus bi administrator morao „ručno“ raditi.

2. Problem lokacije certifikata. Ovaj problem se predstavlja kada dvije osobe žele sigurnosno komunicirati. Naime, problem se sastoji u pronalasku certifikata osobe s kojom želite sigurnosno komunicirati, i obratno. Bez imenika, komunikacija bi bila doslovno čitanje heksadecimalnih znakova.

Imenik se ponaša kao centralno mjesto za administriranje PKI životnim ciklusom. Kada je potreban novi certifikat, putem imenika se jednostavno dodijeli novi. Kada ga treba ugasiti, i to se jednostavno izvede. Imenik također omogućava lociranje certifikata i ostalih sigurnosnih informacija drugih korisnika s kojima želimo sigurnosno komunicirati. U njemu se sigurnosna informacija korisnika nalazi kao još jedan dodatni atribut.

1.4 Što imenik nije?

U ovom dijelu ćemo razmotriti zašto su imenici različiti od:

Baza podataka
Web poslužitelja
FTP poslužitelja
DNS poslužitelja

1.4.1 Imenik – Baza podataka

Već smo se upoznali s razlikama između imenika i baza podataka koje nećemo ponovno navoditi, ali ćemo se dotaknuti onih najvažnijih. Sjetimo se kako smo naveli da su imenici orijentirani više na čitanje nego na pisanje. Ukoliko se radi o upisivanju velikih količina podataka, poželjno je razmisliti o korištenju baza podataka. Dalje, imenici podržavaju relativno jednostavne transakcijske modele. Imeničke transakcije uključuju jednostruku operaciju i jednostruki unos. Baze podataka, naprotiv, su dizajnirane za velike transakcije, obuhvaćaju višestruke podatke i podržavaju mnoge operacije nad istima. Podržavaju i spajanje relacija čiji rezultat može biti veoma kompleksna lista podataka. Ukoliko imate potrebu za kreiranjem i podržavanjem informacija koji ne zahtijevaju prethodno navedeno, jeftinije je i jednostavnije poslužiti se imenikom nego npr. Oracle bazom podataka.

1.4.2 Imenik – Web poslužitelj

Otkad su Web poslužitelji izašli na scenu, prepoznatljiva je njihova sličnost s imenicima. Naime, oni su kreirani kako bi posjetitelji dohvatili informacije koje traže. Zbog toga se oni predstavljaju više za čitanje nego za pisanje, radi se o čitanju dokumenata, multimedije što su podaci poveće veličine te se po tome razlikuju s imenicima. Naime, imenici sadrže podatke male veličine te najčešće ne podržavaju datoteke kao atribute ugrađene unutar sebe. Imenici su kreirani za bržu i efikasniju pretragu i dohvat podataka za razliku od web stranica koje nemaju standard prilikom pretrage. Web poslužitelji se prislanjaju na grafička sučelja za prikaz podataka (GUI – graphical user interface), dok se imenici ne baziraju na GUI-ju već na jednostavnim formama za unos i prikaz informacija.

1.4.3 Imenik – FTP poslužitelj

Glavna razlika se uočava kod veličine podataka i tipa korisnika koji se služe ovim servisima. FTP (File Transfer Protocol) je jednostavan protokol za prebačaj podataka s jednog mjesta na drugo te bi korištenje imenika ovdje bilo bespotrebno. S druge strane, ukoliko je potrebno ne samo fizičko premještanje podataka, prikladnije je koristiti imeničku infrastrukturu.

1.4.4 Imenik – DNS poslužitelj

DNS (Domain Name System) pretvara ime domene, npr. www.fer.hr, u IP adresu, odnosno u 161.53.72.111. DNS omogućuju pamćenje naziva domene, a on umjesto nas omogućuje jednostavnije korištenje Interneta. DNS i imenici su slični jer omogućuju pristup hijerarhijski distribuiranim podacima, ali posjeduju nekoliko razlika. DNS ima unaprijed i striktno definiran izgled imenika bez mogućnosti proširenja, što nije slučaj kod imenika. DNS uobičajeno ne dozvoljava često ažuriranje svojih podataka, što nije slučaj kod imenika.

1.5 Kratki pregled

Još jednom ćemo se osvrnuti na niz informacija zbog kojih razloga je poželjno odabrati imenik:

· Veličina informacija. Imenici su idealni za spremanje podataka malih veličina i pokazivača na velike podatke, ali i ne njih same.

· Vrsta informacija. Imenici najčešće zapisuju podatke u atributnom modelu prikaza podataka, gdje je informacija razlomljena na više dijelova.

· Odnos čitanja/pisanja. Imenici su najbolji odabir za zapis informacija koji se puno više čitaju nego mijenjaju/zapisuju. Ako se informacije više zapisuju, baza podataka je idealniji izbor.

· Mogućnost pretraživanja. Imenici su napravljeni za pretragu svih informacija koje sadrže.

· Standardno – postavljen pristup. Imenik ima standardan pristup informacijama te ga to čini dobrim izborom za pohranu informacija.

2. LDAP

2.1 Što je LDAP?

LDAP ili Lightweight Directory Access Protocol je standardni, na Internetu uslužljiv protokol korišten za pristup imeničkim servisima. Definiran je u nekoliko dokumenata čiji je koncept prikazan u RFC-u 3377. RFC-ovi koji sadrže LDAP definicije su:

RFC 2251 – 2256
RFC 2829
RFC 2830
RFC 3377

Idemo pogledati što znači pojedini dio imena kratice LDAP.

2.1.1 Lightweight

Zašto se LDAP smatra laganim? Korijeni LDAPa su iznimno povezani s X.500 imeničkim servisom; LDAP je originalno dizajniran kao „lakši“ desktop protokol za usmjeravanje zahtjeva prema X.500 poslužiteljima. X.500 je skup standarda o kojem se možete više informirati na adresi http://www.salford.ac.uk/its024/X500.htm. X.500 se smatra „težim“ protokolom jer zahtjeva komunikaciju klijent – poslužitelj putem OSI modela. Ovaj sedam – slojni model je bio dobar predložak za kreiranje mrežnih protokola, ali je u usporedbi s TCP/IP poprilično teži i kompliciraniji. LDAP je lakši jer koristi male podatke u prijenosu informacija koje su direktno preslikani na TCP sloju (port 389 je postavljeni) unutar TCP/IP mrežnog modela. Zbog toga što je X.500 protokol na aplikativnom sloju OSI modela, on „vuče“ puno više upakiranih informacija radi pristupa svakom sloju konačno do mreže. Na slijedećoj slici možemo slikovito vidjeti mrežne modele kojima pripadaju X.500 i LDAP.

Slika 2.1 Razlika između X.500 i LDAP

LDAP također nosi titulu „lagani“ jer izostavlja mnoge X.500 operacije koje se rijetko ili gotovo nikako ne koriste. LDAPv3 sadrži samo devet jezgrenih operacija i omogućava jednostavnost programerima i administratorima. Ovo svojstvo omogućava razvijateljima fokusiranje na semantiku svojih programa bez potrebe razumijevanja rijetko korištenih značajki protokola. Na ovaj način, se LDAP dizajneri nadaju povećanom prihvaćanju uslužujućih mogućnost jednostavnog razvijanja aplikacija.

2.1.2 Directory

S ovim pojmom smo se prethodno detaljno upoznali. Vidjeli smo kako se imenik ne smije zamijeniti s bazom podataka. U ovom trenutnu, bitno je naglasiti razliku između LDAPa i pozadine prilikom smještanja podataka. Podsjetimo se kako je LDAP samo protokol (o čemu ćemo se kasnije upoznati), a pojednostavljeno znači skup poruka za pristup određenim vrstama podataka. Protokol kao takav ne spominje ništa o mjestu pohrane podataka. Stoga, kada se govori o LDAPu kako ne podržava transakcije i druge funkcije baza podataka, misli se na LDAP kao protokol koji nema komunikacijske mogućnosti za izvršavanjem navedenih upita i koji ne zahtjeva od pozadinskog skladišta podataka istu mogućnost.

Bit je da klijent nikada ne vidi i ne poznaje pozadinu mehanizma pohrane podataka, kao što je prikazano na slici 2.2.

Slika 2.2 Prikaz komunikacije između LDAP klijenta i poslužitelja

Bilo je težnji i ideja da se LDAP poslužitelj prenamijeni kao web poslužitelj, ali iz prethodnog poglavlja navedenih razloga, postoji puno jednostavnijih organizacija podataka i dokumenata specifično određenih za web sadržaj.

2.1.3 Access Protocol

LDAP predstavlja podatke u stablastom prikazu, i često se prilikom spomena stablastog prikaza informacija, sjetimo LDAPove organizacije podataka. Za sada se nećemo osvrtati na organizaciju podataka, već na pristup istima. Naime, LDAP je klijent – poslužitelj protokol (prema definiciji iz RFC 2251), koji omogućava asinkroni pristup. On omogućava da klijent izvrši nekoliko upita te da odgovori mogu stići u drukčijem poretku nego što su poslani. Slijedeća slika prikazuje različit poredak zahtjeva i odgovora u komunikaciji klijenta – poslužitelja.

Slika 2.3 Prikaz asinkronog komuniciranja između klijenta i poslužitelja

2.2 LDAP protokol

Ovdje ćemo raspraviti zasebne operacije LDAP protokola i prikazati kako ih klijenti koriste za obavljanje svojih zadaća. Bitno je pojmiti da je LDAP protokol porukama-orijentiran protokol. Klijent kreira LDAP poruku (informaciju) koja sadrži zahtjev i šalje ga poslužitelju. Poslužitelj prihvati poruku, obradi ju i šalje rezultat(e) klijentu u obliku jedne ili više LDAP poruka.

Na primjer, kada LDAP klijent pretražuje imenik za specifični podatak, šalje LDAP poruku o zahtjevu za pretragom poslužitelju. Ova poruka sadržavat će jedinstvenu oznaku koju je proizveo klijent. Poslužitelj zaprimi podatak iz svoje baze podataka i šalje ju klijentu, također u LDAP poruci. Također vraća rezultantni kod klijentu u odvojenoj poruci. Svi odgovori poslani klijentu se identificiraju prema jedinstvenoj oznaci koju je poslužitelj zaprimio od klijenta. Slijedeća slika prikazuje ovakvu komunikaciju.

Slika 2.4 Klijent zaprima jedan zapis iz imenika

Ukoliko klijent pretražuje imenik i pronađe višestruke podatke, ti podaci će biti poslani u više LDAP poruka, po principu svaka poruka za jedan podatak. Svaki podatak ima svoj jedinstven naziv poznatiji pod distinguished name(DN), koji je sadržan u LDAP poruci kako znakovni niz. Kraj poslanih razultantnih podataka sačinjava rezultantna poruka koja sadrži potpuni rezultantni kod, kako je prikazano na slici 2.5.

Slika 2.5 Klijent zaprima višestruke zapise iz imenika

Zbog toga što je LDAP protokol porukama – orijentirani protokol, također dozvoljava slanje višestrukih zahtjeva od strane klijenta prema poslužitelju. Na slijedećoj slici možete vidjeti komunikaciju između klijenta i poslužitelja gdje se uočava brže opsluživanje drugog zahtjeva u odnosu na prvi.

Slika 2.6 Klijent inicira više zahtjeva za pretragom

Dozvoljavanjem višestrukih zahtjeva za pretragom, LDAP se predstavlja kao fleksibilniji protokol u usporedbi s npr. HTTP protokolom (novi zahtjev se može obraditi tek po završetku prijašnjeg).

2.2.1 Operacije LDAP protokola

LDAP ima devet osnovnih operacija koje se mogu svrstati u tri skupine:

Ispitivajuće operacije: search, compare. Ove operacije omogućavaju izvršavanje upita nad imenikom.
Ažurirajuće operacije: add, delete, modify, modify DN(rename). Ove operacije dozvoljavaju ažuriranje informacija u imeniku.
Autentikacija i kontrolne operacije: bind, unbind, abandon. Bind operacija omogućava klijentima indetifikaciju nad imenikom; unbind omogućava zatvaranje veze s imenikom; abandon operacija omogućava obavijest kako klijent nije više zainteresiran za rezultate operacije koju je prethodno tražio.

S nekim od navedenih funkcija ćemo se detaljnije upoznati kasnije. Sada ćemo pogledati kako izgleda klasičan primjer komunikacije između klijenta i poslužitelja kroz nekoliko koraka:

Korak 1. Klijent otvara TCP vezu s LDAP poslužiteljem i podnosi bind (povezujuću) operaciju. Ova operacija uključuje ime imenika gdje se nalaze upisani korisnički podaci za uspješnu prijavu (slanje korisničkog imena i lozinke).
Korak 2. Nakon provjere poslanih podataka, poslužitelj vraća odgovor klijentu o (ne)uspješnoj autorizaciji.

· Korak 3. Klijent pošalje zahtjev za pretraživanjem (search operacija).

Korak 4 i 5. Poslužitelj opslužuje zahtjev klijenta, vraćajući dva rezultata.
Korak 6. Poslužitelj vraća rezultantnu poruku.

· Korak 7. Klijent pošalje zahtjev za prekidom veze (unbind operacija), koji govori poslužitelju da se klijent želi odspojiti.

Korak 8. Poslužitelj izvrši zahtjev za prekidom veze.

Slika 2.7 Prikat tipične LDAP komunikacije

2.2.2 Proširenje LDAP mogućnosti

LDAPv3, uz prethodno navedenih devet operacija, je dizajniran za omogućavanje dodatne tri metode:

LDAP proširene operacije. Ukoliko se pokaže potreba za novom operacijom, onda može biti definirana i proglašena standardom bez promjene jezgre LDAP protokola.
LDAP kontrole. Posebni dijelovi informacija koji omogućavaju trenutnu promjenu LDAP operacija za potrebe pretrage. Zgodno je korištenje ove metode za prilagodbu operacija radi boljeg dohvata i manipulacije podacima.
Jednostavna autentikacija i sigurnosni sloj (SASL). Okosnica koja podržava mnogostruke autentikacijske metode. Ako se u LDAP ugradi SASL okosnica, tada je za očekivati jače autentikacijske mehanizme. Također omogućava kriptiranu komunikaciju klijenta i poslužitelja na nižem sloju. SASL nije specifičnost LDAP protokola; svakako moguće ga je, ali nešto teže, ugraditi u ostale mrežne protokole.

2.3 LDAP modeli

LDAP definira četiri osnovna modela koja u potpunosti opisuju kako rade, koji podaci mogu biti pohranjeni i što se može načiniti s podacima.

2.3.1 LDAP informacijski model

LDAP informacijski model definira tipove podataka i osnovne jedinice informacija koji se mogu spremiti unutar imenika. Dakle, ovaj model opisuje konstruktivne elemente koji se mogu koristiti prilikom kreiranja imenika.

2.3.1.1 Entiteti, atributi i vrijednosti

Osnovna jedinica informacije u imeniku je zapis, koji je skup informacija o nekom objektu. Najčešće informacije iz zapisa određuju relani objekt poput osobe, što model sam po sebi ne zahtjeva. Tipični imenici sadrže na tisuće zapisa o relanim objektima poput osobe, odjela, poslužitelja, pisača i bilo kojih drugih relanih objekata organiziranih u imeniku. Slika 2.8 prikazuje dio tipičnog imenika:

dc=fer, dc=hr

ou=uređaji

ou=djelatnici

ou=zpm

ou=zemris

uid=vmornar

Slika 2.8 Tipičan prikaz imeničke strukture

Svaki imenički zapis ima svoj jedinstven naziv (eng. distinguished name), DN, koji je u prethodnom slučaju oblika dc=fer, dc=hr. O DN-ovima ćemo raspravljati nešto kasnije. Zapis je sadržan od nekoliko atributa; svaki opisuje pojedinu osobinu objekta. Svaki atribut ima svoj određeni tip te jednostruku ili višestruku vrijednost. U slijedećoj tablici moguće je vidjeti od kakvih se sve atributa (puno ime i prezime, prezime, telefonskog broja i e-mail adrese) sastoji objekt osoba:

Tip atributa	Vrijednost atributa
cn:	Vedran Mornar
sn:	Mornar
telephoneNumber:	+385 1 6129 917
mail:	vedran.mornar@fer.hr

Tablica 1. Prikaz atributa za objekt osoba

Tipovi atributa imaju pridruženu sintaksu i skup usklađenih pravila. Sintaksa atributa određuje vrstu tipa podataka, npr. cijeli brojevi (integer) koji mogu sadržavati samo znamenke, dok usklađena pravila definiraju slijedeće stvari:

Pravila za usporedbu vrijednosti za jednakost. Za primjer, caseIgnoreMatch pravilo govori kako nije bitno da li su slova velika ili mala prilikom pretrage ili promjene vrijednosti atributa.
Pravila za sortiranje vrijednosti. Za primjer, caseIgnoreMatch pravilo označava da će vrijednosti biti poredane leksikografski, dok kod integerMatch pravila, vrijednosti će biti poredane prema numeričkim vrijednostima.

Atributi su općenito svrstani u dvije grupe: korisničke i operativne. Korisnički atributi, „normalni“ atributi u zapisu, mogu biti ažurirani od strane korisnika (ukoliko za to ima dozvolu). Operativni atributi su specijalni atributi koji ili prilagođuju operacije imeničkog poslužitelja ili utječu na operativni status imenika.

Atributne vrijednosti također mogu imati ograničenja. Neki poslužiteljski softveri mogu dozvoliti definiranje atributa jednoznačnom ili višeznačnom vrijednošću. Na primjer, givenName atribut je tipično višeznačni atribut jer omogućava unos više imena za primjerice tip osoba (Antonio, Ante, Toni). S druge strane, postoji potreba strogo odrediti jednoznačnu vrijednost kod tipa osoba, npr. JMBG broj. Određivanjem veličine atributa, administrator omogućava uštedu memorijskog prostora svog poslužitelja na kojem će biti pohranjene informacije.

2.3.1.2 Čuvanje dosljednosti: Imeničke scheme

Bilo koji zapis u imeniku ima skup obveznih i skup mogućih tipova atributa. Na primjer, zapis osoba zahtjeva unos cn (common name, puno ime i prezime) atributa i sn (surname, prezime) atributa. Mogući atribut može biti mail (e-mail) atribut, ali on nije bitan. Bilo koji atributni tip koji nije specijalno dozvoljen iz zahtjevan je zabranjen. Skup svih informacija o dozvoljenim i zahtjevanim atributima se naziva imenička schema.

Bitno je naglasiti kako imeničke scheme nemaju nikakav utjecaj na uređenje zapisa u LDAP imeničkom stablu. Ovo može čudno zvučati, pogotovo osobama koje su upoznate s pravilima relacijskih baza podataka, gdje schema određuje sve detalje sadržaja baze. LDAP schema je jednostavno konceptualni opis zapisa te stoga određuje samo vrste podataka koje će se pojaviti u zapisu.

Da ukratko ponovimo. LDAP informacijski model opisuje zapise koji su osnovni gradivni elementi vašeg imenika. Zapisi su sastavljeni od atributa koji su sastavljeni od tipova koji mogu biti jednoznačni ili višeznačni. Atributi mogu imati ograničenja u vidu duljine i tipa podatka za atributnu vrijednost. Imeničke scheme sadrže restrikcije nad atributnim tipovima koji moraju, a koji su dozvoljeni, biti dio zapisa.

2.3.2 LDAP nazivni model

LDAP nazivni model definira kako organizirati i kako pristupiti podacima. Nakon uređenja zapisa u logičku strukturu, nazivni model također definira kako pristupiti specifičnom imeničkom zapisu unutar strukture. Postignuta fleksibilnost od strane LDAP nazivnog modela, dozvoljava čak i razmještaj podataka u imeniku na najbolji način za upravljanje istim. Na primjer, možete urediti imenik na način da kreirate jedan spremnik koji čuva sve zapise koji opisuju osobe u vašoj organizaciji i drugi, posebni, koji čuva zapise o mrežno dostupnim pisačima. S druge strane, moguće je urediti imenik koji je posebno organiziran prema geografskom smještaju ureda neke organizacije.

LDAP nazivni model određuje kako bi zapisi trebali biti organizirani u obliku obrnutog stabla, u obliku hijerarhijskog ustroja. Sličnost organizacije podataka kod LDAPa će ljubitelji Unix operacijskog sustava vrlo brzo prepoznati jer se radi o sličnom ustroju, kako je prikazano i na slijedećoj slici:

Slika 2.9 Prikaz hijerarhijske strukture LDAP imenika i organizacije direktorija kod Unix operacijskog sustava

Postoje bitne razlike između podatkovne organizacije Unix operacijskog sustava i LDAP podatkovne strukture. Prva bitna razlika je u tome što LDAP model ne posjeduje egzaktni vrhovni korijen(root). Kod Unixa, postoji vrhovni korijen koji je zajednički za sve dokumente i mape u sustavu. Kod LDAPa, vrhovni korijen sadrži konfiguracijske informacije o imeničkom poslužitelju. Stoga se ne koristi za pohranu informacija.

Druga razlika je kod LDAP imenika, gdje vaki čvor sadrži podatke i može biti spremnik, što znači da svaki LDAP čvor može imati dijete koje sadrži informacije pod sobom. Kod Unixa, čvor je ili dokument ili mapa, ali ne može biti oboje istodobno. Također, ovdje mape mogu imati djecu, ali samo dokumenti mogu sadržavati podatke.

Iako LDAP podržava hijerarhijsku organizaciju podataka, on ne uvjetuje niti jednu vrstu organizacije. Naime, svatko je slobodan kreirati svoju organizaciju na način kako mu to najviše odgovara. Naravno, za neke određene organizacijske strukture, dobro je poslužiti se savjetima prilikom dizajniranja strukture.

2.3.2.1 Zašto je nazivanje bitno?

Nazivni model je potreban kako bi mogli odrediti jedinstven naziv bilo kojem zapisu u imeniku. Kod LDAPa, jedinstvena imena (prethodno spomenuto kao DN) su oni koji određuju pristup zapisima.

Kao kod putanja za Unix operacijski sustav, kreira se i putanja za dolazak do zapisa u LDAP imeniku spajanjem dijelova imena sa svakog nivoa čvora od kraja do vrhovnog čvora. Gledajući sliku 2.8, putanja do osobe vmornar je slijedeća:

uid=vmornar, ou=zpm, ou=djelatnici, dc=fer, dc=hr

Čitajući putanje s lijeva na desno, može se pročitati putanja od podatkovnog čvora do vrhovnog čvora imeničkog stabla. Svaki naziv čvora je odvojen zarezom te nije bitno da li postoje praznine između navođenja svakog čvora do vrhovnoga.

Kod DN-a nekog zapisa, najljevija komponenta se zove relativno jedinstveno ime ili RDN (engl. relative distinguished name). Svaki RDN, koji se nalazi pod istim roditeljem, bi morao biti jedinstven jer omogućava da ne postoje dva zapisa koja bi imala jedinstven DN. Ukoliko bi se pokušao unijeti drugi zapis s istim DN-om, imenik bi odbio upisivanje što je slično kao i kod Unix, tako i kod Windows operacijskog sustava koji ne dozvoljavaju kreiranje dva ista dokumenta na istom mjestu ili dvije iste mape na istom mjestu.

RDNovi moraju biti jedinstveni samo ukoliko se nalaze pod istim čvorom roditeljem. Ukoliko postoje dva ista RDNa, ali pod različitim granama roditelja, tada LDAP dozvoljava takav unos, kao je prikazano na slijedećoj slici:

Slika 2.10 Prikaz dva ista RDNa pod različitim roditeljima

Svakako je bitno naglasiti da postoji lista specijalnih znakova koje je potrebno izbjegavati prilikom unosa podataka jer mogu narušiti strukturu unesenih podataka. Lista je slijedeća : „ „(praznina), #, ','(zarez), +, „(navodnici), \, <, >, ;(točka – zarez)

2.3.3 LDAP funkcionalni model

LDAP funkcionalni model opisuje operacije koje se mogu izvršiti nad imenikom koristeći LDAP protokol. Ovaj model je sadržan od skupa operacija podijeljenih u tri grupe koje smo već spominjali, a sada ćemo ih još jednom navesti. Ispitivajuće operacije vrše pretragu imenika za primanje povratnih informacija. Ažurirajuće operacije dozvoljavaju dodavanje, brisanje te promjenu imeničkih zapisa. Autentikacijske i kontrolne operacije dozvoljavaju klijentima vlastitu identifikaciju nad imenikom i kontrolu nekih aspekata veze.

2.3.3.1 LDAP ispitivajuće operacije

LDAP ispitivajuće operacije omogućavaju klijentima pretragu imenika i zaprimanja informacija iz imenika. Pretraga omogućava klijentu pronalazak informacije unutar imenika, dok uspoređivanje omogućuje klijentu pronalazak određene informacije prema zadanom upitu.

LDAP operacija: Pretraga

Ova operacija služi za pretragu zapisa u imeniku i zaprimanju odgovora od imenika. Ne postoji operacija za čitanje LDAP imenika, već kad se želi pročitati nekakav zapis, potrebno je iskoristiti formu pretrage kako bi dobili ciljani zapis. LDAP pretražujuća operacija zahtjeva osam parametara:

Osnovni objekt za pretragu. Ovdje se misli na navođenje DNa kao vrha stabla koje će se pretraživati
Opseg pretrage. Ovaj parametar određuje opseg pretrage, kojih ima tri. Sub označava pretragu cijelog stabla od zadanog osnovnog objekta za pretragu pa sve do dna stabla. Opseg onelevel označava pretragu samo jednog nivoa i to djece od zadane pretraživajuće baze. Opseg base označava ograničavanje pretrage na sami navedeni objekt; koristi se za dobivanje točno jednog ciljanog rezultata. Slijedeća slika prikazuje vrste opsega pretrage:

Text Box: search base = „ou=zavodi, dc=fer, dc=hr“
search scope = base

Text Box: search base = „ou=zavodi, dc=fer, dc=hr“
search scope = onelevel

Text Box: search base = „ou=zavodi, dc=fer, dc=hr“
search scope = sub

Slika 2.11 Prikazi tri vrste opsega pretrage

3. Upućivanje na aliase. Treći parametar označava da li u pretrazi uključiti i pretragu aliasa. Naime, postoji mogućonst kreiranja aliasa koji upućuju na podatak na nekom drugom mjestu unutar strukture podataka, no on nije spominjan jer se preporučava njegovo izbjegavanje, stoga ćemo razmatranje o aliasima preskočiti.

4. Ograničenje veličine. Ovaj parametar javlja poslužitelju koliko je klijent spreman prihvatiti rezultirajućih parametara. Ukoliko se pređe zadana granica, poslužitelj će uz rezultate javiti poruku LDAP_SIZELIMIT_EXCEEDED. Veličina 0 označava da je klijent zainteresiran prihvatiti sve rezultate pretrage.

5. Ograničenje vremena. Ovaj parametar označava koliko poslužitelj može maksimalno potrošiti vremena na posluživanje jednog upita. Ukoliko se vremenska kvota premaši, pretraga se prekine te se klijentu vrati poruka LDAP_TIMELIMIT_EXCEEDED. Ukoliko je ovaj parametar postavljen na 0, ograničenja nema.

6. Isključivo atributi parametar. Šesti parametar, attrsOnly, je Boolean parametar. Ako je postavljen na true, poslužitelj će poslati kao odgovor samo atributne tipove, bez njihovih vrijednosti. Ovaj parametar postoji ukoliko klijent želi saznati od kojih tipova se sastoji zapis bez saznanja vrijednosti atributa.

7. Filter pretrage. Ovaj filter označava izraze koji opisuju tip zapisa koji želimo dobiti kao povratnu informaciju. Ovi filteri su poprilično fleksibilni, a o njima ćemo raspravljati u sljedećem odjeljku.

8. Lista povratnih atributa. Ovaj zadnji parametar određuje kakvu listu povratnih atributa želi klijent zaprimiti. Slijedeća tablica prikazuje neke od najznačajnijih parametara za listu povrata atributa:

Naredba za atributnu listu	Povratna atributna lista
cn, sn, givenName	cn, sn, givenName
*	svi korisnički atributi
1.1	bez povrata atributa
modifiersName	podatak o izvršitelju promjena
*, modifiersName	svi atributi + podaci o izvršitelju promjena

Tablica 2. Prikaz liste povratnih atributa

LDAP filteri pretrage

LDAP filteri su Booleove kombinacije atribut – vrijednost tvrdnji. Ovakve tvrdnje su sastavljene od dva dijela: atributnog imena i vrijednosne tvrdnje (neke pretpostavljene ili bilo koje zamjenske). Slijedeća tablica prikazuje skup filtera za pretragu.

Tip filtera	Format	Primjer	Pojašnjenje
Jednakost	(attr=value)	(sn=mornar)	Prezimena jednaka mornar
Podniz	(attr=[leadnig]* [any]*[trailing])	(sn=mornar)	Prezimena sadrže podniz mornar
		(sn=mornar*)	Prezimena započinju s podnizom mornar
		(sn=*mornar)	Prezimena završavaju s podnizom mornar
		(sn=morar)	Prezimena započinju s mo, sadrže r i završavaju na ar
Približno	(attr~=value)	(sn~=morner)	Prezimena slična s morner će biti dio rezultata
Veći ili jednak	(attr>=value)	(sn>=mornar)	Prezimena leksikografski veća od mornar
Manji ili jednak	(attr<=value)	(sn<=mornar)	Prezimena leksikografski manja od mornar
Postojanje	(attr=*)	(sn=*)	Sva prezimena
AND	(&(filter1) (filter2)...)	(&(sn=mornar) (objectclass=person))	Prezimena jednaka mornar i iz klase person
OR	(\|(filter1) (filter2)...)	(\|(sn~=mornar)( sn=*mornar))	Zapisi čija su prezimena slična prezimenu mornar ili prezime završava na mornar
NOT	(!(filter))	(!(mail=*))	Svi zapisi bez mail atributa

Tablica 3. Prikaz filtera za LDAP pretragu

Iako LDAP ima fleksibilne filtere za pretragu, neki tipovi pretraga će se češće koristiti u odnosu na druge:

Dohvat jednostrukog zapisa. Za dohvata jednog zapisa, koristite opseg base, baza pretrage postavljena na DN od zapisa koji se želi dohvatiti, i filter (objectclass=*). Na ovaj način postavljena pretraga će rezultirati čitanjem određenog zapisa.
Ispisivanje svih zapisa ispod zadanog zapisa. Za ispisivanje zapisa s određenog nivoa unutar stabla, koristite isti filter (objectclass=*), ali za opseg pretrage koristite izraz onelevel, te bazni zapis postaviti na DN onog zapisa koji je roditelj nivou kojeg se želi dohvatiti. Svi zapisi na nivou ispod zadanog baznog zapisa će biti vraćeni kao rezultat, ali bez baznoga.
Pretraživanje podudaraćujćeg zapisa u podstablu. Još jedno fleksibilno pretraživanje unutar podstabla neke imeničke strukture prema zadanim podudarajućim kriterijima. Za izvođenje ove operacije, potrebno je postaviti filter prema željama pretrage, s opsegom sub i s baznim zapisom kao DN koji će biti vrh podstabla koji se pretražuje.

LDAP operacija: Usporedba

Druga od ispitivajućih operacija, operacija usporedbe, se koristi prilikom provjere da li određeni zapis posjeduje određenu atributnu vrijednost. Klijent pošalje zahtjev za usporedbu poslužitelju, s DN zapisom, nazivom atributa te vrijednošću. Poslužitelj odgovara afirmativno ili negativno ovisno o rezultatu usporedbe.

Možda se nekima čini smiješnim pored operacije pretrage održavati operaciju usporedbe, no ona ima prikriveni, dublji smisao. Naime, zbog toga što je LDAP izrastao iz X.500, naslijedio je razliku koja postoji između pretrage i usporedbe. Na primjer, ukoliko se poslužitelju pošalje zahtjev za usporedbu nad atributom koji ne postoji u zapisu, poslužitelj će odgovoriti klijentu kako navedeni atribut ne postoji. S druge strane, kada bi poslali zahtjev za pretragom, poslužitelj neće klijentu odgovoriti kako atribut ne postoji već će vratiti kao rezultat prazno polje bez ikakve dodatne naznake klijentu.

2.3.3.2 LDAP ažurirajuće operacije

LDAP posjeduje četiri ažurirajuće operacije: add, delete, rename(modify DN) i modify. Ove naredbe definiraju načine za manipulacijom podacima u vašem imeniku.

Operacija : dodaj (add)

Ova operacija vam omogućava unos novih zapisa u imenik. Ima dva parametra: DN zapisa koji će biti unesen i skup atributa i njihovih vrijednosti novoga zapisa. Za uspješno izvršenje ove naredbe, moraju biti ispunjena četiri kriterija:

Roditelj novoga zapisa mora postojati u imeniku
Ne smije postojati u bazi isti zapis
Novi zapis se mora prilagoditi postojećoj schemi
Dozvole pristupa moraju dozvoliti unos zapisa

Kada su ispunjeni svi ovi kriteriji, bit će dodan novi zapis u imenik.

Operacija : izbriši (delete)

Izbriši operacija odstranjuje zapis iz imenika. Potreban je samo jedan parametar : DN zapisa koji se želi obrisati. Tri su uvjeta koja se moraju ispuniti kako bi zapis bio izbrisan:

Zapis koji se briše mora postojati
Zapis koji se briše ne smije imati djecu
Dozvole pristupa moraju dozvoliti brisanje zapisa

Operacija : Preimenovanje (DN promjena)

Ova operacija služi preimenovanju i/ili premještanju zapisa unutar imenika. Ima četiri parametra: DN zapisa koji će biti preimenovan, novi RDN za zapis, neobvezni argument o novom roditelju zapisa te izbriši – stari RDN zastavica. Kako bi ova operacija bila uspješno izvedena, moraju biti ispunjeni slijedeći uvjeti:

Mora postojati zapis koji će se preimenovati
Novo ime zapisa ne smije već postojati u imeniku
Dozvole pristupa moraju dozvoliti izvršavanje operacije preimenovanja

Text Box: Stari DN: uid=vmornar, ou=zpm, dc=fer, dc=hr
Novi DN: uid=vedranm, ou=zpm, dc=fer, dc=hr

Text Box: Stari DN: uid=vmornar, ou=zpm, dc=fer, dc=hr
Novi DN: uid=vmornar, ou=zemris, dc=fer, dc=hr

Text Box: Stari DN: uid=vmornar, ou=zpm, dc=fer, dc=hr
Novi DN: uid=vedranm, ou=zemris, dc=fer, dc=hr

Slika 2.12 Slikovni prikaz operacije preimenovanja

Operacija : Promjena

Ova operacija omogućava izmjenu podataka u postojećem zapisu. Sadržana je od dva parametra: DN zapisa nad kojim će biti izvršena promjena te skup promjena koji se trebaju zapisati. Ovaj skup promjena može sadržavati nove atributne vrijednosti, može tražiti brisanje doznačenih atributa ili njihovu promjenu vrijednosti. Ova operacija može tražiti promjenu na bilo koliko atributa koliko postoji unutar zapisa. Dva su uvjeta za uspješno obavljane promjena:

Zapis nad kojim se vrši promjena mora postojati
Kako bi operacija bila uspješno izvedena, sve izmjene nad atributima moraju biti uspješno izvedene

Bitno je naglasiti kako ova operacija zahtjeva uspješnu izmjenu svih željenih atributa. Ukoliko propadne izmjena nad jednim atributom, a na ostalima bude promjena izvršena, promjena se neće prihvatiti već će efekti biti poništeni. Ovo sprječava nekonzistentnost podataka prilikom izvršenja izmjene koje bi se mogle pojaviti.

2.3.3.3 LDAP autentikacijske i kontrolne operacije

LDAP ima dvije autentikacijske operacije (bind, unbind), te kontrolnu operaciju (abandon).

Operacija: Spajanje(bind)

Uz pomoć DNa i skupa vjerodajnica, klijent može koristiti opciju spajanje za autentikaciju na imenikom. Poslužitelj provjerava klijentove vjerodajnice za dani DN te, ukoliko su ispravni, obavještava klijenta o uspješnoj autentikaciji dok god je veza otvorena ili do slijedeće reautentikacije. Na temelju klijentovog identiteta, poslužitelj može postavljati ograničenja u radu klijentu. Postoji nekoliko tipova spajajućih metoda. Kod jednostavnog spajanja, klijent se predstavlja s DNom i lozinkom prema LDAP poslužitelju. Poslužitelj provjerava lozinku s vrijednosti polja userPassword zapisa i ukoliko je ispravno, vraća poruku o uspješnom prijavljivanju.

Jednostavno spajanje vrši komunikaciju preko nesigurnog kanala koju šalje nezaštićenu. No, lozinka se može zaštititi od mogućih presretača uz pomoć enkripcije veze koristeći sigurnosnu SSL ili TLS vezu, o čemu će biti riječi nešto kasnije.

LDAPv3 također uključuje nove tipove operacije spajanja : SASL spoj. SASL je proširujući, neovisan protokol za izvođenje autentikacije sa sigurnosnim parametrima. Uz pomoć SASL-a, klijent odabire tip autentikacijskog protokola kojeg želi koristiti. Ukoliko poslužitelj podržava odabrani sigurnosni protokol, bit će izvršena sigurnosna komunikacija.

Ugradnja SASL-a u LDAPv3 omogućuje implementaciju novih antentikacijskih metoda, poput pametnih kartica ili biometrička autentikacija.

Operacija: Odspajanje (unbind)

Druga autentikacijska operacija je odspajanje koja nema parametara. Kada klijent pokrene operaciju, poslužitelj odbacuje sve aktivne operacije koje se izvršavaju na LDAPom, prekida vezu s klijentom te zatvara TCP konekciju.

Iako je dobra praksa poslužitelja čekati na zatvaranje veze inicirane od strane klijenta, poslužitelji posjeduju mehanizme za zatvaranje veze ukoliko veza propadne bez iniciranja od strane klijenta.

Operacija : Prekid(abandon)

Operacija prekida ima jedan parametar : ID zahtjeva za obavljanje LDAP operacije. Klijent inicira operaciju za prekid kada nije više zainteresiran za daljnje obavljane tekuće operacije koju je zadao. No, dok se prihvati prekidanje operacije, klijent mora biti spreman prihvatiti rezultate koji pristignu u međuvremenu.

2.3.4 LDAP sigurnosni model

Svrha ovog modela je zaštita informacija od nedozvoljenih upada na imenik. Ovaj model se oslanja na činjenici da je LDAP vezom – orijentirani protokol. Drugim riječima, LDAP klijent otvara vezu prema LDAP poslužitelju i izvršava različite operacije nad imenikom. Zbog pristupa zaštićenim podacima, moguće je tokom trajanja veze, zaprimiti od poslužitelja zahtjev za autentikacijom. Na primjer, klijent se želi autenticirati nad imeničkim poslužiteljem s svojim identitetom koji ima dozvolu čitanja/pisanja podataka.

No, što je to autentikacija? S klijentove perspektive, to je proces prijave s vlastitim identitetom radi odobravanja korištenja pridodjeljenih dozvola. S poslužiteljeve perspektive, to je proces prihvaćanja identiteta, provjere ispravnosti podataka, te dodjeljivanja prava rada klijentu.

Prethodno je već objašnjen proces autentikacije kod otvaranja veze između klijenta i poslužitelja kao primjer jednostavne autentikacije. Takav proces prijave na imenik se zove vezivanje. Identitet je vezan uz vezu (konekciju) kada operacija spajanja uspije proći autentikaciju.

2.3.4.1 LDAPv3 autentikacijska metoda

Prilikom kreiranja LDAPv3, prihvaćena je ugradnja SASL koji omogućava standardni put za višestruke autentikacijske metode. Zbog jednostavne autentikacijske metode ugrađene u LDAPv2 standard, nastao je problem mogućeg presretanja lozinki i potencijalnog ugrožavanja rada sustava. Za rješenje ovog problema, pobrinula se LDAP Razvojna Grupa prilikom izgradnje nove generacije LDAPa. Rješenje problema je ponuđeno u vidu RFC 2829, Authentication Methods for LDAP. U tom rješenju, poslužitelji su podijeljeni u tri cjeline:

Javni imenički poslužitelji za čitanje podataka bez autentikacije
Poslužitelji koji podržavaju autentikaciju lozinkama. Podržavaju DIGEST-MD5 SASL mehanizam koji je objavljen u RFC 2831, Using Digest Authentification as a SASL Mechanism
Poslužitelji koji zahtijevaju sigurnosnu zaštitu komunikacijskog kanala koji moraju imati ugrađen StartTLS operacije definirane u RFC 2830, Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security. Ove dodatne operacije omogućavaju enkripciju putujućih podataka između LDAP klijenta i poslužitelja.

2.3.4.2 Sigurnost transportnog sloja (TLS)

TLS je sigurnosna tehnologija koja podržava privatnost, integritet podataka i enkripciju za mrežne protokole poput TCP. Klijent koji koristi TLS za komunikaciju s poslužiteljem:

može se pouzdati da je komunikacija sigurna
može se pouzdati da se nitko ne može uplesti
može se autenticirati na poslužitelj koristeći certifikat javnog ključa
može se uvjeriti da komunicira isključivo s pravim poslužiteljem provjeravajući njegov javni ključ

TLS kao takav dozvoljava klijentu otvaranje veze bez enkripcije s uspostavljanjem sigurnosnog kanala nakon što je veza otvorena. Ovo potvrđuje kako LDAP poslužitelj koji podržava TLS, dozvoljava oba tipa klijenata (sigurna i nesigurna) na istom TCP portu.

StartTLS proširena operacija definirana u RFC 2830, Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security, govori o pokretanju postojeće LDAP veze između klijenta i poslužitelja pod TLSom. Nakon što klijent pokrene TLS, može se povezati koristeći SASL EXTERNAL mehanizam. Najprije se otvara TCP veza na poslužitelj, zatim se šalje StartTLS proširena operacija. Tada protokoli na nižim slojevima „dogovaraju“ enkripciju i autentikaciju prema TLS specifikacijama. Izvršavanje vezivanja korištenjem SASL EXTERNAL mehanizma ukoliko je certifikat odobren prilikom TLS pregovaranja. Nakon složenog procesa povezivanja, klijent ima osiguranu sigurnu vezu na imenik.

2.4 LDIF

LDAP Data Interchange Format (LDAP format za izmjenu podataka) je standardni tekstualni format za opisivanje imeničkih zapisa definiran u RFC 2849. LDIF koristi za unos podataka iz imenika u nju te upis u podataka iz nje u imenik. Također, zbog standardiziranosti, moguće je prenijeti podatke s jednog poslužitelja na drugi zbog jednostavnosti i fleksibilnosti formata.

Postoje dvije vrste LDIF datoteka. Prvi tip datoteke opisuje skup imeničkih zapisa, poput cijele organizacije (tvrtke, instituta,...) ili samo poddio istih. Drugi tip LDIF datoteke je niz ažurirajućih LDIF zapisa koji opisuju promjenu podatka nad imeničkim zapisima. Idemo se detaljnije upoznati sa svakim pojedinačno.

2.4.1 LDIF opis imeničkih zapisa

version: 1

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

cn: Vedran Mornar

cn: Vex Mornar

givenName: Vex

sn: Mornar

uid: vmornar

mail: vex@zpm.fer.hr

telephoneNumber: +385 1 6129 917

description: Prodekan za nastavu, prof.dr.sc.

dn: uid=mbaranovic, ou=zpm, dc=fer, dc=hr

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

cn: Mirta Branovic

givenName: Mirta

sn: Baranovic

uid: mbaranovic

mail: mirta@zpm.fer.hr

telephoneNumber: +385 1 6129 916

description: prof.dr.sc.

Svaki zasebni zapis ispisan u LDIF formatu sastoji se od dva dijela: od DNa i od liste atributa i njegovih vrijednosti. DN, koji mora biti naveden u prvoj liniji, je sadržan od niza „dn:“ te jedinstvenog imena zapisa. Nakon DNa, navedeni su atributi i to prvo po imenu atributa, potom dvotočju(:) te vrijednosti atributa. Atributi mogu biti navedeni bez ikakvog pravila, ali gledajući prethodni primjer, dobro je držati se navedene forme.

2.4.2 LDIF s ažurirajućom listom

Drugi tip LDIF datoteke opisuje skup izmjena koje se trebaju izvršiti nad jednim ili više imeničkih zapisa. Svaki LDIF ažurirajući zapis sadrži DN zapisa nad kojim se vrši izmjena, tipom izmjene te skupom vrijednosti. Postoje četiri izmjene nad LDAP imenikom. Ove četiri izmjene odgovaraju upravo tipovima izmjena kod LDAP protokola : dodavanje novog zapisa, brisanje postojećeg, promjena postojećeg, preimenovanje postojećeg.

2.4.2.1 Dodavanje novog zapisa

Add changetype naredba vrši unos zapisa iz LDIF datoteke u LDAP imenik. Sintaksa naredbe je slijedeća:

dn: dn zapisa koji se unosi

changetype: add

tip atributa: vrijednost

...

Primjer unosa jednog zapisa:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: add

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

cn: Vedran Mornar

cn: Vex Mornar

givenName: Vex

sn: Mornar

uid: vmornar

mail: vex@zpm.fer.hr

telephoneNumber: +385 1 6129 917

2.4.2.2 Brisanje zapisa

Delete changetype naredba inicira brisanje zapisa iz imenika. Sintaksa naredbe je slijedeća:

dn: dn zapisa koji se briše

changetype: delete

...

Primjer brisanja zapisa iz LDAP imenika:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: delete

2.4.2.3 Promjena podataka zapisu

Modify changetype naredba omogućuje promjenu nad postojećim zapisom u imeniku. Također dozvoljava dodavanje novih atributnih vrijednosti, brisanje istih, brisanje atributa ili zamjena svih atributnih vrijednosti drugim vrijednostima. Sintaksa naredbe je slijedeća:

dn: dn zapisa nad kojim se vrši promjena

changetype: modify

modifytype: atribut

tip atributa: vrijednost

...

Primijetite kako ovdje postoji dodatni operator: modifytype. Ovaj operator može biti add, delete ili replace.

Primjer dodavanja nove atributne vrijednosti. Ukoliko atributna vrijednost postoji, dodavanje neće prebrisati unesenu vrijednost.

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: modify

add: telephoneNumber

telephoneNumber: +385 1 6129 920

telephoneNumber: +385 1 6129 921

Brisanje sadržaja iz imenika (prethodno unesenog jednog telefonskog broja) će biti izvršeno na slijedeći način:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: modify

delete: telephoneNumber

telephoneNumber: +385 1 6129 920

Kako bi u potpunosti uklonili atribut iz zapisa, potrebno je koristiti prethodno navedenu sintaksu, ali se ne navodi niti jedan specifični telefonski broj, odnosno ne navodi se nikakva atributna vrijednost:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: modify

delete: telephoneNumber

Za ažuriranje vrijednosti atributa, odnosno izmjenu postojeće i upis nove vrijednosti, potrebno je koristiti replace modifytype naredbu. U slijedećem primjeru bilo koji pronađeni telefonski broj u zapisu se mijenja s dva navedena:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: modify

replace: telephoneNumber

telephoneNumber: +385 1 6129 920

telephoneNumber: +385 1 6129 921

Moguće je u LDIF datoteku unijeti višestruke promjene nad zapisom, ali svaka od njih mora biti odvojena znakom „-“(minus), kako je prikazano na slijedećoj slici:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: modify

add: mail

mail: vex@zpm.fer.hr

-

delete: telephoneNumber

telephoneNumber: +385 1 6129 920

-

delete: description

-

Preimenovanje i/ili premještanje zapisa

moddn changetype naredba označava da će postojeći zapis biti promijenjen ili opcionalno premješten na novu lokaciju u imeničnom stablu. Sintaksa ove naredbe je slijedeća:

dn: dn zapisa nad kojim se vrši preimenovanje

changetype: moddn

[noviroditelj: dn novog roditelja]

[deleteoldrdn: ( 0 | 1 )]

[newrdn: novi rdn za zapis]

Primjer promjene naziva zapisu bez premještanja na novu lokaciju unutar imenika će se koristiti slijedeći odsječak LDIF datoteke:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: moddn

newrdn: uid=vedranm

deleteoldrdn: 1

Nakon što se izvrši izmjena pokretanjem LDIF datoteke, zapis će sad izgledati ovako:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

[ostali atributi koji se nisu mijenjali]

uid: vedranm

Da je zastavica deletooldrdn bila postavljena u 0, u zapisu bi se našla i stara uid vrijednost.

Za premještaj zapisa na novu lokaciju u stablu, koristi se newsuperior parametar za određivanje DNa zapisa ispod kojeg će se premješteni zapis. Izgled ovakve promjene prikazana je na slijedeći način:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: moddn

newsuperior: ou=zemris, dc=fer, dc=hr

2.5 LDAP komandne naredbe

Za zadnju temu vezano uz LDAP se razmatra izvršavanje naredbi direktno nad open – source verzijama LDAP implementacija koje uspješno zamjenjuju ručno izvršavanje LDIF datoteka nad imenikom što ponekad zna biti teži dio puta za pronalazak informacija.

2.5.1 ldapsearch komanda naredba

ldapsearch komandna naredba omogućava pretragu imenika. U samoj naredbi postoji veliki broj dodatnih opcija (s kojima ćemo se detaljnije upoznati), a jedna takva naredba izgleda na slijedeći način:

ldapsearch –h ldap.fer.hr –s sub –b „dc=fer, dc=hr“ „(sn=Vedran Mornar)“

Što ona znači? U ovom primjeru poslan je LDAP zahtjev za pretragu imeničkog servisa na poslužitelju ldap.fer.hr. Opseg pretrage je postavljen značkom –s sub, s bazom pretrage dc=fer, dc=hr. Filter za pretraživanje je postavljen na (sn=Vedran Mornar), kojim želimo u stablu pronaći sve zapise čije je ime i prezime (cn) postavljeno na „Vedran Mornar“. Pronađen je jedan takav zapis te je vraćen rezultat:

version: 1

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

cn: Vedran Mornar

cn: Vex Mornar

sn: Mornar

givenName: Vedran

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

ou: zpm

uid: vmornar

Moguće je bilo zaprimiti u ovom slučaju i više zapisa čiji je (sn=Vedran Mornar). Za zaprimanje samo određenog i to jednog zapisa, poželjno je pretragu postaviti na slijedeći način:

ldapsearch –h ldap.fer.hr –s sub –b „uid=vmornar, ou=zpm, dc=fer, dc=hr“ „(sn=Vedran Mornar)“

U prethodna dva primjera nije bila izvršena nikakva provjera autentikacije za pristup podacima. To je bio primjer anonimne veze. Mnogi imenici su dizajnirani tako da anonimnom pristupu dozvoli čitanje određenih informacija (ali ne svih). Sigurnosnim pristupom, možemo doći, prema pravilima pristupa, do cjelovitih informacija o nekom zapisu. Kako bi ostvarili sigurnosnu vezu, poželjno je kao parametre u naredbi ldapsearch dodati značke –D bind dn te –w bind lozinka. Primjetite kako se povećao broj informacija prilikom ostvarivanja sigurnosne veze:

ldapsearch –h ldap.fer.hr –D „uid=vmornar, ou=zpm, dc=fer, dc=hr“ –w lozinka –s sub –b „dc=fer, dc=hr“ „(sn=Vedran Mornar)“

version: 1

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

cn: Vedran Mornar

cn: Vex Mornar

sn: Mornar

givenName: Vedran

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

ou: zpm

uid: vmornar

mail: vedran@zpm.fer.hr

telephoneNumber: +385 1 6129 917

roomNumber: D366

Primjetna je razlika povodom utjecaja prijave na LDAP poslužitelj s DN i lozinkom radi povlaštenog pristupa informacijama.

No, što ukoliko želimo vidjeti samo određene informacije? LDAP pretraga, prema postavkama, vraća određeni skup informacija, te ga mi u pretrazi možemo i smanjiti. Specificiranjem imena atributa u naredbi za pretragu utječemo na rezultat kojim ćemo dobiti samo tražene informacije. Pogledajmo kako:

ldapsearch –h ldap.fer.hr –s sub –b „dc=fer, dc=hr“ „(sn=Vedran Mornar)“ mail roomNumber

version: 1

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

mail: vedran@zpm.fer.hr

roomNumber: D366

Pogledajmo kratki pregled nekih znački(parametara) u ldapsearch naredbi:

Parametar	Opis
-n	prikazuje opis što bi se dogodilo, bez izričitog slanja zahtjeva za pretragu poslužitelju
-v	prikazuje opširan dijagnostički izlaz
-h host	spajanje na LDAP poslužitelj koji se nalazi na host. Inicijalno postavljeni je localhost
-p port	spajanje na poslužitelj na navedeni port. Prema inicijalnim postavkama, ldapsearch koristi 389 port, ukoliko se ne koristi SSL veza u čijem slučaju koristi 636 port
-V n	koristi LDAP protokol verzije n. Inicijalno postavljeni je 3.
-Z	koristi SSL vezu prilikom spajanja na LDAP poslužitelj
-N name	određuje naziv certifikata koji se koristi u SSL klijent autentikaciji
-K path	određuje ime putanje certifikata koji se koristi u SSL klijent autentikaciji
-W passwd	određuje lozinku za SSL autentikaciju
-D binddn	binddn određuje korisničko ime(DN) za jednostavnu autentikaciju
-w passwd	passwd određuje lozinku za jednostavnu autentikaciju
-E	zahtjev za slanje klijentu identitet poslužitelja prilikom korištenja SSL ili SASL antentikacije
-i charset	određuje tip nizova znakova koje se koriste u komandnim naredbama. Zgodan parametar ukoliko se prijavljuje za rad na gdje je postavljen drugi tip znakova. Za LDIF standard je prihvaćeno UTF-8
-H	prikazuje tekstualnu pomoć s kratkim opisom svake naredbe
-o	ispis imeničkih podataka u starijem formatu. Atributni tipovi i vrijednosti su odvojeni s znakom „=“ te vrijednosti dugog niza nisu razlomljene u više redova
-T	bez prelamanja vrijednost atributa kod pretrage
-A	zaprimanje samo atributnih naziva bez vrijednosti
-x	izvršava sortiranje na poslužitelju
-F sep	postavi prazninu između atributnog tipa i vrijednosti. Ovaj parametar vrijedi ukoliko je postavljen –o parametar
-S attr	sortiranje prema atributu attr. Za obrnuti poredak koristiti –S –sn parametar
-s scope	opseg pretraživanja. Postoje base, one te sub
-l time	vremensko ograničenje trajanja pretrage. Poslužitelj će prekinuti izvršavanje pretrage kad se prekorači vremenski limit
-a size	ograničenje u veličini zaprimanja rezultata. Poslužitelj će vratiti maksimalno size veličinu zapisa koji zadovoljavaju uvjete pretrage

Tablica 4. Najznačajnije značke (parametri) ldapsearch naredbe

2.5.2 ldapmodify komanda naredba

ldapmodify naredba omogućava ažuriranje zapisa u imeniku. Ova naredba se često kombinira s LDIF datotekom koju uključuje u svoje izvršavanje. ldapmodify izvršava ažurirajuće naredbe prema redu kako je napisana LDIF datoteka. Mnoge značke (parametri) koji se koriste kod naredbe ldapsearch se koriste i kod ldapmodify. Sve značke vrijede vezane uz poslužiteljevo ime, DN, lozinke i SSL opcije.

Pretpostavimo kako Vedran Mornar ima novu e-mail adresu koju treba zamijeniti s postojećom. Pogledajmo kako ćemo to izvesti s ovom naredbom.

ldapmodify –h ldap.fer.hr –D „cn=administrator imenika“ –w admin_lozinka < promjena.ldif

gdje je sadržaj datoteke promjena.ldif slijedeća:

dn: uid=vmornar, ou=zpm, dc=fer, dc=hr

changetype: modify

replace: mail

mail: vedran.mornar@fer.hr

Slijedeća naredba pokazuje kako koristiti –f parametar:

ldapmodify –h ldap.fer.hr –D „cn=administrator imenika“ –w admin_lozinka -f promjena.ldif

Prilikom dodavanja novih zapisa uz pomoć ldapmodify naredbe, očekuje se također korištenje LDIF datoteke. Prepoznat ćemo dodavanje zapisa u imenik iz LDIF datoteke ako u nju zavirimo i vidimo atribut changetype: add. Ukoliko ta linija ne postoji u LDIF datoteci, -a parametar u ldapmodify naredbi je mijenja. Za ilustraciju ovog načina jednakog unošenja zapisa u imenik, pogledat ćemo slijedeću naredbu:

ldapmodify –h ldap.fer.hr –D „cn=administrator imenika“ –w admin_lozinka < promjena.ldif

gdje je sadržaj datoteke promjena.ldif slijedeća:

version: 1

dn: uid=mbaranovic, ou=zpm, dc=fer, dc=hr

changetype: add

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

cn: Mirta Branovic

givenName: Mirta

sn: Baranovic

uid: mbaranovic

mail: mirta@zpm.fer.hr

telephoneNumber: +385 1 6129 916

description: prof.dr.sc.

Ovo prethodno navedeno je isto poput:

ldapmodify –h ldap.fer.hr –D „cn=administrator imenika“ –w admin_lozinka –a < promjena.ldif

gdje je sadržaj datoteke promjena.ldif slijedeća:

version: 1

dn: uid=mbaranovic, ou=zpm, dc=fer, dc=hr

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

cn: Mirta Branovic

givenName: Mirta

sn: Baranovic

uid: mbaranovic

mail: mirta@zpm.fer.hr

telephoneNumber: +385 1 6129 916

description: prof.dr.sc.

Svakako da postoji mogućnost da ldapmodify naredba naiđe na pogrešku prilikom izvršavanja. Možete uputiti poslužitelj da nastavi s izvršavanjem promjena uz pomoć parametra –c (continuous mode). Također se može od poslužitelja dobiti i informacija o pogreškama koje su nastale, odnosno moguće je zapise iz LDIF datoteke koje nisu uspjele izvršiti promjenu odvojiti u posebnu LDIF datoteku te naknadno, uz ispravljanje pogrešaka, izvršiti promjenu. Kako bi omogućili preseljenje zapisa u datoteku s greškom, greske.ldif, potrebno je uključiti parametar –e. Pogledajmo kako izgleda sada sintaksa ldapmodify naredbe s uključenim parametrima koje smo sada spomenuli:

ldapmodify –h ldap.fer.hr –D „cn=administrator imenika“ –w admin_lozinka –c -e greske.ldif < promjene.ldif

I za sami kraj, pogledajmo neke od znački (parametara) za ldapmodify naredbu:

Parametar	Opis
-n	prikazuje opis što bi se dogodilo, bez izričitog slanja zahtjeva za pretragu poslužitelju. Ovaj parametar se može iskoristiti za provjeru da li je LDIF datoteka ispravno napisana.
-v	prikazuje opširan dijagnostički izlaz
-h host	spajanje na LDAP poslužitelj koji se nalazi na host. Inicijalno postavljeni je localhost
-p port	spajanje na poslužitelj na navedeni port. Prema inicijalnim postavkama, ldapsearch koristi 389 port, ukoliko se ne koristi SSL veza u čijem slučaju koristi 636 port
-V n	koristi LDAP protokol verzije n. Inicijalno postavljeni je 3.
-Z	koristi SSL vezu prilikom spajanja na LDAP poslužitelj
-N name	određuje naziv certifikata koji se koristi u SSL klijent autentikaciji
-K path	određuje ime putanje certifikata koji se koristi u SSL klijent autentikaciji
-W passwd	određuje lozinku za SSL autentikaciju
-D binddn	binddn određuje korisničko ime(DN) za jednostavnu autentikaciju
-w passwd	passwd određuje lozinku za jednostavnu autentikaciju
-E	zahtjev za slanje klijentu identitet poslužitelja prilikom korištenja SSL ili SASL antentikacije
-i charset	određuje tip nizova znakova koje se koriste u komandnim naredbama. Zgodan parametar ukoliko se prijavljuje za rad na gdje je neki drugi tip znakova. Za LDIF standard je prihvaćeno UTF-8
-H	prikazuje tekstualnu pomoć s kratkim opisom svake naredbe
-c	označava uključenu opciju za nastavak izvršavanja promjena ukoliko se tokom rada naiđe na pogrešku.
-f file	čitanje LDIF datoteke imenom file umjesto ručnog upisivanja
-a	dodavanje zapisa iz LDIF datoteke koja nema navedeni atribut changetype
-e rejfile	spremanje zapisa u rejfile datoteku koji se nisu uspješno izveli prilikom trajanja procesa promjena
-q	prilikom dodavanja ili promjene zapisa, ne obavještavaj o uspješnosti izvršenja

Tablica 5. Najznačajnije značke (parametri) ldapmodify naredbe

3. PRAKTIČAN RAD: OpenLDAP

3.1 Instalacija OpenLDAP

Za potrebe izrade praktičnog dijela seminarskog rada, odlučio sam se na instalaciju OpenLDAP verzije LDAP imeničkog servisa pod Debian distribucijom Linuxa radi jednostavnog dohvaćanja i instaliranja dodatnih konfiguracijskih datoteka. Sav rad je vršen pod programom Vmware Workstation koji služi za upravljanje virtualnim strojevima. idemo pogledati korak – po – korak kako se vrši instalacija LDAPa:

Pokrenuti instalaciju LDAPa naredbom apt-get install slapd (koji se povlači s CARNetovog FTP poslužitelja):

Slika 3.1 Korak 1 : Pokretanje LDAP instalacije

2. Instalacija nas traši unos domene za čiju se namjenu instalira LDAP. Kroz ovaj praktični dio, napravit ćemo LDAP imenik za FER, te je stoga u polje DNS domain name upisana domena fer.hr: