Case Summary: 802.1X Wi-Fi 证书认证失败 — Mac 设备 Strong Certificate Mapping 不满足导致 KDC_ERR_CERTIFICATE_MISMATCH

Product/Service: Windows NPS (Network Policy Server) / Active Directory Certificate Services (ADCS) / 802.1X Wireless / Kerberos Strong Certificate Mapping

1. 症状 (Symptoms)

• Mac 用户使用 MDM（第三方 Jamf）下发的用户证书连接企业 802.1X Wi-Fi 时认证失败，无法连接无线网络
• NPS 服务器端 Kerberos 日志显示明确错误：

  KerberosV5:KRB_ERROR - KDC_ERR_CERTIFICATE_MISMATCH (66)
  

• EAP-TLS 认证日志显示：

  CheckUserName() - QuerySecurityContextToken failed and returned 0x8009030b
  MakeReplyMessage() - State change to SentFinished. Error: 0x8009030b
  

• 问题影响所有通过 MDM 下发证书连接 WiFi 的 Mac 用户
• Windows 域成员设备通过同一 WiFi 认证正常

2. 背景 (Background / Environment)

• 客户端：macOS 设备，由第三方 MDM 平台 (Jamf) 管理
• 证书签发：MDM 通过 SCEP 向 Windows CA (ADCS) 申请用户证书
• 证书模板：使用 Supply in the Request 模式（非 Build from AD Information）
• 认证架构：

  Mac Client → Wireless AP (802.1X) → NPS Server (RADIUS) → Domain Controller (KDC)
  

• AD 域：CONTOSO.LOCAL
• NPS 服务器：Windows Server，作为 RADIUS 服务器处理 802.1X 认证
• 认证方法：EAP-TLS（基于客户端证书的 TLS 相互认证）
• KB5014754 影响：域控已部署 2022 年 5 月安全更新，Kerberos 强证书映射（Strong Certificate Mapping）进入 Enforcement 模式

3. Troubleshooting 过程 (Investigation & Troubleshooting)

Step 1: 初始情况确认

做了什么：与客户电话沟通，确认问题环境和 RADIUS 基础架构。

发现了什么：

• 客户端是 Mac OS，无法在设备端直接 troubleshoot
• RADIUS 服务器是 Windows NPS（可以从 NPS 端排查）
• 客户曾因同一问题开过另一个 case

得出了什么结论：排查重心放在 NPS 服务器端，需要采集 NPS 上的 EAP/Schannel/Kerberos 相关日志。

Step 2: NPS 日志采集

做了什么：向客户提供 NPS 日志采集脚本（npstrace.bat），包含以下 ETL 追踪 providers：

同时启用了：

• Schannel EventLogging = 7（详细日志）
• CAPI2 Operational Log（证书链验证日志）
• NPS Audit Policy（Security Event Log）

发现了什么：客户在 NPS 服务器上运行脚本，在 2/6 15:03-15:04 时间窗口复现了问题，使用账号 john.doe@contoso.com。

得出了什么结论：日志采集成功，可以开始分析认证失败的完整链路。

Step 3: EAPHost 日志分析 — 定位 Schannel 映射失败

做了什么：分析 NPS 服务器上的 EAPHost ETL 日志（net_eaphost.etl），追踪 EAP-TLS 认证的完整流程。

发现了什么：

3a. EAP-TLS 会话建立阶段（正常）：

[5] 0280.2774::02/06/26-15:03:34.2058188 [EapHost/Analytic]
  Session(2774974), Identity(john.doe@contoso.com)

[5] 0280.2774::02/06/26-15:03:34.2058192 [host] AuthenticatorHost
  EapHost::Authenticator::Host::IdentityResponse()
  Session(2774974), Identity(john.doe@contoso.com)

[5] 0280.2774::02/06/26-15:03:34.2058278 [EapHost/Analytic]
  flags(0x400), identity(CONTOSO\john.doe), # of attributes(19),
  conn data 0 bytes, max send packet 1496 bytes, init packet id(48)

[5] 0280.2774::02/06/26-15:03:34.2058282 [runtime]
  LegacyEapMethodAuthenticatorruntime
  EapLm::Authenticator::LegacyEapMethodRuntime::BeginSession()
  flags(0x400), identity(CONTOSO\john.doe), # of attributes(19)

[5] 0280.2774::02/06/26-15:03:34.2058397 [eaptls]
  EapTlsBegin(CONTOSO\john.doe)

分析：EAP-TLS 会话正常建立，NPS 成功识别客户端身份为 CONTOSO\john.doe，开始 TLS 握手。

3b. TLS 握手完成后的用户映射阶段（失败）：

[4] 0280.1B04::02/06/26-15:03:42.9515746 [eaptls]
  EapTlsMakeMessage(contoso\john.doe)

[4] 0280.1B04::02/06/26-15:03:42.9675083 [eaptls]
  CheckUserName() - QuerySecurityContextToken failed
  and returned 0x8009030b

[4] 0280.1B04::02/06/26-15:03:42.9675125 [eaptls]
  MakeAlert(49, Manual)

[4] 0280.1B04::02/06/26-15:03:42.9675134 [eaptls]
  MakeReplyMessage() - State change to SentFinished.
  Error: 0x8009030b

分析：

• 0x8009030b = SEC_E_NO_CREDENTIALS — Schannel 在尝试将 TLS 会话映射到 Windows 用户安全上下文时失败
• MakeAlert(49, Manual) — TLS Alert 49 = access_denied，NPS 向客户端发送 TLS 拒绝
• 本质：“证书 → AD 账户”的映射失败，Schannel 无法通过证书获取对应用户的 token
• 时间差：从 EapTlsBegin (15:03:34) 到 CheckUserName 失败 (15:03:42)，TLS 握手本身耗时约 8 秒

Step 4: Schannel/SSL 日志分析 — 定位 DC 映射失败

做了什么：分析 Schannel 相关的 SSL mapper 日志（ds_security.etl），追踪证书到 AD 用户的映射调用链。

发现了什么：

[4] 02D0.158C::02/06/26-15:03:42.9538250 [release]
  mapper_cpp596 SslTryS4U2Self()
  - Looking for UPN name john.doe@contoso.com

[1] 02D0.158C::02/06/26-15:03:42.9617565 [release]
  mapper_cpp2767 SslMapCertAtDC()
  - Remote call to DC to do the mapping

[1] 02D0.158C::02/06/26-15:03:42.9662376 [release]
  mapper_cpp2906 SslMapCertAtDC()
  - SslMapCertAtDC returned sub-status 0xc000006d

[1] 02D0.158C::02/06/26-15:03:42.9662389 [release]
  mapper_cpp3542 SslRemoteMapCredential()
  - CertMapping: SslMapCertAtDC Failed with 0xc000006d

分析：

• SslTryS4U2Self()：NPS 使用证书中的 UPN (john.doe@contoso.com) 发起 S4U2Self 请求 — 即”无密码登录”代理认证
• SslMapCertAtDC()：NPS 向 DC 发起远程调用，请求 DC 验证该证书是否能映射到对应的 AD 用户
• 0xc000006d = STATUS_LOGON_FAILURE — DC（KDC）拒绝了这次映射，认为证书不能有效代表该用户
• 从调用到返回仅 ~12ms (9617565 → 9662376)，说明 DC 快速拒绝（非超时），映射条件检查未通过

Step 5: Kerberos 网络包分析 — 确认 KDC 拒绝原因

做了什么：分析网络抓包（nettrace.etl），查看 NPS 与 DC 之间的 Kerberos 交互。

发现了什么：

15:03:42.9550023  10.1.1.53 → 10.1.1.56  KerberosV5
  KerberosV5:AS Request
  Cname: john.doe@contoso.com
  Realm: CONTOSO.LOCAL
  Sname: krbtgt/CONTOSO.LOCAL

15:03:42.9564333  10.1.1.56 → 10.1.1.53  KerberosV5
  KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25)

15:03:42.9577689  10.1.1.53 → 10.1.1.56  KerberosV5
  KerberosV5:TGS Request
  Realm: CONTOSO.LOCAL
  Sname: nps-srv01$

15:03:42.9615277  10.1.1.56 → 10.1.1.53  KerberosV5
  KerberosV5:KRB_ERROR - KDC_ERR_CERTIFICATE_MISMATCH (66)

分析：

• AS Request → KDC_ERR_PREAUTH_REQUIRED (25)：正常流程，KDC 要求预认证
• TGS Request → KDC_ERR_CERTIFICATE_MISMATCH (66)：关键错误！ KDC 在处理基于证书的 TGS 请求时，判定证书与 AD 用户不匹配
• Error 66 的含义：KDC 执行 strong certificate mapping 检查时，证书中没有找到可用于强映射的标识（SID OID 扩展或 SAN URI），且 AD 用户对象上没有配置 altSecurityIdentities 显式映射
• 10.1.1.53 = NPS 服务器，10.1.1.56 = 域控（KDC）
• 整个 Kerberos 交互从请求到拒绝仅 ~6.5ms，说明 KDC 快速做出了映射失败的判断

Step 6: CAPI2 证书链验证 — 排除信任问题

做了什么：检查 CAPI2 Operational Event Log，验证客户端证书的信任链状态。

发现了什么：证书链验证通过，Root CA → Intermediate CA → User Cert 的信任链完整，证书未被吊销。

得出了什么结论：问题不在证书信任层面，而是在证书内容到 AD 用户的映射层面。CAPI2 验证通过但 Schannel 映射失败，明确锁定为 strong certificate mapping 问题。

Step 7: UPN 一致性验证

做了什么：要求客户在 AD 中核实用户 UPN 是否与证书中的 UPN 一致。

发现了什么：客户确认 AD 中 john.doe 用户的 userPrincipalName 为 john.doe@contoso.com，与证书 SAN 中的 UPN 完全一致。

得出了什么结论：UPN 匹配但映射仍然失败 → 证书只有 UPN 弱映射，不满足 KB5014754 强映射要求。需要 AD 团队介入检查 ADCS 证书模板和强映射配置。

Step 8: AD 团队介入 — 证书模板与强映射分析（关键突破）

做了什么：Escalation 到 AD 团队（Windows Active Directory Support Escalation Engineer），安排线上会议分析证书内容和 ADCS 配置。

发现了什么：

8a. 证书模板问题：

• 客户使用的证书模板为 “Supply in the Request”，而非 “Build from AD Information”
• “Supply in the Request” 模式下，请求者（MDM 平台）自行提供 Subject/SAN 信息
• CA 不会自动在证书中注入 AD SID

8b. Strong Mapping 条件分析：

8c. 为什么 Mac 不能用 Build from AD Information：

• Mac 非域成员，证书请求由 MDM 平台代理提交
• 使用 Build from AD Information 模板时，CA 会从 AD 中拉取请求者（MDM 代理机器）的信息
• 导致证书 Subject 变成 MDM 代理平台的计算机 FQDN，而非用户信息

得出了什么结论：

• 根因确认：证书不包含 AD SID，无法满足 Kerberos 强证书映射，KDC 返回 CERTIFICATE_MISMATCH
• 这不是配置错误，而是架构层面的限制：第三方 MDM + Supply in the Request 模板 + Strong Mapping Enforcement 三者组合导致

Step 9: 解决方案讨论与厂商确认

做了什么：与客户、MDM 厂商（Jamf 服务商）多方讨论可行方案。

发现了什么：

方案 A — altSecurityIdentities 显式映射：

• 在每个 Mac 用户的 AD 对象上配置 altSecurityIdentities 属性
• 格式推荐：X509:<I>IssuerName<SR>SerialNumber
• ✅ 可行，但需逐个用户配置，维护成本高
• 建议通过脚本或自动化流程批量维护，纳入用户新增/证书更新的标准流程

方案 B — 咨询 MDM 厂商是否支持 SID 注入：

• Microsoft Intune 已原生支持通过 OnPremisesSecurityIdentifier 变量在 SCEP 证书 SAN 中注入用户 SID
• Jamf 服务商确认：Jamf 自 2025 年起已更新支持 Active Directory Strong Certificate Mapping Requirements
• 服务商在自己的环境测试成功，证书包含了指定的强映射内容

方案 C — 更理想的架构建议：

• 最佳实践是在证书签发阶段即完成 SID 注入，而非在 AD 侧事后补充
• 如果可能，切换到支持 SID 注入的 MDM 方案

得出了什么结论：客户选择在 Jamf 端配置 strong certificate mapping 支持（方案 B），作为长期解决方案。同时可用 altSecurityIdentities（方案 A）作为过渡。

4. Blockers 与解决 (Blockers & How They Were Resolved)

5. 根因与解决方案 (Root Cause & Resolution)

Root Cause

Mac 设备通过第三方 MDM (Jamf) 使用 Supply in the Request 证书模板向 Windows CA 申请用户证书。该模板签发的证书不包含 AD SID（既无 SID OID 扩展 1.3.6.1.4.1.311.25.2，也无 SAN URI tag:microsoft.com,2022-09-14:sid:<SID>）。

在 KB5014754 Strong Certificate Mapping Enforcement 模式下，域控（KDC）要求证书必须满足强映射条件才能通过认证。由于证书仅包含 UPN（属于弱映射），KDC 拒绝映射并返回 KDC_ERR_CERTIFICATE_MISMATCH (66)，导致 NPS 侧 Schannel 返回 SEC_E_NO_CREDENTIALS (0x8009030b)，EAP-TLS 认证失败，WiFi 连接被拒。

失败链路：

Mac cert (no SID) → NPS EAP-TLS → Schannel SslTryS4U2Self()
→ SslMapCertAtDC() → DC/KDC Strong Mapping Check → FAIL
→ KDC_ERR_CERTIFICATE_MISMATCH (66)
→ STATUS_LOGON_FAILURE (0xc000006d)
→ SEC_E_NO_CREDENTIALS (0x8009030b)
→ TLS Alert 49 (access_denied)
→ WiFi connection rejected

Resolution

客户采用在 Jamf 端配置 Strong Certificate Mapping 支持作为最终解决方案：

1. Jamf 端配置：MDM 服务商按照 Jamf 官方文档配置证书模板，在 SCEP 证书中注入满足 Strong Mapping 要求的标识信息
2. 测试验证：服务商先在独立测试环境验证证书内容符合要求
3. 逐步部署：在客户生产环境中分批部署新配置的证书模板
4. 验证认证：Mac 用户重新申请证书后，802.1X WiFi 认证成功

Workaround

对于无法立即更新 MDM 配置的过渡期间，可使用 altSecurityIdentities 显式映射：

# 1. 从用户证书获取 Issuer 和 SerialNumber
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\certs\user.cer")
$serial = $cert.SerialNumber
$issuer = $cert.Issuer

# 2. 在 AD 用户对象上设置显式映射
Set-ADUser -Identity "john.doe" -Add @{
    altSecurityIdentities = "X509:<I>$issuer<SR>$serial"
}

# 3. 验证设置
Get-ADUser -Identity "john.doe" -Properties altSecurityIdentities |
    Select-Object -ExpandProperty altSecurityIdentities

⚠️ 注意：每次证书更新/重签后 SerialNumber 会变，需同步更新映射。建议将此操作纳入自动化流程。

6. 经验教训 (Lessons Learned)

技术知识

• Strong vs Weak Mapping 的关键区别：
  • 强映射 (Strong)：基于 SID（OID/SAN URI）、Issuer+SerialNumber、SKI、SHA1 Public Key — KDC 能唯一确认证书对应的 AD 对象
  • 弱映射 (Weak)：基于 UPN 或 Email — 存在仿冒风险，Enforcement 模式下被拒绝
• KB5014754 时间线必须熟记：2025-09-09 起完全强制，注册表回退选项彻底移除
• Mac + 第三方 MDM 是 Strong Mapping 的高发场景：因为 MDM 代理申请的证书天然不包含 SID，必须额外配置

排查方法

• NPS 日志采集三件套：EAPHost ETL + Schannel/SSL mapper ETL + Kerberos 网络包，三者结合可覆盖 802.1X 证书认证的全链路
• 排查顺序：先看 EAPHost 确认失败点 → 再看 Schannel mapper 确认映射调用链 → 最后看 Kerberos 包确认 KDC 拒绝原因
• 关键错误码对照表： | 错误码 | 含义 | 在哪一层 | |——–|——|———| | KDC_ERR_CERTIFICATE_MISMATCH (66) | 证书不匹配，强映射失败 | Kerberos / KDC | | 0xc000006d (STATUS_LOGON_FAILURE) | 登录失败 | Schannel → DC 映射 | | 0x8009030b (SEC_E_NO_CREDENTIALS) | 无法获取用户凭据 | EAP-TLS / Schannel | | TLS Alert 49 | access_denied | TLS 层 |

流程改进

• 遇到 802.1X 证书认证失败、且客户端非 Windows 域成员时，应优先询问证书模板类型（Supply in the Request vs Build from AD Information），可以快速判断是否为 Strong Mapping 问题
• 第三方 MDM 场景应第一时间确认 MDM 厂商是否支持 SID 注入，避免走弯路

预防措施

• 部署 802.1X 证书认证方案时，设计阶段就要考虑 KB5014754 强映射要求
• 对于跨平台（Mac/iOS/Android）环境，选择支持 SID 注入的 MDM 平台（如 Intune、Jamf 2025+）
• 如果使用 altSecurityIdentities，务必自动化维护流程，避免证书更新后映射失效

7. 参考文档 (References)

• KB5014754: Certificate-based authentication changes on Windows domain controllers — 强映射变更时间线、注册表配置和故障排查的官方 KB
• Support Tip: Implementing strong mapping in Microsoft Intune certificates — Intune 通过 SCEP 实现 SID 注入的完整指南
• Preview of SAN URI for Certificate Strong Mapping for KB5014754 — SAN URI 强映射格式说明和示例 INF 文件

English Version

Case Summary: 802.1X Wi-Fi Certificate Auth Failure — Mac Device Strong Certificate Mapping Failure Causing KDC_ERR_CERTIFICATE_MISMATCH

Product/Service: Windows NPS (Network Policy Server) / Active Directory Certificate Services (ADCS) / 802.1X Wireless / Kerberos Strong Certificate Mapping

1. Symptoms

• Mac users connecting to enterprise 802.1X Wi-Fi using MDM-deployed (third-party Jamf) user certificates fail authentication
• NPS server Kerberos logs show explicit error:

  KerberosV5:KRB_ERROR - KDC_ERR_CERTIFICATE_MISMATCH (66)
  

• EAP-TLS authentication logs show:

  CheckUserName() - QuerySecurityContextToken failed and returned 0x8009030b
  MakeReplyMessage() - State change to SentFinished. Error: 0x8009030b
  

• Issue affects all Mac users connecting via MDM-deployed certificates
• Windows domain-joined devices authenticate successfully through the same WiFi

2. Background / Environment

• Clients: macOS devices managed by third-party MDM platform (Jamf)
• Certificate Issuance: MDM requests user certificates from Windows CA (ADCS) via SCEP
• Certificate Template: Uses Supply in the Request mode (not Build from AD Information)
• Authentication Architecture:

  Mac Client → Wireless AP (802.1X) → NPS Server (RADIUS) → Domain Controller (KDC)
  

• AD Domain: CONTOSO.LOCAL
• NPS Server: Windows Server acting as RADIUS server for 802.1X authentication
• Auth Method: EAP-TLS (certificate-based mutual TLS authentication)
• KB5014754 Impact: Domain controllers have deployed the May 2022 security update; Kerberos Strong Certificate Mapping in Enforcement mode

3. Investigation & Troubleshooting

Step 1: Initial Situation Assessment

Action: Phone call with customer to confirm environment and RADIUS infrastructure.

Finding:

• Client is macOS — cannot troubleshoot directly on the device
• RADIUS server is Windows NPS — can investigate from the NPS side
• Customer had opened a previous case for the same issue

Conclusion: Focus investigation on NPS server side; need to collect EAP/Schannel/Kerberos traces.

Step 2: NPS Trace Collection

Action: Provided NPS trace collection script (npstrace.bat) covering:

Also enabled Schannel verbose logging (EventLogging=7) and CAPI2 Operational Log.

Finding: Customer reproduced the issue on 2/6 at 15:03-15:04 using account john.doe@contoso.com.

Conclusion: Traces collected successfully; ready for full authentication chain analysis.

Step 3: EAPHost Log Analysis — Locating Schannel Mapping Failure

Action: Analyzed EAPHost ETL traces (net_eaphost.etl) for the complete EAP-TLS flow.

Finding:

3a. EAP-TLS session establishment (successful):

[EapHost/Analytic] Session(2774974), Identity(john.doe@contoso.com)
[eaptls] EapTlsBegin(CONTOSO\john.doe)

3b. Post-TLS-handshake user mapping (FAILED):

[eaptls] EapTlsMakeMessage(contoso\john.doe)
[eaptls] CheckUserName() - QuerySecurityContextToken failed
         and returned 0x8009030b
[eaptls] MakeAlert(49, Manual)
[eaptls] MakeReplyMessage() - State change to SentFinished.
         Error: 0x8009030b

Conclusion:

• 0x8009030b (SEC_E_NO_CREDENTIALS) — Schannel failed to map the TLS session to a Windows user security context
• MakeAlert(49) — TLS Alert access_denied sent to client
• Root issue: Certificate → AD account mapping failed

Step 4: Schannel/SSL Log Analysis — DC Mapping Rejection

Action: Analyzed Schannel SSL mapper logs (ds_security.etl).

Finding:

SslTryS4U2Self() - Looking for UPN name john.doe@contoso.com
SslMapCertAtDC() - Remote call to DC to do the mapping
SslMapCertAtDC() - returned sub-status 0xc000006d
SslRemoteMapCredential() - CertMapping: SslMapCertAtDC Failed with 0xc000006d

Conclusion:

• SslTryS4U2Self(): NPS initiated S4U2Self using the certificate’s UPN
• SslMapCertAtDC(): NPS called DC to validate the certificate-to-user mapping
• 0xc000006d (STATUS_LOGON_FAILURE): DC rejected — certificate cannot represent this user
• Response time ~12ms indicates quick rejection (not timeout); mapping condition check failed immediately

Step 5: Kerberos Packet Analysis — Confirming KDC Rejection Reason

Action: Analyzed network capture (nettrace.etl) for Kerberos exchanges between NPS and DC.

Finding:

10.1.1.53 → 10.1.1.56  AS Request  Cname: john.doe@contoso.com  Realm: CONTOSO.LOCAL
10.1.1.56 → 10.1.1.53  KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25)
10.1.1.53 → 10.1.1.56  TGS Request  Sname: nps-srv01$
10.1.1.56 → 10.1.1.53  KRB_ERROR - KDC_ERR_CERTIFICATE_MISMATCH (66)

Conclusion:

• Error 25 (PREAUTH_REQUIRED) is normal flow
• Error 66 (CERTIFICATE_MISMATCH) is the critical failure: KDC’s strong mapping check found no valid strong identifier in the certificate
• Entire Kerberos exchange took ~6.5ms — KDC rejected instantly

Step 6: CAPI2 Certificate Chain Validation — Ruling Out Trust Issues

Action: Checked CAPI2 Operational Event Log for certificate chain status.

Finding: Chain validation passed — Root CA → Intermediate CA → User Cert trust chain intact, not revoked.

Conclusion: Not a trust issue. Certificate is trusted but cannot be mapped to an AD user under strong mapping requirements.

Step 7: UPN Consistency Check

Action: Customer verified AD user’s UPN matches the certificate UPN.

Finding: AD userPrincipalName = john.doe@contoso.com — exact match with certificate SAN UPN.

Conclusion: UPN matches but mapping still fails → certificate only has UPN-based weak mapping, which doesn’t satisfy KB5014754 strong mapping. Escalation to AD team required.

Step 8: AD Team Analysis — Certificate Template & Strong Mapping (Key Breakthrough)

Action: Escalated to AD team (Support Escalation Engineer). Joint meeting to analyze certificate content and ADCS configuration.

Finding:

8a. Certificate Template:

• Template uses “Supply in the Request” — MDM provides Subject/SAN
• CA does not auto-inject AD SID into the certificate

8b. Strong Mapping Conditions:

8c. Why Mac Can’t Use Build from AD Information:

• Mac is not domain-joined; MDM agent submits cert request on behalf
• CA pulls the requesting machine’s info from AD → cert Subject becomes MDM proxy’s FQDN, not user info

Conclusion: Root cause confirmed — certificate lacks AD SID, fails Kerberos strong mapping, KDC returns CERTIFICATE_MISMATCH. This is an architectural limitation of third-party MDM + Supply in Request + Strong Mapping Enforcement.

Step 9: Solution Discussion & Vendor Confirmation

Action: Multi-party discussion with customer, MDM vendor (Jamf service provider).

Finding:

• Option A: altSecurityIdentities explicit mapping (per user, high maintenance)
• Option B: Jamf service provider confirmed Jamf supports AD Strong Certificate Mapping since 2025, tested successfully
• Option C: Switch to Intune (native SID injection via OnPremisesSecurityIdentifier variable)

Conclusion: Customer chose Option B — configure strong mapping support in Jamf as the long-term solution. Option A available as interim workaround.

4. Blockers & How They Were Resolved

5. Root Cause & Resolution

Root Cause

Mac devices request user certificates from Windows CA via third-party MDM (Jamf) using the Supply in the Request certificate template. This template does not include AD SID in the issued certificate (neither SID OID extension 1.3.6.1.4.1.311.25.2 nor SAN URI tag:microsoft.com,2022-09-14:sid:<SID>).

Under KB5014754 Strong Certificate Mapping Enforcement, the KDC requires certificates to satisfy strong mapping conditions. Since the certificate only contains UPN (classified as weak mapping), the KDC rejects the mapping with KDC_ERR_CERTIFICATE_MISMATCH (66), causing NPS Schannel to return SEC_E_NO_CREDENTIALS (0x8009030b), EAP-TLS authentication failure, and WiFi connection rejection.

Failure chain:

Mac cert (no SID) → NPS EAP-TLS → Schannel SslTryS4U2Self()
→ SslMapCertAtDC() → DC/KDC Strong Mapping Check → FAIL
→ KDC_ERR_CERTIFICATE_MISMATCH (66)
→ STATUS_LOGON_FAILURE (0xc000006d)
→ SEC_E_NO_CREDENTIALS (0x8009030b)
→ TLS Alert 49 (access_denied)
→ WiFi connection rejected

Resolution

Customer adopted configuring Strong Certificate Mapping support in Jamf as the final solution:

1. Jamf Configuration: MDM service provider configured the certificate template per Jamf’s official documentation to inject strong mapping identifiers into SCEP certificates
2. Testing: Provider verified in isolated test environment that certificate content meets requirements
3. Staged Deployment: Rolled out new certificate template configuration in production
4. Verification: Mac users re-enrolled certificates; 802.1X WiFi authentication succeeded

Workaround

For the transition period, altSecurityIdentities explicit mapping can be used:

# Get cert Issuer and SerialNumber
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\certs\user.cer")
$serial = $cert.SerialNumber
$issuer = $cert.Issuer

# Set explicit mapping on AD user object
Set-ADUser -Identity "john.doe" -Add @{
    altSecurityIdentities = "X509:<I>$issuer<SR>$serial"
}

⚠️ Must be updated when certificates are renewed (SerialNumber changes). Automate this process.

6. Lessons Learned

Technical Knowledge

• Strong vs Weak Mapping: SID-based (OID/SAN URI), Issuer+Serial, SKI, SHA1 Public Key = Strong; UPN/Email = Weak. Enforcement mode rejects weak mapping
• KB5014754 Timeline: Full enforcement since 2025-09-09; registry rollback removed entirely
• Mac + Third-party MDM is a high-risk scenario for Strong Mapping failures — certificates inherently lack SID

Troubleshooting Methodology

• NPS log trio: EAPHost ETL + Schannel/SSL mapper ETL + Kerberos network capture = complete 802.1X cert auth coverage
• Analysis order: EAPHost (locate failure) → Schannel mapper (trace mapping call chain) → Kerberos packets (confirm KDC rejection)
• Key error code map: | Error | Meaning | Layer | |——-|———|——-| | KDC_ERR_CERTIFICATE_MISMATCH (66) | Cert doesn’t match; strong mapping failed | Kerberos / KDC | | 0xc000006d (STATUS_LOGON_FAILURE) | Logon failure | Schannel → DC mapping | | 0x8009030b (SEC_E_NO_CREDENTIALS) | Cannot obtain user credentials | EAP-TLS / Schannel | | TLS Alert 49 | access_denied | TLS layer |

Process Improvement

• For 802.1X cert auth failures with non-Windows clients, ask about certificate template type first (Supply in Request vs Build from AD Info) to quickly identify Strong Mapping issues
• For third-party MDM scenarios, confirm vendor SID injection support early to avoid dead-end investigations

Prevention

• Consider KB5014754 strong mapping requirements during design phase of 802.1X cert auth deployments
• For cross-platform environments (Mac/iOS/Android), choose MDM platforms with SID injection support (Intune, Jamf 2025+)
• If using altSecurityIdentities, automate maintenance to prevent mapping expiry after cert renewal

7. References

• KB5014754: Certificate-based authentication changes on Windows domain controllers — Official KB with strong mapping timeline, registry configs, and troubleshooting
• Support Tip: Implementing strong mapping in Microsoft Intune certificates — Intune SCEP SID injection guide
• Preview of SAN URI for Certificate Strong Mapping for KB5014754 — SAN URI strong mapping format and example INF files