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

No se pudieron encontrar asignaciones de certificados seguras y el certificado no tenía la nueva extensión de identificador de seguridad (SID) que el KDC podía validar.

El certificado se emitió al usuario antes de que 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.

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

Nota Algunos campos, como Emisor, Asunto y Número de serie, se notifican en un formato "directo". Debe invertir este formato al agregar la cadena de correlació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 el resultado de ejemplo a continuación.

• Emisor: CN=CONTOSO-DC-CA, DC=contoso, DC=com
• Número de serie: 2B0000000011AC0000000012

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

• "X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B"

Para actualizar este atributo mediante PowerShell, puede utilizar 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>1200000000AC11000000002B"}

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

Una vez que haya instalado las actualizaciones de Windows del 10 de mayo de 2022, los dispositivos estarán en modo de compatibilidad. Si un certificado se puede asignar fuertemente a un usuario, la autenticación se realizará según lo esperado. Si un certificado solo se puede asignar débilmente a un usuario, la autenticación se realizará según lo previsto. 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 retroactiva del certificado no está presente o el intervalo está fuera de la compensación retroactiva, se producirá un error en la autenticación y se registrará un mensaje de error.  Si la clave del Registro retroactiva de certificados está configurada, registrará un mensaje de advertencia en el registro de eventos si las fechas se encuentran dentro de la compensación retroactiva.

Después de instalar las actualizaciones de Windows del 10 de mayo de 2022, esté atento a cualquier mensaje de advertencia que pueda aparecer después de un mes o más. Si no hay ningún mensaje de advertencia, se recomienda encarecidamente habilitar el modo de cumplimiento completo en todos los controladores de dominio que usan la autenticación basada en certificados. Puede usar la clave del registro KDC para habilitar el modo de cumplimiento total.

A menos que se actualicen antes al modo de auditoría o al modo de cumplimiento mediante la clave del Registro StrongCertificateBindingEnforcement , los controladores de dominio pasarán al modo de cumplimiento total cuando se instale la actualización de seguridad de Windows de febrero de 2025. La autenticación se denegará si no se puede asignar un certificado de forma sólida. La opción de volver al modo de compatibilidad se mantendrá hasta que se instale la actualización de seguridad de Windows del 9 de septiembre de 2025. Después de esta fecha, la clave del Registro StrongCertificateBindingEnforcement ya no será compatible

Si la autenticación basada en certificados se basa en una asignación débil que no puede mover del entorno, puede colocar los 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 versiones posteriores y haya admitido clientes con la característica opcional RSAT instalada, la asignación de certificados en Usuarios & equipos de Active Directory seleccionará de forma predeterminada una asignación segura mediante X509IssuerSerialNumber en lugar de una asignación débil mediante X509IssuerSubject. La configuración aún se puede cambiar según se desee.

Síntomas

Microsoft ha recibido informes de que la configuración "Procesar incluso si los objetos de la directiva de grupo no han cambiado" en el objeto de la directiva de grupo "Plantillas administrativasde configuración> delequipo Sistema>>:directiva de grupo Configurar el procesamiento de directivas del Registro>" pueden interferir intermitentemente con las asignaciones basadas en nombres en controladores de dominio.

Solución alternativa

Para solucionar este problema, deshabilite la configuración "Procesar incluso si los objetos de la directiva de grupo no han cambiado" en los controladores de dominio. Solo haga esto si se necesitan asignaciones basadas en nombres como se define en la directiva de grupo "KDC> delsistema> deplantillas> administrativas de configuración> de equipo"Permitir asignaciones seguras basadas en nombres para certificados. Para obtener más información, vea Habilitar la asignación segura basada en nombres en escenarios gubernamentales.

Siguiente paso

Estamos investigando estos informes y proporcionaremos más información cuando esté disponible.

• Use el registro operativo Kerberos en el equipo correspondiente para determinar qué controlador de dominio produce errores en el inicio de sesión. Vaya al Visor de eventosRegistros de>\aplicaciones y serviciosMicrosoft \Windows\Security-Kerberos\Operativo.
• Busque eventos relevantes en el registro de eventos del sistema en el controlador de dominio con el que la cuenta está intentando autenticarse.
• Si el certificado es anterior a la cuenta, vuelva a emitir el certificado o agregue una asignación segura altSecurityIdentities a la cuenta (consulte 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 el uso de una aplicación web de intranet de IIS.

• Después de instalar las protecciones CVE-2022-26391 y CVE-2022-26923 , estos escenarios usan el protocolo Servicio de certificados Kerberos para el usuario (S4U) para la asignación y autenticación de certificados de forma predeterminada.
• En el protocolo Certificado Kerberos S4U, la solicitud de autenticación fluye desde el servidor de aplicaciones al controlador de dominio, no desde el 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 para Windows publicadas en septiembre de 2025 o después.

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 a los usuarios que inician sesión con un certificado de cliente creando asignaciones que relacionen 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 del servidor asocia automáticamente ese usuario con la cuenta de usuario de Windows adecuada.

Schannel intentará asignar cada método de asignación de certificados que haya habilitado hasta que uno se realice correctamente. Schannel intenta asignar primero las asignaciones de Servicio para el usuario a sí mismo (S4U2Self). Las asignaciones de certificado Sujeto/Emisor, Emisor y UPN ahora se consideran débiles y se han deshabilitado de forma predeterminada. La suma de las opciones seleccionadas determina la lista de métodos de asignación de certificados disponibles.

El valor predeterminado de la clave del Registro SChannel era 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 y establézcalo en 0x1F y vea si se soluciona el problema. Para obtener más información, busque en los registros de eventos del sistema del controlador de dominio los errores enumerados en este artículo. Tenga en cuenta que al volver a cambiar el valor de la clave del Registro SChannel al valor predeterminado anterior (0x1F) se volverá a usar métodos de asignación de certificados débiles.

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

Después de instalar las actualizaciones que abordan CVE-2022-26931 y CVE-2022-26923, es posible que se produzca un error en la autenticación en los casos en que los certificados de usuario sean anteriores a la hora de creación de los usuarios. Esta clave del Registro permite una autenticación correcta cuando se usan asignaciones de certificado débiles en su entorno y la hora del certificado es anterior a la hora de creación del usuario dentro de un intervalo establecido. Esta clave del Registro no afecta a los usuarios o máquinas con asignaciones de certificados seguros, ya que la hora de creación del certificado y el usuario no se comprueban con asignaciones de certificados seguros. Esta clave del Registro no tiene ningún efecto cuando StrongCertificateBindingEnforcement está establecido en 2.

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

• Esta clave del Registro solo funciona en el 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 retroactividad, pero se registrará una advertencia del registro de eventos para el enlace débil.
• La habilitación de esta clave del Registro permite la autenticación del usuario cuando la hora del certificado es anterior a la hora de creación del usuario dentro de un intervalo establecido como una asignación débil. Las asignaciones débiles no se admitirán después de instalar las actualizaciones para Windows publicadas en septiembre de 2025 o después.

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

1. Inicie sesión en un servidor de entidad de certificación o en un cliente de Windows 10 unido a un dominio con las credenciales de administrador de empresa o equivalentes.
2. Abra un símbolo del sistema y elija Ejecutar como administrador.
3. Run certutil -dstemplate user msPKI-Enrollment-Flag +0x00080000.

Al deshabilitar la adición de esta extensión, se quitará la protección proporcionada por la nueva extensión. Considere hacer esto solo después de una de las siguientes opciones:

1. Confirma que los certificados correspondientes no son aceptables para la criptografía de clave pública para autenticación inicial (PKINIT) en las autenticaciones de protocolo Kerberos en KDC
2. Los certificados correspondientes tienen configuradas otras asignaciones de certificados seguros

Los entornos que tengan implementaciones de CA que no sean de Microsoft no estarán protegidos con 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 seguros descritas anteriormente.

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

No, no es necesario renovar. La entidad de certificación se enviará en modo de compatibilidad. Si desea una asignación sólida mediante 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) pasarán a cumplimiento. Si se deniega la autenticación, verá el id. de evento 39 (o el 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 clave del Registro en 1 (modo de compatibilidad) en esta fase.

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