Other RADIUS configurations

VPN Type - VPN does not validate AD username and password

If you set VPN Type to VPN does not validate AD username and password when configuring a RADIUS client in ESA Management Tool, both factors (AD username and password as first factor, and OTP as second factor) are verified by ESA:

radius_config_vpn_doesnotvalidateadunameandpwd

 

Afterward, in /etc/pam.d/sshd (or other integration), add the following line:

auth required /usr/lib/pam/pam_radius_auth.so

and comment (place a # tag at the beginning) all the other auth lines.

note

Note

The domain administrator must verify whether this scenario- specifically disabling all other modules - is suitable for their deployment.

 

In this case a SSH login process would look like this:

SMS delivery of OTP - at the first password attempt, the user is prompted for an AD password. At the second password attempt, they enter their OTP.

pam-bothfactors-smsmobile-ssh

Other type of OTP  (compound authentication) - the user must enter both the AD password and OTP at the same time as ADpasswordOTP. For example if your AD password is Test and the received OTP is 123456, you would enter Test123456.
pam-bothfactors-mobilecompound-ssh

 

VPN Type - VPN validates AD username and password

if you set VPN Type to VPN validates AD username and password when configuring a RADIUS client in ESA Management Tool, then  the first factor (AD username and password) is validated by the other PAM module:

radius_config_vpn_validatesadunameandpwd

 

When configuring RADIUS in this manner, add the following line in /etc/pam.d/sshd (or the appropriate integration):

auth required /usr/lib/pam/pam_radius_auth.so force_prompt prompt=RADIUS

 

In this case a SSH login process would look like this:

prompts that start with the string Password: are handled by other PAM modules. Prompts that begin with the string RADIUS: are handled by our PAM module. See the argument 'prompt=RADIUS' in the sample code above

SMS - at the first prompt, a user must enter their AD password. At the second prompt, they must enter the text 'sms' (without apostrophes). At the third prompt, they must enter their AD password. At the fourth prompt, they must enter the received OTP

pam-secondfactor-sms-ssh

Other type of OTP (OTP received via mobile application or a hard token) - enter the AD password at the first attempt. At the second attempt enter the OTP.

pam-secondfactor-mobile-ssh

 

Non-2FA users (user accounts not using 2FA)

When configuring the PAM module for ESA, remember to consider the experience for non-2FA users - for example local Linux/Mac users as opposed to domain users.

Linux:

Using this configuration, a RADIUS server would fail authentication for local users unless the following code (or appropriate for your system) is added in /etc/pam.d/sshd (or the appropriate file for your PAM module):

auth sufficient pam_unix.so try_first_pass

This edit makes standard Unix authentication sufficient to log in, so any local user will be allowed after entering a local password. To allow domain users whose accounts are not secured with 2FA, enable Active Directory Passwords without OTPs when configuring the RADIUS client in ESA Management Console.

Mac:

There is no default PAM module to authenticate local users as on Linux (see above). To achieve this, another PAM module must be used. In this guide, we chose to download a collection of modules for PAM and then build the module by running the following commands in a terminal window:

./configure --disable-pgsql --disable-mysql --disable-ldaphome

make

make install

 

The next steps depend on whether 2FA integration is intended for use with desktop logins or non-desktop logins (for example ssh).
 

Mac non-desktop login integration:

in the integration-specific /etc/pam.d/ file, add the following line before pam_radius_auth.so:

auth sufficient /usr/local/lib/security/pam_regex.so sense=allow regex=^user$
 
 
where user is a local username that we want to be allowed without the requirement of an OTP.

 

make sure the default Mac modules (not added by us) are defined as "required" or "requisite", so that this added "sufficient" module does not cause a success if the first factor failed  

modules other than pam_regex from the collection of Modules for PAM may be used also. For example you could use pam_groupmember to allow groups of users instead of single users to log in.

 

Mac desktop login integration:

change the /etc/pam.d/authorization file so it looks like this:

# authorization: auth account

auth    sufficient /usr/lib/pam/pam_radius_auth.so

auth    requisite /usr/local/lib/security/pam_regex.so sense=allow regex=^user$

auth       optional       pam_krb5.so use_first_pass use_kcminit

auth       optional       pam_ntlm.so use_first_pass

auth       required       pam_opendirectory.so use_first_pass nullok

account    required       pam_opendirectory.so

 
Those changes ensure that:

1.our RADIUS PAM module is listed first as 'sufficient'

2.our regex PAM module is the second as 'requisite'

3.other modules that were in the file before follow later