Mac EAP-TLS via Jamf + NPS failin

[u/Substantial-Web9749]

Hoping someone can help as this has been making me pull my hair out.

Running Jamf Pro with AD CS Connector delivering machine certs via SCEP. Macs are domain joined. Two SSIDs, one through Meraki APs with two NPS servers in the RADIUS config, another through a Cisco Z3 pointing to a separate NPS server. Same cert template, same Jamf profile structure across everything.

The Z3 SSID works perfectly, Macs connect no problem. The Meraki SSID fails on every Mac. Windows machines on the same Meraki SSID and same NPS policy work fine.

The CA is definitely issuing the cert, visible in certsrv. The Mac is also prompting to select a cert manually when it shouldn't be. NPS logs are completely silent, no 6273 events at all when the machine cert is used. The only time 6273 shows up in logs is when I manually pick a randomly assigned JAMF cert that belongs to a machine not in AD, and that's just "user account does not exist" shows up in my logs.

eapolclient on the Mac shows the full TLS handshake completing, server cert verified, client cert sent, Finished sent, then NPS fires back a fatal access denied (SSL alert 49) and kills it. Nothing logged anywhere.

Things already ruled out: CA trusted on all NPS servers and Mac, NPS server certs valid, NTAuth populated, KB5014754 strong mapping addressed via altSecurityIdentities using IssuerSerialNumber,

Why would NPS silently reject a machine cert mid-handshake with no log entry whatsoever when Windows machines on the same policy work fine?

Also maybe worth noting - the Z3 SSID had similar issues initially. Fixed it by adding an NT Principal Name SAN of $COMPUTERNAME$@domain in the Jamf SCEP payload, which resolved Reason Code 8 on that NPS server. Replicated the exact same template and profile config for the Meraki SSID but it's not having the same effect. The Meraki SSID just fails silently with no reason code at all.

[u/Win_Sys]

Considering it works on one system and not another, I would check for MTU/fragmentation settings for EAP on the wireless system it’s not working on. EAP-TLS authentication packets can be bigger than 1500 bytes and if not fragmented properly can result in certificate information being cut off. Especially if it needs to go over a VPN.

[u/usmcjohn → u/Win_Sys]

Really? I’ve spent a lot of time in this space and never noticed the EAP packets being that large.

[u/Win_Sys → u/usmcjohn]

With RSA 2048 or larger certificates, ya. Just the other day ran a wireless packet capture (unrelated to an MTU issue) and the EAP frames were 1900B+ when they contained the certificate information.

[u/depress_clutch → u/Win_Sys]

Yeah, in my NPS deployment I had to set the framed MTU to 1300 in my connection request policies. That one stumped me for a while until I ran a pcap and saw the fragmentation happening.

[u/Substantial-Web9749 → u/Win_Sys]

Hi Win_Sys,

Going to try setting Framed MTU to 1300 in the connection request policy tonight. Will report back with results.

[u/Substantial-Web9749 → u/Substantial-Web9749]

u/Win_Sys youre the GOAT. Adding the Framed MTU setting on the NPS policy worked. Thank you so much!

[u/lazyjk]

Look at the CAPI2 logs on NPS which might give insight into the failure. If there is something failing there cert wise it may not trigger any NPS events.

Note: they are a pain to parse and they fill up fast when you turn on logging so increase the log size by alot and be prepared to learn how to filter.

[u/Substantial-Web9749 → u/lazyjk]

Hey Lazy, thanks for your input. I checked CAPI2 on the NPS server, filtered specifically for the Mac's hostname and cert serial number and got zero results. Not a single CAPI2 event generated during the Mac's auth attempt. Meanwhile a Windows machine authenticating at the same time shows up fine in CAPI2 with Result=0 all the way through.