Security

We have ClearPass 6.5.2, and occasionally have a user who cannot sign into our wireless network.  Authentication to the network is done via 802.1x.  ClearPass is bound to our Active Directory, as are the majority of our computers.

Sometimes CP and the AD Domain Controllers will say that a user's username or password is incorrect, but computers allow these users to sign on without a problem.  Having the user change their password always resolves the issue, but it's annoying, and we don't see why a password that works for computers in an AD would break when CP tries to authenticate the user against the same AD.  Here's the error ClearPass gives us:

MSCHAP: AD status:Logon failure (0xc000006d)
MSCHAP: AD status:Logon failure (0xc000006d)
MSCHAP: Authentication failed
EAP-MSCHAPv2: User authentication failure

So far, there are only two things that seem consistent.  We had this problem on our previous FreeRADIUS server that we replaced with ClearPass, meaning the two common threads are the FreeRADIUS software itself and the AD that we're using.

We're not sure where else to look for clues, and are hoping that the community has ideas.  I haven't asked TAC yet because the issue seems very inconsistent and, when it happens to a user, we don't ask them to wait an unspecified length of time to get online while everyone around them is enjoying being online and we figure it out.

Please let me know if you want more information.  I'm happy to answer questions.  Thanks!

Matt

You should open a case with TAC in parallel.  This could be very difficult to diagnose here on the forum.

Hello

do you have any solution for this problem.

I am interested in a resolution as well as i have seen that exact same behavior.  Any updates OP?

The attached error means that AD returned user authentication failure.

The AD authentication source is only used for user lookup and authorization when the EAP inner method is MSCHAPv2. The domain join is what allows the ClearPass to perform MSCHAPv2 authenticaiton against the DCs.

There could be many reason for this MSCHAPv2 logon/authentication failure, and one of which I could think of (based on the above threads) is that password expired in the AD (user did not reset the password before the expiration time) and the AD rejecting the authenticaiton when the user/system uses the expired password while connecting to the network.

The windows computer will let you login to the system even with the expired password (probably when not connected to the network) as it stores the username and password in the local credential manager and the same password won't work when you try to connect to the network.

You need to work with the AD team to identify the user authentication reject or work with TAC as suggested by Collin.

Hi Sarvanan,

                      I am facing the same issue what you have mentioned here "There could be many reason for this MSCHAPv2 logon/authentication failure, and one of which I could think of (based on the above threads) is that password expired in the AD (user did not reset the password before the expiration time) and the AD rejecting the authenticaiton when the user/system uses the expired password while connecting to the network"

Our wired users when their account passwords expire or the Sys Admin set their account to reset the password on next login, are able to login to their Windows PC but not able to access the network.

On access tracker in clear pass it shows 802.1X timeout with 9002 error code.

can you suggest a solution, that why the users are not seeing the windows screen to change their password and then log in. 

Thanks.

As Colin mentioned, this is difficult to diagnose because we are not sure if the problem with CP or AD, the compatibility between CP and domain LDAP query, plus too many unknowns.  Question and suggestions base on my experience.  Assuming user has correct AD username and password.

Where does your AD Authentication Source point to?

1. If it is pointed to only domain name, i.e. “aruba.com”, try to change it to servers i.e. Primary “ad1.aruba.com”, backup 1 “ad2.aruba.com”
2. If it is already pointed to LDAP servers, and it is on port 636, can you change the port to 389?

Please update any resolutions