Jak działa Kerberos krok po kroku – mechanizm uwierzytelniania w Active Directory od środka

W środowisku Windows logowanie użytkownika do domeny wydaje się prostym procesem. Pracownik wpisuje nazwę użytkownika i hasło, komputer łączy się z domeną, a po chwili otrzymuje dostęp do plików, drukarek i aplikacji.

Za tym prostym działaniem kryje się jednak jeden z najważniejszych protokołów bezpieczeństwa stosowanych w systemach Microsoft – Kerberos.

To właśnie Kerberos odpowiada za bezpieczne uwierzytelnianie użytkowników w Active Directory i umożliwia dostęp do zasobów bez przesyłania hasła przez sieć.

Jego działanie jest niewidoczne dla użytkownika, ale każdego dnia wykonują go tysiące organizacji na całym świecie.

Dlaczego powstał Kerberos?

Starsze mechanizmy uwierzytelniania miały poważny problem.

Jeżeli komputer chciał sprawdzić tożsamość użytkownika, często musiał przesłać informacje umożliwiające potwierdzenie hasła.

To tworzyło ryzyko:

• przechwycenia danych,
• podsłuchu sieciowego,
• ataków typu replay,
• kradzieży poświadczeń.

Kerberos rozwiązuje ten problem inaczej.

Zamiast ciągle wysyłać hasło, użytkownik po jednorazowym uwierzytelnieniu otrzymuje bilety (tickets), które potwierdzają jego tożsamość.

System nie pyta:

„Podaj ponownie hasło.”

Pyta:

„Pokaż ważny bilet potwierdzający, że jesteś tym użytkownikiem.”

Główne elementy Kerberos w Active Directory

Aby zrozumieć działanie Kerberos, trzeba poznać kilka podstawowych elementów.

Key Distribution Center (KDC)

Centralnym elementem Kerberos jest:

KDC – Key Distribution Center

W środowisku Windows jego rolę pełni kontroler domeny.

KDC składa się z dwóch części:

Authentication Service (AS)

Odpowiada za pierwsze uwierzytelnienie użytkownika.

Jego zadanie:

• sprawdzić użytkownika,
• wydać pierwszy bilet.

Ticket Granting Service (TGS)

Odpowiada za wydawanie biletów do konkretnych usług.

Przykład:

Użytkownik chce wejść na:

• udział sieciowy,
• serwer SQL,
• aplikację firmową.

TGS wydaje odpowiedni bilet.

Ticket Granting Ticket (TGT)

Najważniejszym biletem Kerberos jest:

TGT – Ticket Granting Ticket

Można go traktować jako:

„certyfikat tymczasowy potwierdzający, że użytkownik został poprawnie uwierzytelniony.”

Po zalogowaniu użytkownik nie otrzymuje od razu dostępu do wszystkich zasobów.

Najpierw otrzymuje TGT.

Dopiero później wykorzystuje go do uzyskiwania kolejnych biletów.

Kerberos krok po kroku

Prześledźmy typowe logowanie użytkownika domenowego.

Załóżmy:

Użytkownik:

jan.kowalski

Domena:

firma.local

Chce otworzyć:

\\serwer01\dokumenty

Krok 1 – logowanie użytkownika

Użytkownik wpisuje:

• nazwę konta,
• hasło.

Komputer nie wysyła hasła do kontrolera domeny.

Zamiast tego tworzy specjalne żądanie:

AS-REQ (Authentication Service Request)

Zawiera ono między innymi:

• nazwę użytkownika,
• nazwę domeny,
• informacje kryptograficzne,
• znacznik czasu.

Krok 2 – kontroler domeny sprawdza użytkownika

Kontroler domeny odbiera żądanie.

Sprawdza:

• czy konto istnieje,
• czy hasło jest poprawne,
• czy konto jest aktywne,
• czy użytkownik może się logować.

W Active Directory informacje o użytkowniku przechowywane są między innymi w bazie:

NTDS.dit

Jeżeli wszystko jest poprawne, KDC odpowiada:

AS-REP (Authentication Service Response)

Krok 3 – wydanie TGT

Kontroler domeny tworzy:

Ticket Granting Ticket

TGT zawiera między innymi:

• identyfikator użytkownika,
• czas ważności,
• informacje o grupach,
• dane zabezpieczone kryptograficznie.

Bilet jest zaszyfrowany kluczem kontrolera domeny.

Użytkownik zapisuje go lokalnie w pamięci systemu.

Można go sprawdzić poleceniem:

klist

Przykład:

krbtgt/FIRMA.LOCAL

Krok 4 – użytkownik chce uzyskać dostęp do zasobu

Teraz użytkownik otwiera:

\\serwer01\dokumenty

Komputer nie wysyła hasła.

Wysyła żądanie:

TGS-REQ

do usługi Ticket Granting Service.

W żądaniu znajduje się:

• TGT,
• informacja o żądanej usłudze.

Krok 5 – TGS wydaje Service Ticket

Kontroler domeny sprawdza TGT.

Jeżeli wszystko jest poprawne, generuje:

Service Ticket

czyli bilet przeznaczony dla konkretnej usługi.

Przykład:

Dostęp do serwera plików:

cifs/serwer01.firma.local

Dla SQL Server:

MSSQLSvc/sql01.firma.local

Krok 6 – dostęp do zasobu

Komputer użytkownika przesyła Service Ticket do serwera.

Jest to:

AP-REQ (Application Request)

Serwer sprawdza:

• czy bilet jest prawidłowy,
• czy pochodzi z zaufanego KDC,
• czy użytkownik posiada odpowiednie uprawnienia.

Jeżeli tak:

dostęp zostaje przyznany.

Całość odbywa się bez przesyłania hasła.

Schemat całego procesu

W uproszczeniu wygląda to tak:

Użytkownik
    |
    | AS-REQ
    ↓
Kontroler domeny (KDC)
    |
    | AS-REP
    ↓
TGT
    |
    | TGS-REQ
    ↓
KDC
    |
    | TGS-REP
    ↓
Service Ticket
    |
    ↓
Serwer zasobu
    |
    ↓
Dostęp

Dlaczego Kerberos używa biletów?

Największą zaletą jest brak przesyłania hasła.

Po pierwszym uwierzytelnieniu:

• użytkownik posiada TGT,
• usługi otrzymują bilety,
• komunikacja opiera się na kryptografii.

Zmniejsza to ryzyko:

• podsłuchu,
• przechwycenia hasła,
• wielokrotnego użycia danych logowania.

Kerberos i Active Directory – rola SPN

Jednym z ważnych elementów Kerberos są:

Service Principal Names (SPN).

SPN określa, jaka usługa działa na jakim koncie.

Przykład:

MSSQLSvc/sql01.firma.local:1433

oznacza:

• usługa SQL,
• serwer sql01,
• port 1433.

Kiedy użytkownik chce połączyć się z usługą, Kerberos musi wiedzieć:

„Dla którego konta mam wygenerować bilet?”

Do tego właśnie służą SPN.

Kerberos a DNS

Kerberos jest mocno zależny od DNS.

Jeżeli DNS działa źle, mogą pojawić się problemy:

• brak logowania domenowego,
• przejście na NTLM,
• błędy przy dostępie do usług.

Przykład:

Użytkownik wpisuje:

\\serwer01

System musi znaleźć poprawną nazwę domenową:

serwer01.firma.local

i powiązany SPN.

Kerberos Delegation – przekazywanie uprawnień

Kerberos posiada również mechanizm delegacji.

Pozwala usłudze działać w imieniu użytkownika.

Przykład:

Użytkownik korzysta z aplikacji WWW.

Aplikacja musi pobrać dane z SQL Server.

Bez delegacji SQL widzi:

„łączy się aplikacja”.

Z delegacją może zobaczyć:

„użytkownik Jan Kowalski wykonuje zapytanie”.

Stosuje się między innymi:

• Unconstrained Delegation,
• Constrained Delegation,
• Resource-Based Constrained Delegation.

Najbezpieczniejsza jest zazwyczaj ograniczona delegacja.

Najczęstsze ataki na Kerberos

Kerberos jest bardzo bezpieczny, ale błędna konfiguracja może stworzyć problemy.

Kerberoasting

Atakujący pobiera bilety usług i próbuje offline łamać hasła kont usługowych.

Ryzyko rośnie, gdy:

• konta usług mają słabe hasła,
• używane są stare algorytmy szyfrowania.

Pass-the-Ticket

Atakujący kradnie istniejący bilet Kerberos i używa go ponownie.

Dlatego ważne są:

• ochrona kont uprzywilejowanych,
• ograniczenie logowania administratorów,
• tiering administracyjny.

Golden Ticket

Jeden z najgroźniejszych scenariuszy.

Jeżeli atakujący zdobędzie klucz konta:

krbtgt

może tworzyć fałszywe bilety Kerberos.

Dlatego konto krbtgt jest jednym z najważniejszych elementów bezpieczeństwa domeny.

Diagnostyka Kerberos w Windows

Podstawowym narzędziem jest:

klist

Pozwala sprawdzić:

• aktualne bilety,
• czas wygaśnięcia,
• używane usługi.

Czyszczenie cache:

klist purge

Przydatne narzędzia:

setspn

do zarządzania SPN.

oraz:

nltest

do diagnostyki domeny.

Kerberos kontra NTLM

Windows nadal posiada starszy mechanizm:

NTLM.

Kerberos jest jednak preferowany.

Porównanie:

Jeżeli środowisko korzysta z NTLM zamiast Kerberos, często oznacza to problem z konfiguracją.

Podsumowanie

Kerberos jest fundamentem uwierzytelniania w Active Directory. Jego działanie opiera się na prostym, ale bardzo skutecznym założeniu:

użytkownik nie udowadnia swojej tożsamości hasłem przy każdym dostępie – otrzymuje kryptograficzne bilety potwierdzające jego uprawnienia.

Cały proces:

1. użytkownik loguje się do domeny,
2. otrzymuje TGT,
3. żąda biletu do konkretnej usługi,
4. otrzymuje Service Ticket,
5. uzyskuje dostęp do zasobu.

Zrozumienie Kerberos jest kluczowe dla każdego administratora Active Directory, ponieważ większość zaawansowanych mechanizmów Windows – od logowania domenowego po dostęp do serwerów i aplikacji – opiera się właśnie na tym protokole.

Polecane wpisy

Integracja SQL Server z Active Directory na Windows Server – Przewodnik dla Administratorów

Integracja SQL Server z Active Directory na Windows Server – Przewodnik dla Administratorów Wstęp Integracja SQL Server z Active Directory Czytaj dalej

Bezpieczne używanie PowerShell – najczęstsze błędy administratorów i jak ich unikać

Bezpieczne używanie PowerShell – najczęstsze błędy administratorów i jak ich unikać PowerShell jest potężnym narzędziem administracyjnym w systemach Windows, umożliwiającym Czytaj dalej