Co to jest Kerberos? Protokół uwierzytelniania w sieciach komputerowych

W świecie cyberbezpieczeństwa uwierzytelnianie stanowi pierwszą linię obrony przed nieautoryzowanym dostępem do zasobów sieciowych. Spośród protokołów uwierzytelniania stosowanych w środowiskach korporacyjnych Kerberos zajmuje pozycję absolutnie dominującą — jest domyślnym mechanizmem uwierzytelniania w Active Directory, a tym samym fundamentem bezpieczeństwa milionów organizacji na całym świecie. Zrozumienie tego, jak działa Kerberos, jakie są jego słabe strony i jak go prawidłowo zabezpieczyć, jest niezbędne dla każdego specjalisty ds. bezpieczeństwa IT.

W tym artykule szczegółowo wyjaśnimy architekturę i mechanizmy działania protokołu Kerberos, porównamy go z NTLM, omówimy najpoważniejsze ataki wykorzystujące jego słabości oraz przedstawimy najlepsze praktyki ochrony infrastruktury opartej na tym protokole.

Co to jest Kerberos?

Kerberos to sieciowy protokół uwierzytelniania oparty na biletach (tickets), zaprojektowany w celu bezpiecznego potwierdzania tożsamości użytkowników i usług w niezaufanej sieci. Jego fundamentalną cechą jest to, że hasło użytkownika nigdy nie jest przesyłane przez sieć — zamiast tego stosowany jest system biletów kryptograficznych wystawianych przez zaufaną trzecią stronę.

Nazwa protokołu pochodzi od Cerberusa (Kerberos w greckiej mitologii) — trójgłowego psa strzegącego wrót do Hadesu. Analogia jest trafna: protokół chroni dostęp do zasobów sieciowych, a trzy „głowy” reprezentują trzy strony uczestniczące w procesie uwierzytelniania — klienta, serwer i Key Distribution Center (KDC).

Historia i ewolucja

Kerberos został opracowany w Massachusetts Institute of Technology (MIT) w ramach projektu Athena na początku lat 80. XX wieku. Celem projektu było stworzenie bezpiecznego systemu uwierzytelniania dla kampusowej sieci komputerowej, w której tysiące użytkowników korzystało ze współdzielonych stacji roboczych i serwerów.

• Kerberos v1-v3 (1983-1987) — wersje wewnętrzne MIT, nigdy nie zostały upublicznione.
• Kerberos v4 (1989) — pierwsza wersja wydana publicznie. Używała szyfrowania DES i miała ograniczenia w zakresie interoperacyjności między różnymi domenami (realms).
• Kerberos v5 (1993, RFC 1510; zaktualizowany w 2005 jako RFC 4120) — obecna wersja. Wprowadza wsparcie dla wielu algorytmów szyfrowania, delegowanie poświadczeń, cross-realm authentication i mechanizmy pre-authentication. To ta wersja jest używana we współczesnych systemach.

W 2000 roku Microsoft zaimplementował Kerberos v5 jako domyślny protokół uwierzytelniania w Windows 2000 i Active Directory, co uczyniło go de facto standardem w środowiskach korporacyjnych. Implementacja Microsoftu wprowadza pewne rozszerzenia (np. PAC — Privilege Attribute Certificate), które wykraczają poza czysty standard RFC.

Architektura Kerberos — kluczowe komponenty

Zrozumienie architektury Kerberos wymaga poznania kilku fundamentalnych elementów, które współdziałają w procesie uwierzytelniania.

Key Distribution Center (KDC)

KDC to centralny punkt zaufania w infrastrukturze Kerberos. W środowisku Active Directory rolę KDC pełni każdy kontroler domeny (Domain Controller). KDC składa się z dwóch logicznych komponentów:

• Authentication Server (AS) — odpowiada za wstępne uwierzytelnienie użytkownika i wystawienie biletu TGT. To tutaj weryfikowane jest, czy użytkownik jest tym, za kogo się podaje.
• Ticket Granting Server (TGS) — wystawia bilety usługowe (service tickets) na podstawie ważnego TGT. Dzięki temu użytkownik nie musi ponownie podawać hasła przy dostępie do kolejnych zasobów.

KDC przechowuje bazę danych wszystkich kont (principals) wraz z ich kluczami kryptograficznymi. W Active Directory ta baza jest zintegrowana z bazą NTDS.dit na kontrolerze domeny.

Ticket Granting Ticket (TGT)

TGT to bilet uzyskiwany po początkowym uwierzytelnieniu. Można go porównać do tymczasowej przepustki — po jednorazowym potwierdzeniu tożsamości użytkownik otrzymuje TGT, który umożliwia mu żądanie biletów do konkretnych usług bez ponownego podawania hasła. TGT jest zaszyfrowany kluczem konta KRBTGT — specjalnego konta usługowego w Active Directory, którego kompromitacja ma katastrofalne konsekwencje (o czym szerzej w sekcji o atakach).

Domyślny czas ważności TGT w Active Directory wynosi 10 godzin, z możliwością odnawiania przez 7 dni.

Service Ticket (TGS)

Service Ticket (bilet usługowy, często też nazywany biletem TGS) to bilet wystawiany przez Ticket Granting Server, umożliwiający dostęp do konkretnej usługi — np. udziału sieciowego, bazy danych czy serwera webowego. Bilet ten jest zaszyfrowany kluczem konta usługowego docelowego serwera, więc tylko ten serwer może go odszyfrować i zweryfikować.

Service Principal Name (SPN)

SPN to unikalna nazwa identyfikująca instancję usługi w środowisku Kerberos. Format SPN to zazwyczaj:

serviceclass/host:port/servicename

Na przykład:

HTTP/intranet.firma.pl
MSSQLSvc/sql01.firma.pl:1433
CIFS/fileserver.firma.pl

SPN jest kluczowy dla prawidłowego działania Kerberos — klient musi znać SPN usługi, aby zażądać odpowiedniego biletu od TGS. Nieprawidłowa konfiguracja SPN to jedna z najczęstszych przyczyn problemów z uwierzytelnianiem Kerberos.

Realm

Realm (w Active Directory odpowiednikiem jest domena) to granica administracyjna, w której działa jeden KDC. Kerberos umożliwia uwierzytelnianie między różnymi realmami (cross-realm authentication) za pomocą relacji zaufania (trust relationships). W Active Directory odpowiednikiem są relacje zaufania między domenami i lasami (forests).

Jak działa uwierzytelnianie Kerberos?

Proces uwierzytelniania Kerberos składa się z trzech głównych faz, które można opisać jako wymianę sześciu komunikatów.

Faza 1: Authentication Service Exchange (AS Exchange)

Użytkownik loguje się na stacji roboczej, podając login i hasło. Stacja robocza nie wysyła hasła do KDC — zamiast tego wykonuje następujące kroki:

1. AS-REQ (Authentication Service Request) — klient wysyła do AS żądanie zawierające swoją nazwę (principal), żądany czas ważności biletu oraz znacznik czasu (timestamp) zaszyfrowany kluczem derived z hasła użytkownika. Ten zaszyfrowany znacznik czasu to mechanizm pre-authentication (PA-ENC-TIMESTAMP), który zapobiega atakom offline na bazę KDC.

2. AS-REP (Authentication Service Reply) — AS weryfikuje dane w bazie KDC. Jeśli pre-authentication jest poprawna, AS odpowiada dwoma elementami:

   • TGT zaszyfrowany kluczem konta KRBTGT (klient nie może go odszyfrować — jest przeznaczony wyłącznie dla TGS).
   • Session Key (klucz sesji) zaszyfrowany kluczem użytkownika — klient odszyfrowuje go za pomocą klucza wyprowadzonego z hasła i używa do dalszej komunikacji z TGS.

Po tej fazie klient posiada TGT i klucz sesji. Hasło użytkownika zostaje usunięte z pamięci stacji roboczej — nie jest już potrzebne do dalszego uwierzytelniania.

Faza 2: Ticket Granting Service Exchange (TGS Exchange)

Gdy użytkownik chce uzyskać dostęp do konkretnej usługi (np. otworzyć udział sieciowy), klient wykonuje następujące kroki:

3. TGS-REQ (Ticket Granting Service Request) — klient wysyła do TGS żądanie zawierające:

   • TGT uzyskany w fazie 1
   • SPN usługi, do której chce uzyskać dostęp
   • Authenticator — znacznik czasu zaszyfrowany kluczem sesji (dowód, że klient zna klucz sesji)

4. TGS-REP (Ticket Granting Service Reply) — TGS odszyfrowuje TGT za pomocą klucza KRBTGT, weryfikuje authenticator, a następnie odpowiada:

   • Service Ticket zaszyfrowany kluczem konta usługowego docelowego serwera
   • Nowy klucz sesji do komunikacji klient-serwer, zaszyfrowany kluczem sesji z fazy 1

Faza 3: Client/Server Exchange (AP Exchange)

5. AP-REQ (Application Request) — klient przedstawia Service Ticket docelowemu serwerowi wraz z nowym authenticatorem (zaszyfrowanym kluczem sesji klient-serwer).

6. AP-REP (Application Reply) — serwer odszyfrowuje Service Ticket za pomocą swojego klucza, weryfikuje authenticator i — jeśli wszystko jest poprawne — przyznaje dostęp do usługi. Opcjonalnie serwer może odpowiedzieć zaszyfrowanym znacznikiem czasu, potwierdzając swoją tożsamość klientowi (mutual authentication).

Cały ten proces odbywa się transparentnie dla użytkownika — po jednorazowym zalogowaniu się uzyskuje on dostęp do wielu usług bez ponownego podawania hasła. To właśnie jest mechanizm Single Sign-On (SSO) wbudowany w Kerberos.

Kerberos vs NTLM — porównanie protokołów

W środowiskach Windows Kerberos współistnieje z starszym protokołem NTLM. Zrozumienie różnic między nimi jest kluczowe dla oceny bezpieczeństwa infrastruktury.

Aspekt	Kerberos	NTLM
Mechanizm	Bilety kryptograficzne (tickets)	Challenge-response z hashem hasła
Hasło w sieci	Nigdy nie przesyłane	Hash hasła używany w odpowiedzi
Wzajemne uwierzytelnianie	Tak (mutual authentication)	Nie — klient nie weryfikuje serwera
Delegowanie	Tak (constrained/unconstrained delegation)	Ograniczone (NTLM relay)
Wymagania	Kontroler domeny, synchronizacja czasu, DNS	Działa bez domeny
Wydajność	Lepsza — bilety cachowane lokalnie	Każdy dostęp wymaga komunikacji z DC
Ataki	Kerberoasting, Golden/Silver Ticket, AS-REP Roasting	Pass-the-Hash, NTLM Relay, Brute-force
Standard	Otwarty (RFC 4120)	Własnościowy (Microsoft)

NTLM jest nadal obecny w wielu środowiskach z kilku powodów: kompatybilność wsteczna ze starszymi aplikacjami, scenariusze poza domeną (grupy robocze), sytuacje, w których Kerberos nie może być użyty (dostęp po adresie IP zamiast nazwy DNS). Z perspektywy bezpieczeństwa dążenie do minimalizacji użycia NTLM i przejścia na Kerberos jest jednym z priorytetów przy hardeningu Active Directory.

Ataki na protokół Kerberos

Pomimo solidnych podstaw kryptograficznych Kerberos jest podatny na szereg ataków, które wykorzystują słabości implementacji, konfiguracji lub samego projektu protokołu. Znajomość tych ataków jest niezbędna do skutecznej ochrony infrastruktury.

Kerberoasting

Kerberoasting to jeden z najczęściej spotykanych ataków na Kerberos w środowiskach Active Directory. Jego skuteczność wynika z faktu, że bilety TGS są szyfrowane kluczem wyprowadzonym z hasła konta usługowego — jeśli hasło jest słabe, bilet można złamać offline.

Przebieg ataku:

1. Atakujący posiada dowolne ważne konto domenowe (nie wymaga uprawnień administratora).
2. Odpytuje Active Directory o konta z zarejestrowanymi SPN (Get-ADUser -Filter {ServicePrincipalName -ne "$null"}).
3. Żąda biletów TGS dla tych kont — KDC wystawia je bez pytania, bo to normalna operacja Kerberos.
4. Wyeksportowane bilety poddaje atakowi brute-force offline (np. za pomocą Hashcat lub John the Ripper).
5. Jeśli hasło konta usługowego jest słabe, zostaje złamane w ciągu minut lub godzin.

Narzędzia takie jak Rubeus, Impacket (GetUserSPNs.py) czy moduły PowerSploit automatyzują ten proces.

Obrona: stosowanie haseł o długości minimum 25 znaków (losowych) dla kont usługowych, migracja na Group Managed Service Accounts (gMSA), które automatycznie rotują 240-znakowe hasła, oraz monitorowanie masowych żądań TGS (Event ID 4769).

Golden Ticket

Golden Ticket to sfałszowany bilet TGT, który daje atakującemu praktycznie nieograniczony dostęp do całej domeny Active Directory. Jest to jeden z najniebezpieczniejszych ataków, ponieważ pozwala na długotrwałe utrzymanie dostępu (persistence).

Przebieg ataku:

1. Atakujący uzyskuje dostęp do kontrolera domeny i wyciąga hash hasła konta KRBTGT (np. za pomocą narzędzia Mimikatz: lsadump::dcsync /domain:firma.pl /user:krbtgt).
2. Za pomocą tego hasha tworzy sfałszowany TGT z dowolnymi danymi — może podać się za dowolnego użytkownika, w tym za administratora domeny.
3. Sfałszowany TGT jest akceptowany przez TGS, ponieważ jest poprawnie zaszyfrowany kluczem KRBTGT.
4. Atakujący może uzyskać bilety usługowe do dowolnych zasobów w domenie.

Szczególnie niebezpieczne jest to, że Golden Ticket działa nawet po zmianie hasła użytkownika, którego tożsamość została przejęta — bo bilet jest uwierzytelniany kluczem KRBTGT, nie kluczem użytkownika. Domyślny czas ważności Golden Ticket to 10 lat.

Obrona: dwukrotna zmiana hasła konta KRBTGT (ze względu na historię haseł AD musi się to odbyć dwa razy, z odstępem minimum 12 godzin), regularne monitorowanie użycia konta KRBTGT, wdrożenie rozwiązań Privileged Access Management (PAM) oraz segmentacja kontrolerów domeny w oddzielnej, wysoce chronionej strefie sieciowej (Tier 0).

Silver Ticket

Silver Ticket to sfałszowany bilet usługowy (Service Ticket), który — w przeciwieństwie do Golden Ticket — daje dostęp do konkretnej usługi, a nie do całej domeny. Atakujący potrzebuje hasha hasła konta usługowego (nie KRBTGT).

Przebieg ataku:

1. Atakujący uzyskuje hash hasła konta komputerowego lub usługowego (np. przez Kerberoasting lub kompromitację serwera).
2. Tworzy sfałszowany Service Ticket dla usługi uruchomionej pod tym kontem.
3. Przedstawia sfałszowany bilet bezpośrednio serwerowi docelowemu — komunikacja z KDC nie jest potrzebna.

Silver Ticket jest trudniejszy do wykrycia niż Golden Ticket, ponieważ nie generuje logów na kontrolerze domeny — cała interakcja odbywa się bezpośrednio między atakującym a serwerem docelowym.

Obrona: walidacja PAC (Privilege Attribute Certificate) na serwerach docelowych, monitorowanie anomalii w logach dostępu do usług, regularna rotacja haseł kont komputerowych i usługowych.

AS-REP Roasting

AS-REP Roasting to atak skierowany przeciwko kontom, które mają wyłączoną opcję pre-authentication (flaga „Do not require Kerberos pre-authentication” w AD). Gdy pre-authentication jest wyłączona, KDC odpowiada na żądanie AS-REQ bez weryfikacji tożsamości żądającego — atakujący uzyskuje odpowiedź AS-REP zaszyfrowaną kluczem użytkownika, którą może łamać offline.

Obrona: upewnienie się, że pre-authentication jest włączona dla wszystkich kont (nie wyłączać flagi „Do not require Kerberos pre-authentication”), regularne audyty konfiguracji kont w AD.

Pass-the-Ticket (PtT)

Pass-the-Ticket polega na kradzieży biletów Kerberos (TGT lub Service Ticket) z pamięci zalogowanego użytkownika i użyciu ich na innej maszynie. W przeciwieństwie do ataków Pass-the-Hash (specyficznych dla NTLM), PtT operuje na biletach Kerberos.

Narzędzia takie jak Mimikatz (sekurlsa::tickets /export) pozwalają wyeksportować bilety z pamięci procesu LSASS i załadować je na innej maszynie. Atakujący przejmuje tożsamość użytkownika na czas ważności biletu.

Obrona: ochrona procesu LSASS (Credential Guard w Windows 10/11), ograniczenie uprawnień administracyjnych, krótsze czasy ważności biletów, monitorowanie anomalnych logowań.

Atak Skeleton Key

Skeleton Key to zaawansowany atak, w którym malware jest wstrzykiwane do procesu LSASS na kontrolerze domeny. Po wstrzyknięciu atakujący może uwierzytelniać się na dowolne konto za pomocą jednego uniwersalnego hasła (master password), przy czym oryginalne hasła użytkowników nadal działają. Atak nie przetrwa restartu kontrolera domeny.

Obrona: ochrona kontrolerów domeny przed nieautoryzowanym dostępem, monitoring integralności procesu LSASS, regularne restarty kontrolerów, wdrożenie Windows Defender Credential Guard.

Kerberos w Active Directory

W środowisku Active Directory Kerberos jest ściśle zintegrowany z wieloma komponentami i procesami. Zrozumienie tej integracji jest kluczowe dla administratorów bezpieczeństwa.

Konto KRBTGT

Konto KRBTGT jest automatycznie tworzone podczas instalacji Active Directory Domain Services. Jego hasło jest używane do szyfrowania wszystkich biletów TGT w domenie. To konto nie może zostać usunięte, nie może się logować interaktywnie i nie powinno być modyfikowane ręcznie. Kompromitacja hasła KRBTGT oznacza kompromitację całej domeny — stąd jest to jedno z najcenniejszych celów atakujących.

Microsoft zaleca regularną zmianę hasła konta KRBTGT (co 180 dni) oraz natychmiastową podwójną zmianę w przypadku podejrzenia kompromitacji.

Kerberos Delegation

Delegowanie Kerberos pozwala usłudze na działanie w imieniu użytkownika przy dostępie do innych usług. Istnieją trzy typy delegowania:

• Unconstrained Delegation — usługa może używać poświadczeń użytkownika do dostępu do dowolnej innej usługi. Jest to mechanizm niezwykle niebezpieczny — kompromitacja serwera z unconstrained delegation daje atakującemu dostęp do biletów TGT wszystkich użytkowników, którzy się na nim uwierzytelniają.

• Constrained Delegation — usługa może działać w imieniu użytkownika tylko wobec określonej listy usług (zdefiniowanej w atrybucie msDS-AllowedToDelegateTo). Znacznie bezpieczniejsze niż unconstrained delegation.

• Resource-Based Constrained Delegation (RBCD) — wprowadzone w Windows Server 2012. Zamiast konfiguracji na koncie usługowym, uprawnienia delegowania są definiowane na zasobie docelowym (atrybut msDS-AllowedToActOnBehalfOfOtherIdentity). Daje to większą elastyczność i lepszą kontrolę.

Z perspektywy bezpieczeństwa zalecane jest wyłączenie unconstrained delegation wszędzie, gdzie to możliwe, i migracja na constrained delegation lub RBCD.

Kerberos i Group Policy

Group Policy w Active Directory pozwala na centralne zarządzanie ustawieniami protokołu Kerberos:

• Maximum lifetime for user ticket — domyślnie 10 godzin
• Maximum lifetime for service ticket — domyślnie 600 minut
• Maximum lifetime for user ticket renewal — domyślnie 7 dni
• Maximum tolerance for computer clock synchronization — domyślnie 5 minut
• Enforce user logon restrictions — wymusza sprawdzanie polityk logowania przy wystawianiu biletów

Te ustawienia znajdują się w: Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Kerberos Policy.

Synchronizacja czasu

Kerberos wymaga synchronizacji czasu między klientem a KDC z tolerancją domyślnie 5 minut. Różnica czasu większa niż dopuszczalna skutkuje odrzuceniem biletów (błąd KRB_AP_ERR_SKEW). W Active Directory kontrolery domeny pełnią jednocześnie rolę serwerów NTP, a emulator PDC (Primary Domain Controller Emulator) jest źródłem czasu dla całej domeny.

Atakujący mogą próbować manipulować zegarem klienta w celu przedłużenia ważności skradzionych biletów lub wymuszenia fallbacku na NTLM — monitorowanie synchronizacji czasu jest więc istotnym elementem bezpieczeństwa.

Najlepsze praktyki zabezpieczania Kerberos

Prawidłowa konfiguracja i monitoring protokołu Kerberos to kluczowy element hardeningu Active Directory. Poniżej przedstawiamy najważniejsze rekomendacje.

Zarządzanie kontami usługowymi

• Używaj Group Managed Service Accounts (gMSA) — automatyczna rotacja 240-znakowych haseł eliminuje ryzyko Kerberoasting.
• Dla kont, które nie mogą być gMSA — stosuj losowe hasła o długości minimum 25 znaków i rotuj je co 90 dni.
• Audytuj konta z SPN — regularnie sprawdzaj, które konta mają zarejestrowane SPN i czy jest to uzasadnione (Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName).
• Nie rejestruj SPN na kontach użytkowników — jeśli to możliwe, używaj kont komputerowych lub gMSA.

Ochrona konta KRBTGT

• Zmieniaj hasło co 180 dni — i natychmiast (dwukrotnie) w przypadku podejrzenia kompromitacji.
• Monitoruj użycie konta KRBTGT — wszelkie anomalne logi dotyczące tego konta powinny generować alerty najwyższego priorytetu.
• Wdróż Managed Service Accounts z automatyczną rotacją kluczy.

Konfiguracja protokołu

• Wymuszaj pre-authentication — upewnij się, że żadne konto nie ma wyłączonej flagi pre-authentication.
• Wyłącz DES i RC4 — wymuszaj szyfrowanie AES256 (etype 18) dla biletów Kerberos. RC4 (etype 23) jest podatny na ataki i powinien być wyłączony, o ile pozwala na to kompatybilność.
• Skróć czas ważności biletów — rozważ zmniejszenie domyślnych 10 godzin TGT do 4-8 godzin w środowiskach o podwyższonym ryzyku.
• Wyłącz unconstrained delegation — migruj na constrained delegation lub RBCD.

Monitoring i detekcja

Skuteczne monitorowanie aktywności Kerberos wymaga zbierania i analizy następujących zdarzeń Windows:

• Event ID 4768 (TGT Request) — monitoruj nietypowe żądania, zwłaszcza z flagą pre-authentication failure.
• Event ID 4769 (TGS Request) — wykrywaj masowe żądania biletów do wielu usług w krótkim czasie (indykator Kerberoasting).
• Event ID 4770 (TGT Renewal) — monitoruj odnawianie biletów, szczególnie z nietypowych adresów IP.
• Event ID 4771 (Pre-authentication failure) — odpowiednik 4625 dla Kerberos, sygnalizuje próby brute-force.
• Event ID 4773 (Ticket request failed) — błędy w żądaniach biletów mogą wskazywać na ataki.

Integracja tych logów z systemem SIEM pozwala na tworzenie reguł korelacyjnych wykrywających złożone scenariusze ataków, takie jak sekwencja Kerberoasting → lateral movement → privilege escalation.

Segmentacja i ochrona Tier 0

Kontrolery domeny (a więc i KDC) należą do najcenniejszych zasobów organizacji (Tier 0). Rekomendowane zabezpieczenia obejmują:

• Fizyczną i logiczną izolację kontrolerów domeny w dedykowanym segmencie sieciowym.
• Dostęp administracyjny wyłącznie z dedykowanych stacji roboczych (Privileged Access Workstations — PAW).
• Wdrożenie Windows Defender Credential Guard na wszystkich stacjach, na których logują się użytkownicy uprzywilejowani.
• Regularne testy penetracyjne Active Directory z naciskiem na ataki Kerberos.

Kerberos poza Active Directory

Choć Active Directory jest najbardziej rozpowszechnionym środowiskiem wykorzystującym Kerberos, protokół ten ma szerokie zastosowanie poza ekosystemem Microsoftu.

MIT Kerberos i Heimdal

W systemach Linux i Unix dostępne są dwie główne implementacje: MIT Kerberos (referencyjna implementacja) oraz Heimdal (rozwijana w Szwecji, używana m.in. w macOS i FreeBSD). Obie implementacje umożliwiają tworzenie niezależnych realmów Kerberos lub integrację maszyn Linux z domeną Active Directory za pomocą narzędzi takich jak SSSD (System Security Services Daemon) lub Winbind.

Kerberos w aplikacjach

Wiele systemów i aplikacji natywnie wspiera uwierzytelnianie Kerberos:

• Bazy danych — Microsoft SQL Server, PostgreSQL (GSSAPI), Oracle Database
• Serwery webowe — Apache (mod_auth_kerb/mod_auth_gssapi), Nginx, IIS
• Systemy plików — NFS v4 z Kerberos, SMB/CIFS
• Przeglądarka WWW — SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) umożliwia transparentne uwierzytelnianie Kerberos w przeglądarkach (Internet Explorer, Chrome, Firefox)

Kerberos w chmurze

W środowiskach chmurowych Kerberos odgrywa mniejszą rolę na rzecz protokołów takich jak SAML i OIDC. Jednak w architekturach hybrydowych — gdzie organizacja utrzymuje on-premise Active Directory zsynchronizowane z Azure AD (Entra ID) — Kerberos pozostaje protokołem uwierzytelniania dla zasobów on-premise, a Azure AD Kerberos umożliwia dostęp do zasobów chmurowych bez konieczności bezpośredniej komunikacji z kontrolerem domeny.

Rozwiązywanie problemów z Kerberos

Problemy z uwierzytelnianiem Kerberos bywają trudne do diagnozowania. Najczęstsze przyczyny to:

• Desynchronizacja czasu — błąd KRB_AP_ERR_SKEW. Sprawdź synchronizację NTP: w32tm /query /status na Windows, chronyc tracking na Linux.
• Brak lub zduplikowane SPN — użyj setspn -X do wykrycia duplikatów i setspn -L <konto> do listowania SPN.
• Rozwiązywanie nazw DNS — Kerberos wymaga poprawnie działającego DNS. Użycie adresu IP zamiast nazwy DNS spowoduje fallback na NTLM.
• Problemy z delegowaniem — sprawdź atrybuty msDS-AllowedToDelegateTo i TrustedForDelegation na odpowiednich kontach.

Narzędzia diagnostyczne: klist (wyświetla bilety w cache klienta), klist purge (czyści cache biletów), Wireshark z filtrem kerberos, narzędzie Kerberos Event Logging w Windows.

Najczęściej zadawane pytania (FAQ)

Czym różni się Kerberos od NTLM?

Kerberos to nowocześniejszy protokół oparty na biletach i szyfrowaniu symetrycznym, który nie przesyła haseł przez sieć. NTLM używa mechanizmu challenge-response i hashy haseł, jest podatny na ataki relay i pass-the-hash. Microsoft rekomenduje Kerberos jako domyślny protokół uwierzytelniania w Active Directory.

Co to jest atak Kerberoasting i jak się przed nim bronić?

Kerberoasting polega na żądaniu biletów TGS dla kont usługowych z zarejestrowanymi SPN, a następnie offline’owym łamaniu haseł z zaszyfrowanych biletów. Obrona to stosowanie długich, losowych haseł (min. 25 znaków) dla kont usługowych, używanie gMSA (Group Managed Service Accounts) oraz monitorowanie masowych żądań TGS.

Czy Kerberos działa tylko w środowiskach Windows?

Nie. Kerberos to otwarty standard (RFC 4120), który działa na wielu platformach. Implementacje istnieją dla Linuxa (MIT Kerberos, Heimdal), macOS, a także w systemach bazodanowych i aplikacjach webowych. W środowiskach Linux maszyny mogą dołączać do domeny AD i uwierzytelniać się przez Kerberos za pomocą SSSD lub Winbind.

Co to jest Golden Ticket i dlaczego jest tak niebezpieczny?

Golden Ticket to sfałszowany bilet TGT utworzony za pomocą skradzionego klucza konta KRBTGT. Pozwala atakującemu na nieograniczony dostęp do wszystkich zasobów w domenie Active Directory, podszywanie się pod dowolnego użytkownika i utrzymanie dostępu nawet po zmianie haseł użytkowników. Jedynym remedium jest dwukrotna zmiana hasła konta KRBTGT.

Jak sprawdzić, czy moja organizacja używa Kerberos czy NTLM?

W Active Directory można to zweryfikować analizując logi zdarzeń Windows na kontrolerze domeny. Zdarzenia 4768 i 4769 dotyczą uwierzytelniania Kerberos, a 4776 — NTLM. Narzędzia takie jak PingCastle lub Purple Knight generują raporty o wykorzystaniu protokołów uwierzytelniania w domenie.

Podsumowanie

Kerberos to protokół, który od ponad czterech dekad stanowi fundament bezpiecznego uwierzytelniania w sieciach komputerowych. Jego architektura oparta na biletach kryptograficznych i zaufanej trzeciej stronie (KDC) jest znacznie bezpieczniejsza niż starsze mechanizmy takie jak NTLM. Jednak sama obecność Kerberos w infrastrukturze nie gwarantuje bezpieczeństwa — kluczowe jest prawidłowe skonfigurowanie protokołu, ochrona krytycznych komponentów (zwłaszcza konta KRBTGT i kontrolerów domeny) oraz ciągłe monitorowanie pod kątem ataków takich jak Kerberoasting czy Golden Ticket.

Organizacje, które traktują bezpieczeństwo Kerberos poważnie, powinny regularnie audytować konfigurację Active Directory, migrować na nowoczesne mechanizmy (gMSA, AES256, constrained delegation) i integrować logi uwierzytelniania z systemem SIEM. W erze zaawansowanych ataków na Active Directory znajomość protokołu Kerberos — zarówno jego mocnych stron, jak i słabości — jest niezbędnym elementem arsenału każdego zespołu bezpieczeństwa.