HowTo: Part 3 LDAP Client Configuration

Scope of HowTo:

This HowTo will detail how to configure an LDAP client of the server that I showed you how configure here .  This content herein is known to work with CentOS/RHEL 6.4 using OpenLDAP version 2.4

Software Installation:

Install the LDAP client software:

   yum install openldap-clients pam_ldap nss-pam-ldapd autofs libsss_autofs sssd sssd-client sssd-tools nfs4-acl-tools

Configuration:

/etc/ldap.conf:

ldap.conf has been supplanted by sssd.conf in both RHEL/CentOS 6 and Ubuntu 10.04+ as the configuration source of LDAP clients. Almost every “HowTo” on LDAP client configuration on the ‘net still seems to reference it- don’t bother.

/etc/nsswitch.conf:

Edit /etc/nsswitch.conf to add ldap as an authentication source:

   passwd:     sss files
   shadow:     sss files
   group:      sss files

Note that we are still leaving “files” as an authentication source. The reason this is not removed is because we will have at least one user, ROOT who will always remain outside of the LDAP authentication system. If “files” is removed, root access is a bit buggered.

Copy LDAP Server’s Cert

On the CLIENT do the following:

mkdir /etc/openldap/cacerts
scp root@ourLDAPserver:/etc/pki/tls/certs/slapdcert.pem /etc/openldap/cacerts/

Run authconfig

Run the following command:

authconfig --enableldap --enableldapauth --ldapserver='ldapserver.f1linux.com:636' --ldapbasedn='dc=f1linux,dc=com' --enableldaptls --enablerfc2307bis --enablesssd --enablesssdauth --updateall

This command populates, either fully or partially as noted, the following files:

/etc/nsswitch.conf   =>  Adds sss as an authentication source for passwd, shadow and group lookups. Should require no manual editing.
/etc/pam.d/system-auth  => adds sss as an authentication source to PAM.  Should require no further manual edits.
/etc/sssd/sssd.conf   => CREATES THIS FILE & populates it *PARTIALLY*. NOTE: the sssd daemon will not start initally- you must manually add the LDAP domain information to the [PAM] section of sssd.conf

/etc/pam_ldap.conf   => Partially configures this file.

The following file, although updated by authconfig is NOT consulted by sssd when authenticating against PAM. HOWEVER LDAP client tools (ie: “ldapsearch“) do NOT hook-into sssd and will consult this file directly:

/etc/openldap/ldap.conf   => Appends input from the 'authconfig utility.  If LDAPS:// is being used, authconfig will only specify LDAP://' requiring you to correct the error or your ldap tools (ie: "ldapsearch," "ldapadd," etc) will be broken.

But authconfig does one other very important thing other then pushing configuration parameters to files- it hashes the cert for TLS connectivity:

ls -al /etc/openldap/cacerts/
total 12
drwxr-xr-x  2 root root 4096 Nov 12 22:56 .
drwxr-xr-x. 4 root root 4096 Nov 12 22:56 ..
lrwxrwxrwx  1 root root   13 Nov 12 22:56 37e8e4d4.0 -> slapdcert.pem
-rwxr-x---  1 root root 1517 Nov 12 22:35 slapdcert.pem

/etc/nsswitch.conf

authconfig should add the correct authentication sources. A working copy of /etc/nsswitch.conf is provided for comparitive purposes:

passwd:     files sss
shadow:     files sss
group:       files sss
hosts:        files dns
bootparams: nisplus [NOTFOUND=return] files
ethers:       files
netmasks:  files
networks:   files
protocols:   files
rpc:            files
services:     files sss
netgroup:   files sss
publickey:   nisplus
automount: files ldap
aliases:        files nisplus

/etc/pam.d/system-auth

Directs PAM to consult the sssd configuration for authentication. authconfig modifies this file and no manual edits should be required.   A correct version looks as follows:

#%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_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 broken_shadow
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=3 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     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

/etc/sssd/sssd.conf

Use sssd.conf  in lieu of nslcd.conf.  Installing sssd will not give you a sssd.conf file: this is auto-generated when you run authconfig.

The resulting /etc/sssd/sssd.conf file built by authconfig should SHOULD look as follows. However, check carefully…:

[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP
[nss]
[pam]
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldaps://ourLDAPServer.f1linux.com:636/, ldaps://ourLDAPSlave.f1linux.com:636/
ldap_search_base = dc=f1linux,dc=com
cache_credentials = True
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_id_use_start_tls = True
enumerate = true

Finally, start the sssd service and set it to “on” when the system boots:

service sssd restart
chkconfig sssd on

/etc/pam_ldap.conf

NOTE: This file is NOT updated with LDAP information by the authconfig command and must be manually updated.

The following information will NOT be either populated, or uncommented by, authconfig.  This portion of the file must be edited manually:

base dc=f1linux,dc=com
ldap_version 3
binddn uid=authenticate,ou=System,dc=f1linux,dc=com
bindpw <cleartextPasswdHere>
rootbinddn cn=Manager,dc=f1linux,dc=com
port 636
pam_filter objectclass=account
pam_login_attribute uid
pam_min_uid 0
pam_max_uid 0
pam_login_attribute userPrincipalName
pam_template_login_attribute uid
pam_template_login nobody
# The following values need to be input manually:
nss_base_passwd ou=Users,dc=f1linux,dc=com?one
nss_base_shadow ou=Users,dc=f1linux,dc=com?one
nss_base_group ou=Group,dc=f1linux,dc=com?one

authconfig populates the following values

uri ldaps://ourLDAPServer.f1linux.com/
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
pam_password md5

/etc/passwd & /etc/group

Any overlap between services referenced in LDAP and those in local files (/etc/passwd /etc/groupcan result in weirdness, depending on the order they appear in/etc/nsswitch.confMoving (mv) or deleting (rm/etc/passwd/etc/group/etc/shadow, and /etc/gshadow is not an option.  These need to be maintained if only for root logins which should NEVER be in LDAP; root logins only EVER exist in local files.  Just because you’re using LDAP does NOT negate the continued requirement to maintain these files.

An audit should have been done prior to assigning service UIDs to LDAP. Changing UID’s/GID’s to ensure consistency between hosts is a nightmare. Any hosts affected by such changes will necessarily need to be chown’ed to the new user and if you miss a path, you’ve now got a broken application.

Authenticating UIDs below 500:

Just because you can authenticate users with UIDs below 500 doesn’t necessarily imply this is a sensible thing to do. There’s a reason for the restriction (security), but some legacy systems might have commenced human user UID numbering below 500, so for those users I explain the PAM tweak.

/etc/pam.d/system-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_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
# Change "500" to the required value in the following stanza:
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 broken_shadow
account     sufficient    pam_localuser.so
# Change "500" to the required value in the following stanza:
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=3 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     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

/etc/pam.d/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
# Change "500" to the required value in the following stanza:
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 broken_shadow
account     sufficient    pam_localuser.so
# Change "500" to the required value in the following stanza:
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=3 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     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

iptables:

LDAP Rules:

   -A INPUT -s 10.10.5.3 -p tcp -m tcp --sport 389 -m state --state ESTABLISHED -m comment --comment "LDAP" -j ACCEPT
   -A INPUT -s 10.10.5.3 -p tcp -m tcp --sport 636 -m state --state ESTABLISHED -m comment --comment "LDAP StartTLS" -j ACCEPT
   -A OUTPUT -d 10.10.5.3 -p tcp -m tcp --dport 389 -m state --state NEW,ESTABLISHED -m comment --comment "LDAP" -j ACCEPT
   -A OUTPUT -d 10.10.5.3 -p tcp -m tcp --dport 636 -m state --state NEW,ESTABLISHED -m comment --comment "LDAP StartTLS" -j ACCEPT

NFS Rules:

I use different versions of NFS concurrently in production, so you might need to tweak the list of ports used to be more appropriate for your own NFS environment.

   -A INPUT -s 10.10.5.3 -p tcp -m tcp -m multiport --sports 111,662,875,892,2049,32803 -m state --state NEW,ESTABLISHED -m comment --comment "NFS TCP Connectivity" -j ACCEPT
   -A INPUT -s 10.10.5.3 -p udp -m udp -m multiport --sports 111,662,875,892,2049,32769 -m state --state NEW,ESTABLISHED -m comment --comment "NFS UDP Connectivity" -j ACCEPT
   -A OUTPUT -d 10.10.5.3 -p tcp -m tcp -m multiport --dports 111,662,875,892,2049,32803 -m state --state NEW,ESTABLISHED -m comment --comment "NFS TCP Connectivity" -j ACCEPT
   -A OUTPUT -d 10.10.5.3 -p udp -m udp -m multiport --dports 111,662,875,892,2049,32769 -m state --state NEW,ESTABLISHED -m comment --comment "NFS UDP Connectivity" -j ACCEPT

Testing:

On the client, use getent passwd and you should see output similar to the following if all is working correctly:

   getent passwd|grep johndoe
   johndoe:{MD5}vk6L6KRNiol5Wmr8QlG9Gg==:1001:1009:John Doe:/home/johndoe:/bin/bash

For troubleshooting, please go here .

Conclusion:

That should be enough to get you performing host authentication via LDAP.  In a follow-on blog post, I’ll detail how you can use LDAP as an authentication source for applications.  Once again, if you see any errors or omissions, or suggested improvements please let me known and I’ll update the documentation.

-Terrence


Posted in LDAP Tagged with: , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Categories

Recent Comments

    Archives