Asignación fuerte de certificados (KB5014754) en la práctica

Antes de mayo de 2022, un controlador de dominio asignaba un certificado a una cuenta principalmente por su nombre: el UPN del nombre alternativo del sujeto (SAN) en los certificados de usuario y el nombre DNS en los certificados de equipo. Eso hacía que el contenido del certificado fuera lo único que se interponía entre un solicitante y cualquier identidad cuyo nombre pudiera incluir en un certificado. CVE-2022-26923 («Certifried») demostró lo poco que hacía falta: un usuario capaz de crear una cuenta de equipo podía establecer su dNSHostName con el nombre de un controlador de dominio y obtener un certificado que se asignaba al DC. KB5014754 es la corrección de Microsoft. Hace que el KDC y Schannel exijan un vínculo fuerte entre el certificado y la cuenta, y se aplica por completo desde 2025.

Esta guía cubre lo que significa «fuerte» en la práctica, cómo encontrar los certificados y las asignaciones que no lo cumplen, cómo corregir cada categoría y qué rompe la aplicación. Da por hecho que sus plantillas ya están limpias, como se explica en auditar las plantillas de certificado y en el pilar de hardening de AD CS.

Cómo funciona la asignación fuerte

Con la aplicación completa, el KDC solo acepta un certificado para PKINIT si uno de los siguientes elementos lo vincula a la cuenta:

1. La extensión de seguridad SID (szOID_NTDS_CA_SECURITY_EXT, OID 1.3.6.1.4.1.311.25.2). Las CA empresariales con la actualización de mayo de 2022 o posterior escriben el SID del solicitante en esta extensión para las plantillas en línea, en las que el sujeto se construye a partir de Active Directory.
2. Una asignación explícita fuerte en el atributo altSecurityIdentities de la cuenta: X509IssuerSerialNumber, X509SKI o X509SHA1PublicKey.
3. Un SID en el SAN como URL con el formato tag:microsoft.com,2022-09-14:sid:<SID>, que actualizaciones posteriores de KB5014754 añadieron para los certificados que no pueden llevar la extensión. Confirme que el nivel de actualización de sus controladores de dominio lo admite antes de confiar en ello.

El comportamiento del KDC se controlaba con StrongCertificateBindingEnforcement bajo HKLM\SYSTEM\CurrentControlSet\Services\Kdc:

Calendario, según KB5014754: el 10 de mayo de 2022 se introdujeron la extensión SID y el modo de compatibilidad con eventos de auditoría; en febrero de 2025 la aplicación completa pasó a ser el valor predeterminado, aunque se seguía respetando un valor explícito de 1; en septiembre de 2025 se retiró el modo de compatibilidad, de modo que los controladores de dominio actuales aplican la comprobación independientemente del registro. Si todavía ve el valor en su base de referencia, es documentación histórica, no un control. El valor CertificateBackdatingCompensation, que ajustaba la comprobación de «certificado anterior a la cuenta» en el modo de compatibilidad, también es irrelevante una vez que la aplicación es permanente.

Schannel (autenticación TLS con certificado de cliente en IIS, LDAPS y otros) tiene su propio conmutador, CertificateMappingMethods bajo HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel. La actualización cambió su valor predeterminado a 0x18 (asignación basada en S4U2Self), que hace pasar Schannel por las mismas comprobaciones del KDC. Devolverlo a 0x1F vuelve a habilitar la asignación débil por UPN y sujeto, y debe tratarse como un hallazgo.

Medir: eventos 39, 40 y 41 del KDC

Todos los controladores de dominio registran los problemas de asignación de certificados en el registro System, con el proveedor Kerberos Key Distribution Center:

• 39: un certificado era válido pero no pudo asignarse de forma fuerte. Advertencia en el modo de compatibilidad, denegación con la aplicación completa.
• 40: el certificado se emitió antes de que existiera la cuenta y no hay asignación fuerte. Denegado.
• 41: la extensión SID del certificado no coincide con el SID de la cuenta. Denegado, y merece investigarse: o bien la cuenta se volvió a crear, o bien alguien presenta un certificado emitido a otra entidad de seguridad.

Recójalos de todos los controladores de dominio:

$dcs = (Get-ADDomainController -Filter *).HostName
$events = foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -ErrorAction SilentlyContinue -FilterHashtable @{
        LogName = 'System'
        ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
        Id = 39, 40, 41
        StartTime = (Get-Date).AddDays(-30)
    }
}
$events | Group-Object Id, { $_.Properties[0].Value } |
    Sort-Object Count -Descending |
    Select-Object Count, Name -First 50

La primera propiedad de cada evento es el nombre de la cuenta. Agrupar por ID de evento y cuenta convierte miles de eventos en una lista corta de identidades que fallan. Lea un evento completo de cada grupo: el mensaje incluye el sujeto, el emisor y el número de serie del certificado, lo que le indica qué CA y qué plantilla lo generaron.

Auditar: certificados sin la extensión SID

Para los certificados de AD CS, la pregunta es qué plantillas emiten certificados sin la extensión. Tres causas cubren casi todos los casos:

• Plantillas sin conexión («Supply in the request»): la CA no puede saber a qué cuenta se refiere el sujeto, así que no añade el SID.
• CT_FLAG_NO_SECURITY_EXTENSION (0x80000 en msPKI-Enrollment-Flag) en la plantilla, que suprime la extensión. Combinado con la asignación débil, esta era la clase ESC9.
• La extensión deshabilitada en toda la CA mediante DisableExtensionList, que la suprime para todas las plantillas (la clase ESC16).

# Plantillas que suprimen la extensión SID
$tplBase = "CN=Certificate Templates,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)"
Get-ADObject -SearchBase $tplBase -LDAPFilter '(objectClass=pKICertificateTemplate)' -Properties 'msPKI-Enrollment-Flag' |
    Where-Object { $_.'msPKI-Enrollment-Flag' -band 0x80000 } | Select-Object Name

# Supresión en toda la CA (ejecutar contra cada CA): 1.3.6.1.4.1.311.25.2 no debe aparecer
certutil -config "ca01.corp.example\CORP-Issuing-CA" -getreg policy\DisableExtensionList

Para inspeccionar un certificado en un cliente, compruebe directamente sus extensiones:

Get-ChildItem Cert:\LocalMachine\My, Cert:\CurrentUser\My |
    Where-Object { $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.5.5.7.3.2' } |
    Select-Object Subject, Issuer, NotAfter,
        @{n='SidExtension';e={ [bool]($_.Extensions | Where-Object { $_.Oid.Value -eq '1.3.6.1.4.1.311.25.2' }) }}

Auditar: altSecurityIdentities

Las asignaciones explícitas son habituales en tarjetas inteligentes emitidas por sistemas de gestión de tarjetas de terceros, en el inicio de sesión con certificado entre bosques y en cuentas de servicio que se autentican con un certificado. Clasifíquelas:

Get-ADObject -LDAPFilter '(altSecurityIdentities=*)' -Properties altSecurityIdentities, objectClass |
ForEach-Object {
    foreach ($m in $_.altSecurityIdentities) {
        $strength = switch -Regex ($m) {
            '^X509:<I>.+<SR>'     { 'Strong (IssuerSerial)' }
            '^X509:<SKI>'         { 'Strong (SKI)' }
            '^X509:<SHA1-PUKEY>'  { 'Strong (SHA1 public key)' }
            '^X509:<RFC822>'      { 'Weak (email)' }
            '^X509:<I>.+<S>'      { 'Weak (issuer+subject)' }
            '^X509:<S>'           { 'Weak (subject only)' }
            '^Kerberos:'          { 'Kerberos principal mapping' }
            default               { 'Unknown' }
        }
        [pscustomobject]@{ Account = $_.Name; Class = $_.objectClass; Strength = $strength; Mapping = $m }
    }
} | Sort-Object Strength | Format-Table -AutoSize

Audite también quién puede escribir el atributo. El acceso de escritura a altSecurityIdentities en una cuenta privilegiada permite a un atacante asignarle su propio certificado, la clase ESC14. Incluya el atributo en su revisión de ACL de AD y asegúrese de que las cuentas de Tier 0 están protegidas por AdminSDHolder para que no pueda quedar en ellas una ACE delegada.

Aplicar: corregir cada categoría

• Plantillas en línea de AD CS: ya son fuertes una vez que las CA tienen la actualización de mayo de 2022, siempre que no esté activada ninguna de las marcas de supresión. Elimine CT_FLAG_NO_SECURITY_EXTENSION de las plantillas y quite el OID de DisableExtensionList con certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.25.2, seguido de un reinicio del servicio de la CA. Después vuelva a emitir: los certificados existentes no adquieren la extensión, así que provoque la renovación mediante la inscripción automática («Reenroll All Certificate Holders» en la plantilla) o espere a la renovación natural si cae dentro de su plazo.
• Plantillas sin conexión usadas para autenticación: traslade el caso de uso a una plantilla en línea siempre que sea posible. De lo contrario, añada una asignación explícita fuerte por certificado o incluya el SID en la URL del SAN en el momento de la solicitud.
• Asignaciones explícitas débiles: sustitúyalas por X509IssuerSerialNumber. El número de serie debe escribirse con el orden de bytes invertido respecto a como lo muestran los visores de certificados, que es el motivo más común por el que una nueva asignación falla con el evento 39.

# Construir una asignación IssuerSerialNumber a partir de un archivo de certificado
$cert   = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new('C:\temp\jdoe-card.cer')
$bytes  = $cert.GetSerialNumber()          # ya en little-endian (invertido)
$serial = -join ($bytes | ForEach-Object { $_.ToString('x2') })
# Los ejemplos de KB5014754 enumeran los RDN del emisor en orden inverso (DC=... primero)
$rdns   = $cert.Issuer -split ',\s*(?=\w+=)'
[array]::Reverse($rdns)
$issuer = $rdns -join ','
$map    = "X509:<I>$issuer<SR>$serial"
$map    # revisar antes de escribir
# Set-ADUser jdoe -Add @{ altSecurityIdentities = $map }

Pruebe la cadena resultante con una cuenta antes de automatizarla en cientos; el formato del DN del emisor debe coincidir con lo que compara el KDC, y el KB incluye ejemplos resueltos.

• Intune y CA de terceros: añada el SID al SAN como URI (tag:microsoft.com,2022-09-14:sid:<SID>); en los perfiles PKCS y SCEP de Intune, use la variable de SID local. Para las CA de terceros sin esa capacidad, use asignaciones explícitas fuertes o aplique las indicaciones del fabricante sobre KB5014754.
• Cuentas recreadas (evento 41): el certificado antiguo lleva el SID antiguo. Revóquelo e inscriba uno nuevo para la nueva cuenta.

Verificar

Tras las correcciones, la consulta de eventos del paso Medir debe tender a cero para los eventos 39 y 40, y cualquier evento 41 restante debe investigarse individualmente. Compruebe que Schannel no se ha relajado en los servidores:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel' `
    -Name CertificateMappingMethods -ErrorAction SilentlyContinue

Lo esperado es que no exista o que valga 0x18. En la CA, confirme que los certificados de autenticación recién emitidos contienen el OID 1.3.6.1.4.1.311.25.2 volcando uno con certutil -dump <file>.cer. Añada de forma permanente los eventos 39, 40 y 41 a la supervisión de sus controladores de dominio, como se describe en la referencia de ID de eventos de AD: tras la aplicación, una ráfaga de eventos 41 es una señal, no ruido.

Qué se rompe

• Las tarjetas inteligentes de sistemas de gestión de tarjetas de terceros con certificados solo con UPN dejan de iniciar sesión hasta que cada tarjeta tenga una asignación fuerte o se vuelva a emitir.
• 802.1X y VPN con certificados de equipo o de usuario a través de NPS fallan con certificados de plantillas sin conexión o de CA que no son de Microsoft y no llevan el SID. Las caídas de la red inalámbrica tras la aplicación son la queja más habitual.
• El inicio de sesión con certificado entre bosques que depende de la asignación por nombre necesita asignaciones explícitas fuertes en el bosque de recursos.
• Las cuentas eliminadas y recreadas con el mismo nombre no pueden usar los certificados emitidos al objeto antiguo (evento 41).
• Los dispositivos y appliances heredados que se autentican en LDAPS o IIS con certificados de cliente mediante la asignación débil de Schannel fallan cuando CertificateMappingMethods vuelve al valor predeterminado seguro.

Lecturas relacionadas: el tema Servicios de certificados de AD, hardening de Kerberos para el resto de controles del lado del KDC, y cuota de cuentas de equipo, que elimina la fuente fácil de cuentas de equipo controladas por el atacante en la que se basaba Certifried.