SSSD
Starting with CentOS6, remote account login authentication is performed using SSSD. Configuring SSSD to authenticate to an LDAP server can be tricky, but the following instructions work perfectly.
Configuring SSSD
1. Make sure the proper packages are installed
yum install sssd libsss_sudo
2. Use authconfig to enable the proper settings to allow authentication via SSSD
authconfig --enablesssd --enablesssdauth --enablelocauthorize --update
3. Modify /etc/sssd/sssd.conf to reflect the following settings:
[sssd] config_file_version = 2 services = nss, pam domains = default
[nss] filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[domain/default] ldap_tls_reqcert = never auth_provider = ldap ldap_schema = rfc2307 krb5_realm = EXAMPLE.COM ldap_search_base = dc=physics,dc=unh,dc=edu id_provider = ldap ldap_id_use_start_tls = False chpass_provider = ldap ldap_uri = ldaps://einstein.unh.edu 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 = (&(objectclass=shadowaccount)(objectclass=posixaccount)) ldap_rfc2307_fallback_to_local_users = True enumerate = True
4. Modify /etc/openldap/ldap.conf to point to the LDAP server:
URI ldaps://einstein.unh.edu BASE dc=physics,dc=unh,dc=edu TLS_CACERTDIR /etc/openldap/cacerts
Note: If you are not able to get back proper information with the 'id' command try removing the ca certs from the /etc/openldap/cacerts/ directory and restarting the sssd service. Always back that directory up before removing the contents of it.
5. Modify /etc/nsswitch.conf to reflect the following settings:
passwd files sss shadow files sss group files sss sudoers files sss
6. Restart the sssd service to enable changes:
service sssd restart
7. To test the configuration, try requesting user information:
id <username>
Trouble Shooting
You can try if LDAP is talking with you using the ldapsearch command. A very basic test is:
ldapsearch -x -d8 -H ldap://einstein.farm.physics.unh.edu -b dc=physics,dc=unh,dc=edu '(uid=maurik)'
Then you can check if TLS is working by adding an s:
ldapsearch -x -d8 -H ldaps://einstein.farm.physics.unh.edu -b dc=physics,dc=unh,dc=edu '(uid=maurik)'
If you get the error:
TLS: certificate [CN=einstein.unh.edu,OU=Nuclear Physics Group,O=University of New Hampshire,L=Durham,ST=New Hampshire,C=US] is not valid - error -8016:The certificate was signed using a signature algorithm that is disabled because it is not secure.. TLS: error: connect - force handshake failure: errno 0 - moznss error -8157 TLS: can't connect: TLS error -8157:Certificate extension not found.. ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Then you need to check your certificates. It may be the disabled MD5 kind, see: http://blogs.dlt.com/rhel-64-ga-potential-authentication-issues There they suggest setting NSS_HASH_ALG_SUPPORT=+MD5. This did indeed work on the Centos7 install on Gourd, for command line ldapsearch. It does NOT solve the issue for sssd, so "getent" and "id" do not work.
The work-around, for now, is to connect with "ldap" instead of "ldaps" and not use the TLS at all.
Notes
The command 'getent passwd' will not work by default, as SSSD disables user enumeration. Instead, if you specify the user you are looking for, i.e. 'getent passwd <USERNAME>', SSSD will give you the proper information as usual. You can always use the 'id' command for this purpose as well. It does work if you have "enumerate = True" in the sssd.conf
