Problema

En entornos con cientos de usuarios y varios roles críticos, la combinación de Azure Privileged Identity Management (PIM) y Conditional Access (CA) debería garantizar que cada elevación requiera una autenticación fuerte. En la práctica, muchos equipos observan que, al activar un rol privilegiado, la sesión existente se reutiliza y la política de MFA no se dispara. El resultado es que un usuario puede activar dos o más roles sin volver a aprobar MFA, lo que debilita la premisa de “least‑privilege” y expone a la organización a ataques de phishing o de sesión comprometida.

Este comportamiento no es un caso aislado; se repite cada vez que la política de CA está configurada para “Require authentication strength” y la sesión actual ya satisface esa fuerza. Azure considera que la sesión es válida y omite el desafío adicional. Cuando la arquitectura incluye varios recursos (M365, Azure RBAC, suscripciones) y los usuarios activan roles de forma frecuente, el problema se vuelve crítico.

Causa

Reutilización de sesión existente

Azure AD mantiene tokens de acceso y refresco durante el tiempo configurado en la política de token lifetime. Si la política de CA exige una “Authentication Strength” que ya está presente en el token, el servicio reutiliza el token en lugar de iniciar un flujo de MFA. Esto ocurre incluso cuando la activación de PIM se produce después de que el usuario haya completado MFA para otra aplicación.

Falta de separación entre “sign‑in frequency” y “authentication strength”

Algunos administradores configuran solo la fuerza de autenticación sin establecer una frecuencia mínima de inicio de sesión. Sin una regla de “Sign‑in frequency”, Azure no fuerza la expiración del token, por lo que la condición de MFA nunca vuelve a evaluarse.

Políticas de CA que excluyen “grant controls” para PIM

Si la política de CA se aplica a los recursos de Azure pero no incluye explícitamente los “grant controls” de PIM (por ejemplo, “Require multi‑factor authentication” o “Require authentication strength”), la activación de rol puede pasar desapercibida. En algunos casos, la política se aplica a “All cloud apps” pero se excluye “Microsoft Entra ID” o “Privileged Identity Management”, creando una brecha.

Configuración de federación externa sin mapear la fuerza de autenticación

Cuando la organización usa un IdP externo (Okta, Ping, etc.) y delega la evaluación de MFA, la fuerza de autenticación definida en Azure no siempre se refleja en la respuesta del IdP. Azure interpreta la respuesta como suficiente y no vuelve a solicitar MFA.

Solución

Una estrategia robusta combina tres pilares:

  1. Forzar expiración de tokens antes de cada activación de PIM
    Utiliza la opción “Sign‑in frequency” en la política de CA para obligar a que el usuario vuelva a autenticarse cada X minutos (recomendado 5‑15 min para cuentas privilegiadas). Esto invalida el token y garantiza que el flujo de MFA se ejecute.

  2. Aplicar una política de CA específica para PIM
    Crea una política que tenga como “Cloud apps” el servicio “Privileged Identity Management”. En los “Grant controls” incluye tanto “Require multi‑factor authentication” como “Require authentication strength” (por ejemplo, “Phishing‑resistant”). Al limitar la política a PIM, evitas que otras aplicaciones hereden la configuración y asegura que cada elevación pase por MFA.

  3. Sincronizar la fuerza de autenticación con el IdP externo
    Cuando se usa federación, habilita “Conditional Access authentication context” y mapea el contexto a la política de MFA del IdP. En Azure, define un “Authentication context” llamado “Privileged‑MFA” y asócialo a la política de CA. En el IdP, configura la regla correspondiente para que la autenticación sea “phishing‑resistant” o “hardware‑based”.

Paso a paso

  1. Crear Authentication Strength

    • En Azure AD → Security → Authentication methods → Authentication strength, crea “Privileged‑MFA” con los métodos deseados (FIDO2, Microsoft Authenticator push, etc.).

  2. Definir Authentication Context

    • En Azure AD → Security → Conditional Access → Authentication context, crea “Privileged‑MFA” y asigna la fuerza creada en el paso anterior.

  3. Política CA para PIM

    • Assignments → Users and groups: selecciona los grupos con privilegios (por ejemplo, “PrivilegedAdmins”).
    • Cloud apps or actions: elige “Privileged Identity Management”.
    • Conditions → Sign‑in frequency: activa y establece “Every 10 minutes”.
    • Grant → Require authentication strength: selecciona “Privileged‑MFA”.
    • Grant → Require multi‑factor authentication: marca la casilla (aunque redundante, refuerza la regla).
    • Enable policy: “On”.

  4. Ajustar la política de token lifetime (opcional)

    • En Azure AD → Security → Authentication token lifetime, reduce la duración del refresh token a 1 hora para cuentas privilegiadas. Esto no reemplaza la frecuencia de sign‑in, pero reduce la ventana de reutilización.

  5. Mapeo en IdP externo

    • En el IdP, crea una política que responda al “Authentication Context” “Privileged‑MFA” con un método de MFA resistente al phishing.
    • Asegúrate de que la respuesta SAML/WS‑Fed incluya el atributo acr con el valor correspondiente.

Cuándo aplicar esta solución

  • Entornos con PIM activado y usuarios que deben elevar privilegios varias veces al día.
  • Incidentes donde la MFA no se dispara al activar roles críticos.
  • Federación con IdP externo que no sincroniza la fuerza de autenticación de Azure.
  • Políticas de seguridad que exigen “least‑privilege” y auditorías que revisan la frecuencia de MFA.

No es necesario aplicar este enfoque si:

  • Solo se usa MFA para acceso a aplicaciones no críticas y la elevación de privilegios es rara.
  • La organización confía exclusivamente en la política de token lifetime sin requerir MFA en cada activación.

Código

# Crear Authentication Strength (PowerShell)
Connect-AzAccount
$strength = New-AzureADMSAuthenticationStrengthPolicy -DisplayName "Privileged-MFA" -IsEnabled $true -Methods @("Fido2", "MicrosoftAuthenticatorPush")
# Crear Authentication Context y asignar la fuerza
New-AzureADMSAuthenticationContextClassReference -DisplayName "Privileged-MFA" -AuthenticationStrengthPolicyId $strength.Id
# Asignar política de CA a PIM (ejemplo con Azure CLI)
az ad conditional-access policy create \
  --name "PIM-Privileged-MFA" \
  --state enabled \
  --conditions-users "groupId=<PrivilegedAdminsGroupId>" \
  --conditions-applications "appId=00000000-0000-0000-0000-000000000000" \   # ID de PIM
  --grant-controls "mfa" "authenticationStrength=Privileged-MFA" \
  --signInFrequency 10

Verificación

  1. Prueba de activación: inicia sesión con un usuario privilegiado, completa MFA, activa un rol en PIM, espera menos de 10 min y vuelve a activar otro rol. Debería aparecer un nuevo desafío MFA.
  2. Revisar logs: en Azure AD → Sign‑in logs, filtra por “Conditional Access” y verifica que la política “PIM-Privileged-MFA” se haya evaluado y que el resultado sea “grant”.
  3. Validar contexto en IdP: revisa la respuesta SAML/WS‑Fed y confirma que el atributo acr contiene “Privileged-MFA”.

Notas adicionales

  • Orden de evaluación: Azure procesa primero las políticas de “Sign‑in frequency”. Si la frecuencia no está activada, la fuerza de autenticación sola no forzará un nuevo desafío.
  • Impacto en UX: un intervalo de 5‑10 min puede resultar molesto para administradores que realizan cambios rápidos. Ajusta según el nivel de riesgo y la tolerancia del equipo.
  • Auditoría: habilita “Conditional Access insights” para generar alertas cuando la política se omite o se evalúa como “not applied”.
  • FIDO2: si tu organización ya dispone de llaves de seguridad, inclúyelas en la fuerza de autenticación; reducen la fricción y aumentan la resistencia al phishing.
  • Escalado: si la política causa bloqueos inesperados, revisa las exclusiones de “Trusted locations” y “Device platforms”. Asegúrate de que los administradores de emergencia tengan una ruta de escape (por ejemplo, cuentas de break‑glass con MFA obligatoria y sin sign‑in frequency).