Uwierzytelnianie Kerberos a NTLM

Kerberos oferuje bezpieczniejsze uwierzytelnianie sieciowe niż NTLM, wspierając m.in. delegację poświadczeń.

Kerberos i NTLM: różne modele uwierzytelniania

Kerberos i NTLM to protokoły uwierzytelniania używane przede wszystkim w środowiskach Microsoft Windows, ale działają według odmiennych zasad. Kerberos opiera się na biletach oraz zaufanym centrum dystrybucji kluczy, czyli KDC (Key Distribution Center). W domenie Active Directory funkcję KDC pełni kontroler domeny. Podczas logowania użytkownik uwierzytelnia się wobec usługi Kerberos działającej na kontrolerze domeny, a następnie otrzymuje bilet pozwalający uzyskiwać dostęp do konkretnych usług bez przesyłania hasła przy każdym połączeniu.

NTLM wykorzystuje mechanizm odpowiedzi na wyzwanie. Serwer wysyła klientowi wyzwanie, a klient oblicza odpowiedź na podstawie hasła lub pochodnej hasła. Serwer albo kontroler domeny porównuje otrzymaną odpowiedź z wartością oczekiwaną. Hasło nie jest przesyłane wprost, jednak NTLM nie zapewnia takiego modelu biletowego jak Kerberos i ma słabsze możliwości w zakresie wzajemnego potwierdzania tożsamości oraz delegowania dostępu. We współczesnych domenach Windows Kerberos jest podstawowym protokołem, natomiast NTLM pozostaje mechanizmem zgodności dla wybranych scenariuszy.

Jak przebiega uwierzytelnianie Kerberos w domenie

Kerberos korzysta z kilku rodzajów biletów. Po poprawnym uwierzytelnieniu użytkownik otrzymuje bilet przyznający bilety, znany jako TGT (Ticket Granting Ticket). TGT służy do uzyskania biletu dostępu do konkretnej usługi, na przykład udziału plikowego, usługi HTTP albo usługi działającej na określonym komputerze. Tożsamość usługi jest wskazywana przez nazwę SPN (Service Principal Name), która wiąże nazwę usługi z kontem w domenie. Jeżeli SPN jest nieprawidłowy, zduplikowany albo przypisany do niewłaściwego konta, negocjowanie Kerberos może się nie udać.

Ważnym elementem jest synchronizacja czasu między klientem, kontrolerem domeny i serwerem usługi. Kerberos wykorzystuje znaczniki czasu, aby ograniczyć możliwość ponownego użycia przechwyconych komunikatów. Zbyt duża różnica czasu może spowodować odrzucenie biletu. Znaczenie mają także poprawna rozpoznawalność nazw DNS, dostępność kontrolera domeny oraz możliwość dotarcia do wymaganych usług sieciowych. Kerberos nie jest więc wyłącznie funkcją wpisania prawidłowego hasła; poprawny przepływ zależy od relacji zaufania domeny, konfiguracji usługi i bieżącego stanu infrastruktury.

Delegowanie poświadczeń, wzajemna weryfikacja i ograniczenia NTLM

Kerberos umożliwia wzajemne uwierzytelnianie, czyli potwierdzenie nie tylko tożsamości klienta wobec serwera, lecz także tożsamości serwera wobec klienta. Ma to znaczenie przy dostępie do usług, w których klient powinien mieć pewność, że komunikuje się z właściwym komputerem. Kerberos obsługuje również delegowanie, dzięki któremu usługa może w określonych i skonfigurowanych warunkach działać w imieniu użytkownika podczas uzyskiwania dostępu do kolejnej usługi. Typowym przykładem jest aplikacja, która po uwierzytelnieniu użytkownika musi odwołać się do zasobu znajdującego się na innym komputerze.

NTLM nie zapewnia równoważnego mechanizmu biletów dla usług i nie rozwiązuje wielostopniowego przekazywania tożsamości w taki sam sposób jak Kerberos. W praktyce może to powodować problem określany jako „double hop”: użytkownik poprawnie loguje się do pierwszej usługi, ale ta usługa nie może automatycznie użyć jego poświadczeń przy dostępie do drugiego zasobu. NTLM jest również bardziej podatny na ataki polegające na przekazywaniu uwierzytelnienia, znane jako relay, jeżeli środowisko nie wymusza odpowiednich zabezpieczeń, takich jak podpisywanie protokołów, rozszerzona ochrona uwierzytelniania lub ograniczenie użycia NTLM.

Rozpoznawanie problemu z wyborem protokołu

Nie każde logowanie w domenie Windows odbywa się przez Kerberos. Jeżeli klient korzysta z adresu IP zamiast nazwy hosta, usługa nie ma poprawnego SPN, komputer nie może odnaleźć kontrolera domeny albo występuje problem z DNS, system może przejść do NTLM lub zakończyć próbę błędem. Podobnie dzieje się w przypadku starszych aplikacji, urządzeń sieciowych i usług, które nie obsługują Kerberos. Sam fakt, że użytkownik podał prawidłowe hasło, nie potwierdza więc, że zastosowano właściwy protokół.

Podczas diagnozowania warto ustalić, czy klient i serwer należą do oczekiwanej domeny, czy zegary systemowe są zsynchronizowane oraz czy nazwa usługi odpowiada zarejestrowanemu SPN. W systemie Windows informacje o biletach można sprawdzić poleceniem klist, a bieżące bilety wyczyścić poleceniem klist purge; drugie polecenie usuwa lokalny bufor biletów i może wymusić ponowne uwierzytelnienie. Do analizy zdarzeń służą między innymi dzienniki zabezpieczeń systemu Windows oraz rejestrowanie zdarzeń związanych z uwierzytelnianiem. Jeżeli problem dotyczy pojedynczego programu, trzeba dodatkowo sprawdzić, czy aplikacja rzeczywiście żąda Kerberos, czy tylko korzysta z ogólnego mechanizmu negocjacji, który może zakończyć się użyciem NTLM.