Just one user can't certificate auth to RADIUS wi-fi. A certificate mapping mystery.

This one is driving me batty, and I'm looking for suggestions as to where my issue might be hidden.

For just *one user* trying to EAP-TLS cert auth on to on-prem wi-fi, I get NPS errors with reason code 16 "Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect." *For every other user, our configuration works.*

I've narrowed the problem down to certificate mapping. When I create the "CertificateMappingMethods" registry key on the DC and NPS server and set it to 1f, it works.

What I'd like to know is where I might look for user-specific AD settings that would impact certificate mapping functionality. Our AD and this user have been around for a long time, so I suspect some legacy configuration is messing with this step.

I'm using a local Windows CA and NPS RADIUS, both Windows Server 2019. The devices joining wi-fi are Windows 11 Entra-joined (and not hybrid.) The AP is Meraki. The affected user is affected on multiple Autopilot-reset laptops. The same laptops work fine for other users.

EDIT 4 October 2023: SOLVED!

As it turns out, the affected AD account was missing an access permission that was present for others (including new users.)

The "Windows Authorization Access Group" did not have the "Read tokenGroupsGlobalAndUniversal" permission set to "This Object Only". After adding that one thing from the Advanced page of the Security tab of the AD User object, the strong certificate mapping started working. I don't know what the group is or what the permission means, but I'm going to look it up. I'm glad I don't have a way to find out who turned this off, because I'd hate to learn it was me. (I don't think it was me.)

I'm also going to mention that I got EAP error code 0x9009030C in the security log on the failing laptop, and the internet doesn't seem to know what it means. Bing Chat Enterprise (are you reading this?) was hallucinating when it told me that it represented a mismatch in allowed SSL version between supplicant and server.

Thanks everyone for your help. If you're here at some point in the future and this post helps because this is actually the resolution to your problem, too, I'd be thrilled to hear it. I sometimes wonder if I might be the only person in the history of system administration who faced some technical issue or other. Here's a candidate for that.