Enrolling in Central Authentication using SSSD

From CSLabsWiki
Revision as of 12:00, 20 September 2019 by Northug (talk | contribs)

This article should help you get SSSD for our Central Authentication running on a Debian-based machine. The configuration here supplants the deprecated How to add Kerberos to a Debian Machine.

Instructions here might work on machines using distributions (or even operating systems) different from Debian, but the instructions here are specifically turn-key for Debian-based machines with normal package repositories. If you're not using one of these, check that you can install SSSD, use SSSD to provide authentication and directory information (see the addendum below), and configure your local CA certificates. The configuration here should otherwise be useful if you're ready and willing to translate it to your environment.

Get the Certificate

Main article: OpenSSL CA

Talos uses our OpenSSL CA for its SSL services, including its HTTPS server and LDAPS. You'll need this to connect to LDAP with STARTTLS correctly.

In short: As root, make the directory /usr/share/ca-certificates/cosi/, cd to it, and run:

wget --no-check-certificate https://talos.cslabs.clarkson.edu/cosi_ca.crt

Add that path (the one under /usr/share/ca-certificates/) to /etc/ca-certificates.conf—appending it to the bottom will be fine:

cosi/cosi_ca.crt

After that's done, run update-ca-certificates (again as root). Ensure that it says a certificate was added.

At this point, you should be able to wget -O - https://talos.cslabs.clarkson.edu/ without it complaining about certificates.

Install SSSD

As root:

apt install sssd

The default configuration installs SSSD as an NSS and PAM provider, which suffices. It also starts, but does not create the configuration file, as documented below.

Configure SSSD

The following configuration is known to work:

[sssd]
config_file_version = 2
domains = cslabs.clarkson.edu
services = nss, pam

[domain/cslabs.clarkson.edu]
id_provider = ldap
ldap_uri = ldap://talos.cslabs.clarkson.edu
ldap_id_use_start_tls = true
ldap_search_base = dc=cslabs,dc=clarkson,dc=edu
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

auth_provider = krb5
chpass_provider = krb5
krb5_realm = CSLABS.CLARKSON.EDU
krb5_server = talos.cslabs.clarkson.edu
krb5_kpasswd = talos.cslabs.clarkson.edu
cache_credentials = true
enumerate = true

For your convenience, you should be able to get this from https://talos.cslabs.clarkson.edu/sssd.conf:

cd /etc/sssd
wget https://talos.cslabs.clarkson.edu/sssd.conf
chmod go-r sssd.conf

Note the last chmod—SSSD needs /etc/sssd/sssd.conf to be -rw------- and owned by root:root, or it will not load the configuration.

If the last wget fails on the certificate, check above to make sure you installed the OpenSSL CA certificate correctly.

Activate the Configuration

As root:

systemctl restart sssd

Test the Configuration

getent passwd

Be sure that you see the LDAP users in there.

Choose a username—yours will work, for example, but I'll use username illustratively—and do

su username

Since you're still root (right?), this will probably automatically succeed. From your new user shell, do again:

su username

Enter your password, and be sure you can log in.

If all goes well, you should have a new member of the Central Authentication pool. Congratulations!

Finishing Touches

It's not a bad idea to add the following lines to /etc/sudoers:

%admins        ALL=(ALL:ALL) ALL
%maintainers   ALL=(ALL:ALL) ALL

Formerly, we also recommended %services ALL=(ALL:ALL) NOPASSWD: ALL, but only if your service needs automated root logins (backup styles and centralized configuration management come to mind). If you don't need it, it's not worth the security hole.

Of course, adding any of these lines is up to you. Evaluate the security needs of your service as you do so—but consider also its survivability, and who you'd like to inherit its usage eventually.

Addendum for non-Debian Machines

Debian automatically enables SSSD as a PAM and NSS provider. If you're doing it manually, check /etc/nsswitch.conf and be sure that sssd is found amongst at least the passwd, group, and shadow tables. For example, our Debian machines use the following lines (truncated from the larger file):

passwd:         compat systemd sss
group:          compat systemd sss
shadow:         compat sss
gshadow:        files

Additionally, use pam_sss.so as the auth, password, account, and optional session module. Again, Debian's default configuration:

  • common-auth
# here are the per-package modules (the "Primary" block)
auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_sss.so use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth    optional                        pam_cap.so
# end of pam-auth-update config
  • common-password
# here are the per-package modules (the "Primary" block)
password        requisite                       pam_pwquality.so retry=3
password        [success=2 default=ignore]      pam_unix.so obscure use_authtok try_first_pass sha512
password        sufficient                      pam_sss.so use_authtok
# here's the fallback if no module succeeds
password        requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password        required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
  • common-account
# here are the per-package modules (the "Primary" block)
account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
# here's the fallback if no module succeeds
account requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
account sufficient                      pam_localuser.so
account [default=bad success=ok user_unknown=ignore]    pam_sss.so
# end of pam-auth-update config
  • common-session
# here are the per-package modules (the "Primary" block)
session [default=1]                     pam_permit.so
# here's the fallback if no module succeeds
session requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required                        pam_permit.so
# The pam_umask module will set the umask according to the system default in
# /etc/login.defs and user settings, solving the problem of different
# umask settings with different shells, display managers, remote sessions etc.
# See "man pam_umask".
session optional                        pam_umask.so
# and here are more per-package modules (the "Additional" block)
session required        pam_unix.so
session optional                        pam_sss.so
session optional        pam_systemd.so
# end of pam-auth-update config

These example PAM stacks are illustrative; you may need to perform other configuration depending on the nature of your machine. A full discussion of PAM is outside the scope of this document; consult pam.conf(5) for more information.