Consideraciones y problemas conocidos al usar Credential Guard
Microsoft recomienda que, además de implementar Credential Guard, las organizaciones pasen 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 la actualización
A medida que Credential Guard evoluciona y mejora sus características de seguridad, las versiones más recientes de Windows que ejecutan Credential Guard pueden afectar a escenarios funcionales anteriores. Por ejemplo, Credential Guard podría restringir el uso de ciertas credenciales o componentes para impedir que el malware aproveche las vulnerabilidades.
Es aconsejable probar exhaustivamente los escenarios operativos dentro de una organización antes de actualizar los dispositivos que usan Credential Guard.
Las actualizaciones a Windows 11, versión 22H2 y Windows Server 2025 tienen Credential Guard habilitado de forma predeterminada a menos que se deshabilite explícitamente.
Consideraciones sobre wi-fi y VPN
Cuando Credential Guard está habilitado, ya no puede usar la autenticación clásica NTLM (NTLMv1) para el inicio de sesión único (SSO). 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 delegación
Cuando Credential Guard está habilitado, determinados tipos de delegación de identidades no se pueden usar, ya que sus esquemas de autenticación subyacentes son incompatibles con Credential Guard o requieren credenciales proporcionadas.
Cuando Credential Guard está habilitado, el proveedor de soporte técnico de seguridad de credenciales ("CredSSP") ya no puede usar credenciales guardadas o sso, aunque todavía se pueden proporcionar credenciales de texto no cifrado. La delegación basada en CredSSP requiere que se proporcionen credenciales de texto no cifrado en la máquina de destino y no funciona con el inicio de sesión único una vez que Credential Guard está habilitado y bloquea la divulgación de credenciales de texto no cifrado. No se recomienda el uso de CredSSP para la delegación y, en general, debido al riesgo de robo de credenciales.
Credential Guard bloquea la delegación sin restricciones de Kerberos y DES. La delegación sin restricciones no es una práctica recomendada.
En su lugar, se recomienda Kerberos o Negotiate SSP para la autenticación con carácter general y, para la delegación, se recomienda la delegación restringida de Kerberos y la delegación restringida de Kerberos basada en recursos . Estos métodos proporcionan una mayor seguridad de credenciales en general y también son compatibles con Credential Guard.
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 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 controladores de dominio, ya que se pierden las configuraciones de VPN. 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.
Migración en vivo con saltos de Hyper-V al actualizar a Windows Server 2025
Es posible que los dispositivos que usan la delegación basada en CredSSP ya no puedan usar la migración en vivo con Hyper-V después de actualizar a Windows Server 2025. Las aplicaciones y servicios que se basan en la migración en vivo (como SCVMM) también pueden verse afectadas. La delegación basada en CredSSP es el valor predeterminado para Windows Server 2022 y versiones anteriores para la migración en vivo.
| Descripción | |
|---|---|
| Dispositivos afectados | Cualquier servidor con Credential Guard habilitado podría encontrar este problema. A partir de Windows Server 2025, Credential Guard está habilitado de forma predeterminada en todos los servidores unidos a un dominio que no son controladores de dominio. La habilitación predeterminada de Credential Guard se puede bloquear de forma preventiva antes de la actualización. |
| Causa del problema | La migración en vivo con Hyper-V y las aplicaciones y servicios que dependen de ella se ven afectados por el problema si uno o ambos extremos de una conexión determinada intentan usar CredSSP con Credential Guard habilitado. Con Credential Guard habilitado, CredSSP solo puede usar las credenciales proporcionadas, no las credenciales de inicio de sesión único o guardadas. Si la máquina de origen de una migración en vivo usa CredSSP para la delegación con Credential Guard habilitado, se produce un error en la migración en vivo. En la mayoría de los casos, el estado de habilitación de Credential Guard en la máquina de destino no afectará a la migración en vivo. También se produce un error en la migración en vivo en escenarios de clúster (por ejemplo, SCVMM), ya que cualquier dispositivo podría actuar como una máquina de origen. |
| Resolución | En lugar de la delegación de CredSSP, se recomienda la delegación restringida de Kerberos y Resource-Based delegación restringida de Kerberos . Estas formas de delegación proporcionan mayores protecciones de credenciales, además de ser compatibles con Credential Guard. Los administradores de Hyper-V pueden configurar estos tipos de delegación manualmente o con la ayuda de scripts automatizados. |
El inicio de sesión único para los servicios de red se interrumpe después de actualizar a Windows 11, versión 22H2 o Windows Server 2025
Los dispositivos que usan redes inalámbricas o cableadas 802.1x, RDP o CONEXIONES VPN que se basan en 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.
| Descripción | |
|---|---|
| Dispositivos afectados | Cualquier dispositivo con Credential Guard habilitado podría encontrar el problema. A partir de Windows 11, versión 22H2 y Windows Server 2025, dispositivos aptos que no deshabilitaron Credential Guard, tienen habilitado de forma predeterminada. Esto afecta a todos los dispositivos de las licencias Enterprise (E3 y E5) y Education, y a 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, reciben la habilitación predeterminada. |
| 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. |
| Resolución | Microsoft recomienda pasar de las conexiones basadas en MSCHAPv2 (por ejemplo, PEAP-MSCHAPv2 y EAP-MSCHAPv2) a la autenticación basada en certificados (por ejemplo, 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 una versión que recibió la habilitación predeterminada. 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.
Nota
Para determinar si un dispositivo Windows Pro recibe la habilitación predeterminada cuando se actualiza a Windows 11, versión 22H2 o Windows Server 2025, 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.
Credential Guard se puede deshabilitar después de la actualización siguiendo las instrucciones de deshabilitación.
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"
/>
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:
- Check Point compatibilidad del cliente de Endpoint Security con Microsoft Credential Guard y Hypervisor-Protected características de integridad de código
- VMware Workstation y Device/Credential Guard no son compatibles con errores en VMware Workstation en Windows 10 host (2146361)
- Compatibilidad con ThinkPad para la integridad de código Hypervisor-Protected y Credential Guard en Microsoft Windows
- Dispositivos Windows con Credential Guard y Symantec Endpoint Protection 12.1
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.