A centralized authentication mechanism is essential in any medium to large environments. In Linux, we can integrate client servers with Active Directory such that users logging into the systems will be authenticated via their AD credentials provided they have privileges to log into the system. For doing the client side AD integration we can use winbind or SSSD. This article is written using the SSSD method.
In this article I won't dwell into the complete setup for client side configuration for centralized AD authentication but instead focus on a subset of the process which in this case is the PAM part.
In order to configure active directory authentication on Linux client servers, we basically need to modify three PAM related files under /etc/pam.d. They are:
- password-auth
- system-auth
- sshd
Given below are the three files with the required modifications in place:
[root@localhost pam.d]# cat password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=5 type= minlen=8 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_oddjob_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
[root@localhost pam.d]#
[root@localhost pam.d]# cat system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_listfile.so onerr=fail item=group sense=allow file=/etc/login.group.allowed
auth required pam_env.so
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=5 type= minlen=8 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session optional pam_oddjob_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
[root@localhost pam.d]#
[root@localhost pam.d]#
[root@localhost pam.d]# cat sshd
#%PAM-1.0
auth required pam_listfile.so onerr=fail item=group sense=allow file=/etc/login.group.allowed
auth required pam_sepermit.so
auth include password-auth
account required pam_nologin.so
account include password-auth
password include password-auth
# pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session required pam_selinux.so open env_params
session optional pam_keyinit.so force revoke
session include password-auth
[root@localhost pam.d]#
To summarize, we've used two more PAM modules in addition to the default ones already in the files at install time which are pam_listfile.so & pam_sss.so.
Now, let's dive in to the details of these two modules:
pam_sss.so:
This is the PAM interface to the System Security Services daemon (SSSD).
Given below is a description of the options available with this module:
quiet
Suppress log messages for unknown users.
forward_pass
If forward_pass is set the entered password is put on the stack for other PAM modules to use.
use_first_pass
The argument use_first_pass forces the module to use a previous stacked modules password and will never prompt the user - if no password is available or the password is not appropriate, the user will be denied access.
use_authtok
When password changing enforce the module to set the new password to the one provided by a previously stacked password module.
retry=N
If specified the user is asked another N times for a password if authentication fails. Default is 0.
Please note that this option might not work as expected if the application calling PAM handles the user dialog on its own. A typical example is sshd with PasswordAuthentication.
pam_listfile.so:
This module is used to determine which users will be allowed access to the servers. We can use it without in conjunction with an AD integration setup as well as it's function is to determine which users will be allowed access based on entries in a file. Given below is a description of the options available with this module:
item=[tty|user|rhost|ruser|group|shell]
What is listed in the file and should be checked for.
sense=[allow|deny]
Action to take if found in file, if the item is NOT found in the file, then the opposite action is requested.
file=/path/filename
File containing one item per line. The file needs to be a plain file and not world writable.
onerr=[succeed|fail]
What to do if something weird happens like being unable to open the file.
apply=[user|@group]
Restrict the user class for which the restriction apply. Note that with item=[user|ruser|group] this does not make sense, but for item=[tty|rhost|shell] it have a meaning.
quiet
Do not treat service refusals or missing list files as errors that need to be logged.
With this understood I'll just elaborate on the statement we've used in the above example files for password-auth & system-auth files:
auth required pam_listfile.so onerr=fail item=group sense=allow file=/etc/login.group.allowed
The pam_listfile.so module will check for user group entries in the file /etc/login.group.allowed. If a user is a member of a group mentioned in the file, the user will be allowed to access the server. If the user is not a member of a group mentioned in the file, the user is denied access.
Here's a sample login.group.allowed file:
cat /etc/login.group.allowed
root
opcgrp
unixadmin
oinstall
SG-INFRA-HPOV-L2
SG-INFRA-Unix-L2
In the above file, the groups SG-INFRA-HPOV-L2 & SG-INFRA-Unix-L2 are created on Active Directory & members of these groups will be allowed login access to the server. The remaining groups are created locally on the OS & users belong to these groups will also be allowed access to the server.
Assuming that the SG-INFRA-HPOV-L2 & SG-INFRA-Unix-L2 group members are HP-OV & UNIX admin team members respectively, we'll make the below additions in /etc/sudoers file:
%SG-INFRA-Unix-L2 ALL=(ALL) NOPASSWD: ALL
%SG-INFRA-HPOV-L2 ALL=(ALL) NOPASSWD: /bin/su - hpov_user
The effect of these modifications is instantaneous & does not require any service restart or a system reboot.
Just a couple of gotchas:
- If a user is not member of a group mentioned in the file but has ssh keys exchanged, the user will be granted access based on key exchange authentication.
- In my experience if we use the pam_sss.so module in conjunction with the failllock or tally2 modules keeping all other parameters the same, then no users are able to login to the system.
No comments:
Post a Comment