Protokół Kerberos
Artykuł opisuje używaną w domenach Windows 2000 i 2003 wersję protokołu Kerberos.
W przeciwieństwie do protokołu NTLM, Kerberos V5:
1. | Jest opracowaniem otwartych standardów (RFC 1510 w zakresie implementacji i RFC 1964 w zakresie formatu i sposobu przekazywania biletów) co umożliwia, po spełnieniu kilku dodatkowych warunków, korzystanie z niego w środowiskach heterogenicznych, |
2. | Umożliwia delegowanie uprawnień, |
3. | Umożliwia tworzenie relacji zaufania pomiędzy domenami Windows a dowolnym obszarem Kerberos V5, |
4. | Umożliwia tworzenie dwukierunkowych, przechodnich relacji zaufania pomiędzy domenami Windows. |
5. | Nie wymaga od serwerów połączenia z kontrolerem domeny w celu potwierdzenia tożsamości klienta. |
Zawartość strony
 | Podstawowe informacje |
| Zasada działania |
| Konfiguracja |
| Narzędzia |
Podstawowe informacje
Tożsamość użytkownika, komputera lub programu (czyli principium) może zostać potwierdzona jeżeli współdzielą one jakiś sekret. W domenach Windows 2000 i 2003 każde principium ma swój własny sekret:
| • | albo otrzymany w wyniku mieszania (jednokierunkowego przekształcenia) hasła klucz długoterminowy, |
| • | albo, co jest rozszerzeniem standardu Kerberos V5, certyfikat klucza publicznego (poświadczenie). |
W przypadku kluczy długoterminowych współdzielony sekret jest szyfrowany przez jedno principium i za pomocą tego samego klucza (szyfrowanie symetryczne) deszyfrowany przez drugie. Firma Microsoft dodała do protokołu Kerberos (rozszerzając mechanizm wymiany komunikatów KRB_AS_REQ i KRB_AS_REP) obsługę certyfikatów klucza publicznego. Jeżeli użytkownik loguje się za pomocą karty inteligentnej jego poświadczenie szyfrowane jest kluczem publicznym a deszyfrowane przez KDC kluczem prywatnym (szyfrowanie asymetryczne).
Deszyfrując otrzymany i zapisany lokalnie sekret oraz porównując wyniki principium może potwierdzić tożsamość zdalnego principium.
Dane uwierzytelniające
Przesyłane pomiędzy principiami dane uwierzytelniające używane są tylko raz, co eliminuje zagrożenie związane z odsyłaniem przechwyconych przez atakującego danych. Wyjątkiem od tej reguły jest wzajemne uwierzytelnienie obu principiów — w takiej sytuacji wybrane dane potwierdzające tożsamość pierwszego principium (znacznik czasu) są dołączane do odsyłanych do niego danych uwierzytelniających drugiego principium. Strukturę komunikatów uwierzytelniających przedstawia tabela 1.
| Tabela 1. Struktura komunikatów uwierzytelniających. | |
| Nazwa pola | Opis |
authenticator-vno | Numer wersji protokołu Kerberos (5) |
crealm | Nazwa domeny klienta |
cname | Nazwa klienta |
cksum | Suma kontrolna danych |
cusec | Liczba milisekund (od 0 do 999999) wg. zegara komputera klienckiego |
ctime | Czas wysłania wiadomości wg. zegara komputera klienckiego |
subkey | Klucz używany zamiast klucza sesji |
seq-number | Numer identyfikujący aplikację (pole opcjonalne) |
authorization-data | Dane autoryzacyjne (pole opcjonalne) |
Bilet
Bilet jest dokumentem potwierdzającym tożsamość principium. Ten sam bilet może być użyty wielokrotnie, chyba że wygaśnie jego ważność. Chociaż bilety są przesyłane za pośrednictwem różnych komunikatów, ich struktura jest taka sama (tabela 2).
| Tabela 2. Struktura biletu Kerberos V5. | |
| Nazwa pola | Opis |
tkt-vno | Numer wersji protokołu Kerberos (5) |
realm | Nazwa domeny |
sname | Nazwa serwera |
flags | 32 bitowe pole opcji biletu. Używane są następujące bity: 1 — może zostać przesłany dalej, 2 — jest przesyłany dalej, 3 — może zostać przesłany ze wskazanych adresów, 4 — jest przesyłany w cudzym imieniu, 5 — może być postdatowany, 6 — jest postdatowany, 7 — był postdatowany ale ta opcja została wyłączona podczas sprawdzania czasu od którego bilet jest ważny, 8 — może być odnawiany, 9 — bilet jest odpowiedzią na żądanie KRB_AS_REQ, 10 — przed wystawieniem biletu wstępnie potwierdzono tożsamość principium, 11 — wstępnie potwierdzono tożsamość za pomocą zewnętrznego urządzania, 12 — sprawdzono czy wszystkie domeny przez które przesłano bilet są zaufane, 13 — może zostać wykorzystany do delegowania uprawnień, 14 — jest wysłany przez użytkownika anonimowego. |
key | Klucz sesji (SA) |
crealm | Nazwa domeny klienta |
cname | Nazwa klienta |
transited | Nazwy domen przez które bilet był przesyłany |
authtime | Czas utworzenia biletu |
starttime | Czas od którego bilet jest ważny. Jeżeli klient go nie określi albo użyje czasu przeszłego KDC użyje bieżącego czasu zegara systemowego. |
endtime | Czas wygaśnięcia ważności biletu. Może zostać zaproponowany przez klienta, ale KDC ustali go porównując obowiązujący w domenie czas ważności biletów z propozycją klienta i wybierając krótszy z tych czasów . |
renew-till | Czas przez który bilet będzie mógł być odnawiany |
caddr | Poprawne adresy nadawcy |
authorization-data | Dane autoryzacyjne principium. W domenach Windows są to identyfikatory SID użytkownika i wszystkich grup do jakich dany użytkownik należy (PAC). Dane te umożliwiają autoryzację użytkownika na zdalnych komputerach ale jako że użytkownik z reguły należy do wielu grup, ich dołączenie do biletu powoduje że jego rozmiar może znacznie przekraczać 2 KB. |
extensions | Dane wykorzystywane przez aplikacje (pole opcjonalne) |
Informacje z trzech pierwszych pól biletu nie są szyfrowane co ułatwia znalezienie otrzymanych i przechowywanych w chronionym obszarze pamięci biletów.
Odnawianie biletów
Obowiązujące w domenie zasady protokołu Kerberos określają przez ile dni bilety mogą być odnawiane. Jeżeli ważność biletu może zostać przedłużona, KDC w polu renew-till (Renew Till Time) zapisuje maksymalny czas ważności biletu.
Aby odnowić bilet użytkownik musi przed upłynięciem określonego w polu endtime (End Time) czasie jego ważności wysłać nowe dane uwierzytelniające do KDC. Jeżeli ważność biletu może zostać przedłużona, KDC odeśle użytkownikowi kopie biletu ze zmienionym czasem wygaśnięcia ważności i nowym kluczem sesji.
Wstępne potwierdzanie tożsamości
Domyślnie, w domenach Windows wymagane jest wstępne uwierzytelnienie każdego principium. Wykorzystuje się do tego zaszyfrowany znacznik czasu zegara komputera klienckiego. Ponieważ jest to rozszerzenie standardu, dla kont użytkowników którzy muszą być uwierzytelniani w zewnętrznych obszarach Kerberos V5 należy zaznaczyć opcję Nie jest wymagane wstępne uwierzytelnienie protokołu Kerberos.
Uwaga! Ponieważ włączenie tej opcji zwiększa ryzyko ujawnienia klucza długoterminowego, nie należy włączać jej dla kont wysokiego ryzyka. Zamiast tego należy utworzyć nowe konto o ograniczonych uprawnieniach w domenie i posługiwać się nim przy korzystaniu z zasobów zewnętrznych obszarów Kerberos V5. Jeżeli nie jest wymagane wstępne potwierdzenie tożsamości, KDC wyśle bilet TGT na każde żądanie. Atakującemu zostaje odszyfrować otrzymany bilet, czyli złamać klucz długoterminowy użytkownika. Dysponując kluczem atakujący może poznać hasło użytkownika.
Przesyłanie biletów
Standardowo, bilety protokołu Kerberos V5 przesyłane są za pośrednictwem protokołu UDP na port 88. W domenach Windows bilety których rozmiar przekracza 2 000 bajtów przesyłane są za pośrednictwem protokołu TCP na port 88. Wynika to z ograniczenia rozmiaru pojedynczego datagramu Ethernet (1 500 bajtów). Jeżeli rozmiar biletu jest większy niż 1 472 i mniejszy niż 2 000 bajtów bilet zostanie wysłany jako kilka pakietów IP protokołu UDP.
Dane autoryzacyjne
Bilety TGT są szyfrowane kluczem długoterminowym użytkownika a to zapisane w nich dane autoryzacyjne (identyfikatory SID) są dodatkowo podpisywane przez KDC. Zapobiega to próbom poszerzenia uprawnień przez użytkownika polegającym na zgłoszeniu żądania uwierzytelnienia Kerberos, przechwyceniu udzielonego biletu TGT, odszyfrowaniu go i dopisaniu do danych autoryzacyjnych identyfikatory zabezpieczeń grup z wyższym poziomem uprawnień na lokalnym komputerze.
Uwaga! Podsystem zabezpieczeń sprawdza przed zapisaniem biletu TGT w pamięci poprawność podpisu danych autoryzacyjnych. Wyjątkiem od tej reguły jest przedstawienie biletu TGT przez usługę działająca w kontekście zabezpieczeń konta systemowego.
Centrum dystrybucji kluczy
Usługi Kerberos V5 są instalowane na każdym kontrolerze domeny, czyli każdy kontroler domeny pełni funkcję centrum dystrybucji kluczy (KDC). Usługi te są automatycznie uruchamiane i nie mogą zostać wyłączone. Gwarantuje to dostępność i niezawodność usługi — jeżeli preferowane przez użytkownika KDC będzie niedostępne, zostanie znalezione alternatywne.
KDC przechowuje (jako atrybuty obiektów w bazie AD) klucze długoterminowe (i ewentualnie poświadczenia) oraz wydaje uprawniające do uzyskania biletów usługi bilety TGT i uprawniające do skorzystania z określonych zasobów bilety usług.
Każde principium, w tym KDC, musi mieć nazwę. W domenach Windows KDC posługują się (zgodnie ze standardem) nazwą krbtgt. Konto tego użytkownika jest automatycznie tworzone podczas tworzenia domeny, nie może zostać usunięte, nie można też zmienić jego nazwy ani go włączyć.
Uwaga! Chociaż narzędzia systemowe informują, że konto użytkownika krbtgt jest wyłączone, w rzeczywistości jest ono wykorzystywane przez KDC.
Hasło użytkownika krbtgt jest automatycznie generowane i systematycznie zmieniane. To hasło jest, jak w przypadku wszystkich użytkowników, wykorzystywane do obliczenia klucza długoterminowego centrum dystrybucji kluczy (KKDC). Tym kluczem szyfrowane są udzielana przez KDC bilety TGT.
W domenie wszystkie KDC korzystają z tego samego konta, czyli w ramach domeny wszystkie bilety TGT szyfrowane są tym samym kluczem długoterminowym.
Usługa udzielania biletów TGT (AS, Authentication Service)
Logując się do domeny użytkownik wysyła do KDC komunikat KRB_AS_REQ — żądanie uwierzytelnienia usługi Kerberos (tabela 3).
| Tabela 3. Struktura komunikatów KRB_AS_REQ i KRB_TGS_REQ. | |
| Nazwa pola | Opis |
pvno | Numer wersji protokołu Kerberos (5) |
msg-type | Identyfikuje komunikat (KRB_AS_REQ lub KRB_TGS_REQ) |
padata-type | Identyfikuje mechanizm wstępnego potwierdzania tożsamości (PA_AS_REQ) |
padata-value | Zaszyfrowany znacznik czasu |
ap-options | Opcje żądanego biletu: 1 — może zostać przesłany pod podane adresy nadawcy, 2 — jest przesyłany dalej, 3 — może zostać przesłany ze wskazanych adresów, 4 — jest przesyłany w cudzym imieniu, 5 — może być postdatowany, 6 — jest postdatowany, 8 — może być odnawiany, 14 — jest wysłany przez użytkownika anonimowego, 26 — wyłączenie śledzenia domen przez który bilet jest przesyłany, 27 — zezwolenie na tworzenie na jego podatnie kolejnych biletów, 28 — zaszyfrowany kluczem sesji, 30 — wymagający odnowienia, 31 — używany do sprawdzenia poprawności postdatowanych biletów. |
crealm | Nazwa domeny klienta |
cname | Nazwa klienta |
sname | Nazwa KDC |
from | Czas od którego żądany bilet ma być ważny (postdatowanie biletu) |
till | Czas wygaśnięcia ważności biletu |
rtime | Czas do kiedy możliwe będzie odnowienie ważności biletu |
nonce | Pseudolosowa liczba |
etype | Użyty algorytm szyfrowania |
addresses | Adresy nadawcy. Bilet wysłany z tych adresów będzie poprawny. |
enc-authorization-data | Zaszyfrowane dane aplikacji. Pole używane tylko w komunikatach KRB_TGS_REQ. |
additional-tickets | W komunikatach KRB_TGS_REQ możne przesyłać więcej niż jeden bilet. |
Po odebraniu komunikatu żądania uwierzytelnienia usługi Kerberos, KDC weryfikuje jego poprawność. W przypadku błędu odsyłany jest komunikat KDC_ERROR i proces uwierzytelnienia zostaje przerwany. Jeżeli tożsamość użytkownika zostanie potwierdzona, KDC odsyła komunikat KRB_AS_REP — odpowiedź usługi uwierzytelniania Kerberos (tabela 4).
| Tabela 4. Struktura komunikatów KRB_AS_REP i KRB_TGS_REP. | |
| Nazwa pola | Opis |
pvno | Numer wersji protokołu Kerberos (5) |
msg-type | Identyfikuje komunikat (KRB_AS_REP lub KRB_TGS_REP) |
padata | Odebrane dane wstępnego uwierzytelnienia |
crealm | Nazwa domeny klienta |
cname | Nazwa klienta |
ticket | Bilet |
key | Klucz sesji |
last-req | Czas ostatniego żądanie biletu |
nonce | Pseudolosowa liczba |
key-expiration | Czas wygaśnięcia ważności klucza |
flags | Opcje biletu |
authtime | Czas wystawienia biletu |
starttime | Czas od którego bilet jest ważny |
endtime | Czas wygaśnięcia ważności biletu |
renew-till | Czas przez który bilet będzie mógł być odnawiany |
srealm | Domena serwera |
sname | Nazwa serwera |
caddr | Poprawne adresy nadawcy |
Usługa udzielania biletów usługi (TGS, Ticket-Granting Service)
Uwierzytelniony użytkownik zgłasza żądanie wystawienia biletu usługi wysyłając komunikat KRB_TGS_REQ. Struktura tego komunikatu została przedstawiona w tabeli 2. KDC, korzystając z współdzielonego z użytkownikiem sekretu, odszyfrowuje otrzymany komunikat uzyskując w ten sposób klucz TGT. Korzystając z tego klucza odszyfrowuje przesyłane dane uwierzytelniające użytkownika. Jeżeli otrzymane dane są poprawne generowany jest bilet usługi.
KDC szyfruje jedną kopię biletu usługi kluczem TGT użytkownika. Druga kopia biletu usługi zostaje, razem z danymi uwierzytelniającymi użytkownika, zaszyfrowana kluczem TGT świadczącego daną usługę serwera. Obie kopie klucza zostają następnie odesłane w komunikacie KRB_TGS_REP (tabela 4) do użytkownika.
Użytkownik odszyfrowuje swoim kluczem TGT otrzymaną odpowiedź. Uzyskane w ten sposób klucz sesji i bilet usługi zostają zapisane w chronionym obszarze pamięci operacyjnej. Do czasu wygaśnięcia ważności biletu usługi użytkownik może się nim posługiwać w celu nawiązania sesji ze wskazanym serwerem.
Bilet użytkownika (bilet TGT)
Podczas logowania użytkownika wyliczony na podstawie wpisanego hasła klucz długoterminowy jest wysyłany do KDC. Ponieważ KDC przechowuje klucze długoterminowe wszystkich principiów, jest w stanie sprawdzić ich poprawność, a tym samym potwierdzić poprawność hasła.
Wysyłając klucz długoterminowy użytkownik wysyła jednocześnie żądanie wystawienia ważnego przez czas trwania sesji biletu TGT. Bilet TGT jest szyfrowany kluczem długoterminowym KDC, a jego odsyłana do użytkownika kopia kluczem długoterminowym użytkownika. Po otrzymaniu i odszyfrowaniu biletu TGT klucz długoterminowy użytkownika jest usuwany z obszaru pamięci kontrolowanego przez usługę Kerberos, a użytkownik będzie od tej pory potwierdzał swoją tożsamość przechowywanym w chronionym obszarze pamięci biletem TGT.
Uwaga! Kerberos V5 nie jest (co zostało zaznaczone w RFC1510) odporny na ataki polegające na odgadywaniu (za pomocą słownika lub metodą pełnego przeglądu) klucza długoterminowego, o ile atakujący dysponuje materiałem porównawczym. Takiego materiału może dostarczy np. przechwycenie komunikatu KRB_AS_REQ. Ponieważ znajdujący się w nim znacznik czasu szyfrowany jest kluczem długoterminowym użytkownika, to uzyskanie danych w postaci rrrrmmddhhmmssZ w praktyce oznacza złamanie tego klucza — wystarczy sprawdzić czy odszyfrowany tekst zawiera ciąg znaków znanej postaci. Jedynym skutecznym środkiem zapobiegawczym jest uwierzytelnianie użytkowników za pomocą kart inteligentnych. Zagrożone są przede wszystkim konta użytkowników których tożsamość nie jest wstępnie potwierdzana.
W ramach jednej sesji użytkownik prawdopodobnie będzie wielokrotnie potwierdzał swoją tożsamość. Przesyłając do KDC bilet TGT (KDC przechowuje zaszyfrowane swoim kluczem długoterminowym kopie udzielonych biletów TGT może więc potwierdzać ich autentyczność) użytkownik za każdym razem wyśle inne dane uwierzytelniające.
Jeżeli ważność biletu TGT wygaśnie, KDC odrzuci taki bilet, a użytkownik będzie musiał ponownie wysłać żądanie uwierzytelnienia usługi Kerberos. Wysłanie żądania uwierzytelniania wymaga posłużenia się kluczem długoterminowym. Żeby użytkownik nie musiał ponownie podawać hasła, podsystem zabezpieczeń LSA przechowuje w pamięci klucz długoterminowy zalogowanego użytkownika. Klucz długoterminowy i bilety TGT nigdy nie są zapisywane na dysku (w tym w pliku wymiany) i są kasowane podczas wylogowywania użytkownika.
Atak na hasło użytkownika
Czy używając w domenie wyłącznie protokołu Kerberos V5 możemy nie obawiać się ataków polegających na przechwyceniu danych uwierzytelniających i zdobyciu na ich podstawie hasła użytkownika? Nie. Dostępne w Internecie programy Arne Vidstrom’a prawie całkowicie automatyzuje taki atak:
Po pierwsze, atakujący musi zdobyć dane uwierzytelniające, np. uruchamiając program KerbSniff:
C:\>kerbsniff klucze
KerbSniff 1.2 - (c) 2002, Arne Vidstrom
- http://ntsecurity.nu/toolbox/kerbcrack/
Captured packets: **Po zdobyciu pokazanych na listingu 1 danych atakujący spróbuje poznać hasło użytkownika.
testkrb INTRANET 27312F3871E385742E4B778223CAF8127A2D3D4F4C7D548305E9DB69DD83B6B0A8E6A43E33C0D8449A4BEDB36DFC7CC28EA8A92D #
Listing 1. Przechwycone nazwa konta, domeny i klucz przykładowego użytkownika
Ponieważ wyprowadzanie hasła z klucza jest praktycznie niemożliwe, aby go zdobyć atakujący wyliczy sygnatury wszystkich możliwych haseł — otrzymanie tej samej sygnatury oznacza zdobycie hasła:
C:\>kerbcrack.exe key -d slownik.lst
KerbCrack 1.2 - (c) 2002, Arne Vidstrom
- http://ntsecurity.nu/toolbox/kerbcrack/
Loaded capture file.
Currently working on:
Account name - testkrb
From domain - INTRANET
Trying password - Tajne-Hasl0
Number of cracked passwords this far: 2Jedyną obroną przed atakami tego typu, poza stosowaniem kart inteligentnych, jest wymuszenie na użytkownikach:
1. | stosowania długich i skomplikowanych haseł, |
2. | systematycznego ich zmieniania. |
Ponieważ takie hasła nie będą prawdopodobnie znajdować się w słowniku, atakujący będzie zmuszony sprawdzać wszystkie kombinacje liter, cyfr i znaków specjalnych. Przy regularnie zmienianych, dłużnych niż 12 znakowe hasłach ryzyko udanego ataku będzie dużo mniejsze.
Bilet usługi (bilet sesji)
Jeżeli użytkownik chce skorzystać z zasobów wskazanego serwera wysyła do KDC żądanie wystawienia biletu usługi. Otrzymany bilet usługi służy do wzajemnego uwierzytelnienia klienta i serwera.
Bilet usługi wystawiany jest na określony czas. Komputery klienckie (nie serwery) przechowują ważne bilety usług w pamięci, dzięki czemu ponowne nawiązanie sesji z serwerem trwa o wiele krócej. Po upływie terminu ważności biletu usługi użytkownik który chce nadal korzystać z zasobów serwera musi wysłać do KDC żądanie wystawianie nowego biletu usługi. Chociaż serwery odrzucają nieważne bilety usług to jeżeli ważność biletu usługi wygaśnie po nawiązaniu sesji, nie zostanie ona przerwana.
Uwaga! Bilety usług przechowywane są na czas sesji użytkownika w pamięci RAM i po jego wylogowaniu są kasowane.
Usługa wymiany biletów usługi (CS, Client/Server)
Wymiana biletów usługi ma miejsce gdy klient wysyła, w ramach komunikatu KRB_AP_REQ, otrzymany od KDC bilet usługi do świadczącego tą usługę serwera (tabela 5).
| Tabela 5. Struktura komunikatu KRB_AP_REQ. | |
| Nazwa pola | Opis |
pvno | Numer wersji protokołu Kerberos (5) |
msg-type | Identyfikuje komunikat (KRB_AP_REQ) |
ap-options | Używane są następujące bity: 1 — bilet został zaszyfrowany kluczem sesji a nie kluczem długoterminowym serwera, 2 — wymagane jest wzajemne uwierzytelnienie. |
ticket | Bilet usługi |
authenticator | Dane uwierzytelniające użytkownika |
Po otrzymaniu biletu usługi serwer odszyfrowuje go swoim kluczem długoterminowym uzyskując zaszyfrowane dane uwierzytelniające użytkownika i umożliwiający ich odszyfrowanie klucz sesji (KAB). Po odszyfrowaniu i sprawdzeniu autentyczności otrzymanych danych uwierzytelniających serwer może potwierdzić swoją tożsamość przed użytkownikiem. Jeżeli wymagane było wzajemne uwierzytelnienie, serwer szyfruje kluczem sesji otrzymany znacznik czasu i odsyła go w ramach komunikatu KRB_AP_REP do klienta (tabela 6).
| Tabela 6. Struktura komunikatu KRB_AP_REQ. | |
| Nazwa pola | Opis |
pvno | Numer wersji protokołu Kerberos (5) |
msg-type | Identyfikuje komunikat (KRB_AP_REP) |
ctime | Czas zegara systemowego komputer klienckiego odczytany z danych uwierzytelniających |
cusec | Liczba milisekund zegara systemowego komputer klienckiego odczytana z danych uwierzytelniających |
subkey | Klucz sesji |
sequence number | Pole opcjonalne — używane jeżeli dane uwierzytelniające zawierały identyfikator aplikacji |
Po otrzymaniu odpowiedzi klient, używając tego samego klucza sesji odszyfrowuje dane uwierzytelniające serwera i porównuje otrzymany wraz z nimi i wysłany przez siebie znacznik czasu. Jeżeli oba znaczniki mają tą samą wartość, tożsamość serwera jest potwierdzona i sesja zostanie nawiązana.
Uwaga! Jeżeli nie jest wymagane wzajemne uwierzytelnienie serwera i klienta, atakujący może przeprowadzić skuteczny atak typu man-in-the-middle.
Zasada działania
Uwierzytelnianie w obrębie domeny
Proces uwierzytelnienia użytkownika w domenie na podstawie podanego hasła przebiega następująco:
1. | Użytkownik logując się wprowadza nazwę i hasło. |
2. | Nazwa użytkownika zostaje przesłana do KDC. KDC odczytuje zapisany w bazie AD klucz długoterminowy danego użytkownika. |
3. | Jeżeli potwierdzenie tożsamości użytkownika wymaga wstępnego potwierdzenia (ustawienie domyślne) KDC deszyfruje długoterminowym kluczem użytkownika otrzymany znacznik czasu i sprawdza jego poprawność. Poprawny wynik oznacza że użytkownik posłużył się właściwym kluczem długoterminowym. W przypadku błędu proces uwierzytelnienia zostaje przerwany. |
4. | KDC generuje klucz sesji (SA) i bilet TGT. Bilet TGT zawiera min. kopię klucza sesji, nazwę użytkownika i czas wygaśnięcia biletu. |
5. | KDC szyfruje bilet TGT własnym kluczem długoterminowym (KKDC) a jego odsyłaną użytkownikowi kopię — kluczem długoterminowym użytkownika. |
6. | Po otrzymaniu biletu TGT klient oblicza sygnaturę wprowadzonego hasła i używa jej do odszyfrowania biletu. Jeżeli użytkownik podał prawidłowe hasło, od tego momentu dysponuje biletem TGT i kluczem sesji. |
7. | Klient który chce skorzystać z dostępnej w domenie usługi, wysyła do KDC bilet TGT zawierający zaszyfrowany kluczem sesji znacznik czasu. Uwaga! Użytkownik zgłasza co najmniej jedno żądanie udzielenie biletu usługi — biletu dostępu do komputera na którym właśnie się loguje. W domenach Windows 2000 i 2003 każdy komputer ma swoje, chronione automatycznie wygenerowanym i regularnie zmienianym hasłem, konto. |
8. | KDC odszyfrowuje bilet TGT swoim kluczem długoterminowym i następnie odszyfrowuje współdzielonym z użytkownikiem kluczem sesji dane uwierzytelniające (znacznik czasu). Ponieważ tylko dany użytkownik i KDC znają klucz sesji, tożsamość użytkownika zostaje potwierdzona. |
9. | KDC generuje parę biletów usługi — każdy z nich zawiera min. nazwę klienta i serwera, czas utworzenia i wygaśnięcia ich ważności oraz klucz (KAB) który będzie wspólną tajemnicą klienta i serwera. |
10. | KDC szyfruje kluczem długoterminowym serwera (KB) przeznaczoną dla serwera kopię biletu usługi i umieszcza ją w przeznaczonej dla klienta kopii tego biletu. |
11. | Klient odszyfrowuje kluczem sesji otrzymany bilet usługi. Ponieważ nie zna wspólnego sekretu KDC i serwera, nie jest w stanie odczytać kopii serwera biletu usługi. |
12. | Klient szyfruje znacznik czasu kluczem KAB i wysyła go, razem z kopią serwera biletu usługi, do serwera. |
13. | Serwer odszyfrowuje swoim kluczem długoterminowym bilet usługi. Uzyskany w ten sposób klucz KAB używany jest do odszyfrowania znacznika czasu. W tym momencie klient potwierdził swoją tożsamość przed serwerem (znał klucz KAB i znacznik czasu). Jeżeli wymagane jest wzajemne uwierzytelnienie, serwer odeśle zaszyfrowany przez siebie kluczem KAB znacznik czasu. Ponieważ do posłużenie się kluczem KAB niezbędna jest znajomość klucza długoterminowego, serwer potwierdzi swoją tożsamość przed użytkownikiem. |
Uwierzytelnianie pomiędzy domenami
Proces potwierdzania tożsamości użytkownika z poza domeny serwera przebiega następująco:
1. | Użytkownik loguje się do domeny A. |
2. | W opisany powyżej sposób KDC domeny A wystawia użytkownikowi bilet TGT. |
3. | Klient który chce skorzystać z dostępnej w domenie B usługi żąda od KDC domeny A udzielenia biletu usługi. |
4. | KDC na podstawie nazwy serwera sprawdza, czy należy od do domeny A, a w następnej kolejności, czy ten serwer nie znajduje się w zaufanych domenach. Jeżeli tak, udziela klientowi biletu TGT zaszyfrowanego wspólnym dla obu zaufanych domen kluczem obiektu TDO (relacji zaufania miedzy domenami). |
5. | Klient wysyła otrzymany bilet TGT do KDC w domenie B. |
6. | Jeżeli KDC docelowej domeny pomyślnie odszyfruje otrzymany bilet, udziela użytkownikowi domeny A biletu usługi serwera domeny B. |
7. | W opisany powyżej sposób klient korzystając z otrzymanego biletu usługi nawiązuję sesję z danym serwerem. |
Delegowanie uprawnień
Pierwsze cztery bity opcji biletu Kerberos V5 umożliwiają delegowanie uprawnień — przedstawianie przez serwer z którym połączył się użytkownik (serwer A) jego poświadczenia bezpieczeństwa serwerowi B. Dzięki temu aplikacje uzyskują do rozproszonych zasobów tylko taki poziom dostępu jaki został nadany danemu użytkownikowi.
Uwaga! W domenach Windows do delegowania uprawnień używane są wyłącznie opcje Forwardable (ustawiony 1 bit) i Forwarded (ustawiony 2 bit).
Ponieważ uwierzytelnianie odbywa się na podstawie biletów, serwer A musiałby dysponować biletem który mógłby przedstawić serwerowi B. Tyle że użytkownik z reguły nie zna nazwy serwera B, a więc nie może zgłosić żądania wystawienia biletu którym mógłby posłużyć się serwer A — taki bilet musiałby w polu caddr (Client Address) mieć wpisaną nazwę serwera A i zostać oznaczony jako Proxiable (ustawiony 3 bit pola opcji). Zaimplementowane w domenach Windows rozwiązanie tego problemu polega na przesłaniu przez użytkownika do serwera A biletu TGT który będzie mógł zostać przesłany przez ten serwer do innych serwerów.
Delegowanie uprawnień przebiega następująco:
1. | Przy założeniu że konto użytkownika nie jest wrażliwe i może być delegowane, użytkownik zgłasza żądanie wystawienia biletu TGT z ustawionym 1 bitem opcji. Żądanie to musi zawierać nazwę serwera A. |
2. | Jeżeli komputer, na którym działa ten serwer jest zaufany i może być delegowany, to KDC wystawi taki bilet i odeśle go do użytkownika. |
3. | Otrzymany bilet użytkownik wysyła do serwera A. |
4. | Gdy realizacja żądania użytkownika będzie wymagała od serwera A odwołanie się do zasobów serwera B, a konto w kontekście zabezpieczeń których działa ten serwer jest zaufane i może być delegowane, to serwer prześle bilet TGT użytkownika do KDC. |
5. | Na podstawie otrzymanego biletu KDC udzieli serwerowi A biletu umożliwiającego nawiązanie sesji z serwerem B. |
6. | Serwer A posłuży się otrzymanym biletem aby nawiązać w imieniu użytkownika sesję z serwerem B. |
Konfiguracja
Zasady protokołu Kerberos V5 ustalane są dla kont użytkowników domeny (znajdują się w sekcji Konfiguracja komputera/Ustawienia systemu Windows/Ustawienia zabezpieczeń/Zasady kont/Zasady protokołu Kerberos) zasad grupy:
| • | Wymuszaj ograniczenia logowania użytkowników — domyślnie włączona zasada sprawdzania przed udzieleniem biletu sesji uprawnień użytkownika na komputerze docelowym (np. czy użytkownik ma prawo uzyskiwać dostęp do wskazanego komputera przez sieć i czy po otrzymaniu biletu konto użytkownika nie zostało zablokowane). |
| • | Maksymalny okres istnienia biletu usługi — domyślnie bilety usług są ważne przez 600 minut. Wartość opcji musi być większa niż 10 minut, ale nie większa niż okres istnienia biletu TGT. |
| • | Maksymalny okres istnienia biletu użytkownika — domyślnie bilety TGT są ważne przez 10 godzin. |
| • | Maksymalny okres istnienia odnowienia biletu użytkownika — domyślnie bilety TGT mogą być odnawiane przez 7 dni. |
| • | Maksymalna tolerancja synchronizacji zegara komputerowego — dopóki różnica wskazań zegarów klienta i kontrolera domeny jest mniejsza niż ustalona (domyślnie 5 minut) przesyłane znaczniki czasu są uważana za autentyczne. |
Narzędzia
Pakiet Resorce Kit zawiera dwa narzędzia pozwalające zarządzać biletami Kerberos:
| • | Kerberos List (klist) jest programem wiersza polecenia pozwalającym na przeglądanie i usuwanie biletów aktualnie zalogowanego na lokalnym komputerze użytkownika. |
| • | Kerberos Tray jest graficznym programem którego uruchomienie sygnalizowane jest ikoną na pasku stanu. Po dwukrotnym kliknięciu tej ikony możemy przeglądać i usuwać bilety zalogowanego użytkownika. |
Pomocny przy rozwiązywaniu problemów związanych z uwierzytelnianiem będzie również program wiersza polecenia cmdkey — umożliwia on tworzywie, przeglądanie i usuwanie przechowywanych nazw użytkowników i haseł lub poświadczeń.
 | Marcin Szeliga (MCP+I, MCSE, MCDBA, MCSD, MCT) |