Configuración de la protección de identidad y MFA en Azure AD

Proteger las identidades en la nube ya no es algo opcional, es una pieza crítica de cualquier estrategia de seguridad moderna. Azure AD, ahora Microsoft Entra ID, se ha convertido en el centro neurálgico de la autenticación para Microsoft 365, aplicaciones SaaS y entornos híbridos (ver configurar Azure AD y SharePoint), así que cualquier fallo aquí puede abrir la puerta a tu organización entera. Por eso es tan importante entender bien cómo configurar tanto la protección de la identidad como la autenticación multifactor (MFA) de forma correcta y coherente.

Con una buena configuración, puedes combinar MFA, acceso condicional, protección de identidad y métodos de autenticación modernos (incluyendo tokens OATH y claves FIDO2; ver introducción a la criptografía) para lograr un equilibrio entre seguridad fuerte y experiencia de usuario razonable. A lo largo de este artículo vamos a desgranar, con bastante detalle, todas las opciones clave: notificación de actividad sospechosa, uso de tokens OATH, configuración de llamadas telefónicas, direcciones IP de confianza, métodos de verificación, políticas de acceso condicional, escenarios híbridos con Active Directory y posibilidades de autenticación adaptativa basada en riesgo.

La autenticación multifactor es el proceso por el que, durante un inicio de sesión, se solicita al usuario uno o más factores adicionales de verificación además de su contraseña. Puede ser un código enviado al móvil, una notificación push en Microsoft Authenticator, un token de hardware OATH, una clave FIDO2 o incluso un dato biométrico como la huella dactilar (a través de Windows Hello para empresas).

El objetivo es que, aunque un atacante robe o adivine la contraseña, se quede atascado porque no dispone del segundo factor. Teniendo en cuenta el volumen de credenciales filtradas y compradas en la red, y la eficacia del phishing, la MFA se ha convertido en una de las defensas más eficaces para frenar ataques basados en identidad, tanto en Azure AD como en Active Directory local.

En paralelo, Microsoft Entra ID Protection añade una capa de detección y evaluación de riesgo sobre los inicios de sesión y las identidades. A partir de señales como ubicaciones inusuales, dispositivos desconocidos, patrones de ataque conocidos o incluso reportes del propio usuario, el sistema puede marcar cuentas como de alto riesgo y permitir que se apliquen políticas de corrección (bloqueo de acceso o restablecimiento de contraseña).

En la práctica, combinar MFA con protección de identidad y acceso condicional permite exigir factores adicionales solo cuando el contexto lo justifica (por ejemplo, cuando hay riesgo alto), reduciendo fricción sin relajar la seguridad. Este enfoque adaptativo es el que cada vez más organizaciones buscan para sus entornos híbridos y de trabajo remoto.

Notificación de actividad sospechosa y usuarios de alto riesgo

Una de las piezas más interesantes de la protección de identidad en Azure AD es la posibilidad de que los usuarios marquen directamente como sospechosas las solicitudes de MFA que no reconocen. Esto se puede hacer desde la app Microsoft Authenticator (rechazando e informando) o mediante las opciones de las llamadas telefónicas.

Cuando el usuario informa una solicitud de MFA como fraudulenta, Entra ID Protection lo registra como actividad sospechosa notificada por el usuario y eleva el estado de la cuenta a Usuario con alto riesgo. A partir de ahí, entran en juego las políticas basadas en riesgo que hayas configurado, o bien procesos manuales de respuesta.

Este evento se refleja en varios registros y paneles: en el informe de detecciones de riesgo (tipo de detección “actividad sospechosa notificada por el usuario”, nivel de riesgo alto, origen usuario final), en los registros de inicio de sesión (resultado de autenticación como MFA denegado por el usuario) y en los registros de auditoría como actividad específica. Todo esto es clave si quieres investigar incidentes de identidad o automatizar respuestas, y para ello la capacitacion en ciberseguridad del personal es muy relevante.

Para habilitar esta función, desde el centro de administración de Microsoft Entra debes ir a Entra ID > Métodos de autenticación > Configuración y establecer la opción Notificar actividad sospechosa como habilitada. Si la dejas en “Administrado por Microsoft”, la característica sigue inactiva, así que conviene revisarlo si quieres que tus usuarios colaboren activamente en la detección de ataques.

Además puedes definir un código de informe que los usuarios teclearán durante las llamadas de voz para marcar el intento como sospechoso, siempre que también hayas subido saludos de voz personalizados para el inquilino. Si no configuras nada, el código por defecto es 0, independientemente de lo que definas en la directiva.

Gestión del riesgo con licencias Microsoft Entra ID P1

Con una licencia P1, las capacidades de protección de identidad son algo más limitadas, pero sigues pudiendo visualizar e investigar las detecciones de riesgo relacionadas con usuarios que han marcado MFA como sospechoso. Estas detecciones aparecen en el informe de riesgos, los logs de inicio de sesión y los registros de auditoría, lo que ya te da un punto de partida decente para análisis forense.

La mitigación en este escenario suele ser manual o semiautomática: el equipo de TI o el servicio de soporte puede exigir a los usuarios que realicen un restablecimiento de contraseña mediante SSPR (Self-Service Password Reset) o cambiar la contraseña en su nombre. También se pueden automatizar flujos con Microsoft Graph o PowerShell para forzar cambios de contraseña, revocar sesiones activas o incluso deshabilitar temporalmente la cuenta mientras se investiga.

En entornos sin P2, también puedes explotar los eventos de riesgo a través de las API de Graph para construir workflows propios de respuesta, integrarlos con sistemas de ticketing o soluciones SIEM/SOAR y así conseguir una orquestación de incidentes de identidad más profesional.

Corrección automática de riesgo con Microsoft Entra ID P2

Con licencias P2 entra en juego la pieza más potente: las políticas de acceso condicional basadas en riesgo. Estas políticas permiten que, cuando un usuario se marca como de riesgo alto (por ejemplo, tras informar actividad sospechosa), el sistema aplique automáticamente acciones como bloquear el inicio de sesión o exigir un restablecimiento de contraseña.

En la configuración de acceso condicional puedes ir a Condiciones > Riesgo del usuario y establecer reglas que reaccionen a valores como riesgo alto o medio. Un caso clásico es configurar que los usuarios con riesgo alto deban cambiar su contraseña antes de poder continuar, o quedarán directamente bloqueados hasta que un administrador revise el caso.

Este modelo de autenticación adaptativa enlaza muy bien con MFA: en vez de pedir siempre un segundo factor de forma estática, puedes elevar los requisitos de autenticación según el riesgo en tiempo real (ubicación inusual, IP sospechosa, comportamiento anómalo, etc.). De este modo, el usuario no se ve sobrecargado con peticiones de MFA cuando todo está “dentro de lo normal”, pero la barrera sube en cuanto algo huele a ataque.

Tokens OATH y códigos TOTP en Azure AD

Además de la clásica app Microsoft Authenticator, Entra ID soporta tokens de hardware OATH TOTP que generan códigos de un solo uso (OTP) basados en tiempo, típicamente cada 30 o 60 segundos, usando SHA-1. Esta opción encaja muy bien en organizaciones que prefieren dispositivos físicos dedicados a MFA por políticas internas, sectores regulados o usuarios sin smartphone corporativo.

Estos tokens suelen venir con una clave secreta (seed) programada de fábrica. Para poder utilizarlos con Azure AD, esa clave se debe introducir en el inquilino mediante un archivo CSV. Aquí hay algunas restricciones importantes: la clave secreta está limitada a 128 caracteres codificados en Base32, solo puede contener letras a-z / A-Z y dígitos del 1 al 7, y debe respetar el formato esperado para que el sistema la acepte.

También es posible usar tokens de hardware OATH TOTP programables que se puedan reconfigurar, tratándolos de manera similar a como se haría con tokens de software. En cualquier caso, el soporte para tokens OATH de hardware forma parte de una versión preliminar pública, con las implicaciones que eso tiene: cambios potenciales, limitaciones y condiciones adicionales de uso en los términos de Azure Previews.

El proceso de carga de tokens se realiza mediante un CSV con columnas como UPN, número de serie, clave secreta, intervalo de tiempo, fabricante y modelo. Tras subirlo desde Entra ID > Autenticación multifactor > OATH tokens, el servicio procesa el archivo y te permite ver errores de formato en un CSV descargable.

Una vez corregidos los errores, cada token debe activarse manualmente: el administrador selecciona “Activar” y teclea el OTP que muestra el dispositivo, lo que vincula definitivamente el token con el usuario. Cada persona puede combinar hasta cinco factores basados en tokens o apps autenticadoras al mismo tiempo, lo que da bastante flexibilidad para redundancia o transición entre métodos.

Configuración de las llamadas telefónicas y mensajes de voz

Otra vía muy utilizada para MFA en Azure AD es la verificación telefónica mediante llamada de voz. Los usuarios reciben una llamada automatizada y, para completar la autenticación, pulsan la tecla # o introducen un PIN, según la configuración. Esta experiencia se puede personalizar bastante, sobre todo en entornos donde las llamadas de voz siguen siendo el método preferido o necesario.

Por defecto, Microsoft utiliza números de teléfono específicos por país o región para originar las llamadas. En Estados Unidos, por ejemplo, hay varios números predefinidos, y en otros países se ofrece una lista concreta. Es importante compartir estos números con los usuarios o pedirles que los añadan a listas de permitidos si usan filtros de llamadas no deseadas, para evitar problemas de entrega de la llamada.

Si lo prefieres, también puedes definir tu propio número de identificador de llamada (caller ID) para las llamadas de MFA, aunque con la restricción de que debe ser un número de Estados Unidos. Esta opción se configura desde Entra ID > Autenticación multifactor > Configuración de llamadas telefónicas, donde simplemente estableces el número deseado y guardas los cambios.

Otra personalización interesante es el uso de mensajes de voz personalizados. En lugar de las locuciones estándar de Microsoft, puedes subir tus propios audios en formato .wav o .mp3, con un tamaño máximo de 1 MB y una duración inferior a 20 segundos. Si el mensaje es demasiado largo, la verificación puede fallar porque el usuario no llega a responder antes de que acabe la locución.

El idioma que escuchará el usuario depende tanto del idioma detectado en su navegador o contexto, como de los idiomas disponibles en los mensajes personalizados que haya subido el administrador. Si solo existe, por ejemplo, un saludo en alemán, se reproducirá ese mensaje tanto a usuarios cuyo idioma sea alemán como a otros, salvo que existan alternativas más adecuadas en otros idiomas.

Microsoft proporciona guiones por defecto para diferentes tipos de mensajes (autenticación correcta, saludos estándar, mensajes de fraude, reintentos, activación, etc.), que puedes utilizar como base para grabar tus propios audios. Para configurarlos, se accede de nuevo a la sección de configuración de llamadas telefónicas, se elige “Agregar saludo”, se selecciona el tipo de mensaje, el idioma y se sube el archivo de sonido.

Configuración avanzada del servicio MFA y direcciones IP de confianza

Además de los métodos de verificación, el portal heredado de configuración del servicio MFA ofrece opciones como IPs de confianza, contraseñas de aplicación y la función de “Recordar autenticación multifactor”. Aunque Microsoft impulsa cada vez más el uso de acceso condicional y la directiva unificada de métodos de autenticación, este portal sigue siendo relevante en muchos entornos.

Las direcciones IP de confianza permiten que los usuarios que se conectan desde la intranet corporativa (segmentos de IP concretos) no tengan que pasar por MFA en determinados flujos de navegador. Esta característica está disponible con Microsoft Entra ID P1 y resulta útil para reducir fricción cuando estás dentro de la red, manteniendo MFA para accesos externos.

En inquilinos administrados puedes definir hasta 50 rangos de IP en notación CIDR que se consideran de confianza. En inquilinos federados, además, se puede activar la opción “Todos los usuarios federados” para que los usuarios autenticados a través de AD FS desde la intranet omitan MFA, siempre y cuando AD FS emita la notificación adecuada (insidecorporatenetwork), configurada mediante una regla de emisión de claims.

Hay que tener en cuenta que, si utilizas la extensión NPS para proporcionar MFA a aplicaciones locales, la IP que ve Azure AD será siempre la del servidor NPS, por lo que el uso de rangos de IP de confianza puede no comportarse como esperas. También es importante recordar que fuera de la red corporativa, MFA seguirá siendo necesaria, tanto si hay IPs de confianza definidas como si no.

La forma recomendada hoy en día de gestionar ubicaciones confiables es a través de acceso condicional con ubicaciones con nombre. Desde Entra ID > Acceso condicional > Ubicaciones con nombre, puedes crear una nueva ubicación, marcarla como de confianza y definir los rangos de IP (por ejemplo 40.77.182.32/27). Después, estas ubicaciones se utilizan en las políticas de acceso condicional para decidir cuándo se requiere MFA.

Habilitar IPs de confianza mediante acceso condicional o servicio heredado

Si quieres alinear la configuración antigua de IPs de confianza con acceso condicional, existe una opción específica “Configurar direcciones IP de confianza de autenticación multifactor” en la sección de ubicaciones con nombre. Ahí puedes especificar tanto el uso de la notificación de intranet de AD FS para usuarios federados como los rangos de IP públicos concretos a considerar de confianza.

Si prefieres seguir usando la configuración del servicio heredado, también encontrarás en esa página las opciones “Para solicitudes de usuarios federados en mi intranet” y “Para solicitudes de un intervalo específico de subredes de direcciones IP”, con la misma lógica de notación CIDR y límite de rangos. Esta configuración se sigue respetando mientras no hayas completado la migración a la directiva moderna de métodos de autenticación.

Métodos de verificación disponibles y su gestión

Azure AD ofrece un abanico bastante amplio de métodos de autenticación que pueden emplearse tanto para MFA como para SSPR, según cómo los configures. Entre los métodos admitidos para verificación multifactor encontramos: Microsoft Authenticator, Authenticator Lite (en Outlook), Windows Hello para empresas, claves de seguridad FIDO2, tokens de hardware OATH, tokens de software OATH, SMS y llamadas de voz.

Adicionalmente existen métodos como la verificación por correo electrónico o las preguntas de seguridad, que no se consideran MFA pero sí pueden usarse como factores de comprobación para SSPR. También dispones de las denominadas App Passwords, pensadas para aplicaciones antiguas que no soportan autenticación moderna y que se usan de forma específica en escenarios de MFA por usuario.

La forma recomendada por Microsoft para gestionar todos estos métodos es la Authentication Methods Policy, accesible en Entra ID > Seguridad > Métodos de autenticación > Directivas. Esta consola unificada permite habilitar o deshabilitar métodos para distintos grupos de usuarios, definir parámetros adicionales (por ejemplo, configuración de passwordless con Microsoft Authenticator mostrando ubicación y nombre de app) y controlar tanto MFA como SSPR desde un único sitio.

En paralelo siguen existiendo las políticas heredadas: los ajustes de MFA en el centro de administración de 365 (que afectan a MFA per-user y a MFA con acceso condicional) y la configuración de métodos de autenticación de SSPR (Users > Password reset > Authentication methods). Estas políticas no se sincronizan automáticamente con la nueva directiva unificada, así que, durante el periodo de coexistencia, debes tener cuidado de configurarlas coherentemente en todas partes.

El orden de procesado cuando coexisten políticas es: primero la Authentication Methods Policy, luego los ajustes de MFA heredados y, por último, los de SSPR. Azure AD respeta las configuraciones de todas ellas, de forma que si un método está permitido en cualquiera de las políticas, el usuario podrá registrarlo y usarlo. Para bloquear un método completamente, tendrás que restringirlo en todas las políticas relevantes.

En la propia consola de métodos de autenticación encontrarás además una sección de migración que indica en qué fase estás: Pre-Migration, Migration In Progress o Migration Completed. Mientras estés en los dos primeros estados, se siguen teniendo en cuenta las políticas heredadas. Cuando marques Migration Completed, solo se respetará la directiva moderna de métodos de autenticación y se ignorarán las antiguas.

Recordar autenticación multifactor y dispositivos de confianza

La característica “Recordar la autenticación multifactor” trata de reducir la fricción para el usuario permitiendo que, una vez complete correctamente MFA en un dispositivo y navegador, pueda omitir verificaciones adicionales durante un número de días configurado. Funciona mediante una cookie persistente que se guarda en el navegador cuando el usuario marca la opción “No preguntar de nuevo durante X días”.

Mientras la cookie siga siendo válida (no se haya borrado ni haya caducado), y el usuario utilice el mismo navegador, no se le volverá a solicitar MFA en ese contexto concreto. Si cambia de navegador en el mismo dispositivo o limpia las cookies, la verificación volverá a pedirse. Esta opción solo está disponible en flujos basados en navegador, no en aplicaciones sin navegador, aunque en estas Azure AD comprueba igualmente la antigüedad de la última autenticación multifactor al validar tokens de actualización.

Esta funcionalidad puede reducir muchísimo el número de prompts de MFA en aplicaciones web, pero hay que calibrar bien el valor de días: si lo estableces por debajo de los 90 días típicos de la caducidad de tokens en clientes modernos, puede incluso aumentar la frecuencia de MFA en ciertas apps. Además, si combinas esta característica con acceso condicional, la interacción entre ambas puede hacer que haya más o menos solicitudes de MFA según las reglas configuradas.

Para habilitarla, desde el portal heredado de configuración del servicio MFA debes ir a Configuración del servicio > Recordar la autenticación multifactor, marcar “Permitir que los usuarios recuerden la autenticación multifactor en dispositivos de confianza” y definir el número de días (recomendable 90 o menos para buena experiencia de usuario). A partir de ese momento, los usuarios verán la casilla de “No volver a preguntar” cuando pasen por MFA.

Habilitar MFA con directivas de acceso condicional

Aunque Azure AD permite habilitar MFA por usuario de forma directa, Microsoft recomienda utilizar políticas de acceso condicional para controlar cuándo y a quién se le exige autenticación multifactor. Esto te da un nivel de granularidad mucho mayor y encaja mejor con escenarios reales: ciertas apps críticas, accesos desde redes no confiables, roles privilegiados, etc.

Para usar acceso condicional con MFA necesitas un inquilino Entra en funcionamiento con licencias P1 o de prueba, y una cuenta con al menos el rol de Administrador de acceso condicional (algunas opciones de MFA también se pueden gestionar con el rol de Administrador de directivas de autenticación). Además es recomendable contar con un usuario de prueba no administrador y un grupo de prueba (por ejemplo “MFA-Test-Group”) para validar la experiencia sin afectar a toda la organización.

El patrón habitual consiste en crear una política que aplique a un conjunto concreto de usuarios o grupos, y que se active para ciertas aplicaciones en la nube o acciones específicas. Luego, en los controles de acceso, se selecciona “Conceder acceso” y se marca “Requerir autenticación multifactor” como condición necesaria. La política se puede dejar en modo solo informe para observar su impacto antes de activarla.

Un ejemplo clásico de prueba es aplicar la política al grupo de test y a un recurso como la “API de Administración de servicios de Windows Azure” o al propio centro de administración de Microsoft Entra. Así podrás ver cómo, al acceder a esos recursos, se solicita MFA o se pide al usuario registrarse en MFA si todavía no lo ha hecho.

La experiencia de usuario final suele consistir en: primer inicio de sesión sin MFA en un recurso no protegido, cierre de sesión, y luego acceso al recurso protegido, donde se le guía por el proceso de registro de MFA (teléfono de autenticación, teléfono del trabajo con extensión o app móvil). Después de completar el registro, los siguientes inicios de sesión al recurso protegido desencadenan la verificación según el método configurado (notificación push, SMS, llamada, código de app, etc.).

Escenarios híbridos con Active Directory y MFA

En muchos entornos, Active Directory local sigue siendo el núcleo de la infraestructura de identidades, mientras que Azure AD proporciona el front-end de autenticación para Microsoft 365 y aplicaciones en la nube. En estos casos, desplegar MFA de forma coherente tanto on-premises como en la nube es uno de los principales retos.

Active Directory en sí solo ofrece soporte nativo de MFA mediante autenticación con tarjeta inteligente, que no hay que confundir con MFA para AD FS. Para reforzar inicios de sesión interactivos o RDP en servidores y PCs, muchas organizaciones integran soluciones como Windows Hello for Business o proveedores de MFA de terceros (por ejemplo, Duo) directamente en los endpoints o en servidores de salto; la resiliencia de identidad y la alta disponibilidad son consideraciones importantes en estos diseños.

Cuando además se usan proveedores de servicios de identidad en la nube, como Entra ID, es habitual apoyarse en herramientas como Microsoft Entra Connect (antes Azure AD Connect) para sincronizar identidades entre AD local y el inquilino en la nube. A partir de ahí, MFA, acceso condicional y protección de identidad se aplican en la capa de Entra ID para todas las aplicaciones que se autentican directamente contra él.

Los tenants de Entra que no disponen de licencias premium pueden usar Security Defaults para activar un conjunto básico de configuraciones de seguridad, incluyendo MFA obligatoria y bloqueo de autenticación heredada. Sin embargo, sin P1 o P2 no se dispone de acceso condicional, por lo que la capacidad de definir reglas específicas (por aplicación, ubicación, riesgo, etc.) se ve muy limitada.

Por el contrario, con planes como Microsoft 365 Business, E3, E5 o licencias Entra ID P1/P2, se desbloquean las políticas de acceso condicional y se pueden combinar con MFA per-user cuando convenga. Tanto Microsoft 365 como Office 365 soportan MFA mediante SMS, llamada de voz y Microsoft Authenticator, mientras que Entra ID añade más opciones como FIDO2, Windows Hello, tokens OATH y demás.

Las aplicaciones que usan autenticación moderna (por ejemplo OpenID Connect, OAuth2) y se integran directamente con Entra ID pueden aprovechar todas estas características de acceso condicional sin problemas. Para aplicaciones legadas o locales que no hablan directamente con Entra, se pueden utilizar Azure AD Application Proxy o la integración con NPS (Network Policy Server) para interponer MFA en el flujo de autenticación.

Autenticación adaptativa y protección de identidad

La tendencia actual en seguridad de identidades va más allá de aplicar MFA de forma uniforme. La idea es aumentar o reducir los requisitos de autenticación según el contexto, el riesgo y el comportamiento histórico del usuario. Aquí es donde entra la autenticación adaptativa.

Entra ID Protection analiza continuamente el riesgo asociado tanto al usuario como al inicio de sesión: ubicaciones poco habituales, dispositivos desconocidos, patrones asociados a bots o ataques de fuerza bruta, credenciales presentes en listas robadas, etc. Cuando el riesgo es elevado, puede desencadenar acciones correctivas como exigir al usuario que restablezca su contraseña o bloquear directamente el acceso hasta que un administrador intervenga.

Combinando estas capacidades con acceso condicional, puedes diseñar políticas del tipo: “si el riesgo de usuario es alto, bloquear acceso” o “si el riesgo de inicio de sesión es medio-alto, requerir MFA”. De este modo, solo en situaciones sospechosas se elevan las exigencias de verificación, mientras que en circunstancias normales el usuario no ve cambios respecto a su flujo habitual.

Esta capa adicional se suma al resto de defensas (parcheado, segmentación de red, protección de endpoints, monitorización de logs, etc.) para reforzar la resiliencia global frente a ataques. Es importante recordar que MFA por sí sola no basta, pero sí es uno de los componentes más efectivos dentro de una estrategia de defensa en profundidad centrada en identidades.

Al final, una configuración cuidadosa de métodos de autenticación, MFA, acceso condicional, IPs de confianza, SSPR y protección de identidad, tanto en la nube como en entornos híbridos con Active Directory, te permite levantar una barrera muy sólida frente a robos de credenciales, ataques de phishing y movimientos laterales, manteniendo a la vez una experiencia de usuario asumible para el día a día.