Mapeo débil de certificados en AD CS

¿Qué es el mapeo débil de certificados?

El mapeo débil de certificados es un riesgo de autenticación basada en certificados en Active Directory, donde un certificado puede asociarse a una cuenta mediante datos de nombre reutilizables en lugar de una vinculación de cuenta fuerte y no reutilizable. En términos concretos de AD CS, el problema aparece cuando el inicio de sesión Kerberos por certificado o la autenticación por certificado de cliente Schannel acepta mapeos basados en nombres como UPN, nombre DNS, dirección de correo electrónico, nombre del sujeto, o emisor y nombre del sujeto combinados.

El riesgo no es que los certificados sean inseguros por defecto. La autenticación basada en certificados es una función de identidad legítima de Windows. El riesgo es que los mapeos basados en nombres pueden ser ambiguos o reutilizables, especialmente cuando los certificados, nombres de cuenta, UPN, nombres alternativos del sujeto o mapeos heredados no vinculan de forma única el certificado a la cuenta prevista. Microsoft abordó esta clase de problemas mediante cambios en la autenticación por certificado en los controladores de dominio de Windows, incluyendo la aplicación del mapeo fuerte de certificados y eventos de auditoría para certificados incompatibles con el modo Full Enforcement.

Este artículo se centra en el comportamiento de mapeo de certificados documentado por Microsoft: la fuerza del mapeo del KDC de Kerberos, altSecurityIdentities, StrongCertificateBindingEnforcement, los CertificateMappingMethods de Schannel, y los eventos operativos que muestran mapeos débiles o fallidos. No trata todos los problemas de AD CS como el mismo problema. Las configuraciones erróneas de plantilla, como el registro SAN arbitrario, están relacionadas, pero el mapeo débil de certificados trata específicamente de cómo se vincula el certificado a una cuenta durante la autenticación.

Para la superficie de ataque de AD CS más amplia, consulte Ataques de certificados ADCS: cómo ESC1 a ESC8 llevan a Domain Admin. Para una ruta de autenticación basada en claves relacionada pero distinta, consulte Shadow Credentials: abuso de msDS-KeyCredentialLink en Active Directory.

Cómo funciona el mapeo de certificados

Inicio de sesión Kerberos por certificado

En la autenticación Kerberos basada en certificados, el Centro de Distribución de Claves (KDC) recibe una solicitud de autenticación por certificado y debe determinar qué cuenta representa el certificado. La documentación de Microsoft PKCA define la fuerza del mapeo de certificados y clasifica los métodos de mapeo como débiles o fuertes. Los mapeos débiles dependen de datos de nombre. Los mapeos fuertes dependen de identificadores más difíciles de reutilizar o directamente vinculados a la cuenta.

Microsoft enumera mapeos débiles del KDC como SAN UPNName, SAN DNSName, altSecurityIdentities emisor y sujeto, altSecurityIdentities solo sujeto, y el campo 822 de altSecurityIdentities. Microsoft enumera mapeos fuertes como el SID, Key Trust, altSecurityIdentities emisor y número de serie, identificador de clave del sujeto, hash SHA1 de la clave pública, y emisor y SID. La diferencia operativa es directa: si el KDC mapea un certificado mediante un método débil, debe seguir buscando un mapeo más fuerte y puede rechazar la solicitud de autenticación si no encuentra ninguno.

Esa distinción explica por qué importa la vinculación fuerte. Un certificado que contiene un nombre reutilizable no es tan fuerte como uno que porta una extensión SID o que está mapeado explícitamente mediante emisor y número de serie, SKI, o hash SHA1 de la clave pública. El trabajo del defensor es eliminar los mapeos débiles evitables y asegurar que la autenticación por certificado solo tenga éxito mediante mapeos fuertes.

Mapeo de certificado de cliente Schannel

Kerberos no es el único componente de Windows que mapea certificados a cuentas. Microsoft documenta que Schannel puede mapear un certificado de cliente proporcionado a una aplicación de servidor a una cuenta de usuario de Windows. El valor de registro CertificateMappingMethods controla qué métodos de mapeo puede usar Schannel. Microsoft indica que los mapeos de certificado Subject/Issuer, Issuer y UPN son débiles y están deshabilitados por defecto en el comportamiento actualizado, mientras que S4U2Self y S4U2Self explícito son fuertes.

Esto importa porque la autenticación por certificado puede aparecer en más de un lugar: inicio de sesión con tarjeta inteligente, PKINIT, autenticación TLS de cliente, aplicaciones web heredadas, portales VPN, flujos NPS/RADIUS y servicios administrativos internos. Un dominio puede tener el KDC endurecido mientras una ruta de aplicación todavía depende de un mapeo Schannel débil. Trate Kerberos y Schannel como superficies de control relacionadas pero distintas.

El papel de las plantillas de AD CS

Las plantillas de certificado de AD CS influyen en qué certificados se pueden emitir y qué datos de identidad contienen. La documentación de Microsoft Defender for Identity describe plantillas de certificado riesgosas donde los usuarios pueden solicitar certificados válidos para usuarios arbitrarios según la configuración de la plantilla. Señala específicamente la opción Supply in the request, EKU de autenticación como Client Authentication o Smartcard Logon, permisos de inscripción demasiado permisivos, falta de aprobación de un gestor, y plantillas publicadas por una CA.

El abuso de plantillas y el mapeo débil no son idénticos. Un problema de plantilla controla si un usuario puede obtener un certificado con afirmaciones de identidad peligrosas. Un problema de mapeo controla si el dominio o la aplicación acepta ese certificado como una cuenta específica. En entornos reales, ambos problemas a menudo se combinan: una plantilla permite que un usuario sin privilegios solicite un certificado con datos de identidad controlados por el atacante, y un mapeo débil hace que esos datos se resuelvan a una cuenta privilegiada.

Por qué el mapeo débil sigue importando tras los cambios de aplicación de Microsoft

El KB5014754 de Microsoft documenta los cambios de autenticación basada en certificados para los controladores de dominio de Windows. Los cambios abordan vulnerabilidades de elevación de privilegios que pueden ocurrir cuando el KDC de Kerberos atiende solicitudes de autenticación por certificado. Microsoft explica que, antes de la actualización de seguridad del 10 de mayo de 2022, la autenticación por certificado no tenía en cuenta un signo de dólar al final de un nombre de máquina, y que los conflictos entre UPN y sAMAccountName introducían vulnerabilidades de suplantación.

Las fechas operativas importantes ya han pasado. Microsoft documentó que los controladores de dominio pasaron al modo Full Enforcement con la actualización de seguridad de Windows de febrero de 2025, salvo que los administradores ya hubieran configurado la clave de registro StrongCertificateBindingEnforcement. Microsoft también documentó que, tras la actualización de seguridad de Windows del 9 de septiembre de 2025, esa clave de registro dejaría de ser compatible. En el modo Full Enforcement, si un certificado no puede mapearse fuertemente, se deniega la autenticación.

Eso no vuelve obsoleto el tema. Cambia lo que los defensores deben auditar. En un entorno parcheado, las dependencias de mapeo débil se convierten en roturas operativas, deuda de seguridad, o una señal de que alguien conservó configuraciones de compatibilidad que deberían eliminarse. En entornos menos consistentes, los niveles de parcheo mixtos de controladores de dominio, el uso heredado de certificados de cliente, aplicaciones basadas en Schannel, despliegues de CA no Microsoft, y mapeos manuales de altSecurityIdentities pueden seguir creando exposición real.

Una auditoría madura debería responder a tres preguntas:

¿Todos los controladores de dominio y servidores AD CS están parcheados con las actualizaciones de seguridad de Microsoft pertinentes?
¿Los inicios de sesión por certificado tienen éxito mediante mapeos fuertes en lugar de mapeos débiles basados en nombres?
¿Alguna aplicación o controlador de dominio depende todavía de un comportamiento de compatibilidad, métodos Schannel débiles, o mapeos manuales heredados?

La cadena de ataque

Un modelo defensivo seguro de cadena de ataque se ve así:

Etapa	Qué sucede	Qué deben verificar los defensores
1. Oportunidad de emisión de certificado	Una plantilla, configuración de CA, o ruta de inscripción permite a un usuario obtener un certificado con datos de identidad que pueden influir en la autenticación.	Revisar los EKU de autenticación, `Supply in the request`, permisos de inscripción, aprobación de un gestor, firmas autorizadas, y si la plantilla está publicada.
2. Mapeo débil de cuenta	El certificado se mapea a una cuenta mediante datos de nombre reutilizables o un mapeo heredado de `altSecurityIdentities` en lugar de una vinculación de cuenta fuerte.	Inventariar métodos de mapeo débil, mapeos manuales, configuraciones de Schannel, y eventos de auditoría del KDC.
3. Autenticación basada en certificado	El certificado se presenta para PKINIT de Kerberos, inicio de sesión con tarjeta inteligente, o una ruta de autenticación de cliente Schannel.	Correlacionar eventos del KDC, comportamiento de Schannel, emisión de la CA, y sensibilidad de la cuenta objetivo.
4. Impacto en privilegios	La cuenta mapeada está privilegiada, tiene derechos de movimiento lateral, o puede alcanzar servicios sensibles.	Revisar cuentas privilegiadas, acceso a servicios, y uso posterior tras la autenticación por certificado.
5. Riesgo de persistencia o repetición	El certificado permanece válido hasta su expiración o revocación, incluso si ocurre un restablecimiento de contraseña.	Revocar certificados donde corresponda, eliminar mapeos débiles, y verificar la vinculación fuerte tras la limpieza.

El artículo evita intencionadamente la sintaxis de herramientas ofensivas. El fallo técnico es claro sin una ruta de explotación lista para copiar y pegar: se emite o acepta un certificado con datos de identidad que no deberían bastar para representar a la cuenta objetivo.

Esta ruta se sitúa junto a otras rutas de escalada de Active Directory. Para rutas de permisos de objeto, consulte Abuso de ACL y DCSync: las rutas silenciosas hacia Domain Admin. Para persistencia Kerberos que no depende de certificados, compare Ataque Golden Ticket: las llaves de su reino y Ataque Silver Ticket: tickets de servicio Kerberos falsificados en Active Directory.

Detección

La detección del mapeo débil de certificados es un problema de correlación. Un solo evento puede mostrar un mapeo de certificado débil o fallido, pero por sí solo no explica cómo se emitió el certificado, si la cuenta es privilegiada, o si una ruta de aplicación heredada sigue dependiendo de un comportamiento débil.

Señal	Fuente	Qué buscar	Limitación
Eventos de mapeo débil o fallido del KDC	Registro del sistema del controlador de dominio tras las actualizaciones pertinentes	Eventos documentados por KB5014754 para certificados sin mapeo fuerte o que no cumplen los criterios de Full Enforcement.	Requiere controladores de dominio actualizados e intentos de autenticación por certificado pertinentes.
Emisión de certificados a identidades sensibles	Registros de seguridad de la CA de AD CS	Certificados emitidos con EKU de autenticación, identidad del solicitante, nombre de la plantilla, datos SAN o de sujeto si se registran.	El registro de la CA debe estar habilitado y conservado; la emisión por sí sola no prueba una autenticación exitosa.
Valores débiles de `altSecurityIdentities`	Inventario de Active Directory	Mapeos manuales basados en nombres como emisor/sujeto, solo sujeto, o mapeos tipo RFC822/correo electrónico.	El mapeo manual puede ser lógica de negocio heredada; validar antes de eliminar.
Configuración de mapeo débil de Schannel	Registro del controlador de dominio y comportamiento de la aplicación	Valores de `CertificateMappingMethods` que reactivan métodos de mapeo débiles.	Los fallos de Schannel pueden afectar a aplicaciones; probar antes de cambiar configuraciones de producción.
Riesgo de plantilla	Revisión de plantillas de AD CS o evaluación de Defender for Identity	`Supply in the request`, EKU de autenticación, permisos de inscripción amplios, falta de aprobación, plantillas publicadas.	El riesgo de plantilla y el riesgo de mapeo están relacionados pero no son idénticos.

Eventos del KDC y señales de Full Enforcement

El KB5014754 de Microsoft añadió eventos de auditoría para identificar certificados incompatibles con el modo Full Enforcement. También documenta que, en modo Full Enforcement, se deniega la autenticación si un certificado no puede mapearse fuertemente. Los controladores de dominio que registran estos eventos le están indicando que un intento de autenticación por certificado es incompatible con la vinculación fuerte, o que todavía existe un mapeo de certificado heredado en una ruta que necesita entender.

No trate estos eventos como ruido. Una advertencia de mapeo débil puede ser un problema de compatibilidad de negocio, una tarea de migración, o una investigación de seguridad. Priorice los eventos que involucren usuarios privilegiados, cuentas de servicio, controladores de dominio, estaciones de trabajo administrativas, servicios VPN/NPS, y certificados emitidos por plantillas que permiten autenticación.

Telemetría de emisión y plantillas de AD CS

La telemetría de emisión de AD CS responde a una pregunta diferente: ¿de dónde vino el certificado? Revise los registros de la CA en busca de certificados emitidos, solicitudes denegadas, nombres de plantilla, cuentas solicitantes, y propiedades del certificado. Cuando la auditoría de servicios de certificación está habilitada, eventos como 4886, 4887, 4888, 4870, 4871, 4872, 4891, 4892, y 4898 proporcionan telemetría concreta de solicitud, emisión, denegación, revocación, publicación de CRL, cambio de configuración, y carga de plantilla. Combine esto con la configuración de la plantilla: EKU de autenticación, sujeto o SAN proporcionado por el solicitante, permisos de inscripción, requisitos de aprobación, firmas autorizadas, y si la plantilla está publicada en alguna CA.

Las evaluaciones de postura de seguridad de Microsoft Defender for Identity pueden ayudar a identificar plantillas que permiten a los usuarios solicitar certificados válidos para usuarios arbitrarios, y plantillas expuestas por las condiciones de CVE-2024-49019. Defender for Identity recomienda específicamente eliminar permisos de inscripción no privilegiados, deshabilitar Supply in the request, aplicar los parches pertinentes para servidores AD CS vulnerables, y usar mitigaciones como la aprobación de un gestor o requisitos de firma cuando corresponda.

Inventario de mapeos manuales

Inventaríe altSecurityIdentities en usuarios, cuentas privilegiadas, y cuentas de servicio. Microsoft documenta varios valores admitidos y clasifica los mapeos según su fuerza. Los débiles se basan en nombres. Los fuertes usan emisor y número de serie, SKI, hash SHA1 de clave pública, mapeo relacionado con SID, o Key Trust.

Tenga cuidado durante la limpieza. Un mapeo débil en un usuario heredado de bajo riesgo puede ser una dependencia operativa, mientras que un mapeo débil en una cuenta privilegiada es un hallazgo de mucho mayor riesgo. El plan de remediación debe reemplazar los mapeos débiles por mapeos fuertes, no simplemente eliminar rutas de autenticación de producción sin migración.

Para una cobertura de registros más amplia en torno a la actividad del controlador de dominio y los objetos de AD, combine este artículo con Supervisión de Active Directory: los identificadores de eventos de seguridad que importan.

Remediación

La remediación debe abordar tanto la emisión de certificados como el mapeo de certificados. Corregir solo un lado deja huecos. Un plan seguro elimina los mapeos débiles innecesarios, actualiza las prácticas de emisión de certificados, valida la aplicación a nivel de controlador de dominio, y prueba las rutas de aplicación que dependen de certificados de cliente.

Aplicar la vinculación fuerte de certificados

Comience por los controladores de dominio. Asegúrese de que todos los controladores de dominio que sirven autenticación por certificado estén parcheados con las actualizaciones de Microsoft pertinentes. En entornos modernos parcheados, Full Enforcement es el estado esperado. Si algún controlador de dominio todavía tiene una configuración de compatibilidad o una ruta de excepción, documente por qué existe, qué certificados dependen de ella, y el plan exacto de retirada.

⚠️

⚠️ Atención: las directrices de Microsoft son claras — el modo Full Enforcement deniega la autenticación cuando un certificado no cumple los criterios de mapeo fuerte. Microsoft también indica que los métodos Schannel débiles están deshabilitados por defecto en el comportamiento actualizado, y que revertir CertificateMappingMethods al valor amplio anterior reactiva métodos de mapeo de certificados débiles. Trate ese cambio de registro como una excepción de compatibilidad, no como un estado de endurecimiento normal.

Reemplazar mapeos débiles

Para los mapeos manuales en altSecurityIdentities, reemplace los mapeos débiles por mapeos fuertes cuando el negocio todavía necesite un mapeo explícito. Microsoft recomienda mapeos fuertes como emisor y número de serie cuando los certificados no pueden reemitirse con la nueva extensión SID. Otras opciones de mapeo fuerte incluyen SKI y el hash SHA1 de clave pública según la documentación de Microsoft sobre fuerza de mapeo.

No deje cuentas privilegiadas mapeadas mediante nombres reutilizables. Los administradores de dominio, administradores de certificados, agentes de inscripción, cuentas de servicio, identidades de emergencia (break-glass), y usuarios de estaciones de trabajo administrativas no deberían depender de una vinculación de identidad débil. Si existe un flujo de certificado privilegiado, debería usar mapeo fuerte, emisión documentada, vidas de certificado cortas cuando corresponda, y supervisión explícita.

Corregir plantillas de certificado y configuraciones de CA

Revise las plantillas que pueden emitir certificados capaces de autenticación. Las recomendaciones de Microsoft Defender for Identity destacan varias mitigaciones concretas para plantillas que permiten solicitudes de certificado para usuarios arbitrarios: deshabilitar Supply in the request, eliminar EKU que permitan autenticación de usuario cuando no sea necesario, eliminar permisos de inscripción demasiado permisivos, exigir aprobación de un gestor, exigir firmas autorizadas, o despublicar plantillas de las CA si no son necesarias.

Revise también configuraciones a nivel de CA como EDITF_ATTRIBUTESUBJECTALTNAME2. Microsoft Defender for Identity indica que, si este indicador está habilitado y una plantilla es válida para autenticación, un atacante puede inscribir un certificado capaz de suplantar cuentas arbitrarias. Esto no es lo mismo que un mapeo débil, pero afecta directamente a si pueden aparecer afirmaciones de identidad peligrosas en los certificados emitidos.

Probar dependencias de Schannel y de aplicaciones

Antes de cambiar la configuración de mapeo de Schannel, identifique las aplicaciones que usan autenticación por certificado de cliente: aplicaciones IIS, VPN, NPS/RADIUS, portales de administración internos, flujos de autenticación de dispositivos, y middleware heredado. Pruébelas con rutas de mapeo fuerte. Si un servicio falla solo cuando se deshabilita el mapeo débil, la solución no es preservar el mapeo débil indefinidamente. La solución es actualizar la emisión de certificados y el mapeo de cuentas para que el servicio se autentique mediante una vinculación fuerte.

Revocar y reemitir cuando sea necesario

Si se emitieron o mapearon débilmente certificados sospechosos, revoque los certificados afectados, publique CRL actualizadas cuando corresponda, y valide que los sistemas dependientes comprueben la revocación. Reemita certificados con soporte de mapeo fuerte o con mapeo manual fuerte explícito. Si la cuenta se usó tras la autenticación por certificado, trate la investigación como un compromiso de identidad: revise cambios de grupo, acceso a servicios, movimiento lateral, y acciones administrativas posteriores.

Validación tras el endurecimiento

La validación debe demostrar que la autenticación sigue funcionando para usuarios legítimos y falla para certificados con vinculación débil.

Paso de validación	Criterio de éxito
Revisión de parches de controladores de dominio	Todos los controladores de dominio que sirven autenticación por certificado están actualizados y operan en el estado de aplicación esperado.
Revisión de eventos del KDC	No quedan advertencias recurrentes de mapeo débil para flujos de autenticación legítimos tras la migración.
Prueba de mapeo fuerte	Los inicios de sesión de certificado de usuario y de equipo tienen éxito mediante extensión SID, Key Trust, o mapeos fuertes explícitos.
Prueba de mapeo débil	Los certificados que solo se mapean mediante métodos débiles basados en nombres fallan bajo condiciones de aplicación.
Revisión de plantillas	Las plantillas capaces de autenticación no permiten afirmaciones de identidad arbitrarias sin controles compensatorios.
Revisión de Schannel	Las aplicaciones que usan certificados de cliente no dependen de métodos de mapeo débiles Subject/Issuer, Issuer, o UPN.
Validación de incidentes	Los certificados revocados o reemplazados ya no se autentican, y se ha revisado la actividad posterior de la cuenta.

Ejecute la validación por fases. Comience con una UO de prueba o un grupo de servicio representativo, y luego amplíe a usuarios privilegiados, estaciones de trabajo administrativas, VPN/NPS, usuarios de tarjeta inteligente, cuentas de servicio, y escenarios de certificado de equipo. No asuma que pasar una prueba de tarjeta inteligente valida cada ruta de autenticación por certificado del dominio.

Cómo detecta EtcSec esta exposición

EtcSec debería tratar el mapeo débil de certificados como una exposición de vinculación de identidad de certificado, no solo como un problema de plantilla de AD CS. Las señales relacionadas incluyen mapeos débiles o heredados de altSecurityIdentities, plantillas de certificado que emiten certificados capaces de autenticación con control peligroso del sujeto, permisos de inscripción demasiado amplios, configuraciones de CA que permiten SAN proporcionados por la solicitud, y configuraciones de compatibilidad del controlador de dominio que preservan un comportamiento de mapeo débil.

La plataforma también puede conectar esta exposición con rutas de ataque adyacentes: plantillas de AD CS que permiten identidades arbitrarias, principales que pueden modificar las ACL de plantillas de certificado, usuarios privilegiados que dependen de mapeos de certificado débiles, y falta de supervisión del controlador de dominio para eventos de autenticación por certificado. Esa es la vista operativa útil. Un mapeo débil es peligroso porque se sitúa entre la emisión del certificado y la autenticación de la cuenta.

Controles relacionados

Control	Por qué importa
Full Enforcement para autenticación por certificado	Deniega la autenticación cuando el certificado no puede mapearse fuertemente.
Rutas de vinculación fuerte de certificados	Reemplaza los mapeos basados en nombres reutilizables por mapeos manuales fuertes de `altSecurityIdentities` como emisor/número de serie, SKI, o hash SHA1 de clave pública, o por otras rutas fuertes como extensión SID, Key Trust, o emisor/SID.
Endurecimiento de plantillas de AD CS	Impide que usuarios no confiables obtengan certificados capaces de autenticación para identidades arbitrarias.
Revisión del mapeo de Schannel	Encuentra rutas de aplicación que todavía dependen de un mapeo de certificado débil.
Supervisión de emisión de la CA	Muestra qué certificados se emitieron, a quién, desde qué plantilla, y con qué datos de identidad.
Revisión de certificados de cuentas privilegiadas	Asegura que los administradores y cuentas de servicio sensibles no dependan de una vinculación de identidad débil.
Validación de revocación	Confirma que los certificados sospechosos o reemplazados ya no se autentican.

El mapeo débil de certificados no es una casilla aislada. Forma parte de la seguridad de AD CS, la autenticación Kerberos, el ciclo de vida de las cuentas, y la autenticación de aplicaciones. Si está construyendo una revisión completa, combine este artículo con Cómo auditar la seguridad de Active Directory: checklist práctica para equipos internos y Ataques de delegación Kerberos: de la delegación no restringida al abuso de RBCD para comprender rutas de identidad adyacentes.

Mapeo débil de certificados en AD CS: por qué importa la vinculación fuerte