Bardzo dynamiczy rozwój Internetu, stawia coraz wyższą poprzeczkę twórcom narzędzi pozwalających dotrzeć nam do szukanej informacji czy kontaktu z innymi. Jedn ą z takich usług są tzw. usługi katalogowe. Ostatnio dominującym wśród standardów przeznaczonych do obsługi zasobów danych o charakterze katalogowym stał się serw er LDAP (Lightweight Directory Access Protocol), który dostarczając uniwersalną bazę danych oraz interfejs dostępowy wykorzystujący protokół TCP/IP, stanowi wygod ną infrastrukturę dla oferowanych usług sieciowych. Istotną własnością systemów działających w oparciu o protokół LDAP jest dobra skalowalność i możliwość dostoso wania schematu bazy do naszych potrzeb.

Chciałbym Wam przybliżyć zasadę działania LDAP-a i pokazać w jaki sposób stworzyć własną bazę w oparciu o ten serwer.
A więc zacznijmy od początku. Musimy mieć wersję instalacyjną. Możemy ją ściągnąć ze strony http://www.openldap.org/software/download/. Sam proces kompilacji i instalacji jest stosunkowo prosty. Wystarczy, że wykonamy następujące polecenia:

Teraz zostaje nam już tylko edytowanie pliku konfiguracyjnego bazy /usr/local/etc/openldap/slapd.conf. Przykładowy plik konfiguracyjny może wyglądać następująco:

Skonfigurowaną bazę uruchamiamy poleceniem /usr/local/libexec/slapd.
Zanim przystąpimy do dalszej konfiguracji, musimy najpierw utworzyć w bazie tzw. rekord główny. Może to być wpis określający organizację lub domenę. Kolejne rekor dy będą znajdować się poniżej. Każdy następny rekord dodajemy wykonując polecenie:

gdzie -f nasz_plik wskazuje skrypt do tworzenia bazy i podstawowych danych. Kolejny parametr -D określa nazwę użytkownika mającego dostęp do zapisu w bazie, za ś opcja -w nasze_haslo jest hasłem użytkownika. Proponuję stworzyć dwa pliki konfiguracyjne o nazwach organs.ldap, który będzie zawierał informacje o strukturze b azy oraz users.ldap. Przykładowe pliki powinny wyglądać następująco:

W przykładzie określamy rekordy dla Jana Kowalskiego oraz Wojciecha Brzozowskiego. Standardowo każda osoba powinna należeć do klasy person, która wymaga określ enia atrybutów cn (commonname/nazwa zwyczajowa) oraz sn (surname/nazwisko), które są zdefiniowane w core.schema. Użyliśmy także atrybutu gn (givenname/imię) zawar tego w klasie inetOrgPerson. I tak po wykonaniu następujących poleceń:

mamy utworzoną bazę z wprowadzonymi dwoma rekordami.
Jeśli chcemy sprawdzić czy nasze dane znalazły się w bazie uruchamiamy polecenia:

Teraz zajmiemy się bezpieczeństwem. Pod pojęciem bezpieczeństwa bazy LDAP będę tu rozumiał dwa zasadnicze czynniki: prawa dostępu oraz szyfrowanie transmisji. OpenLDAP posiada rozbudowany mechanizm kontrolujący prawa dostępu. Postać ogólną pojedynczej definicji ACL (Access Control Limit - Limit kontroli dostępu) określa następujący schemat:

access to [obiekt] by [użytkownik] [poziom dostępu]

Poszczególne składowe określone w nawiasach kwadratowych określają:

• [obiekt] - atrybut lub rekord, a także cała baza (określając ją *). Rekordy do modyfikacji określa się poprzez filtr poszukiwań (filter=<filtr>). Atrybuty w obrębie rekordu określa się za pomocą odpowiedniego słowa kluczowego (attrs=<lista atrybutów>), przy czym każdy kolejny oddziela się przecinkiem.
• [użytkownik] - kto ma dostęp do podanych atrybutów lub rekordów. Ta składowa, oprócz jednoznacznego określenia nazwy (identycznego z poprzednim: dn=), może zostać podana w formie kluczy:
• * - wszyscy użytkownicy
• anonymous - użytkownicy nie zalogowani
• users - użytkownicy zalogowani (po pomyślnej autentykacji)
• self - użytkowników związanych z podanym atrybutem lub rekordem
• [poziom dostępu] - jaki dostęp zostanie przyznany:
• none - brak dostępu
• auth (x) - wymagane do podłączenia do bazy
• compare (cx) - wymagane do porównania rekordu określonego przez użytkownika z rekordem w bazie
• search (scx) - wymagane dla użycia filtrów poszukiwań
• read (rscx) - wymagane dla odczytania wyników poszukiwania
• write (wrscx) - wymagane do modyfikacji rekordów

Jak widać na tym przykładzie każdy następny poziom dostępu posiada uprawnienia poprzednika. Czyli użytkownik otrzymujący poziom read, otrzymuje także search, compare, auth.
Oto kilka przykładowych list kontroli dostępu do OpenLDAP:

• prawo czytania dla wszystkich:
  access to * by * read

• prawo do modyfikacji tylko dla użytkowników związanego z rekordem i prawo do czytania dla wszystkich, ale tylko po pomyślnej autentykacji:
  access to * by self write by anonymous auth by * read

• prawo czytania dla użytkowników, prawo modyfikacji atrybutu homePhone tylko po autentykacji i tylko przez danego użytkownika i administratora bazy:
  access to attr=homePhone by self write by anonymous auth by dn="cn=Manager,o=FIRMA,c=pl" write by * none
  access to * by self write by dn="cn=Manager,o=FIRMA,c=pl" write by users read

Jednak taki poziom zabezpieczeń jest bardzo prymitywny w dzisiejszych czasach, skoro istnieje możliwość podsłuchania transmisji i przechwycenia przesyłanych da nych. Aby zwiększyć poziom zabezpieczeń możemy użyć połączenia szyfrowanego SSL. Skorzystajmy z biblioteki OpenLDAP z Open SSL dzięki opcjom:

• TLSCertificateFile - określa plik z certyfikatem serwera
• TLSCertificateKeyFile - określa plik z jego kluczem prywatnym.

Dodatkowo możemy użyć następujących parametrów:

• nietypowy - TLSRandFile, określający lokalizację pliku, z którego będą pobierane liczby losowe (w przypadku braku /dev/[u]random)
• zaawansowany - TLSCipherSuite, definiujący wykorzystywane algorytmy kryptograficzne

Taka definicja opcji pozwala na korzystanie z protokołu TLS na standardowym porcie ldap (389/tcp). Uruchomienie OpenLDAP działającego na porcie ldaps (636/tcp) jest dopiero możliwe po uruchomieniu bazy z opcjami:

Dzięki temu demon może nasłuchiwać na wszystkich adresach przypisanych do serwera na portach ldap i ldaps. Definicja adresu, na jakim ma nasłuchiwać powinien w yglądać:

I to by było wszystko na temat bezpieczeństwa w OpenLDAP. Istnieje oczywiście wiele możliwości zabezpieczenia serwera, lecz jest ich tak wiele, że o tym innym razem.

Do mitów należy opinia, że LDAP stosuje się tam gdzie liczbę użytkowników określa się w tysiącach. Usługi katalogowe LDAP można stosować "wszędzie i praktyczni e do wszystkiego". Mam nadzieję, że artykuł ten przybliżył Wam zagadnienia związane z instalowaniem i korzystaniem z serwera LDAP i dzięki niemu zaczniecie korzys tać z tego serwera usług katalogowych.

Autor: Marek Chrobak, 17-09-2004