TOTPRadius supports different authentication modes which can be configured as described in the list below.
If the system you plan to use the TOTPradius with supports multiple authentication methods, the recommended method of configuring TOTPRadius is OTP Only. An example of such a system is Citrix Netscaler: it can be configured to use your LDAP Server (i.e. Active Directory) as the main authentication source and TOTPRadius as the secondary authentication mode.
With OTP Only mode, there is a possibility to allow each user to log in without the second factor for the first couple of times. This may be useful for projects where the second factor is planned to be configured by the users via the self-service mechanisms (for example, via Citrix StoreFront integration package).
Please note that this behavior is allowed by default, if you do not need to allow initial login, make sure you set this value to zero in the General Settings of your appliance.
LDAP Proxy mode
LDAP Proxy mode is useful when you need to enable two-factor authentication for systems that only support single-factor authentication. The principle behind it is that users will provide their AD or LDAP password together with the one-time passwords in the password field. TOTPRadius will then parse the password, split it into two parts and authenticate the OTP and if correct will send the AD/LDAP password part further to the AD/LDAP server configured. The order of authentication is exactly as stated above, OTP is checked first and AD after OTP is confirmed correct; this is done in order to prevent account lockouts during brute force attacks. Enabling LDAP Proxy on your TOTPRadius appliance allows implementing two-factor authentication for systems that do not natively support it, such as Cisco Meraki VPN, Cisco WLC, and many others.
LDAP username format
If the username expected by your LDAP servers should contain additional information, such as domain name, make sure it is specified in LDAP username format field in General Settings page. For example, if the user jsmith is to be presented to LDAP as [email protected] , the username format field should look like "%email@example.com" . TOTPRadius will replace %username% with he username submitted during authentication and/or tests. So when running LDAP test, only provide the username and the password.
LDAP group name format
LDAP search string is required if you want to limit access by AD group membership. The format should be something like "DC=yourdomain,DC=local". LDAP access is not restricted if this field is empty. After you set the LDAP search string, you can specify the LDAP Group name you want to allow to log in. The LDAP Group name field should contain the group name only.
Local passwords mode, as the name states, enables local passwords for user login. Please note that this feature is added primarily for tests and is not recommended for production use. The passwords are stored in the database in SHA1 hashed format.
Prior to v0.2.8, if this setting is enabled, LDAP feature gets disabled automatically. On the versions 0.2.8 and higher, LDAP and Local passwords can co-exist: if this mode is enabled and the password for the user is not set or set as 'ldap' authentication will be attempted against the configured LDAP servers.
Note that this password is for RADIUS authentication only and cannot be used to log in to Web administration panel. This mode does not support single factor mode or initial login attempt allowance. Note that this password is for RADIUS authentication only and cannot be used to log in to Web administration panel. This mode does not support single factor mode or initial login attempt allowance.
TOTPRadius is implementing TOTP the main secondary authentication mechanism. TOTP (Time-based One Time Password) is an open standard that specifies how one-time password (OTP) codes are generated. The algorithms are defined in RFC 6238. TOTP can be implemented using either software or hardware to generate the codes. TOTP can be delivered to the users by different methods, as described below.
TOTPRadius only supports TOTP generators with the following parameters:
The most cost-effective method of organizing access with 2FA is using mobile applications such as Google Authenticator, Microsoft Authenticator, Token2 Mobile OTP, Authy and hundreds of other compatible apps (the main requirement is TOTP support). The enrollment of the second factor can be done by the administrators or by users (if self-service is enabled and configured)
TOTP Hardware tokens
For users not having a compatible smartphone (or not willing to use their smartphones for 2FA for various reasons), TOTP hardware tokens can be used. While we recommend using our classic or programmable tokens (both are supported), any other tokens can be used as long as they have the same specifications (namely: SHA1, 6 digits and 30 seconds). TOTPRadius supports importing hardware tokens using a CSV file in the format same as used for Azure MFA.
Hardware token provisioning can be done by the administrators or by users (if self-service is enabled and configured). The appliance can optionally be configured to allow only one hardware token per user.
TOTP (software or hardware) remains the recommended second factor authentication methods. However, in addition to TOTP, you can then add one or both of the following fallback methods. The methods are SMS (based on Twilio API) or Email (based on SendGrid).
Please note that the fallback methods will be used only if the following conditions are met:
the API configuration is correct
the phone number and/or email address of the user is provided
the first attempt has failed (meaning that if you want to use SMS or Email to be sent, you should try to log in with a wrong OTP at least once to trigger the process)
To enable this method, you should provide the Twilio API key in the General Settings page and populate the phone number value for the user(s).
To enable this method, you should provide the SendGrid API key in the General Settings page and populate the email address value for the user(s).
In addition to TOTP, TOTPRadius allows using FIDO Keys (both legacy U2F and modern FIDO2 Security keys) as well as SAML-based OAuth2 authentication. However, these methods are currently available for VPN access only via the VPN portal functionality.