MFA no obligatorio para todos los usuarios Entra: la brecha crítica de acceso condicional que las políticas solo para administradores no cubren

MFA no obligatorio para todos los usuarios Entra: qué significa realmente

MFA no obligatorio para todos los usuarios Entra designa una brecha de acceso condicional concreta, frecuente y de severidad Crítica en Microsoft Entra ID — y no es el mismo fallo que no tener acceso condicional en absoluto. Un tenant puede superar cualquier lista de comprobación del tipo «¿tiene usted acceso condicional?», mostrar una directiva que apunta literalmente a All users (todos los usuarios), y aun así dejar todas las cuentas que no son de administrador accesibles solo con una contraseña. Eso ocurre cuando el control de concesión de la directiva exige algo distinto del MFA (el cumplimiento del dispositivo, por ejemplo), o cuando la aplicación del MFA está repartida entre varias directivas acotadas a roles o a aplicaciones, cada una sólida por separado, que nunca llegan a sumar una cobertura general.

Esta es la hermana más estrecha, más común y más peligrosa de dos problemas mejor conocidos:

• Ninguna directiva de acceso condicional, del tipo que sea, dirigida a todos los usuarios. Ese es el fallo de cobertura base — véase Brechas de cobertura de las directivas base de acceso condicional en Entra ID para tenants sin ninguna directiva que cubra los roles de administración, todos los usuarios, todas las aplicaciones en la nube o el cumplimiento de dispositivos. Este artículo da por hecho que ya existe una directiva dirigida a todos los usuarios; la brecha aquí es más estrecha y más fácil de pasar por alto — la directiva existe, pero no exige MFA.
• MFA exigido solo a los administradores. La mayoría de los proyectos de fortificación del acceso condicional empiezan por aquí, y con razón — véase Seguridad de identidad en Azure: por qué el MFA por sí solo no basta. Pero una directiva de MFA acotada a administradores, por bien construida que esté, es estructuralmente incapaz de proteger las cuentas a las que nunca se asignó. Los usuarios estándar inician sesión en los mismos buzones, los mismos sitios de SharePoint y las mismas aplicaciones de negocio que los administradores; no son un objetivo de menor valor, simplemente son un objetivo desprotegido.

Por eso también la brecha es fácil de pasar por alto incluso para equipos que ya han hecho un trabajo real de fortificación. Una organización que desplegó el MFA para administradores por MFA_NOT_ENFORCED_ADMINS, o que blindó la autenticación de los Global Admins por PA_GLOBAL_ADMIN_NOT_MFA, ha hecho primero el trabajo que parece más difícil, y asume razonablemente que el caso más sencillo y más amplio — todos los usuarios restantes — ya queda cubierto por extensión. Estructuralmente no es así: las directivas acotadas a administradores y las dirigidas a todos los usuarios se construyen sobre condiciones de asignación diferentes en Entra ID, de modo que completar una deja la cobertura de la otra exactamente donde empezó, en cero.

Dos plantillas distintas, dos acciones de Secure Score distintas

Microsoft no modela «exigir MFA» como un control único. En la galería de plantillas de acceso condicional, Require multifactor authentication for admins y Require multifactor authentication for all users figuran como dos plantillas separadas. Ambas aparecen juntas bajo la propia categoría «Secure foundation» de Microsoft — el conjunto que Microsoft recomienda explícitamente desplegar como grupo — y ambas vuelven a aparecer, todavía como dos entradas separadas, bajo la categoría «Zero Trust». Ninguna de las dos descripciones de plantilla afirma cubrir el terreno de la otra, en ninguna de las dos listas.

La misma división existe en la puntuación. El Identity Secure Score de Microsoft Entra ID sigue «Require multifactor authentication (MFA) for administrative roles» y «Ensure all users can complete MFA» como dos acciones de mejora distintas en su propio catálogo. Un tenant puede obtener el máximo en la primera y cero en la segunda; Secure Score no las trata como redundantes, y quien revise una exportación de acceso condicional tampoco debería.

La acción de todos los usuarios se puntúa además como porcentaje del total de usuarios protegidos, no como un apto/no apto binario. En el propio ejemplo resuelto de Microsoft, tener 5 usuarios protegidos de 100 usuarios totales suma aproximadamente un 0,53 % de un posible 10,71 % para ese control — es decir, la mayoría de los tenants que han «empezado» con el MFA para todos los usuarios siguen arrastrando casi toda la exposición que el control pretende cerrar.

Cómo una cobertura fragmentada oculta la brecha

La plantilla de MFA para administradores y la plantilla de MFA para todos los usuarios no están acotadas igual, y esa diferencia es exactamente como una brecha sobrevive a una revisión superficial de directivas:

• Require multifactor authentication for admins se asigna bajo Directory roles (roles de directorio), y únicamente a una lista definida de roles integrados — Global Administrator, Application Administrator, Authentication Administrator, Privileged Role Administrator, Security Administrator, y otros nombrados explícitamente en la documentación de Microsoft. La advertencia de Microsoft es directa: "Conditional Access policies support built-in roles. Conditional Access policies are not enforced for other role types including administrative unit-scoped or custom roles." Un rol personalizado «IT Support» con permisos elevados, o un rol asignado solo en el ámbito de una unidad administrativa, es invisible para esta directiva incluso mientras está habilitada y aplicándose.
• Require multifactor authentication for all users se asigna bajo Include: All users, con exclusiones limitadas a las cuentas de emergencia y a las cuentas de servicio de sincronización de directorio. No hay ninguna condición de rol por la que un usuario pueda escaparse.

Como las dos directivas usan modelos de asignación diferentes, un tenant puede acumular varias directivas de MFA realmente aplicadas — una acotada a los Global Admins, otra acotada a una aplicación financiera concreta, otra disparada solo por un inicio de sesión de riesgo — y no haber desplegado nunca la única directiva cuyo Include es literalmente All users, cuyo Target resources es All resources, y cuyo control de concesión exige MFA. Cada directiva por separado es real; ninguna de ellas, ni siquiera sumadas, equivale a la base que Microsoft recomienda. Acceso condicional en Azure: brechas y bypass de MFA cubre el patrón más amplio de exclusiones y desajustes de ámbito que dejan que un conjunto de acceso condicional parezca completo mientras deja exposición real en producción. Acceso privilegiado en Azure: demasiados administradores globales cubre el fallo paralelo del lado privilegiado, donde los roles de administración permanentes y las carencias de PIM agravan la misma debilidad de fondo desde el otro extremo.

Detección

Confirmar esta brecha no exige adivinar — Microsoft Entra ID registra la etapa de autenticación exacta alcanzada en cada inicio de sesión, por usuario y por aplicación.

Según la propia guía de Microsoft para encontrar carencias de MFA en administradores: "Any sign-in where Authentication requirement is Single-factor authentication means there was no multifactor authentication policy that was required for the sign-in." Esa guía está escrita específicamente para administradores, pero el campo en sí no está acotado por rol — es una propiedad del evento de inicio de sesión, así que la misma comprobación se aplica a cualquier población de usuarios, administradores o no.

authenticationRequirement se expone en el recurso signIn del endpoint beta de Microsoft Graph — no está presente en el recurso signIn estable v1.0 — y admite $filter con los operadores eq y startsWith:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=authenticationRequirement%20eq%20%27singleFactorAuthentication%27

El filtro va codificado en porcentaje — %20 para los espacios, %27 para las comillas — de modo que la petición funciona tanto pegada en un cliente de línea de comandos como en Graph Explorer. Sin codificar, los espacios en bruto hacen que herramientas como curl rechacen la URL localmente, antes siquiera de enviarla.

O con el módulo beta del SDK de PowerShell para Microsoft Graph:

Import-Module Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"

Get-MgBetaAuditLogSignIn `
  -Filter "authenticationRequirement eq 'singleFactorAuthentication'" `
  -Top 50 `
  -Property UserPrincipalName, AppDisplayName, CreatedDateTime, AuthenticationRequirement

Remediation

1. Desplegar la plantilla de MFA para todos los usuarios de Microsoft

Compruebe primero si Microsoft ya ha puesto una en el tenant. Las directivas Microsoft-managed las crea y despliega Microsoft directamente en los tenants elegibles, y una de ellas se llama Multifactor authentication for all users — "covers all users in your organization and requires them to use multifactor authentication whenever they sign in." Llega inerte: "The policy is automatically created in your tenant in a Report-only state." Microsoft la habilita después "no less than 30 days after they're introduced in your tenant if they're left in the Report-only state," avisando a los tenants dos semanas antes. Filtre por Microsoft en la columna Created by antes de construir un duplicado.

Si no, use la galería de plantillas de acceso condicional, o construya la directiva equivalente directamente:

• En Assignments → Users, establezca Include: All users.
• En Exclude, añada únicamente las cuentas de acceso de emergencia «break-glass» documentadas de su organización y, si usa sincronización de identidad híbrida, el rol Directory Synchronization Accounts — no una exclusión amplia de «equipo de TI» que recree la brecha en silencio.
• En Target resources, establezca Include: All resources, sin exclusiones de aplicaciones.
• En Grant, elija Require authentication strength y seleccione la fuerza integrada Multifactor authentication strength.

2. Desplegar en modo solo informe, y confirmar que realmente sale de ese modo

Revise el impacto previsto mediante Policy impact o el libro Conditional Access Insights and Reporting antes de cambiar Enable policy a On — así es como detecta una cuenta de emergencia, de servicio o de autenticación heredada que de otro modo quedaría bloqueada inesperadamente. Una directiva dejada indefinidamente en modo solo informe, o una lista de exclusiones que ha crecido en silencio más allá de su ámbito original, no aplica nada mientras sigue mostrando «On» — compruébelo después del despliegue, no solo al crearla.

3. Validar la cobertura con la herramienta What If

Ejecute la herramienta What If sobre una muestra de usuarios corrientes, no administradores — no solo las cuentas de administración ya cubiertas por la otra directiva — para confirmar que la nueva directiva se les aplica realmente. Las directivas habilitadas y las directivas en modo solo informe se incluyen ambas en una ejecución de evaluación, así que una directiva todavía en fase de solo informe aparecerá aquí. Lea el resultado como una simulación y no como una garantía: Microsoft señala que la herramienta "doesn't test for Conditional Access service dependencies," y que las condiciones que deje sin especificar son condiciones que no puede evaluar.

4. No sustituir con esto el MFA para administradores, ni al revés

Si la directiva de MFA acotada a administradores tampoco está desplegada todavía, trátela como una segunda acción, separada. Véase Seguridad de identidad en Azure: por qué el MFA por sí solo no basta y Acceso privilegiado en Azure: demasiados administradores globales. Desplegar una directiva no sustituye a la otra; ambas están en la propia lista «Secure foundation» de Microsoft por algo.

5. Ir más allá del MFA básico cuando la cobertura sea estable

Una vez que la cobertura amplia de MFA esté aplicada y estable, pase de la fuerza básica Multifactor authentication strength a métodos resistentes al phishing o sin contraseña para los usuarios que puedan soportarlos — véase Entra ID: el cambio en el registro de MFA sin contraseña.

Cómo lo detecta EtcSec

La auditoría de Azure/Entra de EtcSec comprueba específicamente MFA_NOT_ENFORCED_ALL: una configuración de acceso condicional en la que ninguna directiva dirigida a todos los usuarios y a todas (o prácticamente todas) las aplicaciones en la nube lleva un control de concesión que exija MFA o una fuerza de autenticación equivalente a MFA. Se evalúa de forma independiente de MFA_NOT_ENFORCED_ADMINS, PA_GLOBAL_ADMIN_NOT_MFA y CA_NO_POLICY_ALL_USERS — resolver una de esas comprobaciones no resuelve esta.