Common Authentication Errors and Suggested Fixes
Here are common error messages and causes related to authentication. Expand the section for steps and suggestions to solve the error.
Reason: The password and/or username provided aren't correct.
Resolution: Ensure the username and password are correct. If needed, reset the password.
To reset a user's password (local authentication):
Sign in to the Admin Web UI.
Click User Management > User Permissions.
Find the user and click More Settings.
Enter a new password in the Local Password field.
Provide the user with the new password.
Note
If users authenticate with an external method — LDAP, RADIUS, or SAML — updating passwords must be done with the identity provider.
Tip
If you need to reset access for your admin account, refer to Reset openvpn Account Admin Access.
Reason: The local authentication user account exists but doesn't have a password set.
Resolution: Set the password in the Admin Web UI or command line.
To set the password in the Admin Web UI:
Sign in to the Admin Web UI.
Click User Management > User Permissions.
Click More Settings for the user.
Enter a password in the Local Password field.
To set the password from the command line:
Use the sacli SetLocalPassword command. Refer to the user and group management page for specifics.
Alternative Reason: Another possible reason for the error can occur with a user-locked profile where the user enters a different username to sign in. For example, suppose you download a user-locked profile for "John" but enter "Dave" as the username. In that case, Access Server tries to verify the credentials for the incorrect "Dave" user, and if that doesn't exist or doesn't have a password set, then the local authentication will fail with this message.
Resolution: Fix this by using the correct username and password for the user-locked profile.
Reason: This error message occurs in one of two situations:
The deny access box is checked for the user in the User Permissions table.
The Deny access to unlisted accounts by default is set to Yes. The user authenticates with an external system: PAM, LDAP, RADIUS, or SAML and the user doesn’t exist in the User Permissions table or doesn’t match the username in the external system.
Resolution for deny access box:
Sign in to the Admin Web UI.
Click User Management > User Permissions.
Click Deny Access to uncheck the box for the username.
Resolution for Deny access to unlisted accounts by default:
You can resolve the issue by adding the user to Access Server's user permissions table or by allowing Access Server to add users automatically by setting Deny access to unlisted accounts by default to No.
Add the user:
Sign in to the Admin Web UI.
Click User Management > User Permissions.
Add the user to the User Permissions table if it doesn't exist.
Ensure the spelling and case match between Access Server and the external authentication server.
Allow Access Server to add users:
Sign in to the Admin Web UI.
Click Authentication > Settings.
Under External User Registration, set Deny access to unlisted accounts by default to No.
Reason: This error message displays when a user tries to sign in with credentials for an existing user, "Dave," with a user-locked profile for the existing user, "John. "
Resolution: Ensure to use the correct username with a user-locked profile. You can't mix and match profiles and credentials.
Alternatively, you can replace the user-locked profile with a server-locked connection profile if you need a connection profile that allows any valid Access Server user to connect.
Reason: This error displays with LDAP authentication configured when the username isn’t found with the specified LDAP query.
Resolution: To broaden the search, simplify the query to just the base DN, "DC=example,DC=com." The issue often exists because the user isn’t in the location searched by the LDAP query.
If a directory-wide search still doesn’t return results, it may be due to an incorrect LDAP attribute. Try searching for “sAMAccountName” or “uid”. Refer to the documentation for your LDAP server to determine the correct attribute. The auth.ldap.0.uname_attr sets the attribute for the search.
If changing the LDAP attribute still doesn’t return results, it may be that your LDAP server is case-sensitive with containers and objects and that you need to use lowercase names instead (cn=blabla instead of CN=blabla). Refer to the documentation for your LDAP server to find the correct settings.
One significant issue can occur when defining additional query parameters to allow only users from a specific group in the LDAP directory to sign in. For example, the additional query memberOf=CN=VPN Users fails, but the full query should work: memberOf=CN=VPN Users,OU=Security Groups,DC=company,DC=com. Ensure you use the full query.
Reason: This error may appear in the openvpnas.log log file and indicates that the LDAP server’s credentials entered for the bind are incorrect or don’t allow access to the LDAP directory.
Resolution: If you're trying to connect to an Active Directory server, it may help to create a separate user in the domain for the bind user. We recommend using a format like username@domain.tld as the username in the Access Server's bind username field.
We’ve also seen the same problem reported with an expired SSL certificate for securing communication between Access Server and the LDAP server.
Reason: This error occurs with LDAP authentication using an anonymous bind, which is not allowed by the LDAP server. Refer to the documentation for your LDAP server to see whether it’s allowed.
Resolution: Create a bind user on the LDAP server and give it read access to the LDAP objects you want to search for user authentication. Alternatively, you can enable anonymous LDAP binding on the LDAP server, but this is not as secure as using a special limited bind user account.
Reason: The error message is related to the password lockout policy, implemented automatically by Access Server. The lockout policy temporarily blocks a user from signing in when the password was incorrectly provided a number of times within a specified time.
Resolution: You can adjust the lockout policy to meet your specific needs. Refer to Authentication failure lockout policy for more details.
Reason: This error message relates to using Google Authenticator with Access Server. When you enable Google Authenticator to enforce MFA for users, and a user hasn’t completed enrollment on the Client UI, they can’t establish a VPN tunnel connection.
Resolution: To resolve this, instruct your user to sign in to the Client UI and complete the enrollment. They need to scan the QR code or enter the enrollment code into the Google Authenticator app (or a compatible TOTP app), to save the shared secret and generate the required six-digit one-time password. Refer to TOTP MFA documentation for more details.
Reason: This error message relates to incorrectly entering the six-digit code for MFA with Google Authenticator. When you enable Google Authenticator for Access Server, a user signs in with their username and password and must provide the six-digit code from Google Authenticator (or a compatible TOTP app). Google Authenticator generates a new code every 30 seconds.
Resolution: Use the Google Authenticator application and enter the six-digit code into the Google Authenticator field when asked.
Reason: This error message occurs when the six-digit code for Google Authenticator isn’t correct. This can occur due to entering the wrong code or if the date/time or timezone settings are incorrect on either the server or the client device.
Google Authenticator uses the current date and time and adjusts automatically for time zones. This requires that the server and the device with the Google Authenticator app both have the correct timezone set and the correct time and date set. Time and date, plus a shared secret known by Access Server and Google Authenticator are used to create the unique six-digit codes: shared key + time and date = code. If the date/time or timezone is incorrect on either the server or the client device, the six-digit code won’t match.
The six-digit code is valid for 30 seconds. Access Server accepts the current code as well as the previous and following codes.
Resolution: Either reset the user's authenticator key and ask them to enroll again or install the network time protocol program on your server. Which resolution you choose depends on which is causing your problem.
2023-04-13T14:44:49+0000 [stdout#info] Warning: OpenVPN daemon job Queue size (~10) at or above limit (auth.module.max_parallel=8) .2023-04-13T14:44:53+0000 [stdout#info] Warning: OpenVPN daemon job Queue size (~11) at or above limit (auth.module.max_parallel=8).
Reason: This error means that your Access Server installation faces a high throughput of authentication requests, and the default value (8 parallel threads) is not enough to handle all of them.
Resolution: We recommend increasing the number of parallel authentication threads. The value for this parameter should be equal to or greater than the predicted number of VPN clients trying to connect to Access Server at the moment.
Refer to Set maximum number of authentication and database connection QueuePool size for steps.
Important
Ensure you increase the max database connection QueuePool size as well. More authentication threads will result in more simultaneous connections to the database.
2022-12-13T11:06:24+0000 [stdout#info] VPN Auth Failed: 'QueuePool limit of size 5 overflow 10 reached, connection timed out, timeout 30 (Background on this error at: http://sqlalche.me/e/13/3o7r): ...
Reason: This error occurs when Access Server uses all available threads for connection to the database and needs more to handle current activity. The most common reason for this situation is increasing the auth.module.max_parallel parameter but leaving mysql.max_overflow with the default value.
Resolution: Adjust the mysql.max_overflow value as well. Refer to Set maximum number of authentication and database connection QueuePool size for details.