PAM configuration
Configure a custom realm
- Create a custom realm for users logging in through a PAM module.
- When configuring the RADIUS client, select the custom realm in the Users section.
Custom realm vs. Current AD domain If a custom realm is selected, and the PAM module sends "domain\username" to the ESA RADIUS server, then a user with the username "domain\username" is created in the custom realm. If you select Current AD domain or Current AD domain and domains in trust instead of a custom realm, and the PAM module sends "domain\username" to the ESA RADIUS server, a user with the username "username" will be created in the "domain" realm. |
PAM Authentication Module
- Download PAM RADIUS tar.gz from https://freeradius.org/sub_projects/
- Extract the downloaded package by executing the following command in a terminal window:
tar xzvf pam_radius-release_2_0_0.tar.gz
- Build the .so library by executing the following commands in a terminal window:
cd pam_radius-release_2_0_0
./configure
make
On Linux, for example OpenSuse, depending on the output of the configure command, dependencies might have to be installed.
sudo zypper install gcc make pam-devel - Copy the built library to the default location of PAM modules
Linux:
cp pam_radius_auth.so /lib/security
or
cp pam_radius_auth.so /lib64/security
Mac:
cp pam_radius_auth.so /usr/lib/pam
On OS X El Capitan and later, this location is protected by System Integrity Protection. To use it, you have to disable it for the copy command.
- Create a server configuration file named server at /etc/raddb/. In it, enter the details of the RADIUS server in the following form:
<radius server>:<port> <shared secret> <timeout in seconds>
For example:
1.1.1.1 test 60
where:
- 1.1.1.1 represents the IP address of ESA RADIUS server
- test is the shared secret of a RADIUS client configured in ESA Web Console
- 60 is the time in seconds how long to wait for the approval of push notification
- Apply appropriate security permissions to the configuration file
- chown root /etc/raddb
- chown root /etc/raddb/server
- chmod 600 /etc/raddb
- chmod 600 /etc/raddb/server
See INSTALL for security recommendations for the configuration file and USAGE for parameters that can be passed to the library. For example you can use the 'debug' parameter to identify potential problems.
Incorporating the PAM module
PAM modules may be incorporated into various login types, for example, login, sshd, su, sudo and so on. The list of login types available is located at /etc/pam.d/ .
- sshd - Remote login using SSH
Make sure to set ChallengeResponseAuthentication to yes in /etc/ssh/sshd_config. |
- sudo
- su
- common-auth - OpenSUSE (all authentications)
- login - OpenSUSE (console login)
- authorization - macOS logon screen
To enable two-factor authentication for any of the services above, add the following line to the corresponding configuration file in /etc/pam.d:
auth required pam_radius_auth.so use_first_pass
In the command above, pam_radius_auth.so represents the path to an earlier configured PAM module, or it will be "pam_radius_auth.so". use_first_pass ensures the PAM module does not require an additional password (OTP) in vain, unless ESA RADIUS requires the second factor. For example, if a user with 2FA protection has Push Authentication enabled, then the PAM module waits only for the approval of the Push notification without requesting to enter an OTP.
To ensure 2FA is not requested when the first factor failed, change auth required pam_unix.so to auth requisite pam_unix.so.
Some login interfaces, including the macOS login screen, cannot display a separate field for 2FA. In such cases, only users using Push authentication (Mobile application push), Non-2FA users, paused users or users from a whitelisted IP address can log in. To ensure that only the Mobile application push is used without prompting for OTP even if the user had additional 2FA options enabled, add client_id=challenge_never to the configuration line:
auth required pam_radius_auth.so use_first_pass client_id=challenge_never
Available values for client_id:
- challenge_if_possible - The default option always prompts for OTP if the user has any OTP type enabled, even if sending "Mobile application push" succeeded.
- challenge_always - Always prompt for OTP, even if sending "Mobile application push" succeeded and the user does not have any type of OTP enabled. It always allows you to enter MRK if something goes wrong. (this is recommended for critical scenarios, for example, SSH login to a remote server that cannot be easily accessed otherwise)
- challenge_if_needed - Never prompt for OTP if sending "Mobile application push" succeeded", thus avoiding additional OTP request/field and allowing faster login.
- challenge_never - Never prompt for OTP.
On some Linux distributions it is easily possible to change the login manager. For example, gdm supports prompting for additional information.