Cílem tohoto dokumentu je přiblížit možnosti adresářových služeb a jejich použití v informačních systémech se zaměřením na standardizovaný protokol LDAP.
Prezentovat vlastnosti a možnosti adresářových služeb budu na produktu od firmy Sun Microsystems Sun Java System Directory Server (JES DS), který znám a ve své práci používám. Každopádně níže popsané skutečnosti platí ve velké míře na většinu adresářových serverů LDAP typu, z Open Source projektů je třeba zmínit SW Openldap.
Adresářem je například klasický telefonní seznam, organizovaný seznam kontaktů a vizitek nebo seznam uživatelských kont v počítačových systémech. Slouží nám k organizaci a sdružování dat do skupin, aby se v nich uživatel lépe orientoval. Adresáře jsou v podstatě jakési zasobníky (kontejnery) pro ukládání dat, specializované databáze ve kterých lze uchovat a především vyhledat velké množství informací různého charakteru. Jedná se vlastně o hiearchický seznam objektů a atributů těchto objektů, porovnatelný se strukturou adresářů a podadresářů souborového systému.
Velmi často se spojují termíny adresář a adresářová služba a jsou považovány za synonymum. Naopak adresářové služby v informačních technologiích se skládají z více částí:
Informace uložené v adresáři.
identity (uživatelská jména, hesla, fotografie apod.)
systémové informace (schémata pro mailové služby, kalendářové služby apod.)
Serverový software, který tyto informace poskytuje.
Klientský software, který je schopen uživateli tyto informace zprostředkovat.
Hardware pro klientský a serverový SW.
Podpůrný software jako jsou operační systémy a ovladače zařízení.
Síťová infrastruktura, která je schopna spojit klienty se servery.
Bezpečnostní politika, která specifikuje oprávnění přístupu k záznamům, aktualizaci dat, apod.
Procedury, které adresářové služby používají pro údržbu a monitorování.
Software používaný pro údržbu a monitorování adresářových služeb.
Tento dokument je zaměřen na popis použití klientského a serverového SW.
Proč využít adresář s LDAP přístupovým protokolem místo seznamu v souboru nebo relačních databází?
Data uložená v adresáři lze organizovat a spravovat z jediného místa.
V hiearchické struktuře lze poměrně snadno rozdělovat administrativní pravomoci.
Konfigurace adresáře není závislá na klientském SW.
Objekty a atributy lze snadno editovat. Přidáním dalších atributů k objektu není nutné měnit klienta, jen stačí například přidat další podmínku k využití přidaného atributu. V relačních databázích je poměrně obtížné změnit strukturu již navržené a realizované databáze.
Lze zapnout kontrolu schémat poskytující určitou ochranu proti překlepům a syntaktickým chybám.
Adresář je optimalizovaný na velké množství čtecích operací.
Adresářové služby jsou standardizovány včetně přenosového protokolu a základních schémat, návrháři aplikací mají tedy jistotu, že budu tato schémata dodržována a nebudou pro každou aplikaci individuální jako je tomu v případě SQL tabulek.
Adresářové služby nejsou určeny k zachycení transakčních dat a neovládají práci s referenční integritou. K tomu se velmi dobře hodí klasické relační databáze využívající SQL jazyka. Nepřipadají v úvahu jakékoliv rozsáhlé transakce spojené například s vkládáním více záznamů do databáze, u kterých je nutné provádět kontrolu správných hodnot dat. Není ovšem velký problém vytvořit jakousi datovou pumpu, která by přečerpávala data mezi SQL databází a adresářovými službami.
Lightweight Directory Access Protocol je standardizovaný protokol pro přístup k adresářovým službám, definuje komunikaci mezi serverem a klientem. Zprávy obsahují také příslušná data a informace o jejich formátu. Protokol běží nad internetovými transportními protokoly jako je TCP/IP. LDAP je jednodušší alternativou k protokolu X.500 Directory Access Protocol (DAP), přičemž slouží i jako brána pro přístup k tomuto protokolu.
LDAP je protokol orientovaný na zprávy (message-oriented protocol). Klient vytvoří zprávu obsahující nějakou žádost a odešle ji serveru. Ten ji zpracuje a odešle výsledek zpět jako sérii jedné nebo více LDAP zpráv.
Příklad 1.1. LDAP komunikace - access log
Příklad access logu, uspěšné operace vyhledání atributu.
[22/May/2005:15:41:40] conn=1 op=-1 msgId=-1 - fd=35 slot=35 LDAP connection from 127.0.0.1 to 127.0.0.1 [22/May/2005:15:41:40] conn=1 op=0 msgId=1 - BIND dn="cn=Directory manager" method=128 version=3 [22/May/2005:15:41:40] conn=1 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [22/May/2005:15:41:40] conn=1 op=1 msgId=2 - SRCH base="dc=example,dc=cz" scope=2 filter="(uid=kuky)" attrs=ALL [22/May/2005:15:41:40] conn=1 op=1 msgId=2 - RESULT err=0 tag=101 nentries=1 etime=0 [22/May/2005:15:41:40] conn=1 op=2 msgId=3 - UNBIND [22/May/2005:15:41:40] conn=1 op=2 msgId=-1 - closing - U1 [22/May/2005:15:41:41] conn=1 op=-1 msgId=-1 - closed.
LDAP ve zkratce:
Soubor čtyř modelů - informační, jmenný, funkční a bezpečnostní model.
objekty a atributy - Directory Information Three (DIT)
hierarchie objektů
root suffix - kořen adresáře
dn: dc=example,dc=cz
subsuffix
dn: o=organizace,dc=example,dc=cz
branchpoint - list adresáře
dn: uid=cirkva,ou=People,o=organizace,dc=example,dc=cz
identifikace objektů pomocí jednoznačného identifikátoru - Distinguished Name (dn)
3 druhy schémat (atributy, třídy a namebinding)
atribut - single/multiple (jeden nebo více výskytů u objektu)
třída - may/must (možný nebo povinný výskyt u objektu)
namebinding - definice unikátního rozlišení (moc se nevyužívá)
Příklad 1.2. schéma - 00core.ldif
dn: cn=schema objectclass: top objectclass: ldapSubentry objectclass: subschema cn: schema # # aci # aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl "anonymous, no acis"; allow (read, search, compare) userdn = "ldap:///anyone";) # # attribute types: # attributeTypes: ( 2.5.4.1 NAME 'aliasedObjectName' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'RFC 2256' ) ... # # object classes: # objectClasses: ( 2.5.6.2 NAME 'country' DESC 'Standard LDAP objectclass' SUP top MUST ( c ) MAY ( searchGuide $ description ) X-ORIGIN 'RFC 2256' ) ...
LDAP Data Interchange Format (LDIF) – standardizovaný textový formát pro výměnu adresářových dat.
Objekty v adresáři jsou vzájemně odděleny prázdným řádkem a skládají se z několika částí:
jednoznačné identifikace - distingusihed name - dn
seznamu tříd
seznamu atributů
Příklad 1.3. LDIF se systémovými i uživatelskými informacemi
dn: uid=cirkva,ou=People,o=organizace,dc=example,dc=cz uid: cirkva iplanet-am-modifiable-by: cn=Top-level Admin Role,dc=example,dc=cz icsCalendar: cirkva@example.cz mail: cirkva@example.cz mailUserStatus: active gn: Lukáš sn: Cirkva mailHost: mail.example.cz inetUserStatus: Active userPassword: objectClass: userpresenceprofile objectClass: iplanet-am-managed-person objectClass: top objectClass: icscalendaruser objectClass: iplanet-am-user-service objectClass: inetadmin objectClass: organizationalperson objectClass: person objectClass: sunssoadapterperson mailDeliveryOption: mailbox icsExtendedUserPrefs: ceNotifyEmail=cirkva@example.cz icsExtendedUserPrefs: ceDefaultView=weekview icsExtendedUserPrefs: sunCalEventfilter=accepted,tentative,declined,needs-action icsFirstDay: 1 preferredLanguage: cs sunSSOAdapterConfigurations: default|http:/?configName=sunOneCalendar&configDe sc=SUN-ONE-CALENDAR&domain=example.cz nsRoleDN: cn=Role,o=organizace,dc=example,dc=cz ...
LDAP serverový software – soubor software pro provoz LDAP serveru.
Příkazy k použití:
search
compare
add, delete
modify
dn, bind, unbind, abadon ...
Příklady SW:
Openldap
Sun JES DS
Microsoft Active Directory
LDAP klientský software – soubor programů schopných práce s LDAP serverem.
Příklady GUI:
gq
ldapbrowser
Luma
Sun java console
JXplorer
LDAP API – aplikační programové rozhraní pro vývoj software
S adresáři v informačních systémech setkáváme a budeme setkávat stále více. Všude se mluví o tom, jak identity hierarchické seznamy je třeba integrovat do jediného adresářového serveru. LDAP adresáře jsou v mnoha případech tím pravým řešením.
Příklad využití LDAP adresáře:
Přihlašování do operačního systému - UNIX, Linux, Windows...
Náhrada jmenných služeb typu NIS
Integrace identit služeb elektronické pošty - SMTP, IMAP/POP
Informace pro přístup do MIS a ERP.
Informace pro servery síťových služeb - DHCP, DNS, HTTP serverů.
JES DS je adresářový server napsaný v ANSI C, Perlu a Jave. Jedná se tedy o hiearchickou distribuovanou a rozšiřitelnou databázi objektů vycházející z X.500 ISO normy. JES DS obsahuje několik rozšíření-specialit, které jsou natolik zajímavé, že se jim budu hlouběji věnovat.
Jde o skupiny uživatelů, ale opačné odkazované. U klasické skupiny je seznam registrovaných uživatelů. Pokud je třeba zjistit k jaké skupině uživatel náleží, dochází obvykle k výpočetně náročnějšímu prohledávání. Naopak v případě rolí existuje u každého objektu uživatele atribut nsRoleDN s ukazatelem na existující roli, tudíž není třeba prohledávat všechny skupiny, co někdy znamená i značné zrychlení operací.
Managed role je jednoduchý typ role. (Příkazy ldapsearch a ldapmodify jsou osvětleny v dalších kapitolách.)
Jsou podobné dynamickým skupinám: definuje se filtr, který určuje členy této role. Tento filtr je uložen atributu nsRoleFilter. Pokud je objekt (například uživatel) v dynamické roli, je vygenerován dynamický atribut (obsah atributu nelze měnit) nsRole (narozdíl od statického nsRoleDN), který obsahuje Distinguished Name (dn) role.
Příklad 1.5. Vytvoření Filtered role
ldapmodify -a -h host -p port -D "cn=Directory Manager" -w heslo
dn: cn=Engineer,ou=People,dc=example,dc=cz objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: ManagerFilter nsRoleFilter: (isEngineer=True) Description: filtered role for sales managers
Nested role umožňují vytvářet role, které obsahují další role. Nested role obsahuje seznam (dn) - odkazů na dalších roli. Pokud je uživatel členem nested role, pak je také automaticky členem všech rolí uvedených v nested roli.
Příklad 1.7. Nested role - role mezi částmi organizace (organization unit - ou)
ldapmodify -a -h host -p port -D "cn=Directory Manager" -w password
dn: cn=MarketingSales,ou=marketing,ou=People,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsNestedRoleDefinition cn: MarketingSales nsRoleDN: cn=ManagerFilter,ou=sales,ou=People,dc=example,dc=com nsRoleDN: cn=Marketing,ou=marketing,ou=People,dc=example,dc=com nsRoleScopeDN: ou=sales,ou=People,dc=example,dc=com
Access Control Instructions (ACI) jsou přístupová práva napsaná speciálním jazykem. Pomocí tohoto nástroje lze poměrně jemně nastavit kdo (userdn, ip, authmethod,...) a kdy může přistupovat (read,write,search,compare...) na jaké objekty v adresáři.
Doufám, že čtenář při čtení toho článku získal alespoň částečný rozhled o možnostech adresářových služeb, a že v něm vzbudil zájem o další informace o této problematice. Tento text ovšem není možno brát jako kompletní manuál, k tomu byly o problematice adresářových služeb napsány obsáhlé publikace.
V dalších části tohoto seriálu bude popsána instalace, administrace i s názornými přiklady.
Instalace adresáře od SUNů (JES DS) je poměrně jednoduchá. Nebudu rozvádět licenční politiku, podstatné je možnost otestování zdarma.
Využívám balík SW s názvem Sun Java Enterprise System verze 2004Q3 a 2005Q1, který lze na testovná zdarma získat na www.sun.com/download pro tyto operační systémy:
Solaris verze 8, 9, 10 architektury SPARC
Solaris 9, 10 pro x86
RedHat Enterprise 2.1 (RH Enterprise 3.0 pro 2004Q5)
Pro tuto prezentaci jsem použil JES 2005Q1 na CentOS, který odpovídá RedHat Enterprise 3.0. V Linuxu i Solarisu stačí balík rozbalit a spustit:
./installer -nodisplay -noconsole -saveState /tmp/jes.state
Pro adresářový LDAP server se nastavuje několik věci, například uživatelé pro administraci, přístupový port, uživatel v systému a suffix.
Příklad 2.1. Parametry při instalaci
Enter Server Admin ID [admin] Enter Admin User's Password (At least 8 characters long) [] Enter Directory Manager DN [cn=Directory Manager] Enter Directory Manager's Password Enter Server Identifier [portal] Enter Server Port [389] Enter Suffix [dc=example,dc=cz] Enter Administration Domain [example.cz] Enter System User [ldap] Enter System Group [other]
Na internetu se mi nepodařilo najít souhrnný soupis použití LDAP příkazů, proto se na osvětlení použití s příklady zaměřím.
Grafické utilitky si každý může odzkoušet sám, mnohem zajímavější jsou samotné příkazy LDAPu, na které se v této kapitole zaměřím.
Příkaz slouží
Příklad 3.1. Základní struktura ldapsearch
ldapsearch -D “login“ -w “passwd“ -b “base“ -s “base|one|sub“ co_hledat co_vypsat
Základní vstupní parametry:
login name
Pod jakým uživatelem se ldapsearch provede, s tím souvisí i výsledek vyhledávání. Nejvyšší pravomoci v adresáři má uživatel "Directory Manager".
base object - výchozí bod hledání.Určuje uzel stromu pomocí jeho Distingushed Name (DN), od kterého se má začít s prohledáváním záznamů
search scope - oblast prohledávání.
Tento parametr určuje hloubku prohledávání.
search filter - vyhledávací filtry
Slouží pro vyjádření hledaných výrazů v adresářovém stromu.
Příklad 3.2. ldapsearch - výpis konfigurace adresáře
ldapsearch -p 390 -D "cn=Directory manager" -w "passw" -b "" -s base "objectclass=*"
version: 1 dn: objectClass: top namingContexts: dc=example,dc=cz namingContexts: o=comms-config namingContexts: o=NetscapeRoot namingContexts: o=pab namingContexts: o=PiServerDb supportedExtension: 2.16.840.1.113730.3.5.7 supportedExtension: 2.16.840.1.113730.3.5.8 ... supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: DIGEST-MD5 supportedLDAPVersion: 2 supportedLDAPVersion: 3 vendorName: Sun Microsystems, Inc. vendorVersion: Sun Java(TM) System Directory Server/5.2_Patch_3 dataversion: 02005050310131602005050310131602005050310131602005050310131602005 0503101316 netscapemdsuffix: cn=ldap://dc=book,dc=example,dc=cz:390
Příklad 3.3. ldapsearch - výpis všech atributů objektu uživatele (kromě dynamických atributů)
ldapsearch -p 390 -D "cn=Directory manager" -w "passw" -b "dc=example,dc=cz" uid=cirkva
uid=cirkva,ou=People,o=sun,dc=example,dc=cz sn=Cirkva cn=Lukáš Cirkva iplanet-am-modifiable-by=cn=Top-level Admin Role,dc=example,dc=cz givenName=Lukáš inetUserStatus=Active uid=cirkva objectClass=sunportalnetmailperson objectClass=top objectClass=iplanet-am-managed-person objectClass=person ...
Příklad 3.4. ldapsearch - výpis konkrétního atributu u uživatele
Atribut sunPortalDesktopDPDocument obsahuje informace o nastavení pracovní plochy portálu v BASE kódování.
ldapsearch $AUTH -b "dc=example,dc=cz" uid=cirkva sunPortalDesktopDPDocument
version: 1 dn: uid=kuky,ou=People,o=sun,dc=example,dc=cz sunPortalDesktopDPDocument:: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgi IHN0YW5kYWxvbmU9Im5vIj8+CjwhRE9DVFlQRSBEaXNwbGF5UHJvZmlsZSBTWVNURU0gImphcjov ...
Atribut sunPortalDesktopDPDocument v textové formě:
ldapsearch $AUTH -b "dc=example,dc=cz" -B uid=cirkva sunPortalDesktopDPDocument
uid=kuky,ou=People,o=sun,dc=example,dc=cz
sunPortalDesktopDPDocument=<?xml version="1.0" encoding="utf-8" standalone="no"?>
<!DOCTYPE DisplayProfile SYSTEM "jar://resources/psdp.dtd">
<DisplayProfile version="1.0" priority="10">
<Properties>
<Collection name="GlobalThemes" propagate="false">
<Collection name="SunTheme">
<String name="description" value="Sun"/>
<String name="bgColor" value="white"/>
<String name="titleBarColor" value="#999999"
...Příklad 3.5. ldapsearch - výpis skupiny uživatelů
Pro výpis lze zadávat různé filtry vyhledávání objektů a atributů:
vyhledá uid začínající na "c" a
ldapsearch $AUTH -b "dc=example,dc=cz" uid=c*
vyhledá uid obsahuj na "kv" a
ldapsearch $AUTH -b "dc=example,dc=cz" uid=*kva*
vyhledá objekty obsahující sn=Cirkva a zároveň i givenName=Lukáš
ldapsearch $AUTH -b "dc=example,dc=cz" (&(sn=Cirkva)(givenName=Lukáš)
Podobně se vyjádří logický OR - "(|( )( ))" a NOT - "(!( )( ))"
Příklad 3.6. ldapsearch - výpis všech objektů (jejich dn) v adresáři
ldapsearch $AUTH -b "dc=example,dc=cz" "(|(objectclass=*)(objectclass=ldapsubentry))" dn
Příklad 3.7. ldapsearch - operační atributy
Adresářový server od Sunů obsahuje operační skryté atributy a atributy generované za chodu. Pokud chceme tyto atributy vypsat, je nutné je explicitně vyjmenovat.
ldapsearch $AUTH -b "dc=example,dc=cz" uid=cirkva modifytimestamp
dn: uid=cirkva,ou=People,o=sun,dc=example,dc=cz modifytimestamp: 20050429090115Z
Možnosti využití:
Přidání atributu k objektu:
changetype: add
Modifikace atributu:
changetype: modify
[add] |[replace] |[delete]: atribut
Mazání atributu:
changetype: delete
Příklad 3.8. ldapmodify - přidání objektu uživatele
ldapmodify -p 390 -D "cn=Directory manager" -w passwd
a interaktivně se zadají minimálně povinné atributy:
dn: uid=user,ou=people,o=organizace,dc=example,dc=cz changetype: add objectclass: inetorgperson uid: user sn: test cn: test user
pokud je vše zadáno správně, odešleme údaje Ctrl+D a následuje:
adding new entry uid=user,ou=people,o=sun,dc=example,dc=cz
Seznam souborů je dle mého skromného názoru plně vypovídající.
Základní struktura adresářového serveru, slapd instancí může být několik:
serverroot/
slapd-instance/
shared/
bin/
config/
./startconsole
./start-admin
./stop-admin
start | stop-admin utilitky slouží k ovládání administračního serveru
startconsole- tlustá javovská administrační konzole
serverroot/shared/
config/certmap.conf/config/ldap.conf config/dbswitch.conf config/ssusers.conf config/ds.conf bin/ldapmodify bin/ldapsearch bin/ldapdelete bin/ldapcompare
slapd-instance/
bak/
config/
schema/
./lse.ldif
db/
ldif/
logs/
access
audit
error
bak/ - zálohy db
db/ - data LDAP (formát BerkeleyDB
config/dse.ldif- konfigurace instance (slapd-instance)config/schema- schémata atributů a třídldif/- zálohy ve formátu ldif
Zálohovat lze komplet adresář nebo jen části stromu a to jak db formát tak i z/do LDIFu.
Příklad 3.13. záloha - z DB do LDIF suffixu dc=example,dc=cz
db2ldif -s dc=example,dc=cz
16/May/2005:11:34:25 +0200] - DEBUG - conn=-1 op=-1 msgId=-1 - Backend Instance: userRoot ldiffile: /var/opt/sun/directory-server/slapd-book/ldif/2005_05_16_113423.ldif [16/May/2005:11:34:26 +0200] - export userRoot: Processed 1000 entries (29%). [16/May/2005:11:34:28 +0200] - export userRoot: Processed 2000 entries (58%). [16/May/2005:11:34:29 +0200] - export userRoot: Processed 3000 entries (87%). [16/May/2005:11:34:29 +0200] - export userRoot: Processed 3434 entries (100%).
Logování adresářových služeb je velmi důležitou funkcí, která usnadní nejen ladění aplikací. Dle mého názoru je logování adresářových služeb velmi povedené.
Loguje se v případě Sunovského adresářového serveru do třech souborů, které jsou dle určité politiky rotovány nebo i v případě potřeby automaticky odmazávány.
Obsahuje informace o přístupu do adresářového serveru od operace BIND po SEARCH a MODIFY až k UNBIND. U každého příkazu jsou napsány identifikační kód (počet výsledků - u operace SEARCH) a návratové hodnoty.
Příklad 3.15. access log - demostrace logování - ldapsearch
Z příkladu je zřejmé logování připojení, BIND pod uživatelem (a výsledek), vyhledání s výsledkem jedidého výskytu a ukončení spojení.
ldapsearch -p 390 -D "cn=Directory manager" -w "passw" -b "dc=example,dc=cz" uid=cirkva
[22/May/2005:15:41:40] conn=1 op=-1 msgId=-1 - fd=35 slot=35 LDAP connection from 127.0.0.1 to 127.0.0.1 [22/May/2005:15:41:40] conn=1 op=0 msgId=1 - BIND dn="cn=Directory manager" method=128 version=3 [22/May/2005:15:41:40] conn=1 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [22/May/2005:15:41:40] conn=1 op=1 msgId=2 - SRCH base="dc=example,dc=cz" scope=2 filter="(uid=kuky)" attrs=ALL [22/May/2005:15:41:40] conn=1 op=1 msgId=2 - RESULT err=0 tag=101 nentries=1 etime=0 [22/May/2005:15:41:40] conn=1 op=2 msgId=3 - UNBIND [22/May/2005:15:41:40] conn=1 op=2 msgId=-1 - closing - U1 [22/May/2005:15:41:41] conn=1 op=-1 msgId=-1 - closed.
Příklad 3.16. access log - ldapmodify
Příklad přidání objektu, který již existuje. Návatový kód je 32 - No such object exists. viz. 3.3.4 – „Návratové kódy“
[26/May/2005:16:23:51] conn=0 op=-1 msgId=-1 - fd=35 slot=35 LDAP connection from 127.0.0.1 to 127.0.0.1 [26/May/2005:16:23:51] conn=0 op=0 msgId=1 - BIND dn="cn=Directory manager" method=128 version=3 [26/May/2005:16:23:51] conn=0 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [26/May/2005:16:25:06] conn=0 op=1 msgId=2 - ADD dn="uid=user,ou=people,o=organizace,dc=example,dc=cz" [26/May/2005:16:25:00] conn=0 op=1 msgId=2 - RESULT err=32 tag=105 nentries=0 etime=0 [26/May/2005:16:25:06] conn=0 op=2 msgId=3 - UNBIND [26/May/2005:16:25:06] conn=0 op=2 msgId=-1 - closing - U1 [26/May/2005:16:25:07] conn=0 op=-1 msgId=-1 - closed.
Poskytuje dokonalé informace o všech změnách obsahu adresáře. Audit log je v LDIF formátu a lze ho tudíš využít pro import.
Stučně řečeno, jakákoliv změna provedená v adresáři je v i audit logu (pokud je logování zapnuté). Po obnovení adresáře ze zálohy a lze aplikovat audit log nebo jen jeho určitou část viz příklad 3.10 – „ldapmodify - přidání LDIF ze soubory“.
Pozor na rychlý nárůst těchto logů, doporučuji hlídat prostor na pevném disku nebo audit log používat jen při ladění aplikace.
Příklad 3.17. audit log - příklad dvou záznamů operačních změn
time: 20050526162324 dn: cn=uniqueid generator,cn=config changetype: modify replace: nsState nsState:: ABbit9EdsgGzY7XKrvZxCwAAAAA= - replace: modifiersname modifiersname: cn=server,cn=plugins,cn=config - replace: modifytimestamp modifytimestamp: 20050526142324Z - time: 20050530143631 dn: cn=uniqueid generator,cn=config changetype: modify replace: nsState nsState:: gPEWc9IdsgGzY7XKrvbGPwAAAAA= - replace: modifiersname modifiersname: cn=server,cn=plugins,cn=config - replace: modifytimestamp modifytimestamp: 20050530123631Z -
Obsahuje detailní informace o kritických událostech v adresáři. Například o zapnutí a ukončení adresářového serveru, ale také o nedovoleném přístupu na objekt apod.
Příklad 3.18. error log
[30/May/2005:14:36:31] - Sun Java(TM) System Directory Server/5.2_Patch_3 B2004.331.1254 (32-bit) starting up [30/May/2005:14:36:37] - Listening on all interfaces port 390 for LDAP requests [30/May/2005:14:36:37] - slapd started. [30/May/2005:14:36:40] - Entry "uid=user,ou=People,dc=example,dc=cz" - attribute "add" not allowed [30/May/2005:23:30:42] - slapd shutting down - waiting for 0 threads to terminate [30/May/2005:23:30:42] - Waiting for 5 database threads to stop [30/May/2005:23:30:43] - All database threads now stopped
Tabulka ukazuje příklady návratových kódů při práci s adresářovým serverem.
Příklad 3.19. LDAP - příklady návratových kódů
| LDAP stavový kód | Popis |
|---|---|
| 0 | Success. |
| 2 | Protocol error. |
| 3 | Time limit exceeded. |
| 16 | No such attribute exists. |
| 17 | An udefined attribute type. |
| 32 | No such object exists. |
| 34 | An invalid DN syntax. |
| 49 | Invalid credentials. |
| 50 | Insufficient access rights. |
| 51 | Bussy. |
| 65 | Object class violation. |
| 68 | Attribute already exists. |
Při práci s adresářovým serverem dochází ve většině případů jen k několika problémům:
Nedojde-li k autentizaci a autorizaci uživatele například z důvodu špatného uživatelského hesla, potom jsou příkazy provedeny pod anonymním (pokud je povolen) uživatelem, který logicky nemusí mít dostatečná práva.
Nemožnost vložení již existujícího záznamu. Pokud záznam již existuje je nutná modifikace.
Objekt nelze vytvořit pokud nejsou splněné schématické požadavky - povinné atributy a třídy.
Nedostatečná přístupová práva - ACL.
UTF8 znaky nebo mezery v DN, které jsou nesprávně interpretovány nedokonalými skripty.
Příliš široký rozsah vyhledávání, počet výsledků je omezen.
Odkazy na použitou literaturu:
Benák, K.: Použití adresářových služeb v informačních systémech - Diplomová práce
Sun Java System LDAP SDK for C Programming Guide - Result Codes
Sun Java System Directory Server 5.X Maintenance and Operations - DIR-2337
Odkazy na použitý SW:
Speciální poděkování za spolupráci při psaní dokumentu a korektuře patří Karlu Benákovi.