Authentication
Access Server provides robust user credential authentication. You can use an internal local user properties database (default) or external authentication systems using PAM, LDAP, RADIUS, SAML, or a custom Python script. Access Server supports using these systems simultaneously, where you define a default authentication system and optionally configure other authentication systems by groups or users.
Plugins are also available for RADIUS, LDAP, and SAML group mapping, Duo MFA, and others. Refer to Access Server Plugins.
The Authentication: Settings page gives you configuration options for user authentication options, including a local database or external systems using PAM, RADIUS, LDAP, SAML, or a custom post-auth script.
Default Authentication System
Access Server provides six user authentication methods: Local, PAM, RADIUS, LDAP, SAML, and PAS-only. Each varies in configuration requirements and has different databases containing different user permissions and credentials.
Local | By default, Access Server uses local authentication. With local auth, Access Server stores user information in a SQLite database included in the package at: /usr/local/openvpn_as/etc/db/userprop.db. |
PAM | There are no configuration options for PAM authentication in the Admin Web UI. If you select PAM, the underlying OS manages the PAM user credentials. |
RADIUS | To enable RADIUS, you must configure it under Authentication: RADIUS. For more details, click here for information on the RADIUS page. |
LDAP | To enable LDAP, you must configure it under Authentication: LDAP. For more details, click here for information on the LDAP page. |
SAML | To enable SAML, you must configure it under Authentication: SAML. For more details, click here for the information on the SAML page. |
PAS only | To enable post-auth-script-only authentication (PAS only), you must configure it with your own custom post-auth script. For more details, click here for information about PAS-only authentication. |
Local User Passwords
Here you can configure password options for any users authenticating via the local authentication system:
Allow local users to change password: Determines whether your users can change their passwords on the Client Web UI.
Enforce strong passwords when changing: Determines whether users can create any password of any length they choose or if they must meet rules for strong passwords which include eight characters in length, contain a digit, contain an uppercase letter, and contain a symbol from !@#$%&’()+,-/[\]^_{|}~<>.
External User Registration
You can configure whether Access Server automatically registers external users who have access from a configured external authentication system you set as the default.
Deny access to unlisted accounts by default:
No: Access Server grants access. The user successfully authenticates with the external system, Access Server grants access, and automatically adds the user to the User Permissions table. This is the default setting.
Yes: Access Server denies access. The user successfully authenticates with the external system but doesn’t exist in Access Server’s user permission table, so Access Server denies access.
TOTP Multi-Factor Authentication
When enabled, time-based one-time passwords (TOTP) add an added layer of login security. You can use the TOTP system of your choice, such as Google or Microsoft authenticator apps, to add multi-factor authentication for your Access Server users.
Enable TOTP MFA by setting the toggle to Yes and saving. Once enabled, your users enroll from the Client Web UI to scan a QR code or enter the enrollment code into a TOTP MFA app.
To enable TOTP MFA for specific users and groups, refer to User Permissions and Group Permissions.
Password Lockout Policy
The password lockout policy protects your server by locking a user after repeated failed authentications. By default, the lockout triggers when a wrong password is entered five times consecutively within 15 minutes. You can modify the number of allowed attempts or the lockout time frame by changing these settings here:
Failed attempts until lockout occurs: The number of times a user can try an incorrect password before being locked out.
Lockout release timeout in seconds: How long a user is locked out after reaching the set failed attempts in seconds (900 seconds = 15 minutes).
The Authentication: RADIUS page allows you to use remote authentication dial-in user service (RADIUS) to authenticate users via an external directory server. It provides an interface to choose the RADIUS authentication method and define the RADIUS servers.
RADIUS Settings
With the toggles in the RADIUS settings section, you can enable RADIUS authentication, accounting reports, and case-sensitive matching.
Enable RADIUS Authentication | Set the toggle to Yes to enable RADIUS authentication as the default authentication or for assigned users and groups. With the toggle set to No, RADIUS authentication isn't used as an additional authentication method. |
Enable RADIUS Accounting reports | When enabled, Access Server sends accounting requests to the RADIUS server via the accounting port. |
Account names are case-sensitive | When you set case-sensitive to Yes, Access Server uses case-sensitive username matching. The user admin is different from Admin; the two different users have their own settings. If you set case-sensitive to No, you could have a lowercase user, admin, on Access Server and an uppercase user, Admin, on the RADIUS server, but Access Server grants both users the same rights. |
RADIUS Server
This section allows you to configure RADIUS servers for authentication. Access Server supports the configuration of up to five RADIUS servers.
Hostname or IP Address | Specify the hostname or IP address for each RADIUS server. |
Shared Secret | Specify the shared secret. You must configure the RADIUS server with the same shared secret. |
Authentication Port | Define the port where the RADIUS protocol sends UDP packets. The default port is 1812. |
Accounting Port | Define the port where the RADIUS protocol listens for accounting requests. The default port is 1813, and the accounting port is only required when you enable RADIUS accounting. |
Verify Message-Authenticator Attribute | Whether to verify the integrity and authenticity of RADIUS messages. The message-authenticator contains a 16-byte HMAC-MD5 hash of the entire RADIUS packet, including the shared secret, ensuring that the packet hasn't been tampered with and is from a trusted source. |
RADIUS Authentication Method
Access Server supports RADIUS protocol for three methods:
PAP: password authentication protocol; sends the username and password in plaintext.
CHAP: Challenge handshake authentication protocol; masks the username and password by encrypting the communication.
MS-CHAP v2: Microsoft challenge handshake authentication protocol version 2 (MS-CHAP V2) is Microsoft’s version of CHAP that also masks the username and password by encrypting the communication.
We recommend using CHAP or MS-CHAP v2. In some situations, using PAP is as secure as the former methods, such as if your VPN doesn’t need to send its traffic over the internet or if you deploy the RADIUS server or agent on the same host where Access Server is running.
Authentication: LDAP allows you to configure authentication for LDAP. You must have some basic knowledge of the LDAP syntax. You must also have an LDAP server if you want Access Server to authenticate using the LDAP protocol.
LDAP Settings
This section allows you to enable LDAP authentication, SSL connections, case-sensitive account name matching, and autologin profile behavior.
Enable LDAP Authentication | Set the toggle to Yes to enable LDAP as the default authentication or for assigned users and groups. For example, you can create administrators for Access Server that use local authentication and LDAP authentication for VPN users. With the toggle set to No, LDAP authentication isn’t used as an additional authentication method. |
Use SSL to connect to LDAP servers | This setting establishes a secure, SSL-protected connection to the LDAP servers(s) for all LDAP operations. |
Account names are case-sensitive | This setting determines whether authentication matches case sensitivity for the usernames. |
Re-verify autologin user on connect | When enabled, this check forces Access Server to check that a user exists in the LDAP directory when connecting with an autologin profile. If disabled, it’s possible that a user downloaded an autologin profile when the user account matched a user on the LDAP server. However, it has since been removed from the LDAP directory and could still connect with the autologin profile. |
LDAP Server
In this section, you can define settings for Access Server to properly look up user credentials with an LDAP server when attempting to authenticate.
Primary Server | Define the primary LDAP server, either as a hostname or IP address. |
Secondary Server | (Optional) Define the secondary LDAP server. If present, Access Server attempts to communicate with the secondary server if the connection to the primary server fails. |
Credentials for Initial Bind | This setting determines if Access Server binds to the LDAP server anonymously or with specified credentials for the initial bind. We recommend using credentials as a security best practice. |
Base DN for User Entries | Access Server uses this base distinguished name (DN) to perform an LDAP query to find the user's entry. |
Username Attribute | The username attribute is the field name from the LDAP attributes of your LDAP server that represents the user ID, such as uid or sAMAccountName. |
LDAP filter (optional) | This optional setting specifies a restriction (in LDAP query form) on a user's LDAP entry that must be true for the authentication to succeed. You can also use it to require membership in a particular LDAP group (specified by its group DN) for all users permitted to authenticate to Access Server. |
Authentication: SAML allows you to configure authentication for Security Assertion Markup Language (SAML). SAML is an open standard you can use to communicate between Access Server and identity providers (IdP) to pass credentials for user authentication.
SAML Settings
In this section, you can enable SAML authentication, use the information provided to configure your IdP with Access Server as the service provider, and configure the timeout, hostname, certificate, and key.
Enable SAML authentication | Set the toggle to Yes to enable SAML as the default authentication or for assigned users and groups. For example, you can create administrators for Access Server that use local authentication and use SAML authentication for VPN users. With the toggle set to No, SAML authentication isn’t used as an additional authentication method. |
Send ForceAuthn flag to IdP to require user interaction | When set to yes, this forces users to authenticate with the IdP regardless of any authenticated state with the IdP. |
Send custom AuthnContext to IdP | When set to Yes, Access Server includes an AuthnContext in the SAML request using the value(s) specified in the field below. When set to No, no AuthnContext is sent and the field below is hidden. |
AuthnContexts to include in the AuthNRequest. This is a space separated list of AuthnContext to request. | Visible only when the setting above is Yes. Pre-filled with |
Service Provider (SP) identity and URL | Provide this information for Access Server as your service provider to the IdP. |
VPN Authentication Timeout (seconds) | This timeout determines how long the SAML session is valid. The default is 180 seconds. |
Hostname | The hostname is the Access Server hostname as a service provider. The default is the server's hostname. You can optionally set this to a different, SAML-specific hostname. |
SP Certificate | The SP certificate is the service provider certificate for your Access Server. It is a PEM-formatted SAML certificate. By default, Access Server generates the certificate provided here. Optionally, you can change it to a custom certificate. |
SP Private key | The SP private key is the service provider private key for your Access Server. It is a PEM-formatted SAML private key. By default, Access Server generates the private key provided here. Optionally, you can change it to a custom private key. |
Configure Identity Provider (IdP) Automatically via Metadata
In this section, you can use a metadata URL or metadata file to configure the connection with your IdP automatically.
IdP Metadata URL | Enter the metadata URL from your IdP and click Get to configure IdP settings automatically. |
Select IdP Metadata File | Select a file from your IdP and click Upload to configure IdP settings automatically. |
Configure Identity Provider (IdP) Manually
In this section, you can provide the values needed to configure the connection with your IdP manually.
IdP EntityID | Enter the identity provider issuer or identifier. |
Sign-on Endpoint | Enter the identity provider's single sign-on URL or login URL. |
Log-out Endpoint (optional) | Enter the optional log-out URL. |
Certificate (PEM) format | Enter the IdP certificate as text. |