Błąd negocjacji NTLM – serwer wymaga Kerberos

Błąd negocjacji NTLM, gdy serwer wymaga Kerberos, oznacza, że polityka bezpieczeństwa domeny zabrania uwierzytelniania starszym protokołem — rozwiązaniem jest naprawa konfiguracji DNS/SPN, by Kerberos mógł zostać poprawnie użyty.

Czym jest błąd negocjacji NTLM, gdy serwer wymaga Kerberos

Błąd negocjacji NTLM w sytuacji, gdy serwer wymaga Kerberos, oznacza niezgodność pomiędzy metodą uwierzytelniania proponowaną przez komputer a zasadami przyjętymi w domenie. NTLM jest starszym mechanizmem sprawdzania tożsamości użytkownika, natomiast Kerberos został zaprojektowany jako podstawowy protokół uwierzytelniania w środowiskach opartych na Active Directory. Jeżeli zasady bezpieczeństwa ograniczają lub całkowicie blokują NTLM, próba połączenia wykonana bez prawidłowego przejścia na Kerberos kończy się odmową dostępu, komunikatem o nieudanej negocjacji albo wielokrotnym żądaniem podania hasła.

Nie jest to zwykle błąd samego hasła. Konto może być aktywne, a dane logowania prawidłowe, lecz system nie potrafi zbudować właściwego kontekstu uwierzytelnienia. Do poprawnego działania Kerberos potrzebuje między innymi zgodności nazw, prawidłowego odnalezienia kontrolera domeny, działających rekordów DNS oraz poprawnie zarejestrowanych identyfikatorów usług. Znaczenie ma także czas systemowy, ponieważ bilety uwierzytelniające mają ograniczony okres ważności i są odrzucane, gdy różnica czasu pomiędzy urządzeniami przekracza dopuszczalny zakres.

W praktyce komunikat może pojawić się przy otwieraniu udziału sieciowego, uruchamianiu aplikacji korzystającej z kont domenowych, łączeniu z usługą zdalną albo wykonywaniu operacji wymagającej wzajemnego potwierdzenia tożsamości. Problem może dotyczyć pojedynczego komputera, określonej usługi, całej podsieci lub tylko konkretnej nazwy używanej do nawiązywania połączenia.

Kontekst techniczny i porównanie NTLM z Kerberos

NTLM opiera się na wymianie odpowiedzi kryptograficznej związanej z hasłem użytkownika. W uproszczeniu klient otrzymuje wyzwanie, oblicza odpowiedź i przekazuje ją do sprawdzenia. Taki model może działać w prostszych konfiguracjach, lecz gorzej nadaje się do rozbudowanych środowisk, ponieważ nie zapewnia tak wygodnego mechanizmu przekazywania poświadczeń pomiędzy wieloma usługami. Z tego powodu w dojrzałych domenach często ogranicza się jego użycie, szczególnie gdy wymagane są silniejsze zasady kontroli dostępu i możliwość jednoznacznego wskazania usługi.

Kerberos działa w oparciu o bilety wydawane przez centrum dystrybucji kluczy znajdujące się w infrastrukturze domenowej. Po pomyślnym uwierzytelnieniu użytkownik nie musi przekazywać hasła przy każdym kolejnym żądaniu. Dla konkretnej usługi pobierany jest bilet powiązany z jej nazwą i zarejestrowanym identyfikatorem SPN. Serwer może wtedy zweryfikować, czy bilet został wystawiony dla właściwej usługi i właściwego konta. Taki mechanizm wspiera jednokrotne logowanie oraz ogranicza potrzebę stosowania starszych metod.

Najczęstsza różnica praktyczna polega na tym, że Kerberos wymaga precyzyjnego odwzorowania nazwy usługi na konto, które ją obsługuje. Połączenie wykonane przez alias DNS, niewłaściwy rekord, nazwę niezgodną z rejestracją SPN albo adres, którego infrastruktura domenowa nie rozpoznaje w oczekiwany sposób, może nie otrzymać biletu Kerberos. Wtedy klient próbuje użyć NTLM, a polityka domeny odrzuca tę możliwość. Samo złagodzenie polityki nie usuwa przyczyny i może obniżyć poziom ochrony, dlatego właściwym kierunkiem jest przywrócenie prawidłowej obsługi Kerberos.

Podczas porównania obu mechanizmów należy sprawdzić, czy problem ma charakter uwierzytelnieniowy, nazwowy czy infrastrukturalny. Jeżeli działa logowanie do domeny, ale nie działa dostęp do jednej usługi, większe znaczenie mogą mieć nazwa usługi, rekordy DNS i SPN. Jeżeli nie działa również lokalizowanie kontrolera domeny, podejrzenie powinno zostać skierowane na konfigurację DNS, routing, zaporę sieciową albo stan urządzenia w domenie. Jeżeli błędy występują losowo, warto dodatkowo przeanalizować synchronizację czasu i wygasanie biletów.

Typowe problemy i błędy prowadzące do odmowy uwierzytelnienia - Błąd negocjacji NTLM – serwer wymaga Kerberos

Jedną z podstawowych przyczyn jest używanie niewłaściwego serwera DNS na komputerze klienckim. W domenie katalogowej zapytania dotyczące kontrolerów i usług powinny trafiać do właściwej infrastruktury DNS, a nie przypadkowo do publicznego resolvera lub urządzenia, które nie zna wewnętrznych rekordów. Błędna odpowiedź może spowodować, że komputer odnajdzie nieodpowiedni adres, nie znajdzie kontrolera domeny albo nie będzie w stanie ustalić, dla jakiego konta zarejestrowano daną usługę.

Drugim częstym źródłem problemów są nieprawidłowe lub zduplikowane wpisy SPN. Identyfikator przypisany do niewłaściwego konta może powodować wystawianie biletu dla innego podmiotu niż ten, który faktycznie obsługuje połączenie. Z kolei duplikat może uniemożliwić jednoznaczne wskazanie właściciela usługi. W obu przypadkach Kerberos nie działa zgodnie z oczekiwaniem, a klient może przejść na NTLM albo zwrócić błąd negocjacji, gdy przejście awaryjne zostało zablokowane.

Istotna jest również forma używanej nazwy. Połączenie po nazwie hosta, pełnej nazwie domenowej, aliasie lub adresie IP nie zawsze prowadzi do identycznego rezultatu. Adres IP zazwyczaj nie pozwala na prawidłowe dopasowanie biletu Kerberos do nazwy usługi, a alias wymaga odpowiedniego przygotowania w DNS i katalogu. Zmiana skróconej nazwy na pełną nazwę domenową może ujawnić, że problem nie dotyczy konta użytkownika, tylko sposobu wskazania usługi.

Błąd może być także wywołany rozbieżnością zegarów. Kerberos chroni bilety przed użyciem poza przewidzianym czasem, dlatego nieprawidłowa strefa czasowa, wyłączona synchronizacja lub ręcznie ustawiona data potrafią doprowadzić do odrzucenia poprawnych z pozoru poświadczeń. Warto sprawdzić czas na komputerze, kontrolerze domeny oraz urządzeniu udostępniającym usługę, ponieważ niewielka różnica na jednym z elementów może wystarczyć do przerwania uwierzytelniania.

Do diagnostyki można wykorzystać dzienniki systemowe, informacje o biletach Kerberos oraz narzędzia domenowe pokazujące odnaleziony kontroler i użyty mechanizm logowania. Przydatne jest porównanie działania tej samej usługi z kilku komputerów, z użyciem różnych nazw oraz na różnych kontach. Należy jednak unikać przypadkowego kasowania wpisów katalogowych, wyłączania wymagań bezpieczeństwa i wielokrotnego resetowania kont usługowych bez ustalenia zależności. Takie działania mogą utrudnić późniejszą analizę albo zakłócić działanie innych połączeń.

Kiedy najlepiej poprosić o ocenę stanu sprzętu - Błąd negocjacji NTLM – serwer wymaga Kerberos

Warto zgłosić usterkę, gdy błąd powtarza się mimo prawidłowego hasła, występuje przy kilku usługach albo pojawił się po zmianie nazwy komputera, migracji domeny, wymianie urządzenia sieciowego lub modyfikacji zasad bezpieczeństwa. Pomoc jest szczególnie wskazana wtedy, gdy nie wiadomo, czy przyczyną jest DNS, synchronizacja czasu, rejestracja SPN, relacja komputera z domeną czy ograniczenie NTLM. Samodzielne przełączanie polityk na mniej restrykcyjne może chwilowo przywrócić dostęp, lecz nie rozwiązuje problemu z Kerberos i może pozostawić środowisko w niespójnym stanie.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić uporządkowanie diagnostyki komputera i jego połączeń z infrastrukturą domenową. Analiza może obejmować sprawdzenie rozwiązywania nazw, odnajdywania kontrolera domeny, synchronizacji czasu, używanych nazw usług oraz komunikatów zapisanych w dziennikach. Następnie można rozdzielić problem lokalny od usterki występującej po stronie domeny, aby nie zmieniać przypadkowo ustawień, które wpływają na większą liczbę użytkowników.

Przed zgłoszeniem dobrze przygotować dokładny komunikat błędu, nazwę usługi, sposób nawiązywania połączenia, godzinę wystąpienia problemu oraz informację, czy błąd dotyczy jednego komputera czy całego środowiska. Pomocne będzie również wskazanie ostatnich zmian, takich jak wymiana sprzętu, aktualizacja systemu, zmiana adresacji lub modyfikacja zasad uwierzytelniania. Dzięki temu łatwiej ustalić, czy konieczne jest odtworzenie poprawnego użycia Kerberos, naprawa rozpoznawania nazw, korekta konfiguracji usługi czy przywrócenie prawidłowej relacji z domeną.