07-02-2014 12:18 PM
my logs fill up with Rejected authentications and I'm finding I have to hound these users to change their passwords. We're using the Clearpass server to authenticate against AD for employees with a corporate phones, when employees enter their username and password, they are given access to browse. 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. Is there a way to either force a prompt to update their password on their phones or somehow forget the network so it's not filling up the logs with rejected messages? I'm not sure how other people are handling this but it's quite annoying to have to hound all the users to update their passwords.
Solved! Go to Solution.
07-02-2014 03:15 PM
On the server side, there are tools out there that can alert users (via SMS or email) that their password is going to expire and provide instructions on how to change it and how to update their devices.
Tim Cappalli | Aruba ClearPass TME
@timcappalli | ACMX #367 / ACCX #480 / ACEAP / CWSP
07-02-2014 11:25 PM
08-25-2014 04:34 AM
after some attempts i got it working now. in principle you just extend the filter for your authorisation source. so when the number becomes too high the attempt will fail because these is no valid auth source to auth against. i got this in the tracker: "Cannot select appropriate authentication method".
08-25-2014 05:51 AM
I want to wait for tarnold to reply to this:
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.
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
Validated Reference Design Guides : http://community.arubanetworks.com/t5/Validated-Reference-Design/tkb-p/Aruba-VRDs
01-20-2015 02:05 AM - edited 01-20-2015 02:07 AM
What you should do is implement Password history check (N-2): "Before a Windows Server 2003 operating system increments badPwdCount, it checks the invalid password against the password history. If the password is the same as one of the last two entries that are in the password history,badPwdCount is not incremented for both NTLM and the Kerberos protocol. This change to domain controllers should reduce the number of lockouts that occur because of user error." - http://technet.microsoft.com/en-us/library/cc78027
-- Found something helpful, important, or cool? Click the Kudos Star in a post.
-- Problem Solved? Click "Accept as Solution" in a post.
03-22-2015 09:42 PM
Troy / Anybody that got this working:
I need some assistance please. I just tried adding the below line to my CPPM (under source > My AD Source >Attributes > Filter Name > then clicked on Authenticate filter) as shown in Troys PDF attachement. I did some testing and my users AD account still locking.
Our AD locks after 5 auth errors. As the user was purposely failing auth I was browesing the user in the Attributes > Browse tab and I was not seeing the badPwdCount attribute increase at all. It stayed on 0. Is this a valid test? Should I see it increase here? Any other suggestions or screenshots of how to get this working please?
06-07-2016 01:52 AM
The badPwdCount registry value is not replicated between domain controllers. This registry value, however, is reported to the PDC operations master.
Soo you should use the PDC to check this value