NTLM (dla Microsoft Exchange)

NTLM to starszy protokół uwierzytelniania Microsoftu, w Exchange wypierany przez Kerberos i nowoczesne uwierzytelnianie.

NTLM jako protokół uwierzytelniania w środowisku Microsoft Exchange

NTLM, czyli NT LAN Manager, jest protokołem uwierzytelniania stosowanym w środowiskach Windows, w tym w niektórych sposobach dostępu do skrzynek Microsoft Exchange. Nie przesyła on hasła użytkownika wprost do serwera. Zamiast tego serwer wysyła klientowi losowe wyzwanie, a klient oblicza odpowiedź na podstawie tego wyzwania oraz poświadczeń. Serwer może następnie zweryfikować odpowiedź lokalnie albo przekazać ją do kontrolera domeny. W praktyce użytkownik widzi zwykle tylko monit o hasło lub komunikat o nieudanym logowaniu, natomiast właściwa wymiana odbywa się w kilku etapach protokołu.

W nowszych wdrożeniach rozróżnia się przede wszystkim NTLMv2 oraz starszy NTLMv1. NTLMv2 zapewnia silniejszy mechanizm odpowiedzi niż NTLMv1, ale sam fakt używania NTLM nie oznacza takiego poziomu ochrony jak w przypadku Kerberosa lub nowoczesnego uwierzytelniania opartego na tokenach. NTLM jest związany z mechanizmami kont Windows i domen Active Directory. Dlatego skuteczność logowania zależy nie tylko od ustawień Exchange, lecz także od nazwy domeny, dostępności kontrolera domeny, synchronizacji czasu, rozpoznawania nazw oraz poprawnego działania kanału między serwerem Exchange a usługami katalogowymi.

Jak NTLM pojawia się przy połączeniach z Exchange

Microsoft Exchange nie jest jednym protokołem komunikacyjnym. Klient pocztowy może korzystać między innymi z Outlook Anywhere, MAPI over HTTP, usług webowych albo interfejsów dostępu przez przeglądarkę. W zależności od wersji Exchange, klienta Outlook, konfiguracji katalogu wirtualnego i sposobu publikacji usługi dostępne mechanizmy uwierzytelniania mogą obejmować Kerberos, NTLM, Negotiate, Basic Authentication lub rozwiązania nowoczesnego uwierzytelniania. NTLM może zostać użyty wtedy, gdy klient i serwer uzgodnią ten mechanizm albo gdy próba użycia Kerberosa nie powiedzie się i konfiguracja dopuszcza przejście do NTLM.

W nagłówkach HTTP mechanizm może być sygnalizowany przez wartość WWW-Authenticate: NTLM albo przez negocjację prowadzoną za pośrednictwem SPNEGO, zwykle reprezentowaną jako Negotiate. Sama obecność słowa „Negotiate” nie dowodzi, że faktycznie użyto Kerberosa, ponieważ w ramach tej negocjacji może zostać wybrany również NTLM. Przy połączeniach Outlooka znaczenie mają także nazwy usług i adresy używane przez klienta. Kerberos wymaga poprawnego powiązania nazwy usługi z kontem serwera, natomiast NTLM może zadziałać w sytuacji, w której takie powiązanie jest niepełne, co bywa jedną z przyczyn niepożądanego przechodzenia na starszy mechanizm.

Różnice między NTLM a Kerberosem w przepływie logowania

Kerberos korzysta z biletów wydawanych przez centrum dystrybucji kluczy działające w ramach domeny Active Directory. Po uzyskaniu odpowiedniego biletu klient może przedstawić go konkretnej usłudze, bez każdorazowego przekazywania odpowiedzi opartej bezpośrednio na haśle. NTLM działa inaczej: każda sesja wykorzystuje wymianę wyzwanie–odpowiedź, a serwer musi potwierdzić poświadczenia w sposób zgodny z konfiguracją domeny. Kerberos jest zwykle preferowany w kontrolowanym środowisku domenowym, ponieważ lepiej obsługuje wzajemną identyfikację usług, delegowanie oraz uwierzytelnianie bez ponownego pytania użytkownika o hasło.

Przejście z Kerberosa na NTLM może wskazywać na problem z konfiguracją, ale nie jest samo w sobie dowodem awarii Exchange. Przyczyną może być użycie aliasu, rekordu DNS lub adresu, dla którego nie istnieje właściwy Service Principal Name, niezgodność nazw hostów, brak łączności z kontrolerem domeny, rozbieżność czasu albo ograniczenia po stronie klienta. Warto odróżnić błąd uwierzytelniania od błędu transportu. Jeżeli klient nie dociera do serwera, przyczyną mogą być DNS, certyfikat TLS, zapora lub konfiguracja proxy. Jeżeli wymiana NTLM rozpoczyna się, lecz kończy kodem odmowy, należy sprawdzać konto, hasło, blokadę konta, członkostwo w domenie i zasady bezpieczeństwa.

Diagnostyka nieudanego uwierzytelniania NTLM

Analizę należy rozpocząć od ustalenia, jaka aplikacja i jaki protokół faktycznie zgłaszają problem. Inaczej interpretuje się monit Outlooka, błąd logowania do Outlook Web App, problem z urządzeniem mobilnym i nieudaną próbę połączenia z usługą publikowaną przez IIS. Pomocne są dzienniki IIS, logi protokołów Exchange, Podgląd zdarzeń systemu Windows oraz informacje z klienta Outlook. Należy porównać czas zdarzenia, nazwę użytkownika, adres usługi, użyty adres URL i kod odpowiedzi HTTP. Wielokrotne monity o hasło nie zawsze oznaczają błędne hasło; mogą wynikać z zapisanych nieaktualnych poświadczeń, uszkodzonego profilu Outlooka albo wyboru niewłaściwej metody uwierzytelniania.

W środowisku domenowym sprawdza się rozwiązywanie nazwy serwera, dostęp klienta do kontrolera domeny, synchronizację czasu oraz poprawność konfiguracji usług Exchange i IIS. Przy podejrzeniu problemu z Kerberosem analizuje się również rejestracje SPN i sposób, w jaki klient odwołuje się do usługi. Przy NTLM trzeba uwzględnić zasady zabezpieczeń systemu Windows ograniczające starsze wersje protokołu oraz ustawienia przekazywania poświadczeń. Nie należy bezrefleksyjnie obniżać poziomu zabezpieczeń tylko po to, aby usunąć monit logowania. W przypadku serwisowania laptopa lub komputera PC diagnostyka może obejmować profil Outlooka, zapisane poświadczenia systemu Windows, konfigurację DNS i poprawność lokalnego połączenia z domeną, bez zmiany ustawień serwera Exchange bez odpowiednich uprawnień.