Turning on LDAP authentication for Linux has changed. Significantly. Some serious advice to both old and new timers below.
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.
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=arrow,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.
############SECOND METHOD################
2. Kickstart and build stuff aside, the biggest problem we had with building some new CentOS 6 test boxes had to do with LDAP. You see, RedHat (and CentOS as a result) now supports 2 different providers for LDAP authentication. That's right, two. The bad thing is that it's 2 *new* providers. It's not the "new way" and the "old way." It's the "new way" and the "other new way." Those looking for seamless upgrades, keep wishing. Those who want to figure out how to do this easily, read on.
Basically, the old PADL NSS stuff is dead. They realized what a steaming pile of shit it was (memory leaks and all) and decided to scrap it. So they took a lot of the same stuff, renamed it, and pushed it out the door. I'll call this the "nslcd/openldap/legacy stuff." This is the closest method to "the old way" of doing things. But here's the catch, they fucked it all up. 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. Ignore it all. Just read this page. Ignore any piece of documentation that has you configuring nslcd.conf.
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. Update: This is the page that I used to learn about/configure sssd.
Here's the idiot's guide, super easy configuration:
- yum install sssd
- authconfig --enablesssd --enablesssdauth --enablelocauthorize --update
- Edit /etc/sssd/sssd.conf to look similar to this (I'm not going through each item -- RTFM instead):
[sssd]
config_file_version = 2
services = nss, pam
domains = default
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
[domain/default]
ldap_tls_reqcert = never
auth_provider = ldap
ldap_schema = rfc2307bis
krb5_realm = EXAMPLE.COM
ldap_search_base = dc=domain,dc=com
ldap_group_member = uniquemember
id_provider = ldap
ldap_id_use_start_tls = False
chpass_provider = ldap
ldap_uri = ldaps://ldapserver1/,ldaps://ldapserver2/
ldap_chpass_uri = ldaps://your.ldapwrite.server/
krb5_kdcip = kerberos.example.com
cache_credentials = True
ldap_tls_cacertdir = /etc/openldap/cacerts
entry_cache_timeout = 600
ldap_network_timeout = 3
ldap_access_filter = (&(object)(object)) - Change the passwd, shadow, and group sections of /etc/nsswitch.conf to be "files sss". Do not use "files ldap". If you choose "files ldap", you'll tell the system to use the shitty PADL nslcd crap. Don't do that!
- service sssd restart
- After that, you should be able to type "id $user" and get something back from LDAP. You can make sure it's using the right LDAP servers by checking netstat (netstat -anp | grep sssd_be).
- That's it. Don't mess with nslcd.conf. Don't install any nss-pam-ldapd packages or ldapd or anything. Just don't do it. Use the RedHat/Fedora stuff and tell PADL to kiss your ass.
Oh and if you use nscd with sssd, be sure and set the passwd and group caches to "no". It's good to run nscd as a DNS host name cache, but its user and group caching conflicts with sssd's (which does its own).
No comments:
Post a Comment