System centralnej autentykacji użytkowników - wdrożenie i administrowanie na klastrze komputerowym WCSS. | ||
---|---|---|
Poprzedni | Następny |
Przygotowanie i instalacja pakietów w formacie dystrybucji Linux Debian. Użyto systemu OpenLDAP w wersji 2.1.22-1 i modułów PAM-LDAP w wersji 164-1, bibliotek LIBNSS-LDAP, wersji 211-1 oraz pakietu skryptów Migrationtools 44-6. Aplikacje OpenLDAP, PAM-LDAP i LIBNSS-LDAP zostały skompilowane i z wynikowych plików binarnych utworzone zostały pakiety instalacyjne w formacie .deb. Pakiet źródeł OpenLDAP posłużył do przygotowania dwóch rodzajów pakietów binarnych. Pakiet o nazwie "openldap", zawierający biblioteki, programy-demony udostępniające usługi bazodanowe oraz programy klienckie bazy danych, zainstalowany został na serwerze klastra. Pakiet "libldap2", o nazwie wybranej dla zachowania kompatybilności z nazewnictwem przyjętym w systemie pakietów Debiana, przeznaczony został do instalacji na węzłach klastra. Zawiera on oprogramowanie klienckie bazy danych oraz wykorzystywane przez nie biblioteki funkcji. Na etapie konsolidacji binarnej części pakietu "opanldap" - pliku demona "slapd" istotna była kolejność dołączania bibliotek funkcji - pierwszą biblioteką udostępniającą funkcję systemową "crypt()" musiała być biblioteka "libcrypt". Standardowo dołączana jako pierwsza biblioteka "libssl" dostarczała funkcję "crypt()" niekompatybilną z aktualnym sposobem kodowania haseł w pliku /etc/shadow. Pakiety PAM-LDAP i LIBNSS-LDAP zostały zainstalowane na każdej z maszyn klastra.
Konfigurowanie serwera OpenLDAP. Cały system bazy danych zainstalowany został na zewnątrz wyodrębnionego dla użytkowników środowiska ("CHROOT"). Głównym celem było tu odseparowanie części systemu plików dostępnej dla użytkowników od plików bazy danych, które to mają krytyczne znaczenie dla bezpieczeństwa całego systemu. Demon bazy danych - "slapd" pobiera ustawienia z pliku /etc/ldap/slapd.conf. Zgodnie z zawartą tam konfiguracją demon obsługuje jedną bazę danych, w domenie "kdm.net". Jako format składowania danych (backend) wybrany został prosty schemat "ldbm". Pliki bazy danych przechowywane są w katalogu /var/lib/ldap. W pliku slapd.conf zawarta jest także konfiguracja szyfrowanych tunelów TLS, która będzie opisana w punkcie 6. Czynności opisane w dalszych punktach wykonywane były wewnątrz przestrzeni wydzielonej dla użytkowników ("CHROOT").
Migrowanie danych. Przeniesienie danych o kontach do nowej bazy danych. Wykorzystane zostały skrypty języka PERL z pakietu Migrationtools. Katalogiem zawierającym skrypty jest /usr/share/migrationtools. Konfiguracje dla skryptów ustala się w pliku /usr/share/migrationtools/migrate_common.ph. Wykorzystane były 3 skrypty migrujące dane. Przy użyciu skryptu "migrate_base.pl" tworzy się główne katalogi w bazie danych, skrypty "migrate_group.pl" i "migrate_passwd.pl" przenoszą do tych katalogów odpowiednie dane. Bezpośrednim efektem działania skryptów są pliki typu "ldif", czyli wejściowe dla narzędzi operujących na bazie LDAP. Poniżej umieszczono przykład użycia jednego ze skryptów.
Konfigurowanie klientów bazy. Moduły PAM podczas komunikacji z centralną bazą danych korzystają z konfiguracji zawartej w plikach /etc/ldap.conf. Na serwerze klastra, klient bazy LDAP uruchomiony z prawami superużytkownika systemu operacyjnego automatycznie uzyskuje prawa administratora bazy, pobierając odpowiednie hasło z pliku /etc/ldap.secret. Takie rozwiązanie gwarantuje możliwość modyfikowania bazy LDAP przez moduły PAM i sluży wygodzie ręcznego operowania na bazie LDAP przez administratorów. Ze względów bezpieczeństwa przyjęto, że hasła nie będą przechowywane na maszynach klienckich. Klienci PAM-LDAP skonfigurowani są tak, aby przy połączeniu dokonywać autentykacji serwera, co opisane zostało w punkcie 6.
Ustalenie konfiguracji serwisu NSS. Zainstalowane biblioteki LIBNSS-LDAP zapewniają mapowanie nazw użytkowników i grup na numery UID i GID. Konfiguracja mechanizmu NSS zawarta jest w plikach /etc/nsswitch.conf, biblioteki LIBNSS-LDAP korzystają z konfiguracji zapisanej w plikach /etc/ldap.conf.
Konfigurowanie modułów PAM i zapasowej bazy haseł. Jak wspomniano w punkcie 2, skonfigurowanie modułów PAM obejmuje ustalenie zestawu modułów, kolejności ich przetwarzania oraz znaczenia poszczególnych modułów w procedurze logowania. Wszystkie te ustawienia przechowywane są w plikach odpowiadających nazwom aplikacji, w katalogu /etc/pam.d. Konfiguracja została wybrana tak, żeby przy zachowaniu możliwie wysokiego poziomu bezpieczeństwa zapewnić możliwość logowania się także przy braku połączenia z centralną bazą LDAP. Główne założenia co do konfiguracji można sformułować następująco:
Podstawowym źródłem danych do autentykacji wszystkich aplikacji zainstalowanych na węzłach i przystosowanych do współpracy z modułami PAM jest centralna baza LDAP.
W wypadku niedostępności centralnej bazy danych, pobierane są informacje z lokalnych, standardowych baz w plikach tekstowych.
Dąży się do zachowywana pełnej zgodności danych pomiędzy centralną bazą a bazami lokalnymi.
Baza danych może być modyfikowana tylko z poziomu serwera zarządzającego.
Moduły PAM dokonują na bazach kont zarówno operacji odczytu, jak i zapisu. Modułami modyfikującymi te dane są moduły typu "passwd". Zgodnie z wymienionymi założeniami wszystkie typy modułów (auth, account, session, passwd) skonfigurowane są do korzystania z dwóch źródeł danych, podstawowego i zapasowego. W przypadku, gdy moduł PAM-LDAP nie może przeprowadzić logowania, np. gdy połączenie z bazą jest niedostępne, lub podane hasło jest nieprawidłowe, kontrola przekazywana jest do standardowych modułów PAM-UNIX. Z przyczyn technicznych niemożliwe było zaprogramowanie, w prosty sposób, rozróżniania przez system przypadków podania błędnego hasła i niedostępności bazy LDAP, dlatego ważne, głównie ze względów bezpieczeństwa, jest zachowywanie zgodności pomiędzy wszystkimi bazami danych. Tekstowa baza na serwerze zarządzającym, modyfikowana jednocześnie z bazą LDAP, rozprowadzana jest po węzłach klastra jeden raz dziennie.
Skonfigurowanie tunelów szyfrowanych dla połączeń z serwerem bazy danych. Dla zapewnienia większej poufności danych przesyłanych pomiędzy serwerem a klientami LDAP, zdecydowano się na wprowadzenie szyfrowania treści połączeń. Wykorzystany został protokół TLS (Transport Layer Security), zaprojektowany w oparciu o metody kryptografii asymetrycznej. Zestawienie tunelu szyfrowanego zaczyna się od pobrania przez system kliencki certyfikatu serwera, zawierającego jego klucz publiczny. Zaszyfrowane z wykorzystaniem klucza publicznego, wysyłane do serwera dane, są podstawą do szyfrowania metodą symetryczną w dalszej w części transmisji. Podczas uruchomienia demon LDAP sprawdza autentyczność certyfikatu serwera, odwołując się do certyfikatu CA (Certificate Authority), którym jest tutaj Polskie Centrum Certyfikacji EuroPKI. Klucz prywatny serwera znajduje się w pliku /etc/ssl/private/uklad.key, jego certyfikat w /etc/ssl/certs/uklad.cert a certifikat CA w /etc/ssl/certs/ca.cert. Wymienione dane, ze względu na duże znaczenie dla bezpieczeństwa mieszczą się na zewnątrz przestrzeni dostę?nej dla użytkowników. Komputery klienckie skonfigurowane są do dokonywania autentykacji serwera przy nawiązywaniu połączenia, w oparciu o posiadany certyfikat (klucz publiczny) CA przechowywany w /etc/ssl/certs/ca.cert, wewnątrz przestrzeni "CHROOT".
Poprzedni | Spis treści | Następny |
System PAM-LDAP | Administrowanie systemem |