Integration with SSSD

Make sure that nscd is not installed, as it will interfere with SSSD.

This approach works better if you are forwarding to an AD server, FreeIpa, or other domain-based auth environments.

Setup

Create /etc/sssd/conf.d/auth-something.conf. Note that group enforcement takes place in this same file:

The services directive is commented out because it is not needed in recent versions of SSSD. The documentation mentions leaving it in as a quirky warning, but it will unfortunately create more issues than that description implies.

1[sssd]
2config_file_version = 2
3#services = nss, pam, ssh
4domains = MYDOMAIN
5 
6[nss]
7 
8[pam]
9 
10[domain/MYDOMAIN]
11#cache_credentials = True
12enumerate = False
13id_provider = ldap
14auth_provider = ldap
15access_provider = ldap
16ldap_uri = {auth_uri}
17ldap_search_base = dc=glauth,dc=com
18ldap_default_bind_dn = cn=serviceuser,ou=service,dc=glauth,dc=com
19ldap_default_authtok_type = password
20ldap_default_authtok = {your root user password}
21ldap_use_tokengroups = False
22ldap_tls_cacert = /etc/ssl/certs/auth-yourcert.crt
23sudo_provider = none
24ldap_group_member = member
25ldap_schema = rfc2307bis
26ldap_access_order = filter
27ldap_access_filter = (memberOf=ou=service,dc=glauth,dc=com)

In /etc/ldap/ldap.conf, remove this line:

1TLS_CACERT /etc/ssl/certs/ca-certificates.crt

and replace it with:

1TLS_CACERT /etc/ssl/certs/auth-yourcert.crt

Same as above, create a home directory on demand. In /etc/pam.d/common-session:

1session. required. pam_mkhomedir.so umask=0077

Do not forget to install, start and enable the sssd service. Done.

Enumerating

A sssd domain can be configured, using enumerate = True, to cache locally LDAP’s knowledge of existing users and groups.

If this setting remains False, commands such as getent passwd and getent group will ignore these remote entries, unless an entry name is explicitly provided.

For security reasons, it is usually recommended to not enable this setting.

Note that, even with this setting enabled, SSSD would still only cache entries that match the ldap_access_filter directive.

In addition, while GLAuth implements both rfc2307 and rfc2307bis schemas, SSSD currently only supports the former and does not properly list users belonging to a given group.

Debugging

If you are experiencing issues convincing SSSD to use GLAuth, you can check the SSSD logs by running journalctl -u sssd.

If you need to troubleshoot various subsytems’ behavior, you can also check their logs. The three most likely interesting log files being:

  • /var/log/sssd/sssd_MYDOMAIN.log
  • /var/log/sssd/sssd_pam.log
  • /var/log/sssd/sssd_nss.log

(note: replace MYDOMAIN with the actual domain name you are using)

In order to get more verbose logging, you can edit /etc/sssd/conf.d/auth-something.conf (or whatever you named your configuration file) and change debug_level = 0 to debug_level = 5 or higher in each section.

Basic LDAP filters used by SSSD:

In this example, we are authenticating as the hackers user.

  • (&(uid=hackers)(objectclass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))
  • (&(member=cn=hackers,ou=superheros,ou=users,dc=glauth,dc=com)(objectClass=posixGroup)(cn=*))
  • (&(uid=hackers)(objectclass=posixAccount)(memberOf=ou=superheros,ou=groups,dc=glauth,dc=com))
  • (&(cn=superheros)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))

Considered future improvements

  • Implement support for Update Sequence Value (USN) based synchronization.
  • Use access_provider = simple to allow per-user LDAP access control.
  • Use ldap_access_filter to specify user access to LDAP entries.
Copyright 2021