Bociek PLD - Pisarz
I. Informacje podstawowe
II. Instalacja
III. Podręcznik użytkownika
IV. Podręcznik administratora
Usługi dostępne w PLD
Heimdal - Implementacja protokołu Kerberos
V. Tworzenie PLD - Praktyczny poradnik
VI. O podręczniku
O tej książce
Spis treści
Inne wersje tego dokumentu
PDF
HTML (jeden plik)
TXT
Odnośniki
Tworzymy dokumentację PLD
Strona PLD
Listy dyskusyjne PLD

Heimdal - Implementacja protokołu Kerberos

<- ->
 

Heimdal jest implementacją nowoczesnego sieciowego protokołu uwierzytelniania użytkowników Kerberos. Użytkownik po standardowym zalogowaniu za pomocą hasła na czas trwania sesji otrzymuje specjalny unikalny klucz (w terminologii kerberos'a nazywany biletem (ang. ticket)) za pomocą którego może uzyskać dostęp do innych usług w sieci już bez konieczności dodatkowego podawania hasła.

Każda sieć posiada wydzielony serwer Kerberos, zwany KDC (Key Distibution Center) którego zadaniem jest zarządzanie centralną bazą kluczy (m.in. wydawanie nowych kluczy oraz odpowiadanie na pytania dotyczące ich autentyczności).

Uwaga:Kerberos nie zapewnia dystrybucji bazy użytkowników w sieci - do tego celu najlepiej użyć usługi NIS.

Instalacja i konfiguracja KDC

Za pomocą poldka instalujemy serwer i narzędzia heimdal'a:

# poldek -i heimdal heimdal-server

Edytujemy plik konfiguracyjny /etc/heimdal/krb5.conf. Plik ten używany jest przez biblioteki heimdal'a i powinien być obecny na wszystkich maszynach, na których będziemy używali kerberos'a (na serwerze i klientach)

[libdefaults]
    default_realm = FOO.PL
    clockskew = 300
    v4_instance_resolve = false

[realms]
    FOO.PL = {
        kdc = kdc.foo.pl
        kpasswd_server = kdc.foo.pl
        admin_server = kdc.foo.pl
    }
[domain_realm]
    .foo.pl = FOO.PL
    foo.pl = FOO.PL

default_realm określa domyślną domenę kerberos'a. Zamiast FOO.PL wpisujemy wybraną nazwę domeny, typowo jest to pisana wielkimi literami nazwa naszej domeny dns. kdc.foo.pl zastępujemy adresem serwera, na którym uruchomiony jest serwer KDC heimdal'a.

clockskew określa maksymalną różnicę czasu (w sekundach) pomiędzy serwerem a klientami (jeżeli różnica czasu będzie większa niż podana, kerberos odmówi współpracy) dlatego dobrze w sieci uruchomić także usługę synchronizacji czasu ntp.

Sekcja [realms] definiuje domeny kerberosa. Można tu wymienić kilka niezależnych domen, określając dla nich lokalizację serwerów kerberosa. kdc.foo.pl zastępujemy oczywiście nazwą hosta na którym będzie uruchomiona usługa kdc.

Ostatnia sekcja [domain_realm]określa mapowanie nazw dns na domeny kerberosa. Na tej podstawie heimdal wie na podstawie nazwy dns hosta w jakiej domenie kerberos'a się znajduje. Nazwa dns zaczynająca się od kropki pasuje do dowolnej poddomeny podanej domeny.

uruchamiamy usługę dystrybucji kluczy KDC:

# service heimdal start

Do zarządzania domeną kerberos'a używamy narzędzia kadmin. Inicjalizujemy domenę i dodajemy użytkownika, w tym przypadku mrk (zostawiając domyślnie proponowane wartości):

# kadmin -l
kadmin>init FOO.PL
kadmin>add mrk

Opcja -l uruchamia kadmin w trybie lokalnym, program musi być uruchomiony z konta root. Możemy także dopisać do pliku /etc/heimdal/krb5.acl:

mrk@FOO.PL all

dając użytkownikowi mrk@FOO.PL prawo do administracji kerberosem - w tym przypadku kadmin wołamy z parametrem -p użytkownik

Logujemy się w systemie na koncie zwykłego użytkownika (w naszym przykładzie mrk) i próbujemy się zalogować do domeny kerberosa:

$ kinit

kinit domyślnie próbuje uzyskać bilet dla zalogowanego użytkownika, można to zmienić podając użytkownika jako parametr.

Sprawdzamy, czy kerberos wystawił nam bilet (ticket):

$ klist
Credentials cache: FILE:/tmp/krb5cc_1000_pSN1Vv
        Principal: mrk@FOO.PL

  Issued           Expires          Principal         
Apr 13 11:02:40  Apr 13 21:02:40  krbtgt/FOO.PL@FOO.PL

Logowanie do systemu

Instalujemy moduł pam-pam_krb5.

# poldek -i pam-pam_krb5

Zmieniamy wybrane pliki /etc/pam.d/*, dodając dodatkowo sprawdzanie hasła za pomocą nowego modułu:

Przykładowo /etc/pam.d/login wykorzystywany przez program login poprawiamy tak:

#zmieniamy linijkę

auth    required    pam_unix.so

na:

auth    sufficient  pam_unix.so
auth    required    pam_krb5.so use_first_pass

i dodajemy:

session optional pam_krb5.so

W ten sposób możemy się zalogować przy użyciu standardowej metody sprawdzania haseł w /etc/shadow (pam_unix.so) lub w domenie kerberos'a (pam_krb5.so)

Analogicznie poprawiamy inne pliki, np. /etc/pam.d/gdm, /etc/pam.d/xscreensaver

Po tych poprawkach powinniśmy móc zalogować się już podając hasło kerberos'a. Po zalogowaniu możemy jeszcze za pomocą polecenia klist sprawdzić czy kerberos wystawił nam bilet:

$ klist

Konfiguracja poszczególnych usług

Kolejnym etapem jest "skerberyzowanie" poszczególnych usług w naszej sieci tak, by uwierzytelniały użytkownika na podstawie wystawionego biletu kerberos'a. Zaprezentujemy to na przykładzie sshd, cyrus-imap'a oraz apache'a - opis postępowania w przypadku innych usług obsługujących uwierzytelnianie kerberos jest podobny, Każda skerberyzowana usługa musi mieć utworzone własne konto w domenie Kerberos'a (tzw. service account). Z kontem tym związany jest klucz, który musi być znany zarówno kdc i usłudze. Konto usługi przeważnie jest w postaci: nazwa_usługi/hostname, przy czym hostname musi być pełną nazwą hosta wraz z domeną, czyli tym, co zwraca hostname:

$ hostname --fqdn

Ponadto należy zadbać o poprawne odwzorowanie tej nazwy w DNS - opis jak właściwie ustawić hostname znajduje się podstawach konfiguracji sieci

SSH

Tworzymy konto dla daemona sshd. Konto musi miec nazwę w postaci: host/hostname

# kadmin -l
kadmin> add -r host/host.foo.pl

Parametr -r powoduje, że do konta zostanie przypisany losowy klucz (hasło). Klucz ten jest zapisany jako jeden z atrybutów użytkownika w bazie użytkowników domeny Kerberos'a (dokładnie w /var/lib/heimdal/heimdal.db). By sshd miał także dostęp do tego klucza robimy:

kadmin> ext_keytab host/host.foo.pl

Powyższe polecenie zapisuje klucz związany z kontem usługi do tzw. tablicy kluczy (keytab), z której to tablicy sshd może go pobrać. Klucz zostaje zapisany w domyślnej tablicy kluczy znajdującej się w pliku /etc/heimdal/krb5.keytab. Z tej tablicy kluczy domyślnie korzystają usługi używające kerberos'a.

By sshd uwierzytelniał użytkowników za pomocą kerberos'a do pliku /etc/ssh/sshd_config dodajemy jeszcze linijki:

GSSAPIAuthentication yes

do pliku konfiguracyjnego klienta /etc/ssh/ssh_config dopisujemy:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Opcja GSSAPIDelegateCredentials określa, czy bilet kerberosa ma być przekazany na maszynę, na którą się logujemy.

Po restarcie sshd, jeżeli mamy wystawiony bilet kerberosa powinniśmy móc zalogować się przez ssh na nasz serwer bez pytania o hasło.

Powyższy opis dotyczy sytuacji, gdy serwer sshd znajduje się na tej samej maszynie co kdc. Jeżeli sshd jest na innej maszynie w sieci, musimy wyeksportować klucz do innej tablicy kluczy:

kadmin> ext_keytab host/host.foo.pl sshd.keytab

a następnie przenieść plik sshd.keytab na maszynę na której mamy uruchomione sshd. Trzeba jeszcze poinformować sshd, że ma szukać klucza w innej lokalizacji niż standardowe krb5.keytab. W pliku /etc/sysconfig/sshd dopisujemy:

export KRB5_KTNAME=/etc/heimdal/sshd.keytab

Cyrus IMAP

Doinstalowujemy plugin gssapi do sasl'a

# poldek -i cyrus-sasl-gssapi

Tworzymy konto dla cyrrus'a. Konto ma mieć nazwę w postaci imap/hostname:

kadmin> add -r imap/host.foo.pl

exportujemy klucz do tablicy kluczy:

kadmin> ext_keytab /etc/heimdal/cyrus.keytab

Wybieramy inną niż domyślna tablicę kluczy, ponieważ cyrus imap pracuje z uprawnieniami użytkownika 'cyrus' i jako taki nie ma prawa czytania domyślnej tablicy /etc/heimdal/krb5.keytab.

Dajemy dostęp do tablicy kluczy użytkownikowi cyrus:

chown cyrus.root /etc/heimdal/cyrus.keytab
chmod 660 /etc/heimdal/cyrus.keytab

Na koniec musimy jeszcze poinformować cyrus'a gdzie ma szukać klucza. W pliku /etc/sysconfig/cyrus-imapd dodajemy:

export KRB5_KTNAME=/etc/heimdal/cyrus.keytab

Przykładowe programy klienckie, które potrafią użyć protokołu kerberos do uwierzytelnienia użytkownika to evolution i mutt

Apache

Doinstalowujemy moduł apache'a obsługujący uwierzytelnianie za pomocą kerberos'a:

# poldek -i apache-mod_auth_kerb

Dodajemy konto usługi w domenie kerberos'a:

kadmin> add -r HTTP/hostname

hostname zastępując nazwą hosta na którym uruchomiony jest apache.

Exportujemy klucz, zmieniamy uprawnienia:

kadmin> ext HTTP/hostname /etc/heimdal/httpd.keytab
# chown http.root /etc/heimdal/httpd.keytab
# chmod 660 /etc/heimdal/httpd.keytab

lokalizację tablicy kluczy możemy tak jak wcześniej podać apache'owi globalnie przez zmienną środowiskową, dopisując do /etc/sysconfig/apache:

export KRB5_KTNAME=/etc/heimdal/httpd.keytab

Można to także zrobić za pomocą dyrektywy Krb5Keytab w pliku konfiguracyjnym apache'a

Przykładowa konfiguracja dostępu może wyglądać następująco:

<Directory "/home/users/mrk/public_html/kerberos">
        AuthType Kerberos
        AuthName "Kerberos Login"
        KrbMethodNegotiate on
        KrbMethodK5Passwd on
        KrbAuthRealms FOO.PL
        Krb5Keytab /etc/heimdal/httpd.keytab
        require user mrk@FOO.PL
</Directory>

Próba dostępu z prawdopodobnie zakończy się pytaniem o hasło. Naszym celem jest jednak dostęp do serwisu www'a za pomocą biletu kerberos'a, bez zbędnego podawania hasła. W firefox'ie wpisujemy url: about:config, i szukamy pozycji:

network.negotiate-auth.delegation-uris
network.negotiate-auth.trusted-uris

Określają one url'e, dla których przeglądarka ma zastosować rozszerzenie negotiate. Wpisujemy tam nazwy dns naszego serwisu www oddzielone przecinkami. Teraz, jeśli mamy aktualny bilet (sprawdzamy przez klist), powinniśmy zostać wpuszczeni bez pytania o hasło. Rozszerzenie negotiate oprócz firefox'a powinny obsługiwać także mozilla i epiphany - o innych mi nie wiadomo.

 
&lt;- ->