Qué vas a conseguir
Un conjunto de políticas de Conditional Access que exige MFA, bloquea la autenticación heredada y protege a los administradores, desplegado sin sorpresas gracias al modo solo informe. Y la rutina para el ticket de "no puedo entrar" más frecuente a partir de ahora: el que causa una de tus políticas.
Antes de empezar
- Rol de Conditional Access Administrator (o Security Administrator), idealmente activado por PIM.
- Licencias Entra ID P1 en el tenant (las políticas basadas en riesgo necesitan P2).
- Dos cuentas de emergencia (break-glass) ya creadas, con contraseñas largas guardadas fuera de línea, y un grupo que las contenga.
- La lista de aplicaciones o servicios que usan autenticación heredada (POP/IMAP, SMTP básico): el informe
Sign-in logsfiltrado porClient appte la da.
1. Las cuentas de emergencia, primero
Toda política excluye al grupo de emergencia. Sin esa exclusión, un error en una política te deja fuera del tenant a ti también.
Las cuentas de emergencia no tienen MFA ni licencia, no se usan nunca salvo emergencia, y cada inicio de sesión con ellas dispara una alerta (Nivel 4: Sentinel).
2. Las cuatro políticas base
Las otras tres siguen el mismo patrón:
| Política | Usuarios | Condición | Control |
|---|---|---|---|
| CA002 - Block legacy authentication | Todos (excl. emergencia) | Aplicaciones cliente: Exchange ActiveSync, Otros clientes | Bloquear |
| CA003 - Require MFA for admins | Roles de directorio: Global Admin, Exchange Admin, SharePoint Admin, Security Admin, CA Admin, User Admin… (excl. emergencia) | — | Requerir MFA |
| CA004 - Require compliant device for Office 365 | Todos (excl. emergencia e invitados) | Plataformas: Windows, macOS, iOS, Android | Requerir dispositivo marcado como conforme o unido a Entra híbrido |
Todas en Solo informe al crearlas. Ninguna se activa el mismo día.
3. Una semana en solo informe
Esta lista es la que trabajas antes de activar nada: la impresora que envía por SMTP básico pasa a Microsoft 365 alta disponibilidad SMTP o a un conector; la cuenta IMAP pasa a Outlook moderno; el equipo de M. Ortega se arregla en Intune (guía de Intune). La pestaña Insights and reporting de Conditional Access hace la cuenta por política. Cuando una política lleva cero errores no esperados durante una semana, se pasa a Activado. Una política por semana, no las cuatro a la vez.
Consejo: What If (en la página de políticas) simula un inicio de sesión: usuario, aplicación, plataforma, ubicación. Es lo que usas para responder "¿qué pasará con el director cuando viaje?" antes de que viaje.
4. El ticket: "no puedo entrar"
El detalle del inicio de sesión tiene dos pestañas que resuelven el 90 %: Información básica (código de error) y Acceso condicional (qué política falló y qué control). Con el código vas a Intune: el dispositivo marca no conforme por BitLocker apagado (guía de BitLocker del Nivel 1). Lo que nunca haces es excluir al usuario de la política para "que entre ya": arreglas la causa y lo apuntas.
Los códigos que verás a menudo: 53000/53001 (dispositivo no conforme o no unido), 50074 (MFA obligatoria y el usuario no completó), 530032 (bloqueado por política de autenticación heredada), 50076 (MFA requerida por una política que acaba de activarse).
5. Lo que revisas cada mes
- Que las dos cuentas de emergencia siguen excluidas de todas las políticas (Conditional Access → Políticas → filtro por exclusión).
- Políticas que llevan más de un mes en solo informe: o se activan o se borran.
Insights and reporting: usuarios con más fallos por política. Un pico de CA002 es alguien configurando IMAP en un móvil nuevo.- Que no ha aparecido ninguna política nueva que tú no crearas: el registro de auditoría (
Audit logs, categoría Policy) lo dice, y el repo 27 lo cruza con los tickets de cambio.
Siguientes pasos
- Ubicaciones con nombre: la IP pública de la sede como ubicación de confianza, y una política que bloquee países desde los que la empresa no trabaja.
- Frecuencia de inicio de sesión y sesión persistente para los equipos no gestionados: menos tokens de larga duración fuera de tus dispositivos.
- Con P2, las políticas de riesgo de usuario e inicio de sesión de riesgo (Identity Protection) sustituyen reglas estáticas por señales.
- La guía de Entra ID SSO explica el otro lado: qué aplicaciones hay detrás de "todas las aplicaciones en la nube".
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
A set of Conditional Access policies that requires MFA, blocks legacy authentication and protects administrators, rolled out without surprises thanks to report-only mode. Plus the routine for the most frequent "I can't sign in" ticket from now on: the one caused by one of your policies.
Before you start
- The Conditional Access Administrator role (or Security Administrator), ideally activated through PIM.
- Entra ID P1 licences in the tenant (risk-based policies need P2).
- Two emergency accounts (break-glass) already created, with long passwords stored offline, and a group that contains them.
- The list of applications or services that use legacy authentication (POP/IMAP, basic SMTP): the
Sign-in logsreport filtered byClient appgives you that.
1. Emergency accounts first
Every policy excludes the emergency group. Without that exclusion, a mistake in a policy locks you out of the tenant too.
Emergency accounts have no MFA and no licence, are never used except in an emergency, and every sign-in with them raises an alert (Level 4: Sentinel).
2. The four baseline policies
The other three follow the same pattern:
| Policy | Users | Condition | Control |
|---|---|---|---|
| CA002 - Block legacy authentication | All (excl. emergency) | Client apps: Exchange ActiveSync, Other clients | Block |
| CA003 - Require MFA for admins | Directory roles: Global Admin, Exchange Admin, SharePoint Admin, Security Admin, CA Admin, User Admin… (excl. emergency) | — | Require MFA |
| CA004 - Require compliant device for Office 365 | All (excl. emergency and guests) | Platforms: Windows, macOS, iOS, Android | Require device marked compliant or Hybrid Entra joined |
All in Report-only when created. None is switched on the same day.
3. A week in report-only
This list is what you work through before enabling anything: the printer that sends over basic SMTP moves to Microsoft 365 high-volume SMTP or a connector; the IMAP account moves to modern Outlook; M. Ortega's laptop is fixed in Intune (Intune guide). The Insights and reporting tab in Conditional Access does the count per policy. When a policy shows zero unexpected failures for a week, it moves to On. One policy a week, not all four at once.
Tip: What If (on the policies page) simulates a sign-in: user, application, platform, location. It is what you use to answer "what will happen to the director when she travels?" before she travels.
4. The ticket: "I can't sign in"
The sign-in details have two tabs that solve 90%: Basic info (error code) and Conditional Access (which policy failed and which control). With the code you go to Intune: the device is non-compliant because BitLocker is off (Level 1 BitLocker guide). What you never do is exclude the user from the policy "so they can get in now": you fix the cause and write it down.
Codes you will see often: 53000/53001 (device not compliant or not joined), 50074 (MFA required and the user did not complete it), 530032 (blocked by the legacy authentication policy), 50076 (MFA required by a policy that was just enabled).
5. What you review each month
- That the two emergency accounts are still excluded from every policy (Conditional Access → Policies → filter by exclusion).
- Policies that have been in report-only for more than a month: either enable them or delete them.
Insights and reporting: users with the most failures per policy. A spike in CA002 is someone setting up IMAP on a new phone.- That no new policy has appeared that you didn't create: the audit log (
Audit logs, category Policy) says so, and repo 27 matches it against change tickets.
Next steps
- Named locations: the site's public IP as a trusted location, and a policy that blocks countries the company does not work from.
- Sign-in frequency and persistent browser session for unmanaged devices: fewer long-lived tokens outside your devices.
- With P2, user risk and sign-in risk policies (Identity Protection) replace static rules with signals.
- The Entra ID SSO guide explains the other side: which applications sit behind "all cloud apps".
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →