Access Server's Flexible User Authentication System
Access Server provides a flexible user authentication system that supports multiple methods: LDAP, RADIUS, SAML, PAM, and built-in auth.
This topic provides an overview of Access Server's user credential authentication. Access Server can use the internal, local user properties database (default) or an external authentication system via PAM, LDAP, RADIUS, or SAML.
Multiple authentication methods
Access Server 2.10 and newer supports multiple authentication methods. You define one authentication system as the default and configure other authentication systems by group or user.
On older Access Server versions, you can only use one authentication system at a time.
Certificates and keys
In addition to user-credential authentication, Access Server also uses certificates and private keys. Private keys and public certificates verify client and server identity, and this process is mostly automated. While this is part of the overall authentication system in 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. User-locked and auto-login connection profiles contain private keys and public certificates, which the server verifies. 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 for your server, such as MFA or post_auth conditions.
Tip
Auto-login connection profiles authenticate using only their certificate and bypass credential-based authentication.
Authentication methods
You can configure Access Server's authentication to meet the needs of your users with local or external authentication. You can configure Access Server's support for an external authentication system if you have an existing directory service.
Local authentication
Access Server's default authentication method is local authentication. The local authentication system uses password hashes (SHA256) stored in the user properties database to verify credentials. When you define group and user settings, these are also stored in the user properties database. These settings include access control rules, auto-login privileges, administrative privileges, and MFA data. When a user authenticates with local authentication, the password hash stored in the user properties database is used.
You can manage your user accounts, permissions, and granular access control from the Admin Web UI, including password management. Likewise, when you allow users to change their passwords in the Client Web UI, this only applies to locally authenticated users. Users authenticating against external systems must have their credentials verified and managed through that external system.
External authentication
Access Server can integrate with external authentication systems using PAM, LDAP, RADIUS, and SAML. For each system, Access Server stores user-specific certificates and settings in the certificates and user properties databases, 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.
You must first configure LDAP, RADIUS, and SAML 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. We provide tutorials for many setups.
Tip
Before using SAML, LDAP, or RADIUS, you must configure the authentication system.
TOTP multi-factor authentication
You can add another security layer 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 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. Authentication can proceed if the server and client agree on the code. 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. 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 upon 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.
Important
Only one MFA system can be active. An MFA challenge implemented in a post-auth script overrides Access Server's built-in TOTP MFA functionality.
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 be established based on the response. For more information, refer to Plugins.
Mixing authentication systems
Access Server 2.10 and newer supports mixing different authentication systems. 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 others 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 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/penvpn_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 creating a local administrative account. Refer to Reset openvpn Account Admin Access for the steps. This results in a more secure administrative account that is no longer in the operating system and adheres to MFA and lockout policies.