CentOS 7 LDI Client Configuration
Here I will present a step-by-step guide to configuring a CentOS 7.3 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.
- InCommonCA.crt
- You have a copy of the InCommon CA certificate bundle to allow verification of the connection to the LDI server. [[Link to obtaining this?]]
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.crt /etc/pki/tls/certs/ cp ldi-client.key /etc/pki/tls/private/ chmod 640 /etc/pki/tls/private/ldi-client.key chgrp ldap /etc/pki/tls/private/ldi-client.key cp InCommonCA.crt /etc/pki/ca-trust/source/anchors/ update-ca-trust extract
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 'nss-pam-ldapd' package. It will also bring in the 'nscd' package if not already installed.
root#
#] yum install -y nss-pam-ldapd
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 ldap shadow: files ldap group: files ldap netgroup: files ldap #-- hosts: files dns #-- aliases: files automount: files bootparams: files ethers: files netmasks: files networks: files protocols: files publickey: files rpc: files services: files
uid nslcd gid ldap uri ldap://ldi.s.uw.edu ssl start_tls tls_cacertfile /etc/pki/ca-trust/source/anchors/InCommonCA.crt tls_cert /etc/pki/tls/certs/ldi-client.crt tls_key /etc/pki/tls/private/ldi-client.key sasl_mech EXTERNAL pagesize 250 nss_min_uid 1000 nss_initgroups_ignoreusers ALLLOCAL base ou=phys,dc=ldi,dc=uw,dc=edu base group ou=groups,ou=phys,dc=ldi,dc=uw,dc=edu base passwd ou=accounts,ou=phys,dc=ldi,dc=uw,dc=edu base shadow ou=accounts,ou=phys,dc=ldi,dc=uw,dc=edu ## map passwd gecos unitGecos ## map passwd homeDirectory unitHomeDirectory ## map passwd loginShell unitLoginShell
By default, nslcd gets the user shell, home directory and GECOS information from the similarly names attributes of the user account entry. You can tell nslcd to get this information from the unit- attributes by uncommenting the lines at the end of the nslcd.conf file.
(Side Note: NSCD Caching On the physics systems, we also configure nscd, the name-service caching daemon, to not preserve data across reboots by turning off the 'persistent' flag for each database in the /etc/nscd.conf file. YMMV, so this is optional.)
Enabline & Starting the NSLCD Service
NSLCD runs as a service, so it needs to be enabled and activated.
root#
#] systemctl enable nslcd #] systemctl start nslcd
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. (Also, if you are using automounted home directories w/ configuration coming from LDAP, those won't be working yet either.)
User Authentication w/ LDI
For password-based logins, we will authenticate users against the UW kerberos servers. This is done via PAM modules.
Required Packages
The kerberos pam module is installed via th pam_krb5 package:
root#
#] yum install -y pam_krb5
Configuration Files
For PAM configuration, we create a new file customized for 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_success auth sufficient pam_krb5.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 required pam_ldap.so account [default=bad success=ok user_unknown=ignore] pam_krb5.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_krb5.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_ldap.so session optional pam_krb5.so
Once created, this file needs to be symlinked into place:
root#
#] ln -sf system-auth-ldi /etc/pam.d/system-auth #] ln -sf system-auth-ldi /etc/pam.d/password-auth
Kerberos configuration is handled via the /etc/krb5.conf file
# Configuration snippets may be placed in this directory as well includedir /etc/krb5.conf.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = NETID.WASHINGTON.EDU dns_lookup_realm = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true rdns = false default_ccache_name = KEYRING:persistent:%{uid} [realms] [domain_realm]
Testing
At this point, logins via password should be working.