Jak używać dzienników śledzenia programu Fiddler dla uwierzytelniania wieloskładnikowego na platformie Microsoft 365 i identyfikatorze Entra firmy Microsoft

W tym artykule przedstawiono dziennik śledzenia programu Fiddler dla następujących scenariuszy uwierzytelniania wieloskładnikowego:

• Działające scenariusze uwierzytelniania wieloskładnikowego
• Gdy telefon jest poza zasięgiem lub telefon nie jest wybrany
• Po uruchomieniu alertu o nieprawidłowościach, aby zablokować konto w chmurze
• Dla zablokowanego konta
• Gdy uwierzytelnianie wieloskładnikowe jest używane dla kont zarządzanych

Jeśli konto użytkownika jest federacyjne, użytkownik jest przekierowywany do serwera tokenów usługi (STS) na potrzeby uwierzytelniania i do login.microsoftonline.com, a token SAML jest wystawiany przez usługę STS. Jeśli użytkownik jest zarządzany, login.microsoftonline.com uwierzytelnia użytkownika za pomocą hasła użytkownika.

Uwierzytelnianie wieloskładnikowe jest uruchamiane po zweryfikowaniu hasła użytkownika przez usługę Microsoft Entra ID lub STS. Plik SANeeded=1 cookie jest ustawiany, jeśli użytkownik ma włączone uwierzytelnianie wieloskładnikowe w usłudze Microsoft 365 lub Microsoft Entra ID. Komunikacja między klientem a login.microsoftonline.com po uwierzytelnieniu hasła użytkownika przypomina następujący przykład:

POST https://login.microsoftonline.com/login.srf HTTP/1.1
Host: login.microsoftonline.com

Znaleziono protokół HTTP/1.1 302

Set-Cookie: SANeeded=1; domain=login.microsoftonline.com; secure=; path=/; HTTPOnly=; version=1

Scenariusz 1: Działające scenariusze uwierzytelniania wieloskładnikowego

Plik cookie SANeeded=1 jest ustawiany po uwierzytelnieniu hasła. Ruch sieciowy jest następnie przekierowywany do punktu końcowego: https://login.microsoftonline.com/StrongAuthCheck.srf, a dostępne metody uwierzytelniania są wymagane.

Uwierzytelnianie wieloskładnikowe rozpoczyna się od BeginAuth, a następnie połączenie telefoniczne jest wyzwalane w tle do dostawcy usług telefonicznych.

Po rozpoczęciu autoryzacji uwierzytelniania wieloskładnikowego klient rozpoczyna wykonywanie zapytań o ten sam punkt końcowy dla metody EndAuth co 10 sekund, aby sprawdzić, czy uwierzytelnianie zostało ukończone. Dopóki wywołanie nie zostanie odebrane i zweryfikowane, wartość wynik zostanie zwrócona jako AuthenticationPending.

Po wybraniu i zweryfikowaniu telefonu odpowiedź na następne zapytanie dotyczące uwierzytelniania końcowego będzie wynikiem ResultValue of Success. Ponadto użytkownik ukończył uwierzytelnianie wieloskładnikowe. Ponadto plik cookie Set-Cookie : SANeeded=xxxxxxx jest ustawiany w odpowiedzi, która jest przekazywana endpointowi login.srf w celu zakończenia uwierzytelniania.

Scenariusz 2: Gdy telefon jest poza zasięgiem lub telefon nie jest odbierany

Gdy telefon nie zostanie odebrany i zweryfikowany w ciągu 60 sekund po nawiązaniu połączenia, wartość ResultValue jest ustawiona na UserVoiceAuthFailedPhoneUnreachable. W następnym zapytaniu dla metody EndAuth zwracana jest funkcja UserVoiceAuthFailedPhoneUnreachable, jak pokazano w narzędziu Fiddler.

Scenariusz 3. Po wyzwoleniu alertu o oszustwie w celu zablokowania konta w chmurze

Kiedy telefon nie zostanie odebrany, a alert o oszustwie zostanie opublikowany w ciągu 60 sekund po nawiązaniu połączenia, parametr ResultValue zostanie ustawiony jako "AuthenticationMethodFailed". W następnym zapytaniu dla metody EndAuth zwracana jest odpowiedź AuthenticationMethodFailed, jak pokazano w narzędziu Fiddler.

Scenariusz 4. W przypadku zablokowanego konta

Jeśli użytkownik jest zablokowany, właściwość ResultValue jest ustawiona na wartość UserIsBlocked. Na pierwsze zapytanie do metody EndAuth zwracany jest UserIsBlocked, jak pokazano w narzędziu Fiddler.

Rozwiązanie: zobacz Zgłaszanie podejrzanych działań.

Jeśli uwierzytelnianie wieloskładnikowe jest włączone za pośrednictwem platformy Microsoft 365, prześlij wniosek o pomoc techniczną z firmą Microsoft, aby go odblokować.

Scenariusz 5. Uwierzytelnianie wieloskładnikowe dla kont zarządzanych

W takiej sytuacji uwierzytelnianie pozostaje takie samo, ale punkty końcowe są https://login.microsoftonline.com/common/SAS/BeginAuth i https://login.microsoftonline.com/common/SAS/EndAuth zamiast https://login.microsoftonline.com/StrongAuthCheck.srf dla kont federacyjnych.