Repeated failed radius authentications causing account lockout

[ChrisWy]

Having an issue where client PCs are locking out the user's AD account after entering their password wrong 1 time on wired network.

We setup a new network with Cisco 9300 switches and ISE 2.3 with 802.1x authentication. The client PCs are using Windows EAP-MSCHAP v2 User or Computer authentication sent to them by GPO. Our AD policy is set to lockout an account after 3 failed password attempts. The issue we are having is that when 802.1x user-based authentication is turned on, if an end user types in their password incorrectly one time on a client PC, the AD account is getting locked out. When I look at the logs in ISE, I see one failed authentication, when I click to examine it, it looks like the radius request retries and fails 3 times within that one session. 

I've tried changing settings on the radius suppression and within the group policy settings to limit these retries, but having no luck. Any other thoughts?

[howon · Accepted solution]

There are 4 main components here; endpoint, switch, ISE, and AD. Since you rarely have control over the endpoints (Aside from the GPO) let me list out options that can control the experience:

- Switch: There are two timers you can play around with on the interface. One is 'dot1x max-reauth-req' which controls how many retries will be done after initial failure. Default is 2, which equates to 3 tries in total. So this is why you are seeing total of 3 failures which causes lockout. You can reduce 'dot1x max-reauth-req' to 1 to reduce total tries to 2. Another setting is 'dot1x timeout quiet-period'. This controls how long the switch will wait after the 3 tries (Or 2 after modification) that was set by'dot1x max-reauth-req'.

- ISE: Under Administration > System > Settings > Protocols > RADIUS there are two settings. One is 'Failures prior to automatic rejection' which is the criteria to ignore any future authentication request from the endpoint, and 'Continue rejecting requests for' controls how long to ignore request for.

- AD GPO: Under GPO account lockout policy there are two settings. 'Account lockout threshold' which you want to be higher than either switch's 'max-reauth-req+1' or ISE's 'Failures prior to automatic rejection' value. Also, The 'Reset account lockout counter after' value should be less than switch's 'dot1x timeout quiet-period' value and ISE's 'Continue rejecting requests for' to avoid getting locked out.

[paul]

The user should never be allowed to enter any credentials.  If the user is seeing a credential pop-up the GPO policy is setup incorrectly.  The windows supplicant should be taking the credential information from the computer account or the logged in user automatically.

Also you really shouldn't be allowing PEAP user authentication without some way to ensure they are still on a domain computer.  Otherwise you are opening a security hole in your design.  Anyone can bring in any device they want and put their AD credentials in to get on the network.

[RichardAtkin]

Agreed. He says he’s supporting Machine Auth as well as User though, so a quick extra condition of ‘was Machine Authenticated == True’ added to the User’s Authz Conditions will fix that.

[paul]

True but you need to understand the pitfalls of MAR cache. It is better now but still won’t work for wireless and if your PSNs are at different locations you can’t sync it. There are several ways to solve the PRAP user issue and the all have some caveats you need to be aware of.

[Justin Walker]

Sounds like some settings in the supplicant or group policy needs to be tweaked.  Do you have single sign-on configured in your supplicant under the Additional Settings button? 

[Arne Bier]

Another approach could be to use an LDAP binding to your domain controllers, instead of an AD Join point.  I have used that in one customer scenario where certain devices (e.g. personal phone) fail all day long because AD password changed months ago, but user hasn't bothered to update the creds on his personal phone.  LDAP is perfect for simple auth.

[hslai · Accepted solution]

Hosuk's answers are very comprehensive, except that the suppress repeated failed clients in ISE would not do it for password failures. If using WLC, you may try Client Exclusion Policies.

As the others commented on, it could be due to client behaviors so it's tough to enforce password lockout policies.