AZ-104
Deep Dive
MFA bloquea el 99.9% de los ataques de cuenta. El AZ-104 evalúa los métodos disponibles, la diferencia entre MFA por usuario y vía Conditional Access, y la configuración de SSPR.
Contenido
MFA requiere que el usuario verifique su identidad con dos o más factores de categorías distintas. Si un atacante roba la contraseña, sin el segundo factor no puede entrar.
Algo que SABES
Algo que TIENES
Algo que ERES
Contraseña + PIN ≠ MFA
Ambos son "algo que sabes" — misma categoría. MFA requiere factores de categorías distintas. Contraseña + app authenticator = MFA válido.
| Método | Descripción | MFA | SSPR | Seguridad |
|---|---|---|---|---|
| Microsoft Authenticator App | Push notification o código TOTP. App gratuita iOS/Android. | ✓ | ✓ | ⭐⭐⭐⭐⭐ Recomendado |
| FIDO2 Security Key | Llave física USB/NFC. Passwordless + phishing-resistant. | ✓ | ✓ | ⭐⭐⭐⭐⭐ Máxima seguridad |
| Windows Hello for Business | Biométrico o PIN en dispositivo Windows unido a dominio. | ✓ | ✗ | ⭐⭐⭐⭐⭐ |
| TOTP (Authenticator o 3rd party) | Código de 6 dígitos que rota cada 30 segundos. | ✓ | ✓ | ⭐⭐⭐⭐ |
| SMS / Llamada telefónica | Código por texto o llamada. Conveniente pero susceptible a SIM swap. | ✓ | ✓ | ⭐⭐ — desaconsejado si hay alternativa |
| Email (solo SSPR) | Código de verificación a email externo. Solo para SSPR, no para MFA de login. | ✗ | ✓ | ⭐⭐ |
| Preguntas de seguridad (SSPR) | Respuestas a preguntas predefinidas. Solo SSPR. Fácil de comprometer. | ✗ | ✓ | ⭐ — solo como último recurso |
Cómo funciona
En Entra ID → Users → Per-user MFA, cada usuario tiene un estado:
⚠ Por qué es "legacy"
Conditional Access aplica MFA de forma inteligente basándose en señales de contexto. Requiere Entra ID P1.
Anatomía de una CA Policy
Assignments → Users
A quién aplica: todos los usuarios, grupos específicos, o excluir cuentas de emergencia (break-glass).
Assignments → Cloud apps
Sobre qué apps: todas las apps, Microsoft Admin Portals, o apps específicas (Salesforce, etc.).
Conditions
Señales: ubicación (named location), plataforma de dispositivo, client app, sign-in risk, user risk.
Access controls → Grant
Qué hacer: Block access, o Grant con condiciones (require MFA, compliant device, hybrid Azure AD join, etc.).
Access controls → Session
Controles de sesión: frecuencia de re-autenticación, modo solo lectura para apps no administradas.
Políticas CA comunes — AZ-104
Require MFA for Admins
Todos los usuarios con roles de directorio (Global Admin, etc.) deben hacer MFA siempre.
Require MFA from untrusted locations
MFA solo cuando el login viene de IPs no incluidas en Named Locations de confianza.
Block legacy authentication
Bloquear protocolos legacy (IMAP, SMTP, EAS) que no soportan MFA.
Require compliant device
Solo acceso desde dispositivos marcados como compliant en Intune.
Report-only mode
Antes de activar una CA policy, úsala en modo "Report-only" — evalúa sin enforcar. Ver en Sign-in logs quién sería impactado. Evita lockouts accidentales.
Authentication Strength permite especificar en una CA policy exactamente qué combinaciones de métodos de autenticación son aceptables. Más granular que solo "require MFA".
Políticas built-in
Multifactor authentication
BásicoCualquier combinación válida de MFA. Equivalente a "require MFA" clásico. Acepta password + SMS, password + app, passwordless, etc.
Passwordless MFA
IntermedioSolo métodos que no requieren contraseña + segundo factor: Microsoft Authenticator (sign-in sin contraseña), FIDO2, Windows Hello for Business.
Phishing-resistant MFA
MáximoSolo métodos resistentes a phishing: FIDO2 Security Keys, Windows Hello for Business, Certificate-based authentication. Los más seguros.
Custom Authentication Strength
Crea tus propias combinaciones permitidas. Por ejemplo: permitir solo FIDO2 o certificate-based auth, bloqueando SMS y llamada de voz.
→ Entra ID → Security → Authentication methods → Authentication strengths → New authentication strength
→ Selecciona las combinaciones de métodos permitidas (AND combinations)
→ Asigna la custom strength en una CA policy → Access controls → Grant → Require authentication strength
Cuándo usar Authentication Strength vs "Require MFA"
"Require MFA": cualquier método MFA válido es aceptable. Flexible.
Authentication Strength: cuando necesitas exigir métodos específicos. Ej: recursos muy sensibles donde SMS no es aceptable por riesgo de SIM swap.
Los ataques de MFA fatigue bombardean al usuario con notificaciones push hasta que acepta accidentalmente. Microsoft implementó protecciones que están habilitadas por defecto desde 2023.
Number Matching
Cuando el usuario recibe la notificación push de Authenticator, debe ingresar el número de 2 dígitos que aparece en la pantalla de login. El atacante no tiene ese número.
Habilitado por defecto (no desactivable)
Additional Context
La notificación push muestra: nombre de la app que solicita acceso (ej: "Azure Portal") y ubicación aproximada del login (ej: "Ciudad de México, México"). El usuario puede detectar si no es él.
Habilitado por defecto
GPS Location (optional)
El usuario puede opcionalmente compartir su GPS para contexto adicional. Permite al admin ver desde dónde se autenticó. No obligatorio.
Opcional, controlado por el usuario
MFA Fatigue Attack — cómo funciona
El atacante tiene la contraseña del usuario (obtenida por phishing). Intenta login continuamente generando decenas de push notifications al teléfono del usuario. El usuario, frustrado o confundido, eventualmente acepta. Con number matching, el atacante tiene la contraseña pero no el número que aparece en la pantalla de la víctima → el ataque falla.
Muchas apps corporativas (VPN, Remote Desktop Gateway, switches de red) usan RADIUS para autenticación. No soportan OIDC/SAML modernos. La NPS Extension extiende el servidor NPS on-premises para invocar Entra MFA.
Arquitectura con NPS Extension
Requisitos
• Licencia: Entra ID P1 mínimo
• SO: Windows Server 2012 R2+ con rol NPS instalado
• Conectividad: NPS server necesita HTTPS saliente a Azure
• Los usuarios deben tener método MFA registrado en Entra ID
• PowerShell: AzureAD module y el script de configuración del tenant
Limitaciones de NPS Extension
• Solo soporta Microsoft Authenticator (push/TOTP) y llamada de voz — no FIDO2 ni passwordless
• No soporta cuentas guest B2B
• Si Azure MFA está down, la autenticación puede fallar (sin fallback a solo contraseña por defecto)
• Timeout de RADIUS puede ser problema — extender timeout en el cliente VPN a 60+ segundos
Configuración de SSPR
Entra ID → Password reset → Properties. Tres opciones de scope:
Número de métodos requeridos
Se puede configurar cuántos métodos debe verificar el usuario para resetear:
1 método
Menos fricción
Menos seguro — un método comprometido = reset posible
2 métodos
Más seguro
El usuario debe tener 2 métodos registrados
El registro combinado unifica el registro de métodos para MFA y SSPR en una sola experiencia en aka.ms/mysecurityinfo.
Registration Campaign
Función para empujar a los usuarios a registrar métodos más seguros (ej: migrar de SMS a Authenticator App). Se configura en Authentication methods → Registration campaign.
• Aparece como interrupción en el login: "Mejora tu seguridad"
• El usuario puede posponer N veces (configurable)
• Incluye o excluye grupos específicos
• Se puede monitorear el progreso de adopción
Cuentas break-glass (de emergencia)
Cuentas de acceso de emergencia que deben existir fuera del flujo normal de MFA/CA para recuperar el tenant si se pierde acceso de admins.
• Mínimo 2 cuentas, contraseña larga aleatoria, guardada offline
• Excluir explícitamente de todas las CA policies
• Usar dominio *.onmicrosoft.com (no depende de dominio custom ni ADFS)
• Monitorear accesos — una alerta debe dispararse si se usan
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
¿Qué método de MFA en Microsoft Entra ID es el más seguro y resistente a ataques de phishing y SIM swapping?