KB5014754: Cambios de autenticación basada en certificados en controladores de dominio de Windows

No se pudo encontrar ninguna asignación de certificados seguras y el certificado no tenía la nueva extensión de identificador de seguridad (SID) que el KDC podría validar.

Registro de eventos	Sistema
Tipos de eventos	Advertencia si el KDC está en modo de compatibilidad Error si el KDC está en modo de obligatoriedad
Origen del evento	Kdcsvc
Id. del evento	39 41 (para Windows Server 2008 R2 SP1 y Windows Server 2008 SP2)
Texto del evento	El Centro de distribución de claves (KDC) encontró un certificado de usuario que era válido, pero que no se pudo asignar a un usuario de forma segura (por ejemplo, mediante asignación explícita, asignación de confianza de claves o un SID). Estos certificados deben reemplazarse o asignarse directamente al usuario mediante la asignación explícita. Consulta https://go.microsoft.com/fwlink/?linkid=2189925 para obtener más información. Usuario: <nombre principal> Asunto del certificado: <nombre del asunto en> de certificado Emisor de certificados: <nombre de dominio completo (FQDN) del emisor > Número de serie del certificado: <número de serie del> de certificado Huella digital de certificado: <huella digital del> de certificado

El certificado se emitió al usuario antes de que el usuario existiera en Active Directory y no se pudo encontrar ninguna asignación segura. Este evento solo se registra cuando el KDC está en modo de compatibilidad.

Registro de eventos	Sistema
Tipos de eventos	Error
Origen del evento	Kdcsvc
Id. del evento	40 48 (para Windows Server 2008 R2 SP1 y Windows Server 2008 SP2
Texto del evento	El Centro de distribución de claves (KDC) encontró un certificado de usuario que era válido, pero que no se pudo asignar a un usuario de forma segura (por ejemplo, mediante asignación explícita, asignación de confianza de claves o un SID). El certificado también predestó al usuario al que se asignó, por lo que se rechazó. Consulta https://go.microsoft.com/fwlink/?linkid=2189925 para obtener más información. Usuario: <nombre principal> Asunto del certificado: <nombre del asunto en> de certificado Emisor de certificados: <> FQDN del emisor Número de serie del certificado: <número de serie del> de certificado Huella digital de certificado: <huella digital del> de certificado Tiempo de emisión de certificado: <FILETIME del> de certificado Tiempo de creación de la cuenta: <FILETIME del objeto principal en ad>

El SID incluido en la nueva extensión del certificado de usuario no coincide con el SID de los usuarios, lo que implica que el certificado se emitió a otro usuario.

Registro de eventos	Sistema
Tipos de eventos	Error
Origen del evento	Kdcsvc
Id. del evento	41 49 (para Windows Server 2008 R2 SP1 y Windows Server 2008 SP2)
Texto del evento	El Centro de distribución de claves (KDC) encontró un certificado de usuario que era válido pero contenía un SID diferente al usuario al que asignaba. Como resultado, no se pudo realizar la solicitud que implicaba el certificado. Consulta https://go.microsoft.cm/fwlink/?linkid=2189925 para obtener más información. Usuario: <nombre principal> SID de usuario: <SID de la entidad de seguridad de autenticación> Asunto del certificado: <nombre del asunto en> de certificado Emisor de certificados: <> FQDN del emisor Número de serie del certificado: <número de serie del> de certificado Huella digital de certificado: <huella digital del> de certificado SID de certificado: <SID que se encuentra en el nuevo> de extensión de certificado

Nota Algunos campos, como Emisor, Asunto y Número de serie, se notifican en un formato de "reenvío". Debe invertir este formato al agregar la cadena de asignación al atributo altSecurityIdentities . Por ejemplo, para agregar la asignación X509IssuerSerialNumber a un usuario, busque los campos "Emisor" y "Número de serie" del certificado que desea asignar al usuario. Consulte la salida de ejemplo a continuación.

• Emisor: CN=CONTOSO-DC-CA, DC=contoso, DC=com

• SerialNumber: 2B0000000011AC000000012

A continuación, actualice el atributo altSecurityIdentities del usuario en Active Directory con la cadena siguiente:

• "X509:<>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>120000000AC1100000002B"

Para actualizar este atributo con Powershell, puede usar el siguiente comando. Tenga en cuenta que, de forma predeterminada, solo los administradores de dominio tienen permiso para actualizar este atributo.

• set-aduser 'DomainUser' -replace @{altSecurityIdentities= "X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>120000000AC1100000002B"}

Tenga en cuenta que al invertir el SerialNumber, debe mantener el orden de bytes. Esto significa que la inversión del SerialNumber "A1B2C3" debe dar como resultado la cadena "C3B2A1" y no "3C2B1A". Para obtener más información, vea HowTo: Asignar un usuario a un certificado a través de todos los métodos disponibles en el atributo altSecurityIdentities.

Una vez instaladas las actualizaciones de Windows del 10 de mayo de 2022, los dispositivos estarán en modo de compatibilidad. Si un certificado se puede asignar de forma segura a un usuario, la autenticación se producirá según lo esperado. Si un certificado solo se puede asignar de forma débil a un usuario, la autenticación se producirá según lo esperado. Sin embargo, se registrará un mensaje de advertencia a menos que el certificado sea anterior al usuario. Si el certificado es anterior al usuario y la clave del Registro de copia de seguridad de certificados no está presente o el intervalo está fuera de la compensación de backdating, se producirá un error en la autenticación y se registrará un mensaje de error.  Si se configura la clave del Registro de copia de seguridad de certificados, se registrará un mensaje de advertencia en el registro de eventos si las fechas se encuentran dentro de la compensación de backdating.

Después de instalar las actualizaciones de Windows del 10 de mayo de 2022, watch para cualquier mensaje de advertencia que pueda aparecer después de un mes o más. Si no hay mensajes de advertencia, se recomienda encarecidamente habilitar el modo de cumplimiento completo en todos los controladores de dominio que usen autenticación basada en certificado. Puede usar la clave del Registro KDC para habilitar el modo de obligatoriedad completa.

A menos que se actualice al modo auditoría o al modo de obligatoriedad mediante la clave del Registro StrongCertificateBindingEnforcement anteriormente, los controladores de dominio se moverán al modo de obligatoriedad completa cuando se instale la actualización de seguridad de Windows de febrero de 2025. Se denegará la autenticación si un certificado no se puede asignar de forma segura. La opción para volver al modo de compatibilidad permanecerá hasta septiembre de 2025. Después de esta fecha, ya no se admitirá la clave del Registro StrongCertificateBindingEnforcement

Si la autenticación basada en certificado se basa en una asignación débil que no se puede mover desde el entorno, puede colocar controladores de dominio en modo deshabilitado mediante una configuración de clave del Registro. Microsoft no lo recomienda y quitaremos el modo Deshabilitado el 11 de abril de 2023.

Una vez que haya instalado las actualizaciones de Windows del 13 de febrero de 2024 o posteriores en Server 2019 y en los clientes compatibles con la característica opcional RSAT instalada, la asignación de certificados en usuarios de Active Directory & Equipos seleccionará de forma predeterminada una asignación segura con X509IssuerSerialNumber en lugar de una asignación débil con el X509IssuerSubject. La configuración se puede seguir modificando según lo desee.

• Utilice el registro operativo kerberos en el equipo relevante para determinar qué controlador de dominio está fallando el inicio de sesión. Ve a Visor de eventos > Registros de aplicaciones y servicios\Microsoft \Windows\Security-Kerberos\Operational.

• Busque eventos relevantes en el registro de eventos del sistema en el controlador de dominio con el que la cuenta intenta autenticarse.

• Si el certificado es anterior a la cuenta, vuelva a emitir el certificado o agregue una asignación altSecurityIdentities segura a la cuenta (vea Asignaciones de certificados).

• Si el certificado contiene una extensión SID, compruebe que el SID coincide con la cuenta.

• Si el certificado se usa para autenticar varias cuentas diferentes, cada cuenta necesitará una asignación altSecurityIdentities independiente.

• Si el certificado no tiene una asignación segura a la cuenta, agregue una o deje el dominio en modo de compatibilidad hasta que se pueda agregar una.

Un ejemplo de asignación de certificados TLS es usar una aplicación web de intranet de IIS.

• Después de instalar las protecciones CVE-2022-26391 y CVE-2022-26923 , estos escenarios utilizan el protocolo Kerberos Certificate Service for User (S4U) para la asignación y autenticación de certificados de forma predeterminada.

• En el protocolo Kerberos Certificate S4U, la solicitud de autenticación fluye desde el servidor de aplicaciones al controlador de dominio, no del cliente al controlador de dominio. Por lo tanto, los eventos relevantes estarán en el servidor de aplicaciones.

Esta clave del Registro no será compatible después de instalar las actualizaciones de Windows publicadas el 2025 o después.

Subclave del Registro	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Valor	StrongCertificateBindingEnforcement
Tipo de datos	REG_DWORD
Datos	1: comprueba si hay una asignación de certificados segura. Si es así, se permite la autenticación. De lo contrario, el KDC comprobará si el certificado tiene la nueva extensión SID y la validará. Si esta extensión no está presente, se permite la autenticación si la cuenta de usuario es anterior al certificado. 2– Comprueba si hay una asignación de certificados segura. Si es así, se permite la autenticación. De lo contrario, el KDC comprobará si el certificado tiene la nueva extensión SID y la validará. Si esta extensión no está presente, se denegará la autenticación. 0: deshabilita la comprobación de asignación de certificados fuertes. No se recomienda porque deshabilitará todas las mejoras de seguridad. Si establece esto en 0, también debe establecer CertificateMappingMethods en 0x1F como se describe en la sección de clave del Registro Schannel que se muestra a continuación para que la autenticación basada en certificados del equipo se realice correctamente.
¿Es necesario reiniciar?	No

Cuando una aplicación de servidor requiere autenticación de cliente, Schannel intenta automáticamente asignar el certificado que el cliente TLS proporciona a una cuenta de usuario. Puede autenticar usuarios que inician sesión con un certificado de cliente creando asignaciones que relacionan la información del certificado con una cuenta de usuario de Windows. Después de crear y habilitar una asignación de certificado, cada vez que un cliente presenta un certificado de cliente, la aplicación de servidor asocia automáticamente ese usuario a la cuenta de usuario de Windows adecuada.

Schannel intentará asignar cada método de asignación de certificados que haya habilitado hasta que se complete correctamente. Schannel intenta asignar primero las asignaciones Service-For-User-To-Self (S4U2Self). Las asignaciones de certificados Subject/Issuer, Issuer y UPN ahora se consideran débiles y se han deshabilitado de forma predeterminada. La suma de bitmasked de las opciones seleccionadas determina la lista de métodos de asignación de certificados que están disponibles.

El valor predeterminado de la clave del Registro SChannel estaba 0x1F y ahora está 0x18. Si experimenta errores de autenticación con aplicaciones de servidor basadas en Schannel, le sugerimos que realice una prueba. Agregue o modifique el valor de clave del registro CertificateMappingMethods en el controlador de dominio, establécielo en 0x1F y compruebe si se soluciona el problema. Busque en los registros de eventos del sistema del controlador de dominio cualquier error enumerado en este artículo para obtener más información. Ten en cuenta que cambiar el valor de clave del Registro SChannel al valor predeterminado anterior (0x1F) volverá a usar métodos de asignación de certificados débiles.

Subclave del Registro	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel
Valor	CertificateMappingMethods
Tipo de datos	DWORD
Datos	0x0001: asignación de certificado de asunto/emisor (débil: deshabilitada de forma predeterminada) 0x0002: asignación de certificados del emisor (débil: deshabilitada de forma predeterminada) 0x0004: asignación de certificados UPN (débil: deshabilitada de forma predeterminada) 0x0008: asignación de certificado S4U2Self (strong) 0x0010: S4U2Este asignación explícita de certificados (strong)
¿Es necesario reiniciar?	No

Para obtener más recursos y soporte técnico, consulte la sección "Recursos adicionales".

Después de instalar las actualizaciones que dirección CVE-2022-26931 y CVE-2022-26923, la autenticación podría producir errores en los casos en que los certificados de usuario sean más antiguos que el tiempo de creación de los usuarios. Esta clave del Registro permite la autenticación correcta cuando se usan asignaciones de certificados no seguras en su entorno y el tiempo de creación del certificado es anterior al tiempo de creación del usuario dentro de un intervalo establecido. Esta clave del Registro no afecta a los usuarios o equipos con asignaciones de certificados seguras, ya que la hora del certificado y la hora de creación de usuarios no se comprueban con asignaciones de certificados seguras. Esta clave del Registro no tiene ningún efecto cuando StrongCertificateBindingEnforcement se establece en 2.

Usar esta clave del Registro es una solución temporal para entornos que lo requieren y debe realizarse con precaución. El uso de esta clave del Registro significa lo siguiente para su entorno:

• Esta clave del Registro solo funciona en modo de compatibilidad a partir de las actualizaciones publicadas el 10 de mayo de 2022. Se permitirá la autenticación dentro del desplazamiento de compensación de contrapartida, pero se registrará una advertencia del registro de eventos para la unión débil.

• Habilitar esta clave del Registro permite la autenticación de usuario cuando el tiempo del certificado es anterior al tiempo de creación del usuario dentro de un intervalo establecido como una asignación débil. Las asignaciones no débiles no serán compatibles después de instalar las actualizaciones de Windows publicadas el 2025 o después.

Subclave del Registro	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Valor	CertificateBackdatingCompensation
Tipo de datos	REG_DWORD
Datos	Valores para la solución alternativa en años aproximados: 50 años: 0x5E0C89C0 25 años: 0x2EFE0780 10 años: 0x12CC0300 5 años: 0x9660180 3 años: 0x5A39A80 1 año: 0x1E13380 Nota Si conoce la duración de los certificados en su entorno, establezca esta clave del Registro en algo más larga que la duración del certificado.  Si no conoce la duración del certificado para su entorno, establezca esta clave del Registro en 50 años. El valor predeterminado es 10 minutos cuando esta clave no está presente, que coincide con servicios de certificado de Active Directory (ADCS). El valor máximo es de 50 años (0x5E0C89C0). Esta clave establece la diferencia de tiempo, en segundos, que el Centro de distribución de claves (KDC) ignorará entre una hora de emisión del certificado de autenticación y una hora de creación de cuenta para las cuentas de usuario o máquina. Importante Establezca esta clave del Registro solo si su entorno lo requiere. El uso de esta clave del Registro deshabilita una comprobación de seguridad.
¿Es necesario reiniciar?	No

Ejecute el siguiente comando certutil para excluir de la nueva extensión los certificados de la plantilla de usuario .

1. Inicie sesión en un servidor de entidad de certificación o en un cliente de Windows 10 unido a un dominio con el administrador de la empresa o las credenciales equivalentes.

2. Abra un símbolo del sistema y elija Ejecutar como administrador.

3. Ejecute certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000. 

Si deshabilitas la adición de esta extensión, se quitará la protección proporcionada por la nueva extensión. Considere la posibilidad de hacerlo solo después de una de las siguientes acciones:

1. Usted confirma que los certificados correspondientes no son aceptables para la criptografía de clave pública para la autenticación inicial (PKINIT) en las autenticaciones del protocolo Kerberos en KDC

2. Los certificados correspondientes tienen otras asignaciones de certificados fuertes configuradas

Los entornos que no tengan implementaciones de CA de Microsoft no se protegerán mediante la nueva extensión SID después de instalar la actualización de Windows del 10 de mayo de 2022. Los clientes afectados deben trabajar con los proveedores de CA correspondientes para solucionar este problema o deberían considerar la posibilidad de usar otras asignaciones de certificados seguras descritas anteriormente.

Para obtener más recursos y soporte técnico, consulte la sección "Recursos adicionales".

No, la renovación no es necesaria. La CA se enviará en modo de compatibilidad. Si desea una asignación segura con la extensión ObjectSID, necesitará un nuevo certificado.

En la actualización de Windows del 11 de febrero de 2025, los dispositivos que aún no estén en cumplimiento (el valor del Registro StrongCertificateBindingEnforcement se establece en 2), se moverán a Obligatoriedad. Si se deniega la autenticación, verá Id. de evento 39 (o Id. de evento 41 para Windows Server 2008 R2 SP1 y Windows Server 2008 SP2). Tendrá la opción de volver a establecer el valor de la clave del Registro en 1 (modo de compatibilidad) en esta fase.

En la actualización de Windows del 10 de septiembre de 2025, ya no se admitirá el valor del Registro StrongCertificateBindingEnforcement . ​​​​​​​