# Certificate Mapping

Understanding certificate mapping is crucial to comprehend [ESC6](https://otter.gitbook.io/red-teaming/notes/adcs/esc6), [ESC9](https://otter.gitbook.io/red-teaming/notes/adcs/esc9), and [ESC10](https://otter.gitbook.io/red-teaming/notes/adcs/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](https://support.microsoft.com/en-au/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16), 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).