Radius Account lockout after failed authentication

[Jon_Linton]

I have a request to be able to lock a user out of the WLAN for a defined period of time prior to reaching their AD account lockout value. For example, if the AD account lockout is set to 6 failed attempts, I would want the WLAN to stop processing RADIUS requests for that user after the 5th failed attempt. I suspect this is possible with NAC but is it possible with only the wireless controller?

[hsachse]

Hello Jon,

I think one idea might be placing the user temporaly in a separate user group checked by RADIUS config to place the user in a discard/quarantine vlan. After the user should be able to use the wireless network again, he could moved back to the "primary wireless user group". I have no idea how you could stop the controller to send RADIUS request after the 5nd failed attempt.

If the main problem is that devices with cached credentials (like smart phones, tablet etc.) lockout the AD account after changing the password I would recommend to enable "Password history check (N-2)" at the windows server. This prevent that the badPwdCount counter is incremented, if the user/device tries to connect with one of the two (valid) passwords stored in password history.

[Charles_Yang]

Hello Jon,

I think the following might be able to help. There is really not an easy way to do it since WPA2 always authenticate users. Unless there is an easier way to ban the wireless device in question quickly without log into the VNS web interface, etc... but we all know to ban a wireless device in controller requires many clicks and multiple layer of screens-- it is possible but not durable. the AD account is locked long time ago before you can lunch and get to the VNS interface.

The goal is to use MAC and User authentication together. You can accomplish this by enforcing authentication on switch side of esa port uplink instead of enforcing within VNS. From there, you will be able to control device and user together or separately through NAC by put the MAC address in question in blacklist group--thus it will "quarantine" the device without triggers AD account lockout.

Between associated VNS and switch port with policy enabled, you should use Policy-to-VLAN mapping feature to ensure the policy enforced on switch that is "tunnel" down to VNS as VLANs.

In this suggestion, radio and AP level, device is still trying to authenticate, but any traffic by that wireless MAC is dropped at the uplink port of esa-to-switch port. it gave a apparent of "stopping" Device from communicating.

hope this helps.

PS, ensure you have enough port license for policy on switch side.

-cy