Debugging & Troubleshooting Authentication Problems

When you encounter authentication issues, the tips here can help you identify and resolve them.

You're welcome to send us a support ticket as well.

Use the authcli tool

To validate your authentication configuration for Access Server, we recommend using the authcli command-line utility.

What is authcli?

The authcli tool runs tests and provides useful debugging information. You can print authentication results to your screen, see user-specific properties applied when authentication succeeds, and verify if expected properties get picked up.

How to use authcli?

To run authcli, ensure you are in the /usr/local/openvpn_as/scripts/ directory and run the commands as a root user.

Important

Mismatched usernames are one of the most common problems with authentication, where the username in the User Permissions table for Access Server doesn’t precisely match the username in the external authentication system.

Use the below commands for debugging or testing with authcli.

Verify authentication for a user:

./authcli --user <USER_NAME> --pass <PASSWORD>

Example 1. Sample output of a successful local authentication attempt

API METHOD: authenticate
AUTH_RETURN
 status : SUCCEED
 session_id : AaJkamAuZgjXwsjk+N96eA==
 reason : local auth succeeded
 expire : 1505404548
 user : test
 proplist : {'pvt_password_digest': '9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08', 'type': 'user_connect', 'prop_autogenerate': 'true'}

Verify authentication for a user with multi-factor authentication (MFA) enabled:

./authcli --user <USER_NAME> --pass <PASSWORD> --sr=<MFA_CODE_HERE>

Case-sensitive matters for usernames

Most authentication systems are case-sensitive. Ensure the username case matches between Access Server and the external authentication system. After a successful match, Access Server can apply user-specific properties — auto-login privileges, static IP address, and so on.

For PAM authentication, the username is case-sensitive. Authentication fails if you enter "Gary" to sign in but the actual username is "gary".

Some LDAP servers, such as Active Directory, may not be case-sensitive for usernames. However, if you sign in to Access Server with "Gary" and the LDAP server returns "gary" as the match, Access Server looks up user-specific properties for "gary". Ensure you match cases for your usernames.

Deny access to unlisted accounts by default

By default, unlisted accounts are denied access.

When set to "No" (default):
- Successful authentication with an external system (PAM, LDAP, RADIUS, SAML) is accepted even if the user account is absent from the User Permissions table.
- Users can authenticate even if the username doesn't match the one in the external system.
When set to "Yes":
- Users can't authenticate via external systems (PAM, LDAP, RADIUS, SAML) if their account isn't listed in the User Permissions table.
- Authentication will be denied if the username doesn’t match the one in the external system.

Modifying the setting in the Admin Web UI

You can find the setting to deny access to unlisted accounts in the Admin Web UI, as detailed here, or in the CLI, detailed in the next section.

Sign in to the Admin Web UI.
Click Authentication > Settings.
Under External User Registration, toggle the setting for Deny access to unlisted accounts by default.
Click Save Settings and Update Running Server.

Finding and modifying the "def_deny" setting on the CLI

The "def_deny" setting is found under the user profile named DEFAULT in Access Server’s configuration. To view the current value of this setting, run the following command:
```
sudo su
cd /usr/local/openvpn_as/scripts/
./sacli --pfilt "__DEFAULT__" UserPropGet
```
- Example output:
```
root@openvpnas2:~# sacli --pfilt "__DEFAULT__" UserPropGet
{
  "__DEFAULT__": {
    "def_deny": "false",1
    "prop_autogenerate": "true",
    "prop_force_lzo": "false",
    "type": "user_default"
  }
}
```
  1
  This means that, by default, users can authenticate even if they're not listed in the User Permissions table or don't match the external system's username.
If you need to change the value of the "def_deny" setting, follow these steps:
1. Access the console and get root privileges.
2. Switch to the scripts directory:
```
cd /usr/local/openvpn_as/scripts/
```
3. Modify the "def_deny" value. You can set this value to "true" (to deny authentication when the account isn't listed) or "false" (the default setting, allowing authentication even for unlisted accounts).
  Change the value to false (default):
```
./sacli --user "__DEFAULT__" --key "def_deny" --value "false" UserPropPut
```
  Change the value to true:
```
./sacli --user "__DEFAULT__" --key "def_deny" --value "true" UserPropPut
```
4. Restart and apply changes:
```
./sacli start
```

LDAP authentication debugging tips

The most common problems for LDAP authentication relate to the base DN search query. Ensure you enter that carefully, especially where your search query is very specific. When you encounter an LDAP issue related to your search query, you receive an error message such as “user not found that meets specified criteria.” The user isn’t found in that location in the LDAP directory.

Try these steps to address this issue:

Broaden your search query to include the entire directory: DC=example,DC=com (adjust to your DC values).
If that works, refine your search query how you like: search in a specific location, or search by a specific group.

When debugging problems with authenticating against an LDAP server, generally, the LDAP debug options are not necessary. Still, you need to use some trial and error and the authcli tool.

For more information, refer to Command Line.

In this section: