PAM configuration

Configure a custom realm

1.Create a custom realm for users logging in through a PAM module.

2.When configuring the RADIUS client, select the custom realm in the Users section.


Custom realm versus 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

1.Download PAM RADIUS tar.gz from

2.Extract the downloaded package by executing the following command in a terminal window:

tar xzvf pam_radius-release_2_0_0.tar.gz

3.Build the .so library by executing the following commands in a terminal window:
cd pam_radius-release_2_0_0
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

4.Copy the built library to the default location of PAM modules
cp /lib/security
cp /lib64/security
cp /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.

5.Create a server configuration file named server at /etc/raddb/. In it, type the details of the RADIUS server in the following form:
<radius server>:<port> <shared secret> <timeout in seconds>
For example: test 60

where: 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


6.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.



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 use_first_pass

In the command above, represents the path to an earlier configured PAM module, or it will be "". 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 type an OTP.

To ensure 2FA is not requested when the first factor failed, change auth required to auth requisite

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), or Non-2FA 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 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.