PAM RADIUS Solution for Non-Native SWG Users
Existing SWG installations rely on the PAM RADIUS module to authenticate SSH users against the Radius Server. It is important to understand, that the sequence of Authentication involves comparison of User information against 2 types of Databases.
- Local Linux User Accounts
- Radius Directory Lookup (due to PAM Radius Module)
Any user who attempts to login must satisfy the presence of his login name in both the above databases. This results in a situation, where any user (For Example ‘SAM’), who does not have a native Linux account in the target system, would not be able to login.
This check is enforced by Linux system due to the operational order of services defined under ‘/etc/nsswitch.conf’, which places and prioritizes Linux Native Username check before any PAM modules are supposedly processed.
Current Authentication Problem Sequence:
- User ‘SAM’ attempts to do SSH login to SWG using his Radius credentials.
- 'SAM’ does not have a native Linux User Login.
- ‘SAM’ has a valid and working account in the Radius directory.
- The Authentication for ‘SAM’ fails, as there is no user by id ‘SAM’ in the OS.
Solution -> Using “Local Account Creation”:
- Insert exec module ‘pam_exec’ inside “/etc/pam.d/sshd”.
- Place the exec module before pam_radius_auth module.
- To create a user, the exec module requires a bash script as an argument.
- This bash script has the following functions.
- First, check if the user SAM already exists in the system. If yes, Skip.
- If the user SAM does not exist, create the user SAM along with its HOME directory using ‘useradd’ system command
Advantage:
- Does not require any manipulation of core system files such as NSS, and thus the execution does not interfere with other Linux processes and utilities that may rely on user id checks.
Disadvantages:
- Since the native user id check precedes the pam_exec invocation, it results in Authentication failure for the very first SSH Attempt. Even though the SSH attempt fails, the pam_exec module gets invoked before the SSH login process exits. This results in Local user account creation, which is the reason that the subsequent SSH login process is successful.
- Admin must manually delete the new pam_exec created Linux Accounts, if the users leave the organization.
Configure pam-exec along with pam-radius module:
Along with the pam-radius module, you can configure pam-exec on Web Gateway to automatically create a local user account when a user attempts to ssh and the same user account exists in the Radius directory.
- Log on to the Web Gateway appliance where you want to configure the pam-exec module.
- Run this command to install the module (if you haven't already):
yum install pam_exec - Edit the /etc/pam_radius.conf system file to configure the server where the information for completing the RADIUS authentication method is stored.
- Comment out these lines:
#127.0.0.1 secret 1
#other-server other-secret 3 - Add information about the RADIUS server:
<IP address of the RADIUS server> <shared secret> <timeout in seconds>
- Comment out these lines:
- Write a shell script /usr/local/bin/create_user.sh to create a new User if not already present locally.
#!/bin/bash
username=$PAM_USER
password=password
# Check if the user exists locally
getent passwd $username > /dev/null
if [ $? -ne 0 ]; then
echo "Creating user $username..."
/usr/sbin/useradd -m $username >> /tmp/useradd_output.txt 2>&1
# Set the password for the user
echo "$username:$password" | /usr/sbin/chpasswd
fi
exit 0
This is only an example script. To keep it simple, the password is "password". You may use any other strong password as needed. Password creation is optional. This could be useful if you want to switch back to traditional password authentication rather than Pam Radius. If not necessary, you can comment out the following line in the above script - # echo "$username:$password" | /usr/sbin/chpasswd
- Change the file permissions -
# chmod +x /usr/local/bin/create_user.sh
- Edit the /etc/pam.d/sshd system file to configure use of the RADIUS authentication method when logging on with SSH.
- Comment out this line:
#auth substack password-auth
- Add the below two lines to enforce RADIUS authentication:
auth requisite pam_exec.so /usr/local/bin/create_user.sh
auth required pam_radius_auth.so
- Comment out this line:
To print debug information, you may add the "debug" option, as shown below.
auth requisite pam_exec.so /usr/local/bin/create_user.sh debug
auth required pam_radius_auth.so debug
- Edit the
/etc/pam.d/sudo
system file to configure use of the RADIUS authentication method when running sudo commands in an unprivileged mode.
-
- Comment out this line:
#auth include system-auth
- Add this line to enforce RADIUS authentication:
auth required pam_radius_auth.so
- Comment out this line:
- Enable unprivileged users to run sudo commands.
- Add this line to the /etc/sudoers system file in order to enable a user to run sudo commands: <user name> ALL=(ALL) ALL
We recommend that you use the visudo command to edit this file.
- On the RADIUS server, add a user name and password to submit for authentication.
- On the local system console that is connected to Web Gateway, restart SSHD.
service sshd restart
You have now enforced RADIUS authentication for users who connect to Web Gateway with SSH or run sudo commands in an unprivileged mode. Also, any new users that are present in the Radius database but not present locally will be created locally automatically.
To verify if the enforcement works:
- Log on to Web Gateway from a remote system console with SSH.
You should be prompted to authenticate under RADIUS. - Make sure that if a user exists in the Radius database but not locally, you must retry SSH twice, which is a limitation of the pam_exec module.
- On the remote system console Web Gateway, run a sudo command as follows:
sudo <command name>
You should be prompted to authenticate under RADIUS. - Check the authentication logs in /var/log/secure for both successful and failed logins.