Idąc za ciosem.
Czy nie byłoby wygodnie przechowywać informacji o użytkownikach w jednym, scentralizowanym miejscu? Na podstawie jednego hasła (no to jest troche nadużycie) mieć dostęp do wszystkich aplikacji, usług i serwerów w sieci (to tez jest troche nadużyciem)? W typowych przypadkach dane o użytkowniku pobierane są z różnych źródeł, a w gruncie rzeczy potrzebują zwykle tych samych informacji. Dzięki serwerowi LDAP możemy w łatwy sposób zarządzać bazą użytkowników oraz ich dostępem do usług i aplikacji.
Instalacja i konfiguracja serwera OpenLDAP
Proces opiszę na systemu FreeBSD. O ile instalacja będzie się różniła w zależności od systemu operacyjnego o tyle konfiguracja będzie taka sama dla systemów z rodziny *BSD czy Linuxów.
Dzięki mechanizmowi portów we FreeBSD instalacja pakietu OpenLDAP jest bardzo prosta.
No dobrze. Ale gdzie mozna znaleźć właściwy port. Na początek zacznijmy od strony http://www.freebsd.org/ports/index.html. W wyszukiwarce wpiszmy ‘openldap’, a właściwie pójdźmy krok dalej. Skoro wiemy, że szukamy serwera OpenLDAP poszukajmy serwera – wpiszmy ‘openldap-server’. Na chwilę pisania tego tekstu dostępne są 2 wersje serwera: openldap-server-2.3.43 oraz openldap-server-2.4.23. Którą wybrać? Generalnie jest to obojętne. Dlaczego? Instalując serwer OpenLDAP zainstaluje się automatycznie port openldap-client, z którego korzystają inne programy. Idąc dalej. Kiedy instaluje się inne programy, sprawdzają one swoje zależności – czyli zainstalowane biblioteki w systemie. A najczęściej (niech mnie ktoś poprawi, gdybym był w błędzie) te biblioteki mają taką samą nazwę. Więc wersja samego serwera OpenLDAP nie ma tak wielkiego znaczenia. Osobiście sam nie sprawdzam czym sie różnią dane wersje serwera. Zamiast tego wole zrobić coś takiego: otwieram stronę http://www.freebsd.org/ports/index.html i wpisuję w wyszukiwarkę np. ‘samba’. W wynikach szukam portu serwera Samby i sprawdzam, która wersja klienta jest wymagana (ang. Required). Na tą chwilę mamy ‘openldap-client-2.4.23’. Sprawa jasna. Instaluję ‘openldap-server-2.4.23’.
$/> cd /usr/ports/net/openldap24-server
$/> make install clean
Czas skonfigurować nasz serwer. W tym celu edytujemy plik slapd.conf znajdujący się w katalogu /usr/local/etc/openldap.
Najprostsza i podstawowa konfiguracja wygląda tak:
# /usr/local/etc/openldap/slapd.conf # Basic include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel none modulepath /usr/local/libexec/openldap moduleload back_bdb # moduleload back_hdb # ACLs # Database configuration database bdb suffix "dc=firma,dc=bogus" rootdn "cn=admin,dc=firma,dc=bogus" rootpw secret directory /var/db/openldap-data index objectClass eq
Plik konfiguracyjny składa się z trzech sekcji – ‘Basic’, ‘ACLs’ oraz ‘Database Configuration’.
Sekcja ‘Basic’
Sekcja rozpoczyna się od dyrektywy include. Jest ona wykorzystana do załadowania plików ze schematami, które to przechowują informację o klasach obiektowych oraz typach atrybutów. Do poprawnego wystartowania serwera wystarczy załadować tylko plik ‘core.schema’, który zawiera główne definicje dla LDAP. Pozostałe schematy rozszerzają funkcjonalność serwera.
Dyrektywę include możemy wykorzystać do załadowania dowolnego pliku z konfiguracją, więc w oddzielnych plikach możemy trzymać konfigurację ACLi lub bazy danych.
Kolejne dwie dyrektywy określają miejsce przechowywania plików z informacją o numerze procesu oraz argumentami z jakimi został uruchomiony serwer. Ponieważ proces slapd zapisuję do tych plików, użytkownik który uruchamia slapd musi mieć nadane uprawnienia do odczytu i zapisu zarówno do plików jak i katalogu (/var/run/openldap). Jeśli instalowaliśmy OpenLDAP z portów nie musimy martwić sie uprawnieniami – skrypt instalacji automatycznie doda użytkownika ‘ldap’ do systemu i nada mu właściwe uprawnienia.
Dyrektywa loglevel określa ilość informacji, które OpenLDAP powinien logować. Jeśli nie skonfigurujemy tego parametru, standardowym poziomem logowania jest ‘stats’. Inne poziomy logowania opisane są na stronie podręcznika slapd.conf (http://www.openldap.org/software/man.cgi).
Kolejne dwie dyrektywy – modulepath oraz moduleload – odpowiadają za dodatkowe moduły ładowane podczas startu serwera. Modulepath określa pełną ścieżkę do katalogu z bibliotekami modułów. Moduleload wskazuje bezpośrednio na moduł, który ma zostać załadowany. Ponieważ korzystam ze starszych wersji serwera OpenLDAP, kiedy go instalowałem nie było modułu hdb, dlatego do tej pory używam modułu bdb, który używa bazy Oracle Barkeley DB. hdb jest nowym modułem. Podobnie jak bdb używa bazy Oracle Barkeley DB, ale przechowuje wpisy w sposób hierarchiczny. Dlatego też na chwilę obecną wydaje się być lepszym systemem dla drzewiastej struktury OpenLDAP. Wybór należy do Ciebie.
Pominę teraz sekcję ACL. W niej określa się kto ma dostęp do jakich danych i pod jakimi warunkami. W podstawowej konfiguracji każdy ma dostęp do odczytu (dla całego drzewa), natomiast tylko ‘rootdn’ (czyli administrator) ma pełny dostęp.
Sekcji Databse Configuration przechowuję dane o konfiguracji bazy. Pierwszą dyrektywą jest ‘database’. Okresla ona, z którego modułu (backendu) ma korzystać serwer. W moim przypadku jest to moduł bdb. Jeśli chcemy używać hdb podajemy tutaj ‘database hdb’.
Następnie podajemy suffix, czyli w naszym przypadku będzie to korzeń naszego drzewa ‘dc=firma,dc=bogus’. W ‘rootdn’ definiujemy konto administratora – ‘cn=admin,dc=firma,dc=bogus’, natomiast dyrektywą rootpw określamy dla niego hasło. Można je wpisać jawnym tekstem, aczkolwiek wskazane jest podanie zaszyfrowanego hasła. W tym celu należy użyć programu slappasswd, który wygeneruje zaszyfrowane hasło (standardowo szyfrowane algorytmem SSHA):
$/> slappasswd
W dyrektywie ‘directory’ podajemy miejsce przechowywania plików z bazą. Katalog powinien być dostępny tylko dla procesu slapd.
Ostatnią dyrektywą jest ‘index’. Podajemy w niej, które atrybuty powinny być indeksowane oraz jaki powinny posiadać rodzaj porównania. Czyli jeśli podamy:
index cn eq,
zostanie utworzony w katalogu bazy nowy plik z indeksami dla atrybutu ‘cn’ (common name) i jednolitych zapytań (‘eq’). Jeśli serwer otrzyma zapytanie o wartość np. ‘Ada’ atrybutu ‘cn’, zamiast przeszukiwać całą bazę, najpierw przeszuka plik z indeksami dla atrybutu ‘cn’. Jeśli wyślemy zapytanie o wartości ‘Ada*’ dla atrybutu ‘cn’ plik z indeksami zostanie pominięty.
Dostępne są następujące rodzaje porównań:
pres – szukany atrybut występuje jako dowolna wartość, np. (uid=*)
eq – szukany ciąg znaków dokładnie pasuje do wartości atrybutu,
sub – szukany ciąg znaków pasuje do fragmentu wartości atrybutu, np. (sn=*ska) lub (sn=*aszew*),
none – indeks nie będzie wygenerowany, stosuje się np. dla atrybutów JPEG.
Pliki indeksu muszą być utworzone podczas wstępnej konfiguracji i uruchomienia bazy. W przypadku późniejszego dopisywania indeksów należy wygenerować pliki za pomocą programu slapindex.
Przy małych bazach zapewne nie ma potrzeby indeksowania. Natomiast przy dużych bazach ma to wpływ na prędkość przeszukiwania bazy.
Podstawową konfigurację serwera OpenLDAP mamy juz za nami. Aby uruchomić serwer wystarczy w linie komend wpisać:
$/> /usr/local/libexec/slapd
Jeśli chcemy, aby serwer uruchamiał się przy każdym starcie systemu do pliku /etc/rc.conf musimy dodać:
slapd_enable=”YES”
Na razie mamy skonfigurowany i uruchomiony serwer, ale jeszcze nie dodaliśmy do niego żadnych danych. O tym kolejnym razem.
