Skip to main content
Question

October 2026 Windows update breaks Jamf SCEP Proxy + NDES: Event 60 rejects SID in SAN URI

  • October 25, 2026
  • 2 replies
  • 22 views
Forum|alt.badge.img+3

After the October 13, 2026 cumulative update, our on-prem NDES started rejecting SCEP requests from Jamf Pro SCEP Proxy (Jamf Cloud). Each failure logs:

Application log, source NetworkDeviceEnrollmentService, Event ID 60 (EVENT_MSCEP_REJECTED_SID_IN_SAN_URI): “…rejected a certificate request because the Subject Alternative Name (SAN) extension contained a URI entry with a security identifier (SID). SID values must not be present in SCEP request SAN entries when no custom policy module is registered to validate them.”

Our profiles follow Jamf’s strong-mapping guidance: a URI SAN of tag:microsoft.com,2022-09-14:sid:$EXTENSIONATTRIBUTE_#, with the EA pulling objectSid. That’s exactly what NDES now refuses.

  • Environment: Windows Server 2019 NDES, AD CS, NPS for EAP-TLS Wi-Fi
  • Trigger: KB5126651 (the Server 2019 October update). Uninstalling it restored enrollment immediately.
  • Impact: existing certs keep working, but new enrollments and renewals fail.

Microsoft appears to accept a SID in a SCEP request only when a registered NDES policy module validates it, the way the Intune Certificate Connector does. Jamf SCEP Proxy has no equivalent, so Jamf’s documented method seems to conflict with this update.

Is anyone else seeing Event 60 on a patched NDES? Has anyone found a supported workaround or an override?

Jamf’s strong-mapping article: https://learn.jamf.com/en-US/bundle/technical-articles/page/Supporting_Microsoft_Active_Directory_Strong_Certificate_Mapping_Requirements.html

2 replies

justin_smith
Forum|alt.badge.img+8

This looks like a collision between two Microsoft requirements rather than a profile mistake. Jamf's strong-mapping guidance is to put the objectSid in the SAN URI — tag:microsoft.com,2022-09-14:sid:<SID> — because for SCEP/offline templates that tag is how the KDC gets its strong mapping. Event 60 is the updated NDES refusing that same URI at issuance time because no custom policy module is registered to validate the SID. In Microsoft's own Intune path, the Certificate Connector fills that validator role; Jamf SCEP Proxy forwards the request but registers nothing equivalent, which is why a by-the-book Jamf configuration is the one that breaks.

 

Before changing the profile, I'd pin down two things: (1) the exact cumulative update and Windows Server version on the NDES host, and whether an Intune Certificate Connector has ever been installed on that server — its policy module registration changes what NDES accepts; and (2) whether these certs actually face a domain controller for authentication. If they don't, the SID URI may be removable. If they do, removing it just moves the failure from issuance today to authentication at the next renewal, and the real fix has to be a policy module that validates the SID (or a Jamf/Microsoft update that ships one), with the OID 1.3.6.1.4.1.311.25.2 SID extension or explicit altSecurityIdentities mapping as the interim paths to test, depending on how the template builds its subject.

 

Has anyone on the thread seen an advisory from Jamf or Microsoft on a policy module for the SCEP Proxy path? That seems to be the missing piece the event log is pointing at.

Forum|alt.badge.img+3

Thanks, that matches what I’m seeing.

  1. NDES host is Windows Server 2019; the trigger is KB5126651. Uninstalling it restored enrollment immediately (this is a working/production environment). No Intune Certificate Connector has ever been installed, and nothing is registered under HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP\Modules.
  2. Yes, they face AD. These are per-user EAP-TLS Wi-Fi certs authenticated by NPS, which maps them to AD accounts under strong-mapping enforcement. That’s why the SID URI went in originally, so removing it isn’t an option.

I’m opening a case with Jamf asking for a supported validator for the SCEP Proxy path, a PI number other customers can attach to, and interim guidance. I’ll post the PI number here if they issue one. Until then, the interim paths I’m evaluating are a CA policy module that adds the SID extension (OID 1.3.6.1.4.1.311.25.2) after looking up the account, and post-issuance altSecurityIdentities mapping.

Terms & ConditionsAccessibility statement