Uso de los registros de seguimiento de Fiddler para MFA en Microsoft 365 e ID de Microsoft Entra

En este artículo se presenta el registro de seguimiento de Fiddler para los siguientes escenarios de MFA:

• Escenarios de MFA en funcionamiento
• Cuando el teléfono está fuera de cobertura o no se responde el teléfono.
• Cuando se desencadena la alerta de fraude para bloquear la cuenta en la nube
• Para una cuenta bloqueada
• Cuando se usa MFA para cuentas administradas

Si se federa una cuenta de usuario, el usuario se redirige al servidor de token de servicio (STS) para la autenticación y a login.microsoftonline.com, y el STS emite el token SAML. Si el usuario está gestionado, login.microsoftonline.com autentica al usuario mediante su contraseña.

MFA se inicia después de que microsoft Entra ID o STS comprueben la contraseña del usuario. La SANeeded=1 cookie se establece si el usuario está habilitado para la autenticación de MFA en Microsoft 365 o microsoft Entra ID. La comunicación entre el cliente y login.microsoftonline.com después de que la autenticación de contraseña de usuario sea similar al ejemplo siguiente:

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

HTTP/1.1 302 Encontrado

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

Escenario 1: Escenarios de MFA en funcionamiento

La cookie SANeeded=1 se establece después de la autenticación de contraseña. A continuación, se redirige el tráfico de red al punto de conexión: https://login.microsoftonline.com/StrongAuthCheck.srfy se solicitan los métodos de autenticación disponibles.

MFA comienza con BeginAuth y, a continuación, la llamada telefónica se desencadena en el back-end al proveedor de servicios telefónicos.

Una vez iniciada la autorización de MFA, el cliente comienza a consultar el mismo punto de conexión para el método EndAuth cada 10 segundos para comprobar si se completa la autenticación. Hasta que se atiende y comprueba la llamada, el valor Result se devuelve como AuthenticationPending.

Cuando se selecciona y verifica el teléfono, la respuesta de la siguiente consulta para EndAuth será ResultValue of Success. Además, el usuario ha completado la autenticación multifactor. También el Set-Cookie : SANeeded=xxxxxxx cookie se establece en la respuesta, que se proporciona al punto de conexión : login.srf para completar la autenticación.

Escenario 2: Cuando el teléfono está fuera de cobertura o no se contesta el teléfono

Cuando el teléfono no se selecciona y comprueba en un plazo de 60 segundos después de realizar la llamada, ResultValue se establece como UserVoiceAuthFailedPhoneUnreachable. En la siguiente consulta para el método EndAuth, se devuelve UserVoiceAuthFailedPhoneUnreachable, como se ve en Fiddler.

Escenario 3: cuando se desencadena la alerta de fraude para bloquear la cuenta en la nube

Cuando no se responde al teléfono y se publica una alerta de fraude en un plazo de 60 segundos después de realizar la llamada, el valor de resultado se establece en AuthenticationMethodFailed. En la siguiente consulta para el método EndAuth, se devuelve una respuesta AuthenticationMethodFailed, como se muestra en Fiddler.

Escenario 4: Para una cuenta bloqueada

Si el usuario está bloqueado, ResultValue se establece como UserIsBlocked. En la primera consulta del método EndAuth, UserIsBlocked se devuelve, como se ve en Fiddler.

Solución: consulte Notificar actividad sospechosa.

Si MFA está habilitado a través de Microsoft 365, envíe una solicitud de soporte técnico con Microsoft para desbloquearla.

Escenario 5: MFA para cuentas administradas

En esta situación, la autenticación sigue siendo la misma, pero los puntos de conexión son https://login.microsoftonline.com/common/SAS/BeginAuth y https://login.microsoftonline.com/common/SAS/EndAuth en lugar de https://login.microsoftonline.com/StrongAuthCheck.srf para las cuentas federadas.