WRSomsky
UW Physics & Astronomy Linux Guru

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

/etc/nsswitch.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

/etc/nslcd.conf:

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.

/etc/pam.d/system-auth-ldi:

#%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

/etc/krb5.conf:

# 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.

Optional Items

User Authorization

Netgroups

Automounts