VPN AAA authentication issue (reason = Unspecified : user = *****)

[jm]

Running an ASA 5512, software version 9.5, with VPN set up using AAA authentication against a local Active Directory server.  The vast majority of users are able to authenticate and connect to the VPN with no issue, but some accounts (up to 3 now) provide the following when connecting:

SSL session with client outside:$USER_IP/43674 to VPN_EXTERNAL_IP/443 terminated
AAA user authentication Rejected : reason = Unspecified : server = $ACTIVE_DIRECTORY_IP : user = ***** : user IP = $USER_IP
Device completed SSL handshake with client outside:$USER_IP\43674 to VPN_EXTERNAL_IP/443 for TLSv1.2 session

To be clear, I did not ***** out the user name, that is what comes up in logs, as opposed to the username which comes up in case of an incorrect password such as:

AAA user authentication Rejected : reason = Invalid password : server = $ACTIVE_DIRECTORY_IP : user = jm : user IP = $USER_IP

The passwords are verified as correct as they can authenticate to active directory with no problems, they are not expired, and the accounts are not suspended.  If I create a new account for them, that account can connect with no problem.  This account in particular has been working up until yesterday from a user across the country, so it has definitely been in use previously.  The moment I have them use the new account, they are able to connect, eliminating anything on their end.

I'd rather not have an AD server full of users and re-created User_VPN accounts, so finding a fix for this would be ideal.  Thanks!

[Philip D'Ath]

Have you got multiple AD servers configured to authenticate against?  If so, test against each AD server individually.

My bet - AD replication issues.

Another thing to try - reset the users password.  Maybe a password reset will sync things back up again.

[jm]

Thanks for the input! The first time this occurred, I had actually guessed the password had expired for the user when they called saying they could not connect, so I changed it at first blush.  When that didn't fix it, that's when I did the log digging and found this error.  Over time, I've found the account works again but there's no set interval that seems to make a difference, so finding what it is tied to has been an exercise in frustration.  In addition, when I see it now, I do a net user <USERNAME> /domain to verify password expirations.

Currently, the ASA is configured with 2 AD servers, PDC and secondary, and the password authenticates against both.  However, I will pop a repadmin /showrepl next time it comes up to see if maybe that has happened.  As it is an intermittent issue, my most favorite type, I can't be sure if potentially it had failed at the time.  

[AllertGen]

Hello, jm@perfectaair.com.

Just to be sure: does usernames has non-english characters at the username? And if it's an AnyConnect/Web Authentication I would check at the user side how they type they username and password data. It could be a keyboard encoding problems (just for example you can look at the Japan layout).

Best Regards.

[jm]

Thanks for the reply, but no go.  All standard English characters with no exception there, typed on standard American Dell laptops. 

[Bogdan Shavlo]

You need to check security permissions for user in AD which you use in realm configuration. 

Here are details on pictures.

You need to change OU advanced security properties from:

Before

 To this (click Restore defaults):After