Uno de los problemas que más confusión puede generar al implementar políticas de Acceso Condicional es encontrarnos con un equipo que aparentemente está perfectamente configurado:

• Está unido a Microsoft Entra ID.
• Está administrado por Intune.
• Aparece como Compliant.
• El usuario tiene una sesión iniciada correctamente en Windows.

Sin embargo, cuando ese usuario intenta acceder a una aplicación desde Google Chrome, Microsoft Entra ID puede no reconocer correctamente el dispositivo y una política de Conditional Access termina bloqueando el acceso.

Lo curioso es que el mismo acceso puede funcionar correctamente desde Microsoft Edge.

¿Dónde está entonces el problema?

¿Qué está pasando?

Cuando una política de Conditional Access requiere información específica del dispositivo, Microsoft Entra necesita recibir esa información durante el proceso de autenticación.

En Windows, Microsoft Edge tiene integración nativa con Microsoft Entra y puede utilizar el contexto de autenticación de Windows para proporcionar la identidad del dispositivo. Microsoft documenta que Edge admite de forma nativa el acceso condicionado basado en dispositivo.

Con Google Chrome el escenario es diferente.

Actualmente Chrome 111 y posteriores son compatibles con Conditional Access basado en dispositivo en Windows, pero Microsoft indica que es necesario habilitar la política CloudAPAuthEnabled. Como alternativa, puede utilizarse la extensión Microsoft Single Sign-On.

Por tanto, no se trata simplemente de que «Chrome sea incompatible». El problema aparece cuando Chrome no está configurado para utilizar el mecanismo necesario para proporcionar la información del dispositivo durante la autenticación.

El papel del Primary Refresh Token (PRT)

Aquí entra en juego el Primary Refresh Token (PRT).

El PRT es un artefacto de autenticación utilizado por Microsoft Entra para proporcionar SSO en dispositivos compatibles y forma parte del mecanismo mediante el cual Microsoft puede establecer el contexto de identidad del usuario y del dispositivo.

En un equipo Windows correctamente configurado podemos comprobar su estado ejecutando:

dsregcmd /status

y revisando, entre otros valores:

AzureAdPrt : YES

Pero hay una distinción importante:

Tener un PRT válido no garantiza por sí solo que Chrome vaya a presentar correctamente la identidad del dispositivo a Conditional Access.

El navegador también debe utilizar el mecanismo compatible para que esa información pueda participar en la evaluación de la política.

¿Por qué funciona en Edge pero no en Chrome?

Esta es probablemente la pista más útil durante el troubleshooting.

Si: Edge → funciona

pero: Chrome → Conditional Access bloquea

no deberíamos asumir inmediatamente que existe un problema con Intune o con la política de cumplimiento.

Microsoft Edge dispone de integración nativa con Conditional Access. Mientras que en Chrome, Microsoft requiere una configuración adicional para los escenarios de Conditional Access basados en dispositivo.

En Windows existen actualmente dos mecanismos principales:

Opción 1: CloudAPAuthEnabled

Microsoft documenta la activación de la política: CloudAPAuthEnabled = 1 mediante: HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome con un valor DWORD: CloudAPAuthEnabled = 1

Esta configuración permite habilitar la integración necesaria de Chrome para Conditional Access basado en dispositivo.

Opción 2: Microsoft Single Sign-On (me gusta mucho)

También podemos desplegar por Intune la extensión Microsoft Single Sign-On para Chrome en todos los dispositivos.

Microsoft documenta ambas opciones como mecanismos compatibles para escenarios en los que Conditional Access necesita información específica del dispositivo en Windows.

En un entorno corporativo, la configuración debería desplegarse de forma centralizada mediante las políticas de Chrome, GPO, Intune u otro mecanismo de administración.

Un indicio muy útil en los Sign-in Logs

Cuando aparece este problema, una de las primeras comprobaciones que debemos hacer está en los Sign-in logs de Microsoft Entra.

Seleccionamos el inicio de sesión afectado y revisamos la información relacionada con el dispositivo.

Si Microsoft Entra no ha podido identificar correctamente el dispositivo, podemos encontrar información de dispositivo ausente o incompleta, como:

• Device ID
• Join Type

Esto es una pista muy importante. Si el equipo aparece correctamente en Intune y Microsoft Entra, pero el inicio de sesión realizado desde Chrome no proporciona la información de dispositivo esperada, debemos investigar la integración de Chrome antes de empezar a modificar las políticas de cumplimiento.

¿Por qué puede fallar una política que exige un dispositivo compliant?

Imaginemos una política de Conditional Access que contiene:

Grant → Require device to be marked as compliant

El dispositivo puede ser realmente compliant en Intune.

Pero Conditional Access necesita poder identificar qué dispositivo está realizando el acceso para evaluar esa condición.

Si durante la autenticación no recibe la información necesaria del dispositivo, la política no puede validar correctamente el requisito, por lo que se queda marcado como no complaince.

Esto puede producir una situación aparentemente contradictoria:

Intune dice que el dispositivo es compliant, pero Conditional Access bloquea el acceso.

Checklist de troubleshooting

Cuando nos encontremos con este escenario, seguiría este orden.

1. Comprobar el estado del dispositivo

Ejecutar:

dsregcmd /status

Y comprobar especialmente:

• AzureAdJoined
• AzureAdPrt
• WamDefaultSet

El objetivo es confirmar que Windows está correctamente registrado y que existe un contexto de autenticación válido.

2. Comprobar el estado en Intune

Verificar que:

• El dispositivo está inscrito.
• El dispositivo aparece como Compliant.
• El usuario tiene asignadas las políticas correspondientes.

3. Revisar Microsoft Entra Sign-in Logs

Abrir el inicio de sesión que ha fallado y comprobar:

• Device ID
• Join Type
• Plataforma
• Client App
• Resultado de Conditional Access

Si la información del dispositivo no aparece como esperamos, tenemos una pista clara de que debemos investigar el flujo de autenticación.

4. Comparar Edge y Chrome

Esta prueba es especialmente útil.

Realizar exactamente el mismo acceso desde:

Microsoft Edge y después desde Google Chrome.

Si Edge funciona y Chrome falla, revisar inmediatamente la configuración específica de Chrome.

5. Comprobar CloudAPAuthEnabled

En Chrome podemos revisar si está configurada la política:

CloudAPAuthEnabled

Microsoft documenta que Chrome 111+ necesita esta configuración para Conditional Access basado en dispositivo en Windows.

6. Revisar Microsoft Single Sign-On

Si se utiliza la extensión Microsoft Single Sign-On, comprobar que está correctamente instalada y desplegada.

Microsoft también proporciona instrucciones para desplegarla automáticamente mediante la política ExtensionInstallForcelist.

Buenas prácticas en entornos corporativos

Si Google Chrome es un navegador corporativo soportado en nuestro entorno, merece la pena incluir esta configuración dentro del proceso de administración del navegador.

Algunas recomendaciones:

• Mantener Chrome actualizado.
• Gestionar Chrome mediante políticas corporativas.
• Configurar CloudAPAuthEnabled cuando corresponda.
• Desplegar Microsoft Single Sign-On cuando sea necesario.
• Probar las políticas de Conditional Access con un grupo piloto.
• Revisar los Sign-in Logs cuando aparezcan bloqueos aparentemente inexplicables.
• Comparar el comportamiento entre Edge y Chrome.
• No asumir automáticamente que un fallo de Conditional Access implica un problema de Compliance en Intune.

Conclusión

El Acceso Condicional no depende únicamente de una correcta configuración de Microsoft Entra ID o Intune. El navegador utilizado también desempeña un papel fundamental.

En el caso de Google Chrome, una versión desactualizada o la ausencia de la integración adecuada con la autenticación de Windows pueden impedir que el navegador presente correctamente la identidad del dispositivo durante el inicio de sesión.

Como consecuencia, Microsoft Entra ID no recibe información como el Device ID o el Join Type, no puede comprobar si el dispositivo es Compliant y termina bloqueando el acceso aunque el equipo cumpla realmente todos los requisitos.

Antes de revisar toda la infraestructura de identidad o modificar las políticas de Acceso Condicional, merece la pena comprobar tres aspectos fundamentales:

• Que Google Chrome esté actualizado.
• Que el dispositivo disponga de un Primary Refresh Token (PRT) válido (AzureAdPrt : YES).
• Que la extensión Microsoft Single Sign On esté desplegada en los equipos corporativos.

En nuestra experiencia, estas tres comprobaciones resuelven la gran mayoría de incidencias relacionadas con Acceso Condicional y Google Chrome, evitando diagnósticos erróneos sobre Intune o sobre las propias políticas de seguridad.