802.1X authentication not working for google Pixel phone and Realme

[SLT-Meraki]

We implemented the Meraki MR36 Wi-Fi solution for one of our campus networks. The Wi-Fi solution is configured with an SSID integrated with Windows Server 2012 NPS. The SSID uses 802.1X authentication.

The problem I encountered is that some mobile devices failed to authenticate, with the error message stating, "RADIUS server rejected the authentication request." This issue was observed with specific phone models, including Google Pixel (Android version 15) and Realme (Android version 15).

I have attempted various troubleshooting steps from the Cisco Meraki side, but their final conclusion was that the RADIUS server rejected the authentication requests. They advised checking the RADIUS server configuration.

Can anyone assist me in resolving this issue, either from the Meraki side or the RADIUS server side? Any suggestions or guidance would be greatly appreciated.

[ww]

First step would be to ask the person who manages the radius server for the logging why it send the reject. 

[SLT-Meraki]

I will check it from the customer and update on this thread.

[BlakeRichardson]

This is off topic slightly but you really should be updating your server from Windows 2012 as it's not longer supported by Microsoft. Given this is providing the authentication  for your network you really want it to be secure.

[PhilipDAth]

On the NPS server, filter the "Security" event log for Event ID 6273.  Read the reason why the RADIUS server said it denied access.

[SLT-Meraki]

Thanks for the feedback and i will check with customer on this. If I have resolution on this, I will let you know after checking the NPS logs.

[Jams]

Did you ever figure this out?  I've been running into the same issue.  Some phones won't connect (Auth Failure).  Even logs on the NPS say the same regarding the auth failure.  If I test the same creds on the Meraki dashboard for that SSID, the tests pass and it authenticates against all APs.

Bit stumped, as I know the creds are correct - especially given it passes on the test in the dashboard.  Just seems to be a handful of phones (i.e., Pixel 9) that throw the auth failure.

Edit:  I found a Reddit sub mentioning this issue, and it seems it's more than likely an Android 15 issue (https://www.reddit.com/r/GooglePixel/comments/1hgx56r/wifi_connection_issue_saved_disabled/)

[SLT-Meraki]

No.still i'm trotroubleshooting the case.I throught that this issue might be the certificate issue in NPAS.because authentication is rejected by NPAS side .So still i'm trying to figure it out.I hope to escalate this issue to check with microsoft team also.I will let u know with my findings.

[Jams]

Based on what I've learned so far, if it we are talking about the same issue, it does seem to be related to an Android 15 update that happened back in Dec.  Many ppl reporting rolling back/flashing to A14 gets it working again on these devices (which isn't an ideal option, as no one really wants to spend half hour setting up their phone again after a reset).  Pretty much likely waiting for a fix in the next Android security patch/update.

[ggarolla]

What authentication protocol are you using? On an SSID configured with PEAP I had a similar issue with Pixel phones. It turns out that that specific Android implementation was automatically populating the Anonymous Identity field, and that was not accepted by our NPS. I had to manually clear the Anonymous Identity field from clients and then authentication worked again

[SLT-Meraki]

I'm using PEAP. How can you clear Anonymous Identity field from clients?

[ggarolla]

Do you use an MDM solution to configure your SSID in clients or do you manually configure it?

In the latter case, I think the easiest solution would be to forget the network and then configure it again on the client: in the setup phase you have to select the correct settings, including which authentication protocol to use and the credentials. It is in this configuration phase that you will find the "Anonymous Identity" field. Unfortunately, I do not have a Pixel (or an Android) device at hand, so I am not able to provide a screenshot.

[SLT-Meraki]

Thanks for the support. If we can add username as Anonymous identity, some of the mobiles were successfully authenticated. But still majority not.

[ggarolla]

My bad, I was not very clear with my explanation. What worked for me was leaving the "Anonymous Identity" field empty, and using the username in the other field (I believe it is simply called "Identity", but that might depend on the Android implementation).

[Jams]

I thought the anonymous identity field might be the cause (and who knows? Maybe still is...) From my experience - A couple years ago, it didn't seem to matter what went in there.  Some time later, it was only authenticating when people copied their username to the anonymous id field.  As of recent, I've tried:

• blank/empty
• left the default "anonymous"
• mirrored the username (i.e., anon id = username)
• full AD user (domain\username)
• UPN (username@domain.suffix)

No success.  Timing-wise from when the problem started, and some testing on other devices still on Android 14 (which connect fine), it 'seems' to be related to A15.  Whether it has something to do with something changing in how it handles the Anon Id field - since that has affected things before - or something else altogether... Still stumped.