证书映射

证书映射涉及将已颁发的证书与其对应的主体关联起来。通俗地说，当用户为自己申请证书时，映射机制能够识别出该证书属于这个特定用户，而不是其他人

CVE-2022-26923又叫Certifried ，他是由 Olivier Lyak 发现的。微软发布了一项新的安全拓展和两个注册表项来修复此漏洞，正确处理证书映射

根据微软的说法，从 2023 年 4 月开始，这两个注册表项的“禁用模式”将不再支持，只有“兼容性”和“完全强制”模式才有效。

要讲证书映射到对象，既可以显示完成，也可以隐式的指定：
显式映射： 帐户的 altSecurityIdentities 属性必须包含证书标识符。进行身份验证时，证书必须由受信任的 CA 签名，并且与 altSecurityIdentities 值匹配
隐式映射： 这是证书 SAN 中包含的信息，用于与 DNS 或 UPN（用户主体名称）字段进行映射

在 Kerberos 身份验证期间，证书映射过程会调用 StrongCertificateBindingEnforcement 注册表项。该注册表项可以等于以下三个值：

0：禁用模式 不执行强证书映射。系统不会检查 szOID_NTDS_CA_SECURITY_EXT 扩展插件，身份验证行为与补丁发布前的状态一致。

1：兼容模式 这是补丁发布后的默认值。KDC（密钥分发中心）会首先检查是否存在显式证书映射（强映射）。如果存在，则允许身份验证；如果不存在，它会检查并验证证书中是否存在安全扩展插件。如果该插件也不存在，但用户账户的创建时间早于证书的颁发时间，则仍可允许身份验证。

2：全强制模式 KDC 会检查是否存在显式证书映射（强映射）。如果存在，则允许身份验证；如果不存在，则检查并验证证书的安全扩展插件。如果该插件不存在，身份验证将被拒绝。

当注册表键值为 0 且证书包含 UPN 值时： （UPN 通常用于用户账户）KDC 会首先尝试将证书映射到具有匹配 userPrincipalName 值的用户。如果无法完成验证，KDC 将搜索具有匹配 sAMAccountName 属性的账户。如果仍未找到，它会尝试在用户名末尾添加 $ 符号再次搜索。因此，带有 UPN 的证书也可以被映射到机器账户（计算机对象）。 （UPN Spoofing就用到了这个特性）

当注册表键值为 0 且证书包含 DNS 值时： （DNS 通常用于机器账户）KDC 会将用户名拆分为两个部分：用户和域名。例如，user.domain.local 会变为 user 和 domain.local。域名部分会针对AD域进行验证，而用户部分则通过在末尾添加 $ 符号并搜索具有相应 sAMAccountName 的账户来进行验证。

当注册表键值为 1 或 2 时： 系统将使用 szOID_NTDS_CA_SECURITY_EXT 安全扩展，通过账户的 objectSid 来进行映射。如果注册表键值设置为 1 且不存在该安全扩展，则映射行为与键值为 0 时相似。

在 Schannel 身份验证期间，证书映射过程涉及 CertificateMappingMethods 注册表项。该注册表项可以具有以下值的组合：

目前的默认值为0x18（0x8+0x10）Schannel不直接支持szOID_NTDS_CA_SECURITY_EXT安全拓展。
但是可以通过S4USelf来“转换”Schannel证书映射为Kerberos证书映射来进行利用此拓展。 之后的映射就按照证书映射 > 2. Kerberos 映射中的过程进行

如果有任何证书的认证问题出现的话， 微软推荐设置CertificateMappingMethods的值为0x1f（旧版本的值）