SSSD

From Nuclear Physics Group Documentation Pages
Revision as of 16:55, 1 September 2015 by Maurik (talk | contribs) (→‎Notes)
Jump to navigationJump to search

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

External Information