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
- Install:
yum install -y sssd openldap-clients sssd-ldap nss-pam-ldapd libsss_sudo - Copy Gourd ldap dir in /etc:
rsync -ravH gourd:/etc/openldap .- Check/edit the ldap.conf if needed.
- Copy gourd sssd.conf in /etc/sssd:
scp gourd:/etc/sssd/sssd.conf .
Configuring SSSD - Details
- Setting up a failover Fedora sssd
8.2.3.2.4. Configuring Failover The failover feature allows back ends to automatically switch to a different server if the primary server fails. These servers are entered as a case-insensitive, comma-separated list in the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and listed in order of preference. This list can contain any number of servers. For example, if you have configured a native LDAP domain, you could specify the following as your ldap_uri values: ldap_uri = ldap://ldap0.mydomain.org, ldap://ldap1.mydomain.org, ldap://ldap2.mydomain.org In this configuration, ldap://ldap0.mydomain.org functions as the primary server. If this server fails, the SSSD failover mechanism first attempts to connect to ldap1.mydomain.org, and if that server is unavailable, it then attempts to connect to ldap2.mydomain.org. If the parameter that specifies which server to connect to for the specific domain (for example, ldap_uri, krb5_server, …) is not specified, the back end defaults to using Use service discovery. Refer to Section 8.2.3.2.4.1, “Using SRV Records with Failover” for more information on service discovery.
- 2. Use authconfig to enable the proper settings to allow authentication via SSSD
- Minimal
authconfig --enablesssd --enablesssdauth --enablelocauthorize --update
- Better
authconfig --enablesssd --enablesssdauth --enableldap --enableldapauth --enablemkhomedir \ --ldapserver=ldap://einstein --ldapbasedn=dc=physics,dc=unh,dc=edu --enablelocauthorize --enableldaptls --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> getent passwd Try to log in, try auto mount.
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
