=== === IN PROGRESS === ===
CentOS 7 SSSD LDI Client Configuration
Here I will present a step-by-step guide to configuring a CentOS 7.7 sssd-based system as a client to the Linux Directory Infrastructure (LDI) Service. At each phase, tests will be presented to verify the operation of that phase, allowing one to debug their installation as they go.
In this guide, I will be using our setup from Physics as an example, registed with LDI as the organization unit 'ou=phys'. In following this guide, you should substitute your own organizational name/code for 'phys' as needed.
Preliminaries
Before beginning on the client system, you should have the following items/tasks completed and on hand:
- An LDI instance
- You have an LDI instance set up and populated with at least a minimal population of users. You don't need your full set of users, just enough to verify successful operation. Create a group w/ just you in it if need be for testing.
- An ldi-client.crt, ldi-client.key pair
- You have created a UWCA certificate for 'ldi-client.your-domain.washington.edu' and registered it as a 'BasicAccess' certificate in your LDI instance.
LDAP Access to LDI
Here we will set up basic access to the LDI server and make sure all certificates and certificate validation is working.
Installing Certificates
First you should install ldi-client certificate and key, making sure to set the proper permissions and ownerships, and install and extract the the InCommon CA certificate:
root#
cp ldi-client.key /etc/pki/tls/private/ldi-client.key cp ldi-client.crt /etc/pki/tls/certs/ldi-client.crt chown root:root /etc/pki/tls/private/ldi-client.key chown root:root /etc/pki/tls/certs/ldi-client.crt chmod 640 /etc/pki/tls/private/ldi-client.key chmod 640 /etc/pki/tls/certs/ldi-client.crt
Testing Access
At this point, you should be able to access the LDI via the ldapsearch command: (Install openldap-clients if ldapsearch is not found.)
(csh,tcsh) root#
#] setenv LDAPTLS_CERT /etc/pki/tls/certs/ldi-client.crt #] setenv LDAPTLS_KEY /etc/pki/tls/private/ldi-client.key #] ldapsearch -ZH ldap://ldi.s.uw.edu -QY EXTERNAL -LLL -s base -b ou=phys,dc=ldi,dc=uw,dc=edu
(sh,bash) root#
#] export LDAPTLS_CERT=/etc/pki/tls/certs/ldi-client.crt #] export LDAPTLS_KEY=/etc/pki/tls/private/ldi-client.key #] ldapsearch -ZH ldap://ldi.s.uw.edu -QY EXTERNAL -LLL -s base -b ou=phys,dc=ldi,dc=uw,dc=edu
If things are working properly, you should get output something like:
dn: ou=phys,dc=ldi,dc=uw,dc=edu objectClass: organizationalUnit description: phys ou: phys
Connecting Name Services to LDI
This next phase will connect LDI to your passwd, group and other databases.
Required Packages
The necessary libraries and commands come from the 'sssd' package.
root#
#] yum install -y sssd
Configuration Files
Next, we need to tell the system where to look for the data via the configuration files /etc/nsswitch and /etc/nslcd.conf
passwd: files sss shadow: files sss group: files sss netgroup: files sss automount: files #-- hosts: files dns myhostname #-- aliases: files bootparams: files ethers: files netmasks: files networks: files protocols: files publickey: files rpc: files services: files
[sssd] domains = LDI services = nss, pam config_file_version = 2 [nss] filter_users = root filter_groups = root reconnection_retries = 3 #entry_cache_timeout = 300 entry_cache_nowait_percentage = 75 [pam] [domain/LDI] min_id = 2001 enumerate = true entry_cache_timeout = 300 cache_credentials = false ldap_uri = ldap://ldi.s.uw.edu ldap_id_use_start_tls = true ldap_tls_reqcert = demand ldap_sasl_mech = EXTERNAL ldap_tls_cert = /etc/pki/tls/certs/ldi-client.crt ldap_tls_key = /etc/pki/tls/private/ldi-client.key id_provider = ldap access_provider = ldap ldap_search_base = ou=phys,dc=ldi,dc=uw,dc=edu ldap_user_search_base = ou=accounts,ou=phys,dc=ldi,dc=uw,dc=edu ldap_group_search_base = ou=groups,ou=phys,dc=ldi,dc=uw,dc=edu ldap_netgroup_search_base = ou=machgroup,ou=unit,ou=phys,dc=ldi,dc=uw,dc=edu ldap_user_gecos = unitGecos ldap_user_shell = unitLoginShell ldap_user_home_directory = unitHomeDirectory auth_provider = krb5 ## chpass_provider = none krb5_realm = NETID.WASHINGTON.EDU krb5_server = netid.washington.edu
By default, sssd gets the user shell, home directory and GECOS information from the similarly names attributes of the user account entry. Here we tell sssd to get this information from the unit- attributes via the ldap_user_... lines.
Enabline & Starting the NSLCD Service
NSLCD runs as a service, so it needs to be enabled and activated.
root#
#] systemctl enable sssd #] systemctl start sssd
Testing
Your system should now be using the LDI to name-service information. Running the getent command for passwd and group information should give you a list which includes users and groups from your LDI instance.
#] getent passwd #] getent group
At this point, your user accounts are active, and you should be able to successfuly 'su' to any of them. You can't log in via a password yet -- that's coming in the next section.
User Authentication w/ LDI
For password-based logins, we will authenticate users against the UW kerberos servers. This is done via the SSSD PAM modules.
Configuration Files
For PAM configuration, we create a new file customized for SSSD kerberos authentication.
#%PAM-1.0 # optional = [ default=ignore success=ok new_authtok_reqd=ok ] # sufficient = [ default=ignore success=done new_authtok_reqd=done ] # required = [ default=bad success=ok new_authtok_reqd=ok ignore=ignore] # requisite = [ default=die success=ok new_authtok_reqd=ok ignore=ignore] auth required pam_env.so auth sufficient pam_unix.so try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow 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 try_first_pass use_authtok password requisite pam_succeed_if.so uid >= 1000 quiet 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
Once created, this file needs to be symlinked into place:
root#
#] ln -sf system-auth-sssd /etc/pam.d/system-auth #] ln -sf system-auth-sssd /etc/pam.d/password-auth
Testing
At this point, logins via password should be working.