Acceso condicional de Microsoft Entra: Protección de tokens (versión preliminar)

La protección de tokens (a veces denominada vinculación de tokens en el sector) intenta reducir los ataques de robo de tokens asegurando que un token solo sea utilizable desde el dispositivo previsto. Cuando un atacante puede robar un token, mediante secuestro o reproducción, puede hacerse pasar por su víctima hasta que el token expire o sea revocado. Se cree que el robo de tokens es un suceso relativamente raro, pero los daños que ocasiona pueden ser importantes.

La protección de tokens crea un vínculo criptográficomente seguro entre el token y el dispositivo (secreto de cliente) al que se emite. Sin el secreto de cliente, el token enlazado es inútil. Cuando un usuario registra un dispositivo Windows 10 o posterior en el id. de Microsoft Entra, su identidad principal está enlazada al dispositivo. Lo que significa: una directiva puede asegurarse de que las aplicaciones usan solo los tokens de sesión de inicio de sesión enlazados (o actualización), lo que se conoce como Tokens de actualización principal (PRT) al solicitar acceso a un recurso.

Requisitos

El uso de esta característica requiere licencias de Microsoft Entra ID P2. Para encontrar la licencia adecuada para sus requisitos, consulte planes y precios de Microsoft Entra.

Los siguientes dispositivos y aplicaciones admiten el acceso a recursos en los que se aplica una directiva de acceso condicional de protección de tokens:

Dispositivos compatibles:

• Dispositivos Windows 10 o más recientes que están integrados en Microsoft Entra, híbridos integrados en Microsoft Entra o registrados en Microsoft Entra. Consulte la sección de limitaciones conocidas para los tipos de dispositivos no admitidos.
• Windows Server 2019 o versiones posteriores que están unidos a Microsoft Entra híbrido.

Aplicaciones admitidas:

• Cliente de sincronización de OneDrive versión 22.217 o posterior
• Cliente nativo de Teams versión 1.6.00.1331 o posterior
• Power BI Desktop, versión 2.117.841.0 (mayo de 2023) o posterior
• Módulo de Exchange PowerShell versión 3.7.0 o posterior
• Microsoft Graph PowerShell versión 2.0.0 o posterior con la opción EnableLoginByWAM
• Visual Studio 2022 o posterior al usar la opción de inicio de sesión "Agente de autenticación de Windows"
• Aplicación de Windows versión 2.0.379.0 o posterior

Limitaciones conocidas

• No se admiten clientes perpetuos de Office.
• Las siguientes aplicaciones no admiten el inicio de sesión con flujos de token protegidos y los usuarios se bloquean al acceder a Exchange y SharePoint:
  • Módulos de PowerShell que acceden a SharePoint
  • Extensión de PowerQuery para Excel
  • Extensiones para Visual Studio Code que acceden a Exchange o SharePoint
• Los siguientes dispositivos cliente Windows no son compatibles:
  • Surface Hub (pantalla interactiva)
  • Sistemas de Salas de Microsoft Teams basados en Windows (MTR)
• Los usuarios externos que cumplen los requisitos de registro de dispositivos de protección de tokens en su inquilino de origen son admitidos. Sin embargo, los usuarios que no cumplen estos requisitos ven un mensaje de error poco claro sin indicar la causa principal.
• Los dispositivos registrados con el identificador de Microsoft Entra mediante los métodos siguientes no son compatibles:
  • Hosts de sesión de Azure Virtual Desktop unidos a Microsoft Entra.
  • Dispositivos Windows implementados mediante la inscripción masiva.
  • PC en la nube implementados por Windows 365 unidos a Microsoft Entra.
  • Grupos de máquinas hospedados en Power Automate que están unidos a Microsoft Entra.
  • Dispositivos Windows Autopilot implementados mediante el modo de implementación automática.
  • Máquinas virtuales Windows implementadas en Azure mediante la extensión de máquina virtual (VM) habilitada para la autenticación de Id. de Microsoft Entra.
• Es posible que los nuevos dispositivos registrados de Microsoft Entra en versiones de Windows anteriores a 24H2 se bloqueen si los usuarios no realizan un inicio de sesión nuevo durante el registro. Si está bloqueado, los usuarios deben volver a registrar el dispositivo.

Para identificar los dispositivos afectados debido a tipos de registro no admitidos enumerados anteriormente, inspeccione el atributo tokenProtectionStatusDetails en los registros de inicio de sesión. Las solicitudes de token bloqueadas debido a un tipo de registro de dispositivo no admitido se pueden identificar con un signInSessionStatusCode valor de 1003.

Para evitar cualquier interrupción de la incorporación nueva, puede modificar la directiva de acceso condicional de protección de tokens agregando una condición de filtro de dispositivo que excluya los dispositivos que se encuentran en la categoría de implementación descrita anteriormente. Por ejemplo, para excluir:

• PCs en la nube que están unidos a Microsoft Entra, pueden usar systemLabels -eq "CloudPC" and trustType -eq "AzureAD".
• Azure Virtual Desktops unidos a Microsoft Entra, puede usar systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD".
• Grupos de equipos hospedados de Power Automate unidos a Microsoft Entra, puede usar systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD".
• Para los dispositivos Windows Autopilot implementados mediante el modo de autodespliegue, puede utilizar la propiedad enrollmentProfileName. Por ejemplo, si ha creado un perfil de inscripción en Intune para los dispositivos del modo de autodespliegue de Autopilot como "Perfil de autodespliegue de Autopilot", puede usar `enrollmentProfileName -eq "Perfil de autodespliegue de Autopilot".
• Máquinas virtuales Windows en Azure unidas a Microsoft Entra, puede usar profileType -eq "SecureVM" and trustType -eq "AzureAD".

Implementación

Para los usuarios, la implementación de una directiva de acceso condicional para aplicar la protección de tokens debe ser invisible al usar plataformas cliente compatibles en dispositivos registrados y aplicaciones compatibles.

Para minimizar la probabilidad de interrupción del usuario debido a la incompatibilidad de aplicaciones o dispositivos, se recomienda encarecidamente:

• Comience con un grupo piloto de usuarios y expándalo con el tiempo.
• Cree una directiva de acceso condicional en modo de solo informe antes de pasar a la aplicación de la protección de tokens.
• Capture los registros de inicio de sesión interactivos y no interactivos.
• Analice estos registros durante el tiempo suficiente para cubrir el uso normal de la aplicación.
• Agregue usuarios correctos conocidos a una directiva de cumplimiento.

Este proceso ayuda a evaluar la compatibilidad de la aplicación y del cliente de sus usuarios para la implementación de la protección de tokens.

Creación de una directiva de acceso condicional

Los usuarios que realizan roles especializados como los descritos en Niveles de seguridad de acceso con privilegios son posibles destinos para esta funcionalidad. Se recomienda realizar una prueba piloto con un pequeño subconjunto para comenzar.

Los siguientes pasos ayudan a crear una directiva de acceso condicional para requerir protección de token para Exchange Online y SharePoint Online en dispositivos Windows.

1. Inicie sesión en el Centro de administración de Microsoft Entra como al menos un administrador de acceso condicional.
2. Vaya a las directivas de>acceso condiciona del>Entra ID.
3. Seleccione Nueva directiva.
4. Asigne un nombre a la directiva. Se recomienda que las organizaciones creen un estándar significativo para los nombres de sus políticas.
5. En Asignaciones, seleccione Usuarios o identidades de carga de trabajo.
   1. En Incluir, seleccione los usuarios o grupos que están probando esta directiva.
   2. En Excluir, seleccione Usuarios y grupos y, después, elija las cuentas de acceso de emergencia de la organización.
6. Recursos de destino>Recursos (anteriormente aplicaciones en la nube)>Incluir>Seleccionar recursos

   1. En Seleccionar, seleccione las siguientes aplicaciones compatibles con la versión preliminar:

      1. Office 365 Exchange Online
      2. Office 365 SharePoint Online
      3. Si ha implementado la aplicación de Windows en su entorno, incluya:
         1. Azure Virtual Desktop
         2. Windows 365
         3. Inicio de sesión en la nube de Windows

      Advertencia

      La directiva de acceso condicional solo debe configurarse para estas aplicaciones. Si selecciona el grupo de aplicaciones de Office 365 , podría producirse errores no deseados. Este cambio es una excepción a la regla general que el grupo de aplicaciones de Office 365 debe seleccionarse en una directiva de acceso condicional.

   2. Elija Seleccionar.

7. En Condiciones:
   1. En Plataformas de dispositivos:
      1. Establezca Configurar en Sí.
      2. Incluir>Selección de plataformas de dispositivos>Windows.
      3. Seleccione Listo.
   2. En Aplicaciones cliente:

      1. Establezca Configurar en Sí.

         Advertencia

         Si no se configura la condición Aplicaciones cliente , o si se deja el explorador seleccionado, las aplicaciones que usan MSAL.js, como Teams Web, se bloquearán.

      2. En Clientes de autenticación moderna, seleccione Solo aplicaciones móviles y clientes de escritorio. Deje los demás elementos sin marcar.

      3. Seleccione Listo.

8. En Controles de acceso>Sesión, seleccione Requerir protección de tokens para las sesiones de inicio de sesión y seleccione Seleccionar.
9. Confirme la configuración y establezca Habilitar directiva en Solo informe.
10. Seleccione Crear para crear la directiva.

Después de que los administradores evalúen la configuración de directiva mediante el Impacto de la directiva o el modo de solo informe, pueden mover el botón de alternancia Habilitar directiva de Solo informe a Activado.

Captura de registros y análisis

Supervise la aplicación del acceso condicional de la protección de tokens antes y después de la aplicación mediante características como impacto en la directiva (versión preliminar), Registros de inicio de sesión o Log Analytics.

Registros de inicio de sesión

Use el registro de inicio de sesión de Microsoft Entra para verificar el resultado de una directiva de aplicación de protección de token en modo de solo informe o en modo activado.

1. Inicie sesión en el Centro de administración de Microsoft Entra como al menos un administrador de acceso condicional.
2. Vaya a Entra ID>, luego a Supervisión y salud>, y por último a Registros de inicio de sesión.
3. Seleccione una solicitud específica para determinar si la directiva se aplica o no.
4. Vaya al panel Acceso condicional o Solo de informes según su estado y seleccione el nombre de la directiva que requiere protección de token.
5. En Controles de sesión , compruebe si se cumplen o no los requisitos de la directiva.
6. Para obtener más detalles sobre el estado de enlace de la solicitud, seleccione el panel Información básica y vea el campo Protección de tokens: sesión de inicio de sesión. Los valores posibles son:
   1. Enlazado: la solicitud usaba protocolos enlazados. Algunos inicios de sesión pueden incluir varias solicitudes y todas las solicitudes deben enlazarse para satisfacer la directiva de protección de tokens. Incluso si una solicitud individual parece estar enlazada, no garantiza el cumplimiento de la directiva si otras solicitudes no están enlazadas. Para ver todas las solicitudes de un inicio de sesión, puede filtrar todas las solicitudes de un usuario específico o buscar por corelationid.
   2. Unbound: la solicitud no usaba protocolos enlazados. Los posibles statusCodes cuando la solicitud no está delimitada son:
      1. 1002: La solicitud no está vinculada debido a la falta de estado del dispositivo de Microsoft Entra ID.
      2. 1003: La solicitud no está vinculada porque el estado del dispositivo de Microsoft Entra ID no cumple con los requisitos de la directiva de acceso condicional para la protección de tokens. Este error podría deberse a un tipo de registro de dispositivo no compatible o al dispositivo no se registró con credenciales de inicio de sesión nuevas.
      3. 1005: La solicitud no está vinculada por otras razones no especificadas.
      4. 1006: La solicitud no está vinculada porque no se admite la versión del sistema operativo.
      5. 1008: la solicitud no está vinculada porque el cliente no está integrado con el agente de plataforma, como el Administrador de cuentas de Windows (WAM).

Analítica de registros

También puede usar Log Analytics para consultar los registros de inicio de sesión (interactivos y no interactivos) para las solicitudes bloqueadas debido a un error de cumplimiento de la protección de tokens.

Esta es una consulta de Log Analytics de ejemplo en la que se buscan los registros de inicio de sesión no interactivos durante los últimos siete días, donde se resaltan las solicitudes Bloqueadas frente a Permitidas por la Aplicación. Estas consultas son solo muestras y están sujetas a cambios.

//Per Apps query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]' 
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"] 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result 
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by Requests desc 

El resultado de la consulta anterior debe ser similar a la siguiente captura de pantalla:

En el ejemplo de consulta siguiente se examina el registro de inicio de sesión no interactivo durante los últimos siete días, resaltando las solicitudes bloqueadas frente a las permitidas por usuario.

//Per users query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by UserPrincipalName asc   

En el ejemplo de consulta siguiente se examina el registro de inicio de sesión no interactivo durante los últimos siete días, resaltando los usuarios que usan dispositivos, donde el estado del dispositivo de Microsoft Entra ID no cumple los requisitos de la directiva de CA de protección de tokens.

AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| where TokenProtectionStatusDetails!= "" 
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails) 
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"]) 
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]) 
| where bindingStatusCode == 1003 
| summarize count() by UserPrincipalName 

Experiencia de usuario final

Un usuario que registró o inscribió su dispositivo no experimenta ninguna diferencia en la experiencia de inicio de sesión en una aplicación compatible con la protección de tokens cuando se habilita el requisito de protección de tokens.

Un usuario que no ha registrado ni inscrito su dispositivo, o cuando se usa una aplicación no admitida cuando el requisito de protección de tokens está habilitado, verá la captura de pantalla siguiente después de la autenticación.

Un usuario que no usa una aplicación compatible cuando se habilita el requisito de protección de tokens verá la captura de pantalla siguiente después de la autenticación.

Contenido relacionado

¿Qué es un token de actualización principal?