title: SSSD for LDAP auth on Linux link: https://onemoretech.wordpress.com/2014/02/23/sssd-for-ldap-auth-on-linux/ author: phil2nc description: post_id: 7039 created: 2014/02/23 18:24:31 created_gmt: 2014/02/23 23:24:31 comment_status: closed post_name: sssd-for-ldap-auth-on-linux status: publish post_type: post

SSSD for LDAP auth on Linux

Turning on LDAP authentication for Linux has changed. Significantly. Some serious advice to both old and new timers below. This procedures outlined below were tested on Fedora 19 (and so should work on RHEL/CentOS 7). Enabling LDAP authentication used to involve invoking nslcd, the Local LDAP Name Service Daemon. In my experience it worked, but was ugly. Red Hat and others still offer nslcd, but as Dik writes:

It's broken, convoluted, and not well documented. Worst, there's a lot of bad advice floating around the Internet in places like StackOverflow, ServerFault, ExpertsExchange, etc.

Of course you could say the same thing about a lot of open source (and most closed source) software as well. Documentation and clear instruction are sadly not the strong suit of many technologists, or the companies that hawk their wares. That's why I especially appreciated this line from the above-referenced blogger, "Ignore it all. Just read this page. Ignore any piece of documentation that has you configuring nslcd.conf." In fact the guy doesn't stop there, he goes on to write:

Fedora/RedHat realized how terrible PADL software is, so they wrote their own stuff; it's called SSSD. It's a terrible name, but overall it works pretty well. Use SSSD, don't use nslcd or anything that has pam_ldap or ldapd in the name. Just use SSSD.

Now that's clarity. So is, as it turns out, Red Hat's latest documentation on the subject: in the Fedora 18 System Administrator's Guide. An older, but fuller treatment can be found in the Fedora 15 Deployment Guide. Still, as much as I admire Red Hat's documentation, I have to admit that the crisp instructions that I found in that blog post were really what made it all work for me. Notes: Here's my own distillation of the instructions found in Dik's blog post. This was tested on Fedora 19: 1. Install sssd and authconfig if they aren't already. The packages you'll want are:

sssd-client
sssd-common
sssd-common-pac
sssd-ldap
sssd-proxy
python-sssdconfig
authconfig
authconfig-gtk

The sssd package is a "meta" package that gets added by one or more of these others. My Fedora 19 installation from the Live DVD already had all these loaded. 2. Check the current settings for sssd, if any:

authconfig --test

This will show the settings already in place. Generally at this stage everything is disabled. Check for an existing /etc/sssd/sssd.conf file. If this is a new installation where LDAP authentication has not been set up before the file will not exist, although the directory will. 3. Configure sssd.

authconfig \
--enablesssd \
--enablesssdauth \
--enablelocauthorize \
--enableldap \
--enableldapauth \
--ldapserver=ldap://ldap.example.com:389 \
--disableldaptls \
--ldapbasedn=dc=example,dc=com \
--enablerfc2307bis \
--enablemkhomedir \
--enablecachecreds \
--update

A few notes: (a) It is extremely important to include "enablelocalauthorize", which allows local account (/etc/passwd) values to override network (LDAP) values. This will allow you to log into the server if your LDAP directory goes down. (b) The LDAP uri you enter will depend upon whether you're going to be connecting over unencrypted LDAP, SSL LDAPS or LDAP TLS. Password changes may not work using unencrypted LDAP, and it's eventually going to be deprecated. LDAPS is also supposed to be deprecated in a future release (there are concerns about the efficacy of its security). As a result, using TLS is highly recommended. (c) Even if you're going to use LDAP TLS, use the disableldaptls option on initial setup to avoid an abend due to a failure to provide a certificate url. I prefer to keep my certificates in a better place that the default /etc/openldap/certs (my preference is for the common system /etc/pki/tls/certs). (d) If you want to use LDAP groups be sure to include enablerfc2307bis, this is the schema variant that recognizes uniquember as the attribute for storing group member dns. (e) Both enablemkhomedir and enablecachecreds are not required, but recommended. The former because it saves administrators a maintenance step by letting the system create the user's home directory on their first login, and the second because it helps avoid the consequences of periodic network connectivity "hiccups". (f) If you use the authconfig tool you should not have to edit any other files such as /etc/nsswitch.conf, authconfig will have done that for you (see below for one exception). The sssd service should also be up and running with that new configuration and enabled for restart on reboot. 4. Check the configuration in /etc/sssd/sssd.conf. In particular you'll need to edit it so that the ldap_tls_cacertdir and ldap_tls_cacert parameters have valid (real) paths to your certificates. If you're going to use TLS (which you really should if your LDAP directory supports it -- most, including OpenDJ, do), change "ldap_id_use_start_tls" to "True".

[domain/default]

autofs_provider = ldap
ldap_schema = rfc2307bis
krb5_realm = #
ldap_search_base = dc=example,dc=com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://ldap.example.com:389
ldap_id_use_start_tls = True
cache_credentials = True
ldap_tls_cacertdir = /etc/pki/tls/certs
ldap_tls_cacert = /etc/pki/tls/certs/mybundle.pem
[sssd]
services = nss, pam, autofs
config_file_version = 2

domains = default
[nss]

[pam]

[sudo]

[autofs]

[ssh]

[pac]

Restart sssd to effect these changes:

systemctl restart sssd

DO NOT use the update option with authconfig until you've restarted the service, otherwise you'll wipe out any changes you've made to the configuration file. Then run a check to make sure they've been read in correctly:

authconfig --test

5. Update /etc/openldap/ldap.conf to follow the same configuration. It should look something like this when you're done:

SASL_NOCANON    on
URI ldaps://ldap.example.com:389
BASE dc=example,dc=com
TLS_REQUIRE never
TLS_CACERTDIR /etc/pki/tls/cacerts
TLS_CACERT /etc/pki/tls/certs/mybundle.pem

That "TLS_REQUIRE never" is for the benefit of application stacks like php that leverage the system's LDAP but have difficulty with LDAPS and TLS, even when dealing with certs signed by an external authority. 6. Make sure that sssd is up and running, as well as enabled to restart when the system reboots next. Use "systemctl status sssd" to check this. If it isn't use "systemctl enable sssd" and "systemctl start sssd". Sometimes it is best to restart the service in order to ensure that the cache is cleared out and all changes applied. Use "systemctl restart sssd" for this.

Copyright 2004-2019 Phil Lembo