03-25-2015 12:12 PM
Since upgrading to 184.108.40.206, I seem to have a problem with users trying to login with our guest account. The guest account is local to each controller. Problem seems to be that if the user enters the wrong password, the account then fails over and tries to authenticate to our corporate RADIUS server, so that each time they subsequently try to use the account, it no longer tries to hit the internal db.
This hasn't been an issue in the past 4 years, so I'm wondering if something changed with the upgrade to 220.127.116.11?
03-26-2015 06:02 AM
Yes, captive portal group uses both internal and RADIUS server. Fail through is enabled.
Our configuration has remained consistent for 3-4 years.
We've only started receiving these complaints since upgrading to 18.104.22.168.
I've been able to duplicate the issue:
1) login with guest account using incorrect password - check local events log and see failure at internal server/db;
2) try again, see failure at RADIUS server;
3) each subsequent attempt goes directly to RADIUS server, even if I enter a new user name.
The only way I've been able to fix the issue to to go to CLI of the controller and remove client with the "aaa user delete mac" command. After that, login will then attempt to hit the internal server/db.
Users have turned off their wi-fi, and rebooted devices, and problem still remains.
My problem is that I have 180+ locations, and the support process usually means that the user is gone by the time a ticket reaches me. I'll have another user on-site try to login and they are successful, so problem appears to be fixed.....of course I can't prove the other user provided an invalid password on the first attempt.
04-01-2015 07:09 AM
Guess the fix is to create a domain account for this. Seems kind of ridiculous that I would have to risk network security by creating a domain account for my guests because the internal server is apparently a "one and done" chance of authentication.
I'm sure the standard response of "open a TAC case" would apply here.