Introduction
This document provides an overview of user credential authentication for OpenVPN Access Server. OpenVPN Access Server can use the internal local user properties database (default) or external authentication systems using PAM, LDAP, RADIUS, or SAML. Access Server 2.10 and newer supports using these systems simultaneously, where you define one authentication system as the default authentication system and optionally configure other authentication systems by group or user. On older versions of Access Server, you can only use one authentication system at a time.
On top of user-credential authentication, Access Server also uses certificates and private keys. Verification of client and server identity is done with private keys and public certificates, which is mostly automated. While this is part of the overall authentication system in OpenVPN Access Server, this document details mainly the user credential authentication system. The methods used for authentication for VPN connectivity depend on the connection profile type used and the server configuration. Connection profiles generated by Access Server for OpenVPN clients contain a public CA certificate signed by the OpenVPN Access Server’s internal PKI CA. OpenVPN clients use this to verify the identity of the server. Connection profiles of the user-locked and autologin types contain sets of private keys and public certificates, and the server verifies these. User-locked profiles only work with the credentials for that specific user, and server-locked profiles work with any valid user credentials. You can also configure additional challenges such as MFA or post_auth conditions for your server.
Note: Connection profiles of the autologin type authenticate using their certificate only and bypass credential-based authentication.
Authentication systems
You can configure authentication for OpenVPN Access Server to meet the needs of your users. If you have an existing directory service you can configure Access Server's support for an external authentication system.
Local authentication
By default, Access Server uses local authentication. The local authentication system uses password hashes (SHA256) stored in the user properties database to verify credentials during login. The user properties database is always used to define settings per group and per user. These settings include access control rules, autologin privilege, administrative login privilege, MFA data, and other settings for the group or user. If a user authenticates with the local authentication mode, the password hash stored in the user properties database is used. The Admin Web UI provides easy user management for the administrator to set up accounts, permissions, and granular access control. The password credentials managed via the Admin Web UI only apply to locally authenticated users. Likewise, the Client Web UI functionality to allow users to change their passwords only applies to locally authenticated users. User accounts authenticated via external systems such as PAM, LDAP, and RADIUS, have their credentials verified and managed through that external system.
External authentication
OpenVPN Access Server also integrates with external authentication systems using PAM, LDAP, RADIUS, and SAML. For each system, Access Server stores user-specific certificates and settings in the certificates database and the user properties database, but the password setting, resetting, storage, and validation, remain with the external authentication system. When a user enters credentials in the Client Web UI or an OpenVPN client, these are relayed to the external authentication system for validation. If they pass, the user successfully signs in.
For LDAP, RADIUS, and SAML, you must configure them first in the Admin Web UI. Ensure you configure them to contact the correct directory servers with the necessary authentication and connection details. You must also enable the specific authentication method before users can authenticate with that method. You configure and enable these with the Admin Web UI via the Authentication > LDAP, Authentication > RADIUS, and Authentication > SAML screens.
Note: You must configure the authentication system before you can use SAML, LDAP, or RADIUS.
TOTP Multi-Factor Authentication
You can add another layer of security with multi-factor authentication (MFA) using time-based one-time passwords (TOTP), an industry-standard method of using a user device to store a secret key. Using the current time and date and the secret key, a calculation is done that yields a 6-digit code. This key changes every 30 seconds. You can require this MFA code for authentication in addition to certificates and credentials. If the server and client agree on the code, then authentication is allowed to proceed. Typical programs you can use to generate these codes include Google Authenticator, Microsoft Authenticator, Duo, LastPass MFA, Bitwarden, and others. You can also use hardware devices that generate TOTP keys. OpenVPN Access Server can accept codes generated by any of these devices provided that the time and date are correctly set, and the secret key is agreed between the server and the device generating the MFA codes.
Access Server also supports custom MFA by implementing this in post_auth scripts. With a post_auth script, you can define a custom question/answer set according to your specifications.
Note: Only one MFA system can be active. An MFA challenge implemented in a post_auth script overrides the built-in TOTP MFA functionality of Access Server.
Custom authentication with post_auth scripts
Using post_auth scripts, you can write custom Python3 code to load into Access Server’s post_auth programming hook, allowing you to supplement or even replace the authentication system. It is called a post_auth script because it is typically executed after successfully authenticating with username and password. After successful authentication, the post_auth script can add additional challenges or checks such as verifying a connecting device’s UUID/MAC address or issuing a custom MFA challenge. The post_auth script can deny or allow the VPN connection to establish, based on the response. For more information, refer to Access Server Integrations.
Mixing authentication systems
OpenVPN Access Server 2.10 and newer supports mixing different authentication systems. OpenVPN Access Server 2.9 and older allowed only one authentication system. For example, on Access Server 2.10 and newer, you can configure certain user groups to authenticate with an LDAP server while other users or groups authenticate via the local authentication system. Access Server supports any combination of authentication systems on the server, but you can only assign one authentication system to an individual user account. This is set on the user or group object using the user_auth_type property.
One authentication system must be the global default authentication system. By default, this is the local authentication system. This is defined in the configuration database with the key auth.module.type. Local authentication is the authentication system used by all accounts that don’t have it configured otherwise. You can set authentication at the user, group, or global level. As you add users, you can configure them individually to use a particular authentication system, or they can inherit the authentication system setting from a group or the global default authentication system. When you change the default authentication system, all users and groups that don’t have the authentication system specifically set will adhere to the new default setting and use the new default authentication system. Any users or groups specified to use another authentication system will continue to use that configured authentication system.
Main administrative account
The installation of OpenVPN Access Server executes the initialization script ovpn-init. This script creates the necessary configuration files and sets up the main administrative account. Depending on how you install Access Server, the initialization procedure runs in batch mode, assuming all default settings, or it runs in interactive mode, allowing you to deviate from the default settings. In either case, you can still adjust any settings later on. One of the settings is the account name for the main administrative account. By default, this is openvpn. In batch mode, Access Server 2.10 and newer generates a random password and prints it on the console. In interactive mode, you can choose to specify your own administrative account’s username and password. On Access Server 2.9 and older, the administrative account was configured as a bootstrap account and added to the operating system, and you have to then set the password yourself on the operating system account.
You use the main administrative account to get started accessing the Admin Web UI for your Access Server and configure things further. We recommend adding new users who do not have administrative privileges for VPN access.
Bootstrap accounts
Bootstrap accounts are always authenticated with PAM regardless of the configured authentication system. These are accounts defined in the as.conf file and exist in the operating system as PAM authenticated users. On Access Server versions older than 2.10, where multiple authentication system support was not yet present, this was the method to log in to the Admin Web UI with an account that authenticates on the Access Server itself regardless of the chosen authentication system. When Access Server starts up and sees bootstrap accounts, as shown in the example below, it sets them to authenticate through PAM.
Bootstrap account entry in /usr/local/openvpn_as/etc/as.conf:
boot_pam_users.0=openvpn
The bootstrap account is endowed with specific additional privileges. It is automatically granted administrative login privileges. On Access Server 2.9 and older, it also bypasses the post_auth script, any MFA requirement, and the password lockout policy. If you are on Access Server 2.9 or older, we recommend upgrading to the latest version, removing this bootstrap account, and then using the reset default administrative account instructions to create a local administrative account. This results in a more secure administrative account that is no longer in the operating system and adheres to MFA and lockout policies.
With the changes since Access Server 2.10, we now recommend to anyone still relying on the bootstrap user account on their Access Server to follow the recommendation laid out in the secure the openvpn administrative account section in our documentation.