So nutzen Sie Fiddler-Ablaufverfolgungsprotokolle für MFA in Microsoft 365 und Microsoft Entra ID

In diesem Artikel wird die Fiddler-Protokolldatei für die folgenden MFA-Szenarien vorgestellt.

• Betriebliche MFA-Szenarien
• Wenn das Telefon außerhalb der Abdeckung liegt oder das Telefon nicht ausgewählt ist
• Wenn die Betrugswarnung ausgelöst wird, um das Konto in der Cloud zu blockieren
• Für ein gesperrtes Konto
• Wenn MFA für verwaltete Konten verwendet wird

Wenn ein Benutzerkonto verbunden ist, wird der Benutzer zur Authentifizierung und zum login.microsoftonline.com an den Diensttokenserver (Service Token Server, STS) umgeleitet, und das SAML-Token wird vom STS ausgegeben. Wenn der Benutzer verwaltet wird, authentifiziert login.microsoftonline.com den Benutzer über das Kennwort des Benutzers.

MFA beginnt, nachdem das Kennwort des Benutzers von Microsoft Entra ID oder STS überprüft wurde. Das SANeeded=1 Cookie wird festgelegt, wenn der Benutzer für die MFA-Authentifizierung in Microsoft 365 oder Microsoft Entra ID aktiviert ist. Die Kommunikation zwischen dem Client und login.microsoftonline.com nach der Benutzerkennwortauthentifizierung ähnelt dem folgenden Beispiel:

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

HTTP/1.1 302 gefunden

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

Szenario 1: Funktionierende MFA-Szenarien

Das SANeeded=1-Cookie wird nach der Kennwortauthentifizierung festgelegt. Der Netzwerkdatenverkehr wird dann an den Endpunkt umgeleitet: https://login.microsoftonline.com/StrongAuthCheck.srfund verfügbare Authentifizierungsmethoden werden angefordert.

MFA beginnt mit BeginAuth, und dann wird der Telefonanruf am Back-End an den Telefondienstanbieter ausgelöst.

Nachdem die MFA-Autorisierung beginnt, beginnt der Client alle 10 Sekunden mit der Abfrage desselben Endpunkts für die EndAuth-Methode, um zu überprüfen, ob die Authentifizierung abgeschlossen ist. Bis der Aufruf ausgewählt und überprüft wird, wird der Ergebniswert als AuthenticationPendingzurückgegeben.

Wenn das Telefon ausgewählt und überprüft wird, wird die Antwort für die nächste Abfrage bei EndAuth ein Ergebniswert für Erfolg sein. Darüber hinaus hat der Benutzer die mehrstufige Authentifizierung abgeschlossen. Außerdem wird das Set-Cookie : SANeeded=xxxxxxx-Cookie in der Antwort gesetzt, die an den Endpunkt login.srf geschickt wird, um die Authentifizierung abzuschließen.

Szenario 2: Wenn das Telefon nicht abgedeckt ist oder das Telefon nicht ausgewählt ist

Wenn das Telefon nicht innerhalb von 60 Sekunden nach dem Anruf ausgewählt und überprüft wird, wird der ResultValue als UserVoiceAuthFailedPhoneUnreachablefestgelegt. Bei der nächsten Abfrage für die EndAuth-Methode wird UserVoiceAuthFailedPhoneUnreachable zurückgegeben, wie in Fiddler dargestellt.

Szenario 3: Wenn die Betrugswarnung ausgelöst wird, um das Konto in der Cloud zu blockieren

Wenn das Telefon nicht abgenommen wird und eine Betrugswarnung innerhalb von 60 Sekunden nach dem Anruf gepostet wird, wird "ResultValue" als AuthenticationMethodFailed festgelegt. Bei der nächsten Abfrage für die EndAuth-Methode wird eine AuthenticationMethodFailed-Antwort zurückgegeben, wie in Fiddler dargestellt.

Szenario 4: Für ein gesperrtes Konto

Wenn der Benutzer blockiert ist, wird ResultValue als UserIsBlockedfestgelegt. Bei der ersten Abfrage für die EndAuth-Methode UserIsBlocked wird zurückgegeben, wie in Fiddler dargestellt.

Lösung: Siehe "Verdächtige Aktivitäten melden".

Wenn MFA über Microsoft 365 aktiviert ist, senden Sie eine Supportanfrage mit Microsoft, um die Blockierung aufzuheben.

Szenario 5: MFA für verwaltete Konten

In diesem Fall bleibt die Authentifizierung gleich, aber die Endpunkte sind https://login.microsoftonline.com/common/SAS/BeginAuth und https://login.microsoftonline.com/common/SAS/EndAuth nicht https://login.microsoftonline.com/StrongAuthCheck.srf für die Verbundkonten.