macOS authentications failing

[eglinsky2012]

It’s our favorite time of year again – renewal of the expiring EAP authentication certificate. Since switching to the new cert last Wednesday, we have an issue where some (three that I know of so far) MacBooks are unable to authenticate to our vanity SSID. Nothing else has change in WLC or RADIUS (ISE) configuration since then. The error on the client is “Authentication failed on network [SSID]” and is displayed immediately upon clicking Connect after entering the user’s credentials.

The two I’ve looked at can successfully get on eduroam, which uses the same SSID security settings as the vanity SSID and the same certificate, as well as our open guest network. We’ve tried forgetting both SSIDs and removing our certificate from Keychain, restarting, installing updates (from 13.4.1 to 13.5), moving to different APs on different controllers (AireOS 8.10.183.0 and IOS 17.9.3) and ISE nodes…. No go. One is an M1(?) processor, the other is Intel.

Client logs on the controller show the Mac attempting to authenticate with the username in the format of: [domain]\[Mac’sSerialNumber]$ sometimes, and sometimes just the NetID (which is expected).

ISE logs show the following:

Event	5400 Authentication failed
Failure Reason	12322 PEAP failed SSL/TLS handshake after a client alert
Resolution	Check whether the proper server certificate is installed and configured for EAP in the Local Certificates page ( Administration > System > Certificates > Local Certificates ). Also ensure that the certificate authority that signed this server certificate is properly installed in client's supplicant. Check the previous steps in the log for this EAP-TLS conversation for a message indicating why the handshake failed. Check the OpenSSLErrorMessage and OpenSSLErrorStack for more information.

Also, the ISE live logs show just "PEAP" for the authentication protocol for the failed authentications on the vanity SSID, but on eduroam, they show PEAP (EAP-MSCHAPv2).

I’ve brought this issue to TAC since I have a case open for an ISE-specific issue with the cert change and am waiting to hear back. I was wondering if anyone here has seen this issue or might know what else to look at.

[marce1000]

  -  You can do client debugging with : 
                             https://www.cisco.com/c/en/us/support/docs/wireless/aironet-1200-series/100260-wlc-debug-client.html    (AireOS)
                            https://logadvisor.cisco.com/logadvisor/wireless/9800/9800ClientConnectivity (IOS-XE)

    Client debugs can be processed with : https://cway.cisco.com/tools/WirelessDebugAnalyzer/

  M.
                             

[eglinsky2012]

I did that. As I mentioned, the WLC's view is authentication failure. But again, different SSIDs but same settings and certificate in use on ISE and one works one doesn't.

TimeTaskTranslated

2023/08/01 08:22:19.469	client-orch-sm	Client made a new Association to an AP/BSSID: BSSID 70df.2f5d.382b, WLAN xxx, Slot 1 AP xxx, xxx
2023/08/01 08:22:19.470	dot11	Association success for client, assigned AID is: 7
2023/08/01 08:22:19.683	errmsg	Client failed EAP authentication with following reason: Cred Fail
2023/08/01 08:22:19.684	client-orch-sm	Controller initiated client deletion with code: CO_CLIENT_DELETE_REASON_CLIENT_CREDENTIAL_FAILURE. Explanation: Wrong username or password. Actions: Check client side user configuration

[marce1000]

        - Check the radius server(s) logs for more info's

 M.

[eglinsky2012]

I included the RADIUS error for the client in my original post, or was there something more specific you were looking for?

[eglinsky2012 · Accepted solution]

Issue resolved, apparently these particular Macs had the old certificate deployed with JAMF. I had asked the JAMF team if they used JAMF to configure WiFi connections on Macs and they said no, only on iPads. Turns out that's not the case! Thank you for the pointers, Marce.

[vdj2008]

Hi! I know this is old and resolved, but how do the JAMF settings relate to the fact that it was the same cert working for one SSID and not the other?  We're seeing the exact same issue. 

[Scott Fella]

I think it really doesn't matter if its JAMF, Intune or even Windows GPO.  You need to validate what certificates are being used in the wireless profile and also, what is on the device itself.  What I have found in the past was the radius certificate was pushed to the endpoints, I don't know why, but when that expires, it doesn't matter if you have the root and or intermediate, the device would fail with similar error.  Now during the cleanup of certs and some testing, our MAcOS devices in JAMF was still connecting using EAP-TLS even though the team also pushed out the ISE server cert as a trusted ca.  So at least with MacOS, the device still looked at the root and intermediate ca that ISE was using and the device was able to authenticate.  WIndows, Android, iOS, they didn't work when that ISE cert expired. Also note, there was a lot of certs in our case that was being pushed out and applied to the wireless profile, which should not be the case.  I think it was more of... let just add all our certs because we don't know what cert to use for wireless.  SO in the end, its best for you to work with them and see for yourself how the policy looks like, and what certificates they are pushing for wireless.