Kerberos — jak działa protokół uwierzytelniania w Active Directory

Kerberos to protokół uwierzytelniania sieciowego, w którym zamiast przesyłać hasło do każdej usługi, użytkownik otrzymuje od zaufanego serwera zaszyfrowane bilety. W sieciach Windows jest domyślną metodą logowania w domenie Active Directory: to dzięki niemu po zalogowaniu się do komputera masz dostęp do udziałów plików, drukarek, SQL Servera czy intranetu bez ponownego wpisywania hasła.

Protokół powstał w latach 80. w MIT w ramach Projektu Athena. Obecnie używana wersja 5 jest opisana w RFC 4120, a Microsoft zastosował ją jako podstawę uwierzytelniania w domenie już w Windows 2000. Nazwa pochodzi od Cerbera, trójgłowego psa z mitologii — w protokole też występują trzy strony: klient, usługa i centrum dystrybucji kluczy.

Podstawowe pojęcia: KDC, TGT, TGS i SPN

Zanim przejdziemy do przebiegu logowania, warto znać kilka terminów, które pojawiają się w logach, komunikatach błędów i narzędziach.

Kluczowa idea: KDC zna klucze (pochodne haseł) wszystkich użytkowników i usług. Dzięki temu może zaszyfrować bilet tak, żeby odczytać go mogła tylko właściwa strona. Kerberos opiera się na kryptografii symetrycznej — w nowoczesnych domenach jest to AES.

Jak działa Kerberos krok po kroku

Cały proces składa się z trzech wymian. Pierwsza odbywa się raz przy logowaniu, dwie kolejne przy dostępie do każdej nowej usługi.

Krok 1: logowanie i bilet TGT (AS-REQ / AS-REP)

1. Użytkownik wpisuje hasło. Komputer wylicza z niego klucz i szyfruje nim aktualny znacznik czasu — to tzw. preautentykacja.
2. Klient wysyła żądanie AS-REQ do KDC na porcie 88.
3. KDC odszyfrowuje znacznik czasu kluczem użytkownika z bazy AD. Jeśli się udało i czas się zgadza, użytkownik udowodnił znajomość hasła — bez przesyłania go przez sieć.
4. KDC odsyła AS-REP z biletem TGT (zaszyfrowanym kluczem krbtgt, którego klient nie zna) oraz kluczem sesji zaszyfrowanym kluczem użytkownika.

Krok 2: bilet do usługi (TGS-REQ / TGS-REP)

1. Użytkownik otwiera np. \\fs01.firma.local\dane. Klient ustala SPN usługi: cifs/fs01.firma.local.
2. Wysyła do KDC żądanie TGS-REQ z biletem TGT i tzw. authenticatorem (znacznik czasu zaszyfrowany kluczem sesji).
3. KDC wyszukuje w AD konto, do którego przypisany jest ten SPN, i wystawia bilet usługi zaszyfrowany kluczem tego konta.

Krok 3: dostęp do usługi (AP-REQ / AP-REP)

1. Klient przekazuje bilet usługi serwerowi plików.
2. Serwer odszyfrowuje go własnym kluczem, odczytuje z PAC grupy użytkownika i na tej podstawie przyznaje uprawnienia.
3. Opcjonalnie serwer odpowiada AP-REP — klient ma wtedy pewność, że rozmawia z prawdziwym serwerem (uwierzytelnienie wzajemne).

Serwer nie musi w tym czasie kontaktować się z kontrolerem domeny, co odróżnia Kerberos od NTLM i odciąża sieć. Szerzej o roli kontrolerów i bazy katalogu przeczytasz w artykule jak działa Active Directory.

Czas, DNS i SPN — trzy warunki działania Kerberosa

Większość problemów z Kerberosem w domenie Windows sprowadza się do jednego z trzech warunków.

Synchronizacja czasu

Znaczniki czasu chronią przed powtórzeniem przechwyconego żądania. Domyślna polityka domeny dopuszcza różnicę maksymalnie 5 minut między klientem a kontrolerem domeny. Komputery w domenie synchronizują czas z hierarchii domeny, a kontroler z rolą emulatora PDC — ze źródłem zewnętrznym. Stan sprawdzisz poleceniami:

w32tm /query /status
w32tm /query /source
w32tm /resync

Poprawny DNS i nazwy zamiast adresów IP

Klient buduje SPN z nazwy hosta, więc musi łączyć się po pełnej nazwie DNS. Jeśli wpiszesz \\192.168.1.20\dane, Windows zwykle nie znajdzie pasującego SPN i po cichu przełączy się na NTLM. Błędny DNS na kliencie (np. publiczny serwer DNS zamiast kontrolera domeny) to też najczęstsza przyczyna komunikatu, że nie można skontaktować się z kontrolerem domeny.

SPN przypisany do właściwego konta

Każdy SPN może być przypisany tylko do jednego konta. Gdy usługa (np. SQL Server lub pula aplikacji IIS) działa na koncie domenowym, SPN trzeba zarejestrować na tym koncie:

# lista SPN przypisanych do konta
setspn -L FIRMA\svc-sql

# dodanie SPN z kontrolą duplikatów
setspn -S MSSQLSvc/sql01.firma.local:1433 FIRMA\svc-sql

# wyszukanie zduplikowanych SPN w całym lesie
setspn -X -F

Zduplikowany SPN lub SPN przypisany do złego konta kończy się błędem KRB_AP_ERR_MODIFIED — serwer nie potrafi odszyfrować biletu, bo został wystawiony dla innego klucza.

Polecenie klist i diagnostyka biletów Kerberos

Narzędzie klist jest wbudowane w Windows i pokazuje bilety zapisane w pamięci podręcznej bieżącej sesji.

# bilety bieżącego użytkownika (TGT i bilety usług)
klist

# tylko TGT
klist tgt

# usunięcie biletów, np. po dodaniu użytkownika do nowej grupy
klist purge

# bilety konta komputera (sesja SYSTEM), wymaga uprawnień administratora
klist -li 0x3e7 purge

W wyniku sprawdzisz serwer (SPN), czas ważności i typ szyfrowania — w poprawnie skonfigurowanej domenie powinien to być AES-256-CTS-HMAC-SHA1-96. Domyślnie bilet użytkownika jest ważny 10 godzin i może być odnawiany przez 7 dni. To dlatego nowe członkostwo w grupie „nie działa” do ponownego zalogowania albo do klist purge.

Na kontrolerach domeny zdarzenia Kerberosa trafiają do dziennika Zabezpieczenia (po włączeniu inspekcji „Audit Kerberos Authentication Service” i „Audit Kerberos Service Ticket Operations”):

Najczęstsze kody błędów to KDC_ERR_PREAUTH_FAILED (błędne hasło), KRB_AP_ERR_SKEW (różnica czasu), KDC_ERR_S_PRINCIPAL_UNKNOWN (brak SPN) i KDC_ERR_ETYPE_NOTSUPP (brak wspólnego typu szyfrowania).

Kerberos w Linuksie i innych systemach

Kerberos nie jest technologią wyłącznie Microsoftu. Implementacje MIT Kerberos i Heimdal działają w Linuksie i macOS, a Kerberos zabezpiecza m.in. NFSv4, SSH (uwierzytelnianie GSSAPI), Sambę, PostgreSQL czy Hadoopa. Linuksowy komputer dołączony do AD (np. przez SSSD i realm join) korzysta z tych samych kontrolerów domeny jako KDC.

Podstawowe polecenia są podobne:

kinit jan.kowalski@FIRMA.LOCAL   # pobranie TGT
klist                            # lista biletów
kdestroy                         # usunięcie biletów

Konfiguracja klienta znajduje się w pliku /etc/krb5.conf (realm, adresy KDC), a klucze usług na serwerach — w plikach keytab, najczęściej /etc/krb5.keytab.

Ataki na Kerberosa i jak się przed nimi bronić

Kerberos jest dobrze zaprojektowany, ale jego implementacja w AD bywa celem ataków, zwłaszcza po przejęciu pierwszego konta w sieci.

Kerberoasting

Każdy uwierzytelniony użytkownik może poprosić o bilet do dowolnej usługi z SPN. Część biletu jest zaszyfrowana kluczem konta usługi, więc atakujący może łamać go offline, np. narzędziem Hashcat. Konta usług ze słabymi, latami niezmienianymi hasłami padają szybko, zwłaszcza gdy bilety są szyfrowane RC4.

Obrona: konta zarządzane przez AD z automatycznie zmienianymi, długimi hasłami — więcej w poradniku o kontach usług MSA i gMSA — a dla zwykłych kont usług hasła co najmniej 25-znakowe i wyłącznie AES.

AS-REP Roasting

Dotyczy kont z zaznaczoną opcją „Nie wymagaj wstępnego uwierzytelniania protokołu Kerberos”. Dla nich KDC zwraca dane zaszyfrowane kluczem użytkownika bez sprawdzenia hasła. Znajdź takie konta i wyłącz tę opcję:

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth

Pass-the-Ticket, Golden Ticket i Silver Ticket

Po przejęciu komputera atakujący może wykraść bilety z pamięci i użyć ich na innej maszynie (Pass-the-Ticket). Najgroźniejszy jest Golden Ticket: kto zdobędzie skrót hasła konta krbtgt, może sam wystawiać TGT dla dowolnego użytkownika. Silver Ticket działa analogicznie dla pojedynczej usługi.

Uwaga: Po podejrzeniu kompromitacji domeny hasło konta krbtgt resetuje się dwukrotnie, z odstępem co najmniej równym maksymalnemu czasowi życia biletu (domyślnie 10 godzin). Pojedynczy reset nie unieważnia wystawionych biletów, a dwa resety naraz mogą przerwać działanie domeny.

Dodatkowe zabezpieczenia: dodanie kont administracyjnych do grupy Protected Users (wymusza AES, wyłącza NTLM i delegowanie dla tych kont), rezygnacja z delegowania nieograniczonego, model warstwowy kont administratorów oraz monitorowanie zdarzeń 4769 z typem szyfrowania 0x17 (RC4).

RC4, AES i zmiany w 2026 roku

Przez lata kontrolery domeny akceptowały RC4-HMAC dla zgodności ze starymi systemami, co ułatwiało Kerberoasting. Microsoft wycofuje RC4 etapami: aktualizacje ze stycznia 2026 r. dodały audyt jego użycia, od kwietnia 2026 r. kontrolery domeny domyślnie stosują AES dla kont bez jawnie określonych typów szyfrowania, a od lipca 2026 r. tej zmiany nie da się już globalnie wycofać. RC4 można włączyć tylko jawnie dla konkretnego konta (atrybut msDS-SupportedEncryptionTypes).

W praktyce oznacza to, że stare urządzenia i aplikacje obsługujące wyłącznie RC4 (niektóre NAS-y, drukarki, starsze implementacje Javy) mogą przestać się uwierzytelniać. Zanim wymienisz sprzęt, sprawdź w zdarzeniach 4768 i 4769, które konta i usługi wciąż żądają RC4, i zaktualizuj ich konfigurację lub keytaby. Jeśli dopiero porządkujesz wiedzę o samej usłudze katalogowej, zacznij od artykułu czym jest Active Directory Domain Services.