We are experiencing the following issue and I am wondering what other folks are doing regarding expired password client exclusion blacklisting on their 802.1X WLANs. This is specifically about a Cisco environment, but others may have knowledge about it (albeit with different vendor-specific language).
Client(supplicant) connects to our 802.1X WLAN(SSID) and it fails authentication 3 times because of an expired password. It is now blacklisted (for 60 seconds), during which time the client will usually then try to associate with our open WLAN, but cannot join and then retries associating with the secure WLAN once again, failing once again. I think we are mainly seeing this when a user's Active Directory password expires without their knowledge. Here is our environment: Cisco 8510 WLCs running 8.0.121.0 code Cisco ISE Version 1.4.0.253, Patch 3,5,6 There are some settings involved: 1.)"Client Exclusion Policy" (which under Security-->Wireless Protection Policy) has 6 elements, all on by default; one of these is "Maximum 802.1x-AAA Failure Attempts" which is set to "3" by default, and gives a range of "1-3". 2.)"Client Exclusion" (under WLANs-->Advanced) is set to "enabled" with a timeout of 60 seconds. The Client Exclusion Policy is a global setting, and you can enable it for each WLAN or not, and pick the timeout in seconds (or 0 seconds, which means it must be manually cleared by an admin). My questions are whether other folks are leaving this feature on, or have they shortened the timeout, or have they disabled it altogether? We have this enabled on both WLANs, even on the open one--and this wouldn't seem to matter here, and perhaps is causing the client to be unable to connect to this one as well, erroneously. The timeout of 60 seconds seems like an eternity for a wireless client, and I imagine this feature intends to prevent a massive DoS or spoofing attack, except for we've seen iPhones that can register 100's of thousands of failed login attempts in less than an hour before our wireless overhaul, and our AD servers never even broke a sweat. Is it then perhaps for the safety of the wireless controller? We've resolved this in some instances, even today, by "forgetting this network" on the client and powering it off, then finding its session in both ISE and the WLC and deleting them each, before powering the client back up. Then, it works flawlessly, once again. Because of this, it seems like this setting might be more of a nuisance than anything. Any thoughts would be appreciated. Thanks!--JW Jess Walczak Senior Network Analyst Information Technology Services [email protected] University of St. Thomas | stthomas.edu ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
