
W lutym 2026 r. Microsoft zapowiedział trzyetapowy plan wycofania protokołu NTLM, który od lat 90. służył do uwierzytelniania w środowiskach Windows. Przyczyną są słabe mechanizmy kryptograficzne NTLM i podatność na ataki przechwycenia hashy (pass‑the‑hash), replay oraz man‑in‑the‑middle. W kolejnych wersjach Windows Server NTLM będzie domyślnie wyłączany, dlatego administratorzy muszą migrować usługi do nowocześniejszego Kerberosa. Ten artykuł jest uzupełnieniem naszego technicznego opracowania o fazach wycofania NTLM i szczegółach konfiguracji Kerberosa. W sposób bardziej przystępny wyjaśnia podstawy protokołu, jego zalety oraz najważniejsze dobre praktyki, na których powinni skupić się mniej doświadczeni administratorzy.
Czym jest Kerberos?
Kerberos to sieciowy protokół uwierzytelniania opracowany pierwotnie w Massachusetts Institute of Technology (MIT). W Windows został wprowadzony w 2000 r., zastępując przestarzały NTLM. Kerberos umożliwia bezpieczne potwierdzenie tożsamości użytkownika i usługi bez przesyłania hasła w sieci. Kluczowe cechy protokołu to:
- Użycie biletów (tickets) – zamiast przesyłać hasło, klient uzyskuje bilet (Ticket Granting Ticket), a następnie bilety do konkretnych usług, które potwierdzają jego tożsamość.
- Wzajemne uwierzytelnianie – zarówno klient, jak i serwer potwierdzają, że rozmawiają z zaufaną stroną, co chroni przed atakami MITM i replay.
- Cross‑Forest Trust – Kerberos umożliwia zaufanie między domenami/lasami Active Directory za pomocą jednego trustu na poziomie root, co eliminuje konieczność tworzenia „pełnej siatki” połączeń między wszystkimi domenami.
- Interoperacyjność – protokół jest standardem otwartym i działa również w systemach Unix/Linux, co pozwala na uwierzytelnianie aplikacji na różnych platformach.
- Uwierzytelnianie w sieci Web – Kerberos obsługuje uwierzytelnianie w aplikacjach internetowych poprzez mechanizm SPNEGO/Negotiate
Jak działa Kerberos – w uproszczeniu
Proces uwierzytelniania Kerberos można przedstawić w czterech krokach. W tradycyjnym środowisku Active Directory klient (użytkownik) komunikuje się z serwerem uwierzytelniania (Authentication Service – AS) znajdującym się na kontrolerze domeny (KDC) i otrzymuje bilet TGT. Następnie klient używa tego biletu, aby uzyskać od serwera biletów usługowych (Ticket Granting Service – TGS) bilet do konkretnej usługi (np. serwera plików). Ten bilet jest szyfrowany kluczem usługi i może być przedstawiany wielokrotnie w danym przedziale czasu. Hasło użytkownika nie jest przesyłane w sieci, ponieważ zarówno klient, jak i KDC wykorzystują ten sam algorytm generowania klucza z hasła (tzw. „shared secret”)
Dlaczego warto przejść z NTLM na Kerberos?
NTLM został zaprojektowany w latach 90., a jego mechanizmy kryptograficzne są dziś uważane za słabe i podatne na ataki (np. pass‑the‑hash). Kerberos jest bezpieczniejszy, gdyż:
- Stosuje silne szyfrowanie i bilety – hasła nie opuszczają klienta, a serwer może zweryfikować bilet bez dostępu do hasła.
- Zapewnia wzajemne uwierzytelnianie i Single Sign‑On – użytkownik loguje się raz i uzyskuje dostęp do wielu usług, a każda strona potwierdza tożsamość drugiej.
- Umożliwia interoperacyjność i skalowalność – działa w środowiskach wielodomenowych i hybrydowych, a nawet w środowiskach Unix/Linux.
- Zapewnia mniejszą podatność na replay – bilet jest ważny tylko przez określony czas i zawiera znaczniki czasu, co utrudnia przechwycenie i powtórne wykorzystanie
O czym trzeba pamiętać
Synchronizacja czasu
Kerberos wymaga, aby zegary wszystkich urządzeń w domenie były zsynchronizowane. W ramach mechanizmu „Authenticator” serwer porównuje znacznik czasu w bilecie z własnym zegarem; jeśli różnica przekracza pięć minut, bilet jest odrzucany. Microsoft zaleca korzystanie z usługi Windows Time Service i protokołu NTP (od Windows Server 2003) w celu utrzymywania referencyjnego czasu UTC w całej domenie. Przestawienie lokalnego zegara (np. poprzez zmianę godziny zamiast strefy czasowej) może spowodować duży time skew i problemy z uwierzytelnianiem.
Pre‑Authentication
W wersji 5 Kerberos wymaga, aby klient udowodnił posiadanie hasła jeszcze przed wydaniem biletu (tzw. pre‑authentication). Wyłączenie tego mechanizmu w celu zgodności ze starszymi aplikacjami może poważnie osłabić bezpieczeństwo. Dlatego w nowoczesnych środowiskach nie należy dezaktywować pre‑authentication, a zamiast tego przenieść aplikacje na nowsze biblioteki.
Silne hasła kont usługowych
Choć Kerberos jest bezpieczny, słabe lub łatwe do zgadnięcia hasła kont usługowych mogą narazić organizację na ataki typu Kerberoasting. W tym scenariuszu atakujący uzyskuje bilet usługowy dla konta z określonym Service Principal Name (SPN), a następnie offline łamie hash hasła tego konta. Słabe hasło pozwala przejąć konto i uzyskać dostęp do wszystkich zasobów przypisanych do usługi. Aby zmniejszyć to ryzyko:
- Wymuszaj długie, złożone i losowe hasła dla kont z SPN – co najmniej 14 znaków, zawierające małe i duże litery, cyfry i znaki specjalne.
- Regularnie rotuj hasła oraz włącz obsługę szyfrów AES 128/256 dla kont usługowych – ustaw opcję „This account supports Kerberos AES 128/256 bit encryption” w właściwościach konta.
- Unikaj rejestrowania SPN na zwykłych kontach użytkowników; przypisuj SPN tylko dedykowanym kontom usługowym.
Monitorowanie i narzędzia bezpieczeństwa
Tradycyjne systemy antywirusowe mogą nie wykrywać ataków takich jak Kerberoasting, ponieważ nie wykorzystują one złośliwego oprogramowania. Warto korzystać z narzędzi identity‑based threat detection oraz systemów EDR, które analizują anomalne żądania biletów i próby łamania haseł. Regularnie przeglądaj logi bezpieczeństwa (np. zdarzenia KDCSVC) i włącz audyty Kerberos w politykach grupowych.
Najlepsze praktyki wdrożeniowe
- Przygotuj środowisko do migracji. Uruchom audyty NTLM i Kerberos, aby zidentyfikować aplikacje korzystające z przestarzałych mechanizmów uwierzytelniania. W miarę możliwości zaktualizuj je, aby obsługiwały Kerberosa.
- Zadbaj o synchronizację czasu. Skonfiguruj kontrolery domen i serwery, aby korzystały z NTP i miały prawidłowe strefy czasowe. Unikaj ręcznych zmian czasu, które mogą wprowadzić time skew.
- Używaj silnych haseł i szyfrów. Stosuj złożone hasła kont usługowych, włącz obsługę AES i regularnie rotuj klucze.
- Nie wyłączaj pre‑authentication. Zapewnia ona ochronę przed atakami offline, dlatego modernizuj aplikacje zamiast obniżać poziom bezpieczeństwa.
- Monitoruj i wykrywaj anomalie. Wdrażaj narzędzia do monitorowania tożsamości i analizuj logi Kerberos, aby szybko wykrywać nietypowe żądania biletów i próby łamania haseł.
- Edukuj zespół. Szkol administratorów i deweloperów w zakresie bezpiecznej konfiguracji Kerberosa oraz konsekwencji wycofania NTLM. Regularnie aktualizuj wiedzę na temat nowych luk i zaleceń producentów.
Podsumowanie
Kerberos jest fundamentem nowoczesnych mechanizmów uwierzytelniania w Windows Server, Active Directory i środowiskach hybrydowych. Jego wprowadzenie zastąpi przestarzały NTLM, zapewniając silniejsze szyfrowanie, wzajemne uwierzytelnianie i lepszą interoperacyjność. Aby jednak w pełni wykorzystać potencjał Kerberosa, administratorzy muszą pamiętać o synchronizacji czasu, pre‑authentication, silnych hasłach i aktywnym monitorowaniu bezpieczeństwa. Dobrze zaplanowana migracja i zgodność z najlepszymi praktykami pozwolą uniknąć problemów z uwierzytelnianiem oraz obronić środowisko przed nowymi technikami ataków, takimi jak Kerberoasting. Zachęcamy do lektury naszego technicznego artykułu, w którym szczegółowo opisujemy fazy wycofania NTLM, konfigurację Kerberosa i najnowsze aktualizacje zabezpieczeń.
