How to prevent AD account being Locked out by 5 failed authentications

Aruba Employee
Aruba Employee

When we use Clearpass server to authenticate(EAP-PEAP) against AD for employees with corporate phones, the problem comes when their 60 day password expiration happens and they change their AD password on their computer but forget to change it on their phones. Due to this, the phones keep authenticating using the old credentials that are saved and results in the account being locked out after 5 failures.

 

Environment : 

This article applies to the WLAN/LAN setups where users are authenticating against Clearpass Server with AD/LDAP as Authentication Source

 

Network Topology : This article applies to the WLAN/LAN setups where users are authenticating against Clearpass Server with AD/LDAP as Authentication Source

 

1. Log into Clearpass Policy Manager WebUI and navigate to Configuration » Authentication » Sources » [LDAP/AD Server] » Click on Attributes Tab » Click on Filter name "Authentication".

 

 

rtaImage.jpg

 

2. Add the logic into Filter Query

By adding “!(badPwdCount>=4)” into the filter Query, CPPM will not send authentication to AD/LDAP if a user has badPwdCount which is not >=4.

The entire filter query is as below:
(&(&(sAMAccountName=%{Authentication:Username})(objectClass=user))(!(badPwdCount>=4)))

 

rtaImage (1).jpg

 

3. Click on the Browse Tab and browse the user info "badPwdCount" to check the count for a specific user as shown below 

 

rtaImage (2).jpg

 

Before authentication, the default LDAP filter searches the LDAP tree for a user object.  If the user object does not exist, it does not submit the authentication and returns "user does not exist".

Adding "(badPwdCount>=4)" to the filter adds a restriction to the filter, that the user object also cannot have had 4 incorrect passwords.  The net effect is that any user who has inputted 4 incorrect passwords, will not be returned by the filter.  ClearPass will say that the user object does not exist.  Since this search occurs before authentication is submitted, no authentications will be sent from ClearPass for users who are on their "last strike", preventing a lockout.
 
Any other successful authentications to AD outside of ClearPass will reset the badpwdcount counter, and that user will be able to be found in the LDAP search and authenticate through clearpass again.

 

After making the configuration changes as suggested above, you can test with a client by authenticating the client against cppm and providing wrong password for morethan or equal to 5 times. Access tracker records on CPPM GUI for the initial 4 attempts will show a failed authentication attempt with message as "User Authentication Failure".

After the 4th attempt with wrong password, you can browse the user info by logging into Clearpass Policy Manager WebUI and navigate to Configuration » Authentication » Sources » [LDAP/AD Server] » Click on Attributes Tab » Click on Filter name "Authentication" » Click on the Browse Tab. The "badPwdCount" should show the value as 4.

 

 

rtaImage (3).jpg

 

Any additional authentication requests from this user with wrong password will again fail but with a different error message in Access tracker as "user does not exist". This is due to the filter query now considering the "badPwdCount" and not returning the user as the count is equal to or greaterthan 4.

 

In order to troubleshoot any user reported issue in the above scenario, please go to Access tracker and verify the alert message for this user authentication event.

You have to then browse the user info to verify the "badPwdCount" by logging into Clearpass Policy Manager WebUI and navigate to Configuration » Authentication » Sources » [LDAP/AD Server] » Click on Attributes Tab » Click on Filter name "Authentication" » Click on the Browse Tab.

If the "badPwdCount" is 4 or greaterthan 4, then you need to make sure you successful authenticate the user to AD outside of ClearPass which will then reset the badPwdCount counter to "0" for this user and that user will be able to be found in the LDAP search and authenticate through clearpass again.

Version history
Revision #:
1 of 1
Last update:
‎04-08-2015 07:18 AM
Updated by:
 
Labels (1)
Contributors
Comments

The badpwdcount attribute in AD is not replicated between the DCs.  Multiple DCs can have different badpwdcounts, which all contribute to an overall account lockout.

 

This may prevent the Clearpass itself from causing an account lockout, but only if it's configured to talk to a single specific DC, specifically the PDC operations master for the domain, as it knows about all bad password attempts in the entire domain.  If you add multiple authentication sources (not sure if that's possible), or point to a non PDC emulator, then this solution will likely not work as expected.  FYI

We have our clearpass on version 6.4.0 and we also facing this issue. AD is set to 10 incorrect password and we have already got the filter set up on clearpassas below:

(&(&(sAMAccountName=%{Authentication:Username})(objectClass=user))(!(badPwdCount>=3)))

But everyday we still recieve calls from users being locked out and from the logs from AD clearpass is the main reason.

 

Please help

HI,

untill 10 day ago all work properly

Now when i set the filter

 

“(&(&(sAMAccountName=%{Authentication:Username})(objectClass=user))(!(badPwdCount>=2)))”

 

And click on “filter” for test it i’l receive this error: “The specified filter query cannot be parsed. Do you want to clear this filter?”

 

I see that the attribute name is "badPwdCount>" it seems that the operator not is recognized as ">=" but only as "=".

 

Can be a problem of AD server?

 

Regards.

Andrea

Hi

We have three AD servers in our domain and this setting can cause problems if your not careful. Since we implemented thsi setting it has stoped our users from locking thier accounts when the mobile is trying to authenticate with an old password after they changed the AD password and forgot to update on thier mobile.

 

BUT!

We use the same authantication source for our computers tho authenticate and this has caused us a LOT of problems. Whenever a computer authaticates successfully to a DC the attribut "badPwdCount" is set to 0 on that DC. This setting is then NOT replicated to the other DC's or the PDC master. So everything could be great and correct but when a computer would try to authenticate CPPM could respond with "User not found".

Looking at the three different DC's one or two of the DC's would have the setting "badPwdCount" set to 0 but the attribute would not exist on the PDC master (which is set as the primary DC source in CPPM).

 

Our solution was to add an other check that the badPwdCount should either be les or equal to 3 OR not exist, then the user could be found. Our current filter looks like this now. And finaly it is working.

 

(|(&(objectClass=user)(sAMAccountName=%{Authentication:Username})(|(badPwdCount<=3)(!(badPwdCount=*))))(&(objectClass=user)(userPrincipalName=%{Authentication:Username})(|(badPwdCount<=3)(!(badPwdCount=*)))))

 

This problem has taken us some time to find so I hope this helps anybody else if they encounter the same problem in thier implementation of this solution.

 

Kasper

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: