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. Install: yum install -y sssd openldap-clients sssd-ldap nss-pam-ldapd libsss_sudo
2. Copy Gourd ldap dir in /etc: rsync -ravH gourd:/etc/openldap .
   1. Check/edit the ldap.conf if needed.
   2. Copy gourd sssd.conf in /etc/sssd: scp gourd:/etc/sssd/sssd.conf .

Configuring SSSD - Details

1. 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

See

Authconfig

At the bottom is a list of command line features.

  authconfig --enablesssd --enablesssdauth --enableldap --enableldapauth --enablemkhomedir \
 --ldapserver=ldap://einstein --ldapbasedn=dc=physics,dc=unh,dc=edu --enablelocauthorize --enableldaptls --update

3. Exsmple /etc/sssd/sssd.conf

 [nss]
 # The following prevents SSSD from searching for the root user/group in
 # all domains (you can add here a comma-separated list of system accounts that
 # are always going to be /etc/passwd users, or that you want to filter out).
 filter_groups = root
 #filter_users = root
 filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
 reconnection_retries = 3

 [pam]
 reconnection_retries = 3

 [domain/LDAP]
 id_provider = ldap
 ldap_schema = rfc2307
 autofs_provider = ldap
 ldap_autofs_search_base = cn=automount,dc=physics,dc=unh,dc=edu

 [domain/default]
 enumerate = True
 ldap_tls_reqcert = never
 auth_provider = ldap
 krb5_realm = physics.unh.edu
 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, ldaps://pepper
 chpass_provider = ldap
 krb5_kdcip = einstein.farm.physics.unh.edu
 cache_credentials = True
 ldap_tls_cacertdir = /etc/openldap/cacerts
 entry_cache_timeout = 600
 ldap_network_timeout = 3
 ldap_rfc2307_fallback_to_local_users = True
 sudo_provider = ldap
 ldap_sudo_search_base = ou=groups,dc=physics,dc=unh,dc=edu
 ldap_sudo_full_refresh_interval = 86400
 ldap_sudo_smart_refresh_interval = 3600
 autofs_provider = ldap

4. Example /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

External Information

• https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html
• http://www.couyon.net/1/post/2012/04/enabling-ldap-usergroup-support-and-authentication-in-centos-6.html