Security

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.

 

Thanks,

Carrun

The only solution for something like this on the network side of the house is to use certificates for authentication (EAP-TLS).

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.

See attached.

@Troy - What does this actually do?  I'm trying to understand the logic.

 

After 5 bad password checks, what happens?

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".

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.

 

 

related from another topic (http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-802-1x-Auth-Locking-out-Account/m-p/162118/highlight/true#M12122)

---

cjoseph wrote: 

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/cc780271(v=ws.10).aspx

 

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.

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

 

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?

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

 

Hi all,

i still have some questions on this topic:
In order to validate the user's password (EAP-PEAP-MSCHAPv2), clearpass servers must be AD joined. Several sources describe what to do, see i.e. https://www.arubanetworks.com/techdocs/ClearPass/Aruba_DeployGd_HTML/Content/Active%20Directory/Joining_AD_domain.htm

Pls note this remark :

During the NT LAN Manager authentication process, ClearPass queries Active Directory for a suitable domain controller to use to handle the authentication.

Please note that when used with 802.1x EAP-PEAP-MSCHAPv2 services, the authentication process is separate from the Active Directory authentication source in ClearPass, which in this context only handles authorization.

 

My question is : how can any modification in the authentication/authorisation filter (as described above) impact the actual password check (hashes) ? According to the note, these 2 process are separate.

Is it even necessary to specify AD as authentication source (in the service) if we check no other attribute in AD (for authorization)?

 

(Oke, i haven't actually tried this solution, had to disassociate clearpass server from AD due to huge amount of problems...)

 

Thx a lot !!