Linux SL7, SSSD & UWWI
These are notes about my attempts to get a Scientific Linux 7.2 system to use the UWWI for user information, authentication and authorization via the SSSD system.
I have manged to get things to partially work, but there are significant difficulties:
- WORKS: lookup of user entries (getent passwd user_netid)
- WORKS: lookup of user uids (getent passwd user_uid)
- WORKS: lookup of group service entries (getent group uwgs_name)
- WORKS: lookup of group serivce gids (getent group uwgs_gid)
- SEMI-WORKS: su to user (su username) -- fails to pick up secondary groups
- FAILS: lookup of user-personal group by name (getent group username)
- FAILS w/ LONG DELAY: lookup of user-personal group by gid (getent group user_gid)
(Note that this affects any command attempts to map gid's back to a name. Most notably 'id' and 'ls -l'.) - SEMI-WORKS: login/ssh via UWNetID -- fails to pick up secondary groups
- FAILS: any user access control -- ANY UWNetID can successfully log in!!!
- UNTRIED: user access control
- UNTRIED: automatic mounting of user UDrive
Current Conclusion
Further work may alleviate these issues, but at the current time, the following difficulties should be deemed critical:
- lack of user login access control
- failure to pick up secondary groups upon login/su
- inordinate delays in basic commands due to the lookup failures for user-personal groups
References
- https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/SSSD.html
- https://staff.washington.edu/ketcham/c7-sssd-uwwi/
Trial Installations and Setups
Being as I have not been able to create a fully satisfactory SSSD to UWWI setup, what I present here are several piece-wise configurations and describe what works and what doesn't under each, so that one can get some idea of what parts provide (or fail to provide) what functionality.
SL7 Installation
We begin with a base install of SL7 OS with no extra packages. What works here should work for RHEL7 and CentOS7 as well. Our example machine will be trantor.phys.washington.edu.
Install SL7.2, base only, on trantor.phys.washington.edu
Joining to the UWWI AD
The linux system can be joined to the UWWI AD using the adcli command, obtained from the 'adcli' package:
yum install adcli
It is presupposed that you already have a UWWI delegated OU, an admin account w/ priviliges to join machines to that OU, and an appropriate UWWI AD name for the machine. No pre-creation of the machine w/in the UWWI AD is required.
Note that there are guidelines for naming machines w/in the UWWI AD [reference?], and that the AD name and the DNS name do not have to be the same.
adcli join \ -U sadm_somsky \ # your admin account -N phys-trantor \ # UWWI AD machine name -O OU=phys,OU=Delegated,DC=netid,DC=washington,DC=edu \ # your delegated OU netid.washington.edu
This will register the machine w/ the UWWI, and will create the file /etc/krb5.keytab on the machine.
SSSD + NSS
Here we install sssd and configure it to supply the nss (passwd/group) data.
If no shell is defined w/in AD, we are using /bin/tcsh.
Also, we are ignoring the unixHomeDirectory field and overriding it to be /home/<username>.
Note that we are *not* using SID to UID/GID mapping -- we wish to use the posix UID and GID values from the uidNumber and gidNumber fields.
yum install sssd # will pull in needed dependancies
# /etc/sssd.conf # Note: must be mode 600! [sssd] debug_level = 0 config_file_version = 2 domains = netid.washington.edu services = nss [nss] debug_level = 0 default_shell = /bin/tcsh override_homedir = /home/%u # allowed_shells, vetoed_shells, override_shell, shell_fallback [domain/netid.washington.edu] debug_level = 0 id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad ldap_id_mapping = false # cache_credentials = false (default) # use_fully_qualified_names = false (default)
Once the sssd.conf file is in place, we can start (or restart) the sssd system:
systemctl enable sssd.service systemctl restart sssd.service
With this, we have the following functionality:
#] getent passwd somsky somsky:*:9050:1100398039:somsky:/home/somsky:/bin/tcsh ## Okay! #] getent group somsky ## Fails!!! #] getent group uw_phys_pacs_staff uw_phys_pacs_staff:*:150842:jedlow,somsky,waldrw,sdebolt,rushfive ## Okay! #] getent passwd 9050 somsky:*:9050:1100398039:somsky:/home/somsky:/bin/tcsh ## Okay! #] getent group 1100398039 ## Fails!!! AND takes a long time! (30s) #] getent group 150842 uw_phys_pacs_staff:*:150842:jedlow,somsky,waldrw,sdebolt,rushfive ## Okay! #] su somsky id: cannot find name for group ID 1100398039 ## Completes BUT fails to get secondary groups ## Also, takes a long time, presumably due to gid lookup #] su - somsky ## Completes BUT fails to get secondary groups ## Also, takes a long time, presumably due to gid lookup
This failure -- especially with the delay -- to map the user-personal GID back to a name is troubling. Operations such as 'id' and 'ls -l' which try to map gid's back to names end up having unacceptable delays. Additionaly, the failure to return the the username makes various .profile/.cshrc tests for the use of user-personal GID's fail.
(Note: I have *occasionally* seen results where the user-personal GID lookup comes back quickly (still failing) -- it may be hitting some cache -- but the majority of the time it takes approx 30 seconds to fail.)
The 'su' command partially works in that it will start a new shell w/ the proper UID and primary GID, but it fails to obtain any of the secondary GID's for the account.
SSSD + NSS,PAM
The addition of PAM configuration allows logins to be performed using the UWWI information.
# /etc/sssd.conf # Note: must be mode 600! [sssd] debug_level = 0 config_file_version = 2 domains = netid.washington.edu services = nss, pam [nss] debug_level = 0 default_shell = /bin/tcsh override_homedir = /home/%u # allowed_shells, vetoed_shells, override_shell, shell_fallback [pam] debug_level = 0 [domain/netid.washington.edu] debug_level = 0 id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad ldap_id_mapping = false # cache_credentials = false (default) # use_fully_qualified_names = false (default)
auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success 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 < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= 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_systemd.so 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
Replace the existing system-auth and password-auth PAM files w/ the new system-auth-sss file
ln -sf system-auth-sss /etc/pam.d/system-auth ln -sf system-auth-sss /etc/pam.d/password-auth
Again, we can start (or restart) the sssd system
systemctl enable sssd.service systemctl restart sssd.service
All the previous functionality of the SSSD+NSS setup still works as before (with all its successes AND failures), but we can now ssh into the machine or log into the console using a UWNetID. However, just as in the ssh case above, none of the secondary groups are picked up.
Note further, that with this configuration, ANY UWNetID can successfully log in. No access control is implemented w/ this level of configuration.
Next Step?
I am considering what to try for the next step.