A user identity and password alone (known as “single factor” authentication) are not enough to mitigate persistent security risks. Additional methods for proving an identity, besides a secret pin or password, include the use of a biometric (something you are) and/or use of a hardware token or physical key (something you have). The security industry has coined the term two-factor (2FA) or multifactor for the requirement for two or more different methods of proving an identity (Sophos, 2014). More recently, mainstream digital security systems at large have integrated 2FA methods to reduce the impact of cybercrime and nation-state cyber threats that utilize attacks targeting the discovery, recovery, or theft of user passwords (Davis, 2015). Verizon’s 2015 Data Breach Investigation Report (DBIR) recommends 2FA as one of two top mitigation strategies for cyberattacks (Verizon, 2015). Cyber intruders have become so adept at password theft that, recently, the North American Energy Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) regulations for electrical transmission and generation systems have mandated the use of 2FA for all remote access into any devices that may negatively impact the reliability of the power grid if degraded or misused (NERC, 2014).
The most popular method for enabling the use of 2FA is through the addition of something you have, typically in the form of a piece of hardware or a software application on a smartphone, that is carried by the person at all times that generates a random One-Time Passcode (OTP). The user may then use the OTP (a random jumble of numbers and/or letters) in addition to the user’s password. To an attacker who has stolen a user’s credentials, any pilfered password is now worthless since the authentication system requires the additional OTP information that the user is physically carries at all times.
Many industries and organizations see the risk-reduction benefit of integrating 2FA systems into their user access control environments. However, any system administrator who has dealt with common enterprise 2FA services knows the difficulties that such systems can present. Many enterprise multifactor authentication systems require dedicated maintenance, are expensive; and from a technical difficult perspective, can be difficult to approach for most cybersecurity personnel. However, in addition to paid 2FA services, there are free, easy-to-approach, and easy-to-maintain alternatives (Davis, Two Factor Auth (2FA) Providers, 2015).
Currently, there are three different OATH OTP types that are the most widely used: event-based tokens, time-based tokens, and challenge-based tokens.
Event-Based Token (HOTP): An OTP system generates event-based tokens ondemand using a combination of a static random key value (HMAC; the H in HOTP) and a dynamic value, such as a counter (IETF, 2005). The event-based token is usually valid for a variable amount of time, but could be valid for an unlimited amount of time.
Time-Based Token (TOTP): An OTP system generates time-based tokens automatically every so often based on a static random key value and a dynamic time alue (such as currently time of day). The time-based token is only valid for a certain amount of time, such as 30 or 60 seconds (IETF, TOTP: Time-Based One-Time Password Algorithm, 2011). TOTP is a subset of HOTP.
Challenge-Based Token (OCRA): An OTP system generates challenge-based tokens on demand (IETF, OCRA: OATH Challenge-Response Algorithm, 2011), using a random challenge key that is provided by the authentication server at each unique user log-in. The challenge-based token is valid for a certain amount of time such as several minutes.
Event-based one-time passcodes (HOTP) may be usable for a long period of time, which increases the likelihood that the OTP could be stolen or misused. Time-based tokens (TOTP) are currently gaining in popularity over event-based tokens (HOTP) due to the additional security TOTP provides via a set, predictable windows of use for onetime passcode (typically 30-90 seconds).
Challenge-based one-time passcodes (OCRA) are a good choice for organizations that want the configuration process for end-users to be as painless as possible, since pushing a challenge token to a user only requires a phone number and/or email address. There are some downsides to the OCRA method, in that it is reliant on cellular or network connectivity between the authentication server and the user to ensure that the authentication process will function. Please see Table 1 for pros/cons of different OTP types.
Another decision for organizations implementing 2FA using an OTP system is what type of token client to use (either software-based or hardware). Highly secure environments may demand the use of small hardware devices that generate and display one-time tokens, since the security industry generally recognizes that it is more difficult to extract keys from or compromise hardware tokens. These are so-called “true” 2FA solutions (Sophos, 2014) that do not rely on any mobile network or software platform to get OTP tokens.
However, soft-tokens, OTPs that are generated and displayed by smartphone applications, are generally easier to manage and configure, and may be used with most every smartphone variety, which is a low-cost and end-user friendly decision, especially in organizations that are adopting Bring Your Own Device (BYOD) policies (see Figure 1). Here, we use the Google Authenticator smartphone application as a soft-token manager. Google Authenticator generates time-based one-time passcodes (TOTP).
OpenOTP™ Authentication Server by RCDevs is a highly configurable authentication server that utilizes open-source solutions and systems. OpenOTP is flexible enough to act both as a stand-alone option, using a free user database, or may be integrated into existing Microsoft® Active Directory® or other centralized user directory services or databases. OpenOTP stands out as an approachable method for introducing 2FA by easily enabling the addition of “something you have” to existing groups of existing users with passwords.
OpenOTP supports software tokens and hardware tokens, such as Yubikey, FIDO, SecuTech, and others, which can live on a person’s smartphone. Additionally, OpenOTP brings the following non-exhaustive list benefits to its administrators and end-users:
• Ability to install onto an existing Linux-based OS on commodity hardware • Ability to quickly commission and test via pre-packaged and pre-configured Virtual Machines (VMs) • Comprehensive documentation and support that is freely available on the OpenOTP website • Ubiquitous smartphone and hardware token support • Support for hardware security modules (HSMs) for safer storing of secret token information • Supports Initiative for Open Authentication (OATH) algorithms for better OTP hardware and soft-token interoperability • Active support and maintenance via RCDevs company developers • Free licenses for up to 40 active users • Support for three different OATH OTP types: event-based tokens, time-based tokens, and challenge-based tokens.
Users completing this guide will require basic to medium Ethernet networking skills. Some knowledge of virtual environments, security concepts, and Linux-based operating systems are helpful but not required.
Here, the author uses a virtualized environment using the following Operating Systems:
• Windows Server (2008 R2) • Linux with OpenOTP installed. The author used the RCdevs OpenOTP virtual instance with WebADM Web-Based Directory Administrator (download at https://www.rcdevs.com/downloads/index.php?id=VMWare+Appliances#) • Authentication clients that supports RADIUS. Here the author uses an OpenVPN Access Server virtual appliance (download at https://openvpn.net/index.php/access-server/download-openvpn-as-vm.html) • Laptop or workstation for testing, configuration, and hosting virtual machines The author recommends using virtualization for testing environment (e.g. VMware, VirtualBox, HyperV).
The author’s lab configuration consists of a Windows Server 2008 R2 as the primary user directory, the OpenOTP server (version 1.3.3-2) for 2FA and RADIUS communications, and then various “test” machines and devices (one Linux and one Windows).
The author will test the solution using the OpenVPN Access Server (version 2.0.12 at the time of writing) as an authentication clients.
Here, the author created a running Windows 2008 R2 instance with Active Directory Domain Services installed and functional. OpenOTP requires the following configurations on the AD server:
• X.509 certificate installed on the Windows Server or AD Domain Services service to protect the confidentiality of user data during LDAP transactions between OpenOTP and the user directory. Please ensure that a certificate is active, and that the AD instance can be accessed securely via the “STARTTLS” method on TCP port 389. NOTE: STARTTLS is not strictly required. However, be aware that unprotected LDAP binds will carry Domain Admin credentials in clear-text over the network. Also, Active Directory requires STARTTLS if you intend to allow OpenOTP to update confidential user data, such as user passwords. • Several distinct AD groups, with active members. The example of some active users and groups can be see (see Table 2 for users/groups the author will use). Please ensure that the users in the table are members of their respective groups. • DNS services should be installed and active on the AD server.
Three groups (Engineers, IT_Technicians, IT_Supervisors) and three respective users, “Ada Engineer”, “Ted Technician”, and “Bob Supervisor” were used. Then, OpenOTP Authenticator Server will be used to map the three groups to distinct authorizations on each authentication client (in the cases where authorizations are supported by the authentication clients).
In addition to the configurations mentioned above, OpenOTP requires access to the Active Directory® server using a user account with Domain Admin level privileges. OpenOTP uses the Domain Admin user account to extend the schema of the AD instance to support the OpenOTP attributes for users/groups and as a proxy user to authenticate to the AD server using LDAP protocol to checks the authenticity of users, accounts, and attribute data.
OpenOTP requires a “Super Administrators” user or group in the Active Directory server. Any member of this group has full access to the WebADM configuration interface. The author will use the “IT_Supervisors” group as the “Super Administrators” for OpenOTP. Alternatively, a user may use the Domain Administrators group (cn=Domain Admins,cn=Users,dc=otp,dc=home) as the Super Administrators group. The author uses the settings and attributes listed in Table 3.
NOTE: Readers may (rightly) point out that configuring the OpenOTP LDAP proxy user for Domain Admin authorizations is a potential security weakness. The OpenOTP LDAP proxy user can be a different user on the LDAP directory with more specific permissions. Please see Chapter 21 of the WebADM Manual “LDAP Permissions” for more information about how to restrict the authorizations of the OpenOTP LDAP proxy user (and to avoid using the AD Domain Administrator account).
In this section, the RCDev appliance WebADM service will be configured with the attributes necessary (see Table 3) for OpenOTP to integrate into Active Directory®.
NOTE: There is a mode for integrating OpenOTP into the AD server that will work without extending the LDAP schema. To see more about this process, see the WebADM Installation Manual Section 5.4, “Setup the LDAP Directory”. Also note that the Domain Controller the user connects to using OpenOTP does need to be the Schema Master for the Domain.
Your OpenOTP instance should now be integrated into the AD server.
If there are problems logging into WebADM after configuring /opt/webadm/conf/webadm.conf, the following are some tips:
• Turn on Syslog logging in /opt/webadm/conf/webadm and use the command“tail –f /var/log/messages” to see messages sent by the WebADM service inreal time. • Log into WebADM in UID mode using the full DN of a member of the groups listed in the super_admins section of webadm.conf. For the Domain Admins, this will be cn=Administrator,cn=Users,dc=otp,dc=home, or for theIT_Supervisors this will be cn=Bob Supervisor,cn=Users,dc=otp,dc=home.
Here user accounts and centralized user groups (found in Table 2) will be activated so that the OpenOTP Authentication Server can recognize them.
By now, various users and groups have been activated to be able to take advantage of the OpenOTP authentication server.
In this section, the OpenOTP is enabled to service itself and create TOTPs for the test users. NOTE: This next section requires the Google Authentication smartphone application.
NOTE: A variety of token types for the user from this menu can be enabled, including the option to enable a pin code for the user to use with the TOTP. This would enable 2FA without the need to enter the user’s LDAP password, similar to how RSA® multifactor tokens function. This feature is outside of the scope here.
NOTE: You can have a user self-configure their own TOTP using Google Authenticator by activating other WebADM services that are available. For example, the User Self-Service Desk application allows users to configure their own personal information (phone numbers, email addresses, etc.), LDAP password, and OTP tokens without requiring direct guidance from an administrator.
If you have problems authenticating using the test users’ LDAP and TOTP password combinations, please see the following tips:
• Ensure the LDAP password for the user is correct. • Ensure that you have successfully registered the TOTP token before attempting to use it. • Ensure the RCDevs appliance is getting accurate time via NTP. • Turn on Syslog logging in /opt/webadm/conf/webadm.conf and use the command “tail –f /var/log/messages” to see messages sent by the WebADM service in real time. • You may also view logs directly from the WebADM service by using the command “tail /opt/webadm/logs/soapd.log” (see Figure 26).
Here we will test 2FA for one or more test users using the OpenOTP RADIUS Bridge service. Please ensure you have 2FA using LDAP password and Google Authenticator TOTP working successfully in the previous section before attempting to perform the steps in this section.
In the case of the author, the command to test the Ada Engineer user’s authentication is:
Note that on systems using the bash shell, the ‘$’ symbol is special, and therefore must be escaped using the backslash ‘\’ symbol (see Figure 28).
If you have problems authenticating to the OpenOTP RADIUS Bridge using the radtest client, please see the following tips:
• Ensure the LDAP password and TOTP token for the user are correct, and that you have registered the TOTP token for the user. • Ensure the RCDevs appliance is getting accurate time via NTP. • You may download and install tcpdump, then using the command “tcpdump –i eth0 port 1812 –vvv” to show incoming RADIUS packet requests and responses in real time. • You may view /opt/webadm/logs/soapd.log for OpenOTP Authentication Server debug information, or /opt/radiusd/logs/radiusd.log (see Figure 30) for /opt/radiusd/logs/requests.log for or debug information from the radius service.
To configure an OpenVPN Access Server (AS) authentication client that with RADIUS protocol, please follow the steps outlined in this section.
NOTE: the author uses an OpenVPN AS server virtual instance downloaded from the openvpn official website. The IP address of the author’s OpenVPN AS appliance is 10.200.3.12.
NOTE: The official OpenVPN AS client does support challenge mode. However, the unofficial OpenVPN client (currently 2.3.6 as of April 20, 2015) does not support challenge mode, and will fail the authentication session if it receives a challenge from the OpenVPN AS instance.
NOTE: OpenVPN AS does support additional user authorizations using RADIUS attributes .
If you are having trouble authenticating to OpenOTP via the OpenVPN AS instance, please see following troubleshooting steps.
• Ensure the LDAP password and TOTP token for the user are correct, and that you have registered the TOTP token for the user. • Ensure the RCDevs appliance is getting accurate time via NTP. • You may view /opt/webadm/logs/soapd.log for OpenOTP Authentication Server debug information. • You may view /opt/radiusd/logs/radiusd.log or /opt/radiusd/logs/requests.log for or debug information from the radiusd service. • You may download and install tcpdump, then using the command “tcpdump–i eth0 port 1812 –vvv” to show incoming RADIUS packet requests and responses in real time. • If you are having trouble authenticating to the OpenVPN AS instance, please ensure that you are using an OpenVPN AS client that supports challenge mode. • If you are having problems remaining connected to the OpenVPN AS instance, please ensure that you have configured the “reneg-sec 0” parameter on both the OpenVPN server and client profiles. This will prevent the OpenVPN server from attempting to renegotiate the, which forces the user to re-authenticate to the OpenOTP Authentication Server using a username/password + TOTP code.
By now the reader should have an understanding of the effort involved with integrating 2FA into an existing user directory, and the basics for configuring various authentication client devices to interact with the OpenOTP Authentication Server. Administrators can configure most any device that supports RADIUS for user-based authentication purposes to allow users to use their AD username/password with Google Authenticator token. Solutions such as OpenOTP are inexpensive, and are easy to configure and maintain (especially for smaller organizations).
Published with the express permission of the author.