02-02-2016 11:25 AM
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!
02-03-2016 02:26 AM
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.
02-03-2016 12:55 PM
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.
02-03-2016 07:17 AM
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.
02-03-2016 12:54 PM
Thanks for the reply, but no go. All standard English characters with no exception there, typed on standard American Dell laptops.
04-25-2018 02:01 AM - edited 04-25-2018 02:05 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide