You can enable Defender authentication for a PAM-enabled service by adding the Defender PAM to the system PAM configuration for that service. Some UNIX/Linux systems store system PAM configuration in the /etc/pam.conf file, while others keep PAM configuration in a set of files in the /etc/pam.d directory.
To configure the Defender PAM on your system, you can use a PAM configuration utility and script supplied with the Defender PAM. For example, to configure Defender authentication for a single service such as sshd, run the following command:
/opt/quest/libexec/defender/configure_pam_defender.sh sshd add
This script establishes the correct location for the specified service and adds the configuration for the Defender PAM. If you want to configure Defender authentication for more than one service, run the script again, specifying a new service name in place of sshd.
You can use this same script to remove the Defender PAM configuration. To do this, run the following command:
/opt/quest/libexec/defender/configure_pam_defender.sh sshd remove
Before enabling the Defender PAM for the sshd service, ensure that the use of PAM modules and challenge-response authentication are enabled on the ssh server. For example, on OpenSSH servers the /etc/ssh/sshd_config file should contain the following configuration lines:
UsePAM yes
ChallengeResponseAuthentication yes
You will need to restart sshd after making any changes to the sshd_config file.
Any ssh clients used to login to the server should also be configured to allow challenge-response authentication. For example, on OpenSSH clients, the following line should exist either in the system ssh config file (/etc/ssh/ssh_config) or in the user’s ssh config file (~/.ssh/config):
ChallengeResponseAuthentication yes
When a user accesses a service that has been configured for Defender authentication, they are prompted for a Defender token passcode, as shown in the example below:
$ ssh jbloggs@unix002
Passcode:*******
Password:*******
Last login: Wed 14 May 14:03:22 2014 on /dev/pts/2 from unix001
$
After entering a valid passcode, the user may be prompted for further credentials, depending on other authentication methods in the service’s System PAM configuration, for example, UNIX password authentication or Authentication Services AD authentication.
Please refer to the PAM_DEFENDER (5) man page on your UNIX system for more information on the Defender PAM (use the command man –M /opt/quest/man pam_defender to display the man page).
The Defender PAM communicates with the Defender Security Server via the RADIUS protocol. The communication details for the Defender Security Server must be specified in the /etc/defender.conf file. This file must be readable by all.
The entries in the file must have the following format:
<hostname>:<portnumber> <sharedsecret> <timeout>
where
- <hostname> is the name of the RADIUS server, that is, the Defender Security Server.
- <portnumber> is the port number on which the Defender PAM will communicate with the RADIUS server. There must be no spaces between <hostname> and <portnumber>.
- <sharedsecret> is the shared secret specified for the Defender PAM and the RADIUS server.
- <timeout> is the length of time, in seconds, after which the connection between the Defender PAM and the RADIUS server will be lost if no activity is detected.
You can specify more than one RADIUS server in the file. The Defender PAM attempts to connect to the servers in the order they are listed.
The following example enables the Defender PAM to communicate with the RADIUS server on host dss.example.com, port 1645, with shared secret shared_secret, and timeout of 3 seconds:
dss.example.com:1645 shared_secret 3
The Defender PAM uses a PAM RADIUS Access Control List file (/etc/pam_radius_acl.conf) to determine which service/user combinations will be authenticated by the Defender PAM.
The Access Control file should contain a list of <servicename>:<username> pairs (one line per entry), to indicate which service/user combinations require Defender authentication. The <servicename> and/or <username> may be substituted with an asterisk (*) or left blank to indicate a wildcard (all users or services).
If the pam_radius_acl.conf does not exist, then all users must authenticate via Defender.
Table 29:
pam_radius_acl.conf syntax examples
|
All users must authenticate via Defender for all Defender PAM-enabled services. |
Use a single entry with wildcards for both <servicename> and <username>.
Example 1
*:*
Example 2
:
|
|
All users must authenticate via Defender for a specific service. |
Use a wildcard for the <username>.
Example 1
sshd:*
Example 2
telnet:
|
|
Specific users must authenticate via Defender for all services. |
List individual users, but specify a wildcard for the <servicename>.
Example 1
:john
Example 2
*:sally
|
|
Specific users must authenticate via Defender for specific services. |
List individual users and services without using wildcards.
Example
sshd:jane
sshd:david
su:adam
|
|
No users require authentication via Defender. |
Ensure that the /etc/pam_radius_acl.conf file exists, but remove all entries from the file. |
The following is an example pam_radius_acl.conf file:
upm:*
telnet:
:john
*:sally
login:david
In this example, all users accessing the service upm or telnet must authenticate via Defender. Users john and sally must authenticate via Defender for every service. User david must authenticate via Defender for the login service only. Any servicename:username combination not listed in the file does not require users to authenticate via Defender.
You should ensure that for each service specified in the pam_radius_acl.conf file there is a valid system PAM configuration for that service as described in Step 1: Enable authentication for target service.
You may need to add or modify Defender objects in Active Directory so that your UNIX/Linux system can use Defender authentication. You should ensure that an Access Node is defined for your UNIX/Linux system in the Defender configuration and that the Access Node is assigned to the Defender Security Servers listed in the /etc/defender.conf file.
Also, ensure that your UNIX users are defined in Active Directory, have tokens assigned to them, and are included under the Members tab of the Access Node object corresponding to your UNIX system.
