Consideraciones y problemas conocidos al usar Credential Guard

Se recomienda que, además de implementar Credential Guard, las organizaciones se alejen de las contraseñas a otros métodos de autenticación, como Windows Hello para empresas, claves de seguridad FIDO 2 o tarjetas inteligentes.

Consideraciones sobre wi-fi y VPN

Al habilitar Credential Guard, ya no puede usar la autenticación NTLM clásica para el inicio de sesión único. Se le obligará a escribir sus credenciales para usar estos protocolos y no podrá guardar las credenciales para su uso futuro.

Si usa puntos de conexión WiFi y VPN basados en MS-CHAPv2, están sujetos a ataques similares a los de NTLMv1.

En el caso de las conexiones WiFi y VPN, se recomienda pasar de las conexiones basadas en MSCHAPv2 (como PEAP-MSCHAPv2 y EAP-MSCHAPv2) a la autenticación basada en certificados (como PEAP-TLS o EAP-TLS).

Consideraciones de Kerberos

Al habilitar Credential Guard, ya no se puede usar la delegación de Kerberos sin restricciones ni el cifrado DES. La delegación sin restricciones podría permitir a los atacantes extraer claves de Kerberos del proceso de LSA aislado.
Usa la delegación de Kerberos restringida o basada en recursos en su lugar.

Consideraciones sobre proveedores de soporte técnico de seguridad que no son de Microsoft

Es posible que algunos proveedores de soporte técnico de seguridad (SSP y AP) que no son de Microsoft no sean compatibles con Credential Guard porque no permite que los CSP que no son de Microsoft soliciten hashes de contraseña de LSA. Sin embargo, los SSP y puntos de acceso personalizados siguen recibiendo la notificación de la contraseña cuando un usuario inicia sesión o cambia su contraseña. No se admite el uso de API no documentadas en SSP y AP personalizados.
Se recomienda probar las implementaciones personalizadas de SSP/AP con Credential Guard. Los SSP y puntos de acceso que dependen de cualquier error de comportamiento no documentado o no compatible. Por ejemplo, no se admite el uso de la API KerbQuerySupplementalCredentialsMessage. Reemplazar SSP de Kerberos o NTLM con SSP y puntos de acceso personalizados.

Para obtener más información, vea Restricciones en torno al registro e instalación de un paquete de seguridad.

Consideraciones sobre la actualización

A medida que aumenta la profundidad y amplitud de las protecciones proporcionadas por Credential Guard, las nuevas versiones de Windows con Credential Guard en ejecución pueden afectar a los escenarios que estaban funcionando en el pasado. Por ejemplo, Credential Guard puede bloquear el uso de un tipo determinado de credencial o un componente determinado para evitar que el malware aproveche las vulnerabilidades.

Pruebe los escenarios necesarios para las operaciones en una organización antes de actualizar un dispositivo mediante Credential Guard.

Consideraciones sobre las credenciales de Windows guardadas

El Administrador de credenciales le permite almacenar tres tipos de credenciales:

  • Credenciales de Windows
  • Credenciales basadas en certificados
  • Credenciales genéricas

Las credenciales de dominio almacenadas en el Administrador de credenciales están protegidas con Credential Guard.

Las credenciales genéricas, como los nombres de usuario y las contraseñas que se usan para iniciar sesión en sitios web, no están protegidas, ya que las aplicaciones requieren la contraseña de texto no cifrado. Si la aplicación no necesita una copia de la contraseña, puede guardar las credenciales de dominio como credenciales de Windows que están protegidas. Las credenciales de Windows se usan para conectarse a otros equipos en una red.

Las consideraciones siguientes se aplican a las protecciones de Credential Guard para el Administrador de credenciales:

  • Las credenciales de Windows guardadas por el cliente de Escritorio remoto no se pueden enviar a un host remoto. Se produce un error al intentar usar las credenciales de Windows guardadas y se muestra el mensaje de error Error al intentar iniciar sesión.
  • Error en las aplicaciones que extraen credenciales de Windows
  • Cuando se realiza una copia de seguridad de las credenciales desde un equipo con Credential Guard habilitado, no se pueden restaurar las credenciales de Windows. Si necesita realizar una copia de seguridad de sus credenciales, debe hacerlo antes de habilitar Credential Guard.

Consideraciones sobre la eliminación de TPM

La seguridad basada en la virtualización (VBS) usa el TPM para proteger su clave. Cuando se borra el TPM, se pierde la clave protegida de TPM que se usa para cifrar los secretos de VBS.

Advertencia

Al borrar el TPM, se pierden los datos protegidos de todas las características que usan VBS para proteger los datos.

Cuando se borra un TPM, todas las características que usan VBS para proteger los datos ya no pueden descifrar sus datos protegidos.

Como resultado, Credential Guard ya no puede descifrar datos protegidos. VBS crea una nueva clave TPM protegido para Credential Guard. Credential Guard usa la nueva clave para proteger los datos nuevos. Sin embargo, los datos protegidos anteriormente se pierden para siempre.

Nota

Credential Guard obtiene la clave durante la inicialización. La pérdida de datos solo afectará a los datos persistentes y se producirá después del siguiente inicio del sistema.

Credenciales de Windows guardadas en el Administrador de credenciales

Dado que el Administrador de credenciales no puede descifrar las credenciales de Windows guardadas, se eliminan. Las aplicaciones deben solicitar credenciales que se guardaron anteriormente. Si se guardan de nuevo, las credenciales de Windows están protegidas por Credential Guard.

Clave pública aprovisionada automáticamente del dispositivo unido a un dominio

Los dispositivos unidos a un dominio de Active Directory aprovisionan automáticamente una clave pública enlazada. Para obtener más información sobre el aprovisionamiento automático de claves públicas, consulte Autenticación de clave pública de dispositivo unido a un dominio.

Puesto que Credential Guard no puede descifrar la clave privada protegida, Windows usa la contraseña del equipo unido al dominio para la autenticación en el dominio. A menos que se implementen otras directivas, no debería haber una pérdida de funcionalidad. Si un dispositivo está configurado para usar solo la clave pública, no se puede autenticar con contraseña hasta que esa directiva esté deshabilitada. Para obtener más información sobre cómo configurar dispositivos para usar únicamente una clave pública, consulta Autenticación de clave pública de dispositivo unido al dominio.

Además, si las comprobaciones de control de acceso, incluidas las directivas de autenticación, requieren que los dispositivos tengan los KEY TRUST IDENTITY (S-1-18-4) SID conocidos o FRESH PUBLIC KEY IDENTITY (S-1-18-3) bien, se producirá un error en esas comprobaciones de acceso. Para obtener más información acerca de las directivas de autenticación, consulta Directivas de autenticación y silos de directivas de autenticación. Para obtener más información acerca de los SID conocidos, consulta [MS-DTYP] sección 2.4.2.4 Well-known SID Structures (Estructuras de SID conocido).

Dividir la DPAPI en dispositivos unidos a un dominio

En los dispositivos unidos a un dominio, la DPAPI puede recuperar las claves de usuario con un controlador de dominio desde el dominio del usuario. Si un dispositivo unido a un dominio no tiene conectividad con un controlador de dominio, no es posible la recuperación.

Importante

La práctica recomendada al borrar un TPM en un dispositivo unido a un dominio es estar en una red con conectividad a los controladores de dominio. Esto garantiza que la DPAPI funcione y el usuario no experimente un comportamiento extraño.

La configuración de VPN automática está protegida con la DPAPI del usuario. Es posible que el usuario no pueda usar VPN para conectarse a los controladores de dominio, dado que las configuraciones de VPN se pierden. Si debes borrar el TPM en un dispositivo unido al dominio sin conectividad a los controladores de dominio, debes tener en cuenta lo siguiente.

Inicio de sesión de usuario de dominio en un dispositivo unido a un dominio después de borrar un TPM, siempre y cuando no haya conectividad con un controlador de dominio:

Tipo de credencial Comportamiento
Certificado (tarjeta inteligente o Windows Hello para empresas) Todos los datos protegidos con DPAPI de usuario no se pueden usar y dpapi de usuario no funciona en absoluto.
Contraseña Si el usuario inició sesión con un certificado o una contraseña antes de borrar el TPM, puede iniciar sesión con contraseña y dpapi de usuario no se verá afectada.

Una vez que el dispositivo tiene conectividad a los controladores de dominio, la DPAPI recupera la clave del usuario y los datos protegidos antes de borrar el TPM pueden descifrarse.

Efecto de los errores de la DPAPI en Windows Information Protection

Cuando los datos protegidos con la DPAPI de usuario son inutilizables, el usuario pierde el acceso a todos los datos de trabajo protegidos por Windows Information Protection. El impacto incluye: Outlook no puede iniciarse y no se pueden abrir documentos protegidos por el trabajo. Si la DPAPI está funcionando, los datos de trabajo creados recientemente están protegidos y se puede tener acceso a ellos.

Solución alternativa: los usuarios pueden resolver el problema conectando su dispositivo al dominio y reiniciando o usando el certificado de Agente de recuperación de datos del Sistema de cifrado de archivos. Para obtener más información sobre el certificado de Agente de recuperación de datos del Sistema de cifrado de archivos, consulta Crear y comprobar un certificado del Agente de recuperación de datos (DRA) del Sistema de cifrado de archivos (EFS).

Problemas conocidos

Credential Guard bloquea determinadas funcionalidades de autenticación. Las aplicaciones que requieren estas funcionalidades no funcionarán cuando Credential Guard esté habilitado.

En este artículo se describen problemas conocidos cuando Credential Guard está habilitado.

El inicio de sesión único para los servicios de red se interrumpe después de actualizar a Windows 11, versión 22H2

Los dispositivos que usan redes inalámbricas o cableadas 802.1x, RDP o conexiones VPN que dependen de protocolos no seguros con autenticación basada en contraseña no pueden usar el inicio de sesión único para iniciar sesión y se ven obligados a volver a autenticarse manualmente en cada nueva sesión de Windows cuando se ejecuta Credential Guard.

Dispositivos afectados

Cualquier dispositivo con Credential Guard habilitado puede encontrar el problema. Como parte de la Windows 11, la actualización de la versión 22H2, los dispositivos aptos que no deshabilitaron Credential Guard, lo tienen habilitado de forma predeterminada. Esto afectó a todos los dispositivos en las licencias Enterprise (E3 y E5) y Education, así como algunas licencias Pro, siempre y cuando cumplan los requisitos mínimos de hardware.

Todos los dispositivos Windows Pro que anteriormente ejecutaron Credential Guard con una licencia apta y que posteriormente se degradaron a Pro, y que aún cumplen los requisitos mínimos de hardware, recibirán la habilitación predeterminada.

Sugerencia

Para determinar si un dispositivo Windows Pro recibe la habilitación predeterminada cuando se actualiza a Windows 11, versión 22H2, compruebe si la clave IsolatedCredentialsRootSecret del Registro está presente en Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Si está presente, el dispositivo habilita Credential Guard después de la actualización.

Puede deshabilitar Credential Guard después de la actualización siguiendo las instrucciones de deshabilitación.

Causa del problema

Las aplicaciones y los servicios se ven afectados por el problema cuando se basan en protocolos no seguros que usan la autenticación basada en contraseña. Estos protocolos se consideran inseguros porque pueden provocar la divulgación de contraseñas en el cliente o el servidor, y Credential Guard los bloquea. Los protocolos afectados incluyen:

  • Delegación sin restricciones de Kerberos (tanto el inicio de sesión único como las credenciales proporcionadas están bloqueadas)
  • Kerberos cuando PKINIT usa el cifrado RSA en lugar de Diffie-Hellman (tanto el inicio de sesión único como las credenciales proporcionadas están bloqueadas)
  • MS-CHAP (solo se bloquea el inicio de sesión único)
  • WDigest (solo se bloquea el inicio de sesión único)
  • NTLM v1 (solo se bloquea el inicio de sesión único)

Nota

Dado que solo se bloquea el inicio de sesión único para MS-CHAP, WDigest y NTLM v1, estos protocolos se pueden seguir usando solicitando al usuario que proporcione credenciales.

Cómo confirmar el problema

MS-CHAP y NTLMv1 son relevantes para la interrupción del inicio de sesión único después de la actualización de la Windows 11, versión 22H2. Para confirmar si Credential Guard está bloqueando MS-CHAP o NTLMv1, abra el Visor de eventos (eventvwr.exe) y vaya a Application and Services Logs\Microsoft\Windows\NTLM\Operational. Compruebe los registros siguientes:

Id. de evento (tipo)

Descripción

4013 (advertencia)

<string
id="NTLMv1BlockedByCredGuard"
value="Attempt to use NTLMv1 failed.
Target server: %1%nSupplied user: %2%nSupplied domain: %3%nPID
of client process: %4%nName
of client process: %5%nLUID
of client process: %6%nUser identity
of client process: %7%nDomain name
of user identity of client process: %8%nMechanism OID: 9%n%n
This device doesn't support NTLMv1.
/>

4014 (error)

<string
id="NTLMGetCredentialKeyBlockedByCredGuard"
value="Attempt to get credential key by call package blocked by Credential Guard.%n%n
Calling Process Name: %1%nService Host Tag: %2"
/>

Cómo corregir el problema

Se recomienda pasar de las conexiones basadas en MSCHAPv2, como PEAP-MSCHAPv2 y EAP-MSCHAPv2, a la autenticación basada en certificados, como PEAP-TLS o EAP-TLS. Credential Guard no bloquea la autenticación basada en certificados.

Para una corrección más inmediata, pero menos segura, deshabilite Credential Guard. Credential Guard no tiene directivas por protocolo o por aplicación y se puede activar o desactivar. Si deshabilita Credential Guard, dejará las credenciales de dominio almacenadas vulnerables al robo.

Sugerencia

Para evitar la habilitación predeterminada, configure los dispositivos para deshabilitar Credential Guard antes de actualizar a Windows 11, versión 22H2. Si la configuración no está configurada (que es el estado predeterminado) y si el dispositivo es apto, el dispositivo habilita automáticamente Credential Guard después de la actualización.

Si Credential Guard está deshabilitado explícitamente, el dispositivo no habilitará automáticamente Credential Guard después de la actualización.

Problemas con aplicaciones que no son de Microsoft

El siguiente problema afecta a MSCHAPv2:

El siguiente problema afecta a la GSS API de Java. Consulta el siguiente artículo de la base de datos de errores de Oracle:

Cuando Credential Guard está habilitado en Windows, la API de GSS de Java no se autentica. Credential Guard bloquea funcionalidades específicas de autenticación de aplicaciones y no proporciona la clave de sesión de TGT a las aplicaciones, independientemente de la configuración de la clave del Registro. Para obtener más información, consulte Requisitos de la aplicación.

Compatibilidad del proveedor

Los siguientes productos y servicios no admiten Credential Guard:

Importante

Esta lista no es completa. Compruebe si el proveedor del producto, la versión del producto o el sistema informático admiten Credential Guard en sistemas que ejecutan una versión específica de Windows. Los modelos de sistema de equipo específicos pueden ser incompatibles con Credential Guard.