Security

According to AOS user guide, client blacklisting will occur when X amount of client authentication failures occur.  I want to be sure that blacklisting will only occur if an authentication failure occurs and is not based on a RADIUS deny message being received for any other reason.  It is possible that a client may pass authentication, but fail to match a CPPM policy (resulting in a RADIUS deny).  I've never dissected a RADIUS response so it's not clear if the controller understands why the RADIUS deny was sent.

The radius server only sends "accepted" with or without radius attributes or a deny to the controller.

So for example, in an environment where machine authentication is enforced by CPPM (not the controller), if machine authentication didn't occur for a Windows machine (ex: wifi switch on laptop was set to off then flipped on once the user desktop appeared), the RADIUS server will send back a RADIUS reject message because a machine authentication did not preceed the user authentication.  This would count as a failed authentication on the controller?

[Machine Authenticated] is a built-in role that is set for devices who's mac addresses have passed machine authentication within a certain amount of time.  The authentication did not have to occur in the current authentication to be marked with that designation.  Whether the user is rejected or not are based on rules that the administrator would write based on that information.  The controller does not know any of this;  it is only looking for an accept or reject.

Long story short, blacklisting is typically meant to stop hacking.  Blacklisting based on authentication mainly works in a Captive Portal environment when a user can actually put in an incorrect username a number of times manually to justify a blacklist.  Most other authentication occurs automatically via a supplicant so there is no telling if the user only put in the wrong credentials once and the supplicant submitted it X number of times, so it is unpredictable.  I would not use it as a first choice for any mechanism that automatically submits credentials.

Okay, well that's unfortunate that it won't work well for my 802.1X scenario.

Number one use case for blacklisting on an 802.1X SSID is preventing employees from locking out their AD account by trying to connect to the coporate network with their personal device (ioS, android, etc).  I've seen several times where an employee tried unsuccessfuly to connect their personal device to the corporate network using their AD credentials.  This fails the RADIUS policy, but the device caches the credentials and continues to authenticate to the network.  Eventually, the employee changes their AD password, but the personal device keeps authenticating with the cached (now incorrect) password and locks out the account.  If I could blacklist the client after 2 failed attempts, I could keep the AD account from getting locked out.

Well, someone forwarded me this solution from the Educause mailing list, and I have not tested it.  It basically does not lock your user account out if they are using an old valid password, only if they are using an incorrect password.  It will still reject them, just not increment the bad password count that leads to a lockout.

"If you're using AD as your authentication source, look at implementing "Password history check (N-2)"

With Password history check (N-2), as long as the password being used is one of the last two in the history file, the bad password count is not incremented... thus, no account lockout when using an old, but valid password. That is, while the user can't authenticate using the old password (it still fails as an incorrect password), account lookout doesn't occur. It works around the problem where a user changes their password on say their desktop, and then their mobile device instantly locks their account as it attempts to auth on WPA."

A technet thread on it is here:  http://social.technet.microsoft.com/Forums/windowsserver/en-US/4b9f3fdd-f6e0-4a55-af99-ec065fe1b785/password-history-check-n2?forum=winserverGP

Has anyone had experience with this working for them with ClearPass?

Thanx - Eric

what is this in this case?