@Mr.RFC wrote:
@kuairhead wrote:
@cjoseph wrote:
@Mr.RFC wrote:
What happens when you create a set of new test credentials and try to aaa test those credentials?
Have you tried creating a test SSID and using the internal database on the controller to authenticate your users? Is the behaviour the same?
Also if i am not wrong, freeRadius is available as a windows .exe file?
What happens when you configure another freeRadius server and add the IP of the new server to test the test SSID with the test credentials?
--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
--Problem Solved? Click "Accepted Solution" in a post.
@kuairhead already wrote that it is not working because the AAA test server is not sending all the attributes required by his radius server.
As said I would expect no matter the account it would respond with reject. We have tried loads of different accounts that all can access the wifi ok and all get the reject response when doing AAA test but otherwise auth ok and get assigned the role they should get etc in production on an actual wireless device.
With regards to test SSID etc I have not tried that but as I have not experienced this issue myself in the 3 or so months the controllers have been live I wouldn't expect to see it on a test SSID and can't ask the hundred or so users in the production environment to use the test SSID so pretty limited there as well unfortunately.
We initially suspected the issue was with FreeRADIUS as we didn't have any reports of issues using NPS but we pointed auth back to NPS and we got reports from users so can only assume the issue is configuration of the controllers or AOS 8 behaviour.
Thanks.
What do you see in the security logs on the controller for any of the users experiencing this issue?
Command : show log security all | include <mac of user>
Note: This command does not need a live client
Do these logs indicate that the issues could be the same in both scenarios? (when using freeradius and when using NPS)
--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
--Problem Solved? Click "Accepted Solution" in a post.
Checking the logs for MAC address of the user device affected yesterday I see the following, none of which relates to yesterday. Not sure if any help.
Aug 19 17:36:05 dot1x-proc:1[4592]: <138057> <4592> <ERRS> |dot1x-proc:1| Failed to send the radius request for Station b8:8a:60:xx:xx:xx b4:5d:50:xx:xx:xx
Aug 29 14:46:11 dot1x-proc:2[4595]: <138094> <4595> <WARN> |dot1x-proc:2| MIC failed in WPA2 Key Message 2 from Station b8:8a:60:xx:xx:xx b4:5d:50:xx:xx:xx AP-b4:5d:50:xx:xx:xx
Aug 30 16:01:20 dot1x-proc:1[4592]: <138094> <4592> <WARN> |dot1x-proc:1| MIC failed in WPA2 Key Message 2 from Station b8:8a:60:xx:xx:xx b4:5d:50:7c:5c:d0 AP-b4:5d:50:xx:xx:xx
Sep 25 15:37:50 authmgr[3926]: <199802> <3926> <ERRS> |authmgr| dot1x.c, auth_handle_dot1x_key_handshake_data:4957: Key handshake data received for unknown user b8:8a:60:xx:xx:xx
The user who experienced issue yesterday was challenged for their credentials when roaming, then credentials were rejected even though correct so they left their device alone for around 7-8 minutes and after that it reconnected by itself. Not sure if a timer at play somewhere relating to this? The RADIUS requests when the issue occured seem to show the user went from an AP on one controller to an AP on the other controller in the cluster and at that point got the RADIUS login failed although this doesn't seem to be the case for other users when they experienced issues as it is roaming between APs on the same controller.
Thanks.