Certificate Mapping

Understanding certificate mapping is crucial to comprehend ESC6, ESC9, and ESC10 attacks.

Certificate mapping involves associating issued certificates with their respective subjects. In simple terms, when a user requests a certificate for themselves, the mapping enables the identification of the issued certificate as belonging to that specific user and not to another.

In response to CVE-2022–26923 (known as Certifried) , Microsoft has implemented a new security extension for issued certificates, along with two registry keys to properly handle certificate mapping.

  • The szOID_NTDS_CA_SECURITY_EXT certificate extension contains the objectSid (which is a unique identifier in all the Active Directory) of the requester

  • The StrongCertificateBindingEnforcement registry key is used for Kerberos implicit mapping

  • The CertificateMappingMethods registry key is used for Schannel implicit mapping

According to Microsoft, starting on April 2023 the "Disabled mode" of the two registry keys will not be taken into count and only the "Compatibility" and "Full Enforcement" mode will be valid.

Mapping a certificate to an object can be done explicitly or implicitly:

  • For explicit mapping, the altSecurityIdentities attribute of the account must contains the identifier of the certificate. This way, for authentication the certificate must be signed by a trusted CA and match the altSecurityIdentities value

  • For implicit mapping, this is the information contained in the certificate's SAN that are used to map with the DNS or the UPN (userPrincipalName) field

Kerberos mapping

During Kerberos authentication, the certificate mapping process will call the StrongCertificateBindingEnforcement registry key. This key can be equal to three values:

  • 0: no strong certificate mapping is realised. The szOID_NTDS_CA_SECURITY_EXT extension is not check and the authentication behavior is similar to what was done before the patch. This is the "Disabled mode"

  • 1: default value after the patch. The KDC checks if the explicit certificate mapping is present (strong mapping). If yes, the authentication is allowed; if no, it checks if the certificate security extension is present and validate it. If it is not present, the authentication can be allowed if the user account predates the certificate. This is the "Compatibility mode"

  • 2: the KDC checks if the explicit certificate mapping is present (strong mapping). If yes, the authentication is allowed; if no, it checks if the certificate security extension is present and validate it. If it is not present, the authentication is refused. This is the "Full Enforcement mode"

If the registry key value is 0 and the certificate contains a UPN value (typically used for a user account), the KDC will first attempt to map the certificate to a user with a matching userPrincipalName value. If no validation can be performed, the KDC will search for an account with a matching sAMAccountName property. If none can be found, it will retry with a $ at the end of the username. Therefore, a certificate with a UPN can be mapped to a machine account.

If the registry key value is 0 and the certificate contains a DNS value (typically used for a machine account), the KDC splits the username into two parts: the user and the domain. For example, user.domain.local becomes user and domain.local. The domain part is validated against the Active Directory domain, and the user part is validated by adding a $ at the end and searching for an account with a corresponding sAMAccountName.

If the registry key value is 1 or 2, the szOID_NTDS_CA_SECURITY_EXT security extension will be used to map the account using its objectSid. If the registry key is set to 1 and no security extension is present, the mapping behavior is similar to a registry key value of 0.

Schannel mapping

During Schannel authentication, the certificate mapping process involves the CertificateMappingMethods registry key. This key can have a combination of the following values:

  • 0x0001: Subject/issuer explicit mapping

  • 0x0002: Issuer explicit mapping

  • 0x0004: SAN implicit mapping

  • 0x0008: S4USelf implicit Kerberos mapping

  • 0x0010: S4USelf explicit Kerberos mapping

The current default value is 0x18 (0x8 and 0x10). Schannel doesn't directly support the szOID_NTDS_CA_SECURITY_EXT security extension, but it can utilize it by "converting" the Schannel certificate mapping to a Kerberos certificate mapping using S4USelf. The mapping process will then be performed as explained in the Kerberos mapping section.

If any certificate authentication issues arise in an Active Directory environment, Microsoft has officially recommended setting the CertificateMappingMethods value to 0x1f (the old value).

PreviousESC11NextPowerShell

Last updated