Enrolling in Central Authentication using SSSD

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

sudo

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.

NFS

Main article: How to add Kerberos to a Debian Machine#Setting up NFS

Bacon, our storage server, serves NFSv4 with Kerberos authentication (backed by Talos). This provides the shared home directories, in particular. In order to allow the system to authenticate against the NFS share at all, you'll need to add a host key, first.

As root, first apt install krb5-user if you haven't already. If it says (You will have to enable component called 'universe') when you try to run kadmin, or otherwise fails to find an installation candidate, make sure that universe is available in /etc/apt/sources.list, e.g.:

deb http://mirror.clarkson.edu/ubuntu bionic main universe
deb http://mirror.clarkson.edu/ubuntu bionic-security main universe
deb http://mirror.clarkson.edu/ubuntu bionic-updates main universe

If you just changed it so that it's present, you'll need to run apt update now before trying again to install krb5-user.

The krb5-user installer may prompt you what default domain to use. Use the one in the default_realm given below. That's where it will end up, anyway; you'll still need to change the configuration file when it's done, as follows.

You'll need to configure it to recognize our realm; go into /etc/krb5.conf and ensure the following line is set to this value under the appropriate section:

[libdefaults]
        default_realm = CSLABS.CLARKSON.EDU

Under the [realms] section, fill out the following information:

[realms]
# ...
        CSLABS.CLARKSON.EDU = {
                kdc = talos.cslabs.clarkson.edu
                admin_server = talos.cslabs.clarkson.edu
                default_domain = cslabs.clarkson.edu
        }

And, in case DNS isn't working, it's good to fill this out too, as long as your host knows its fully-qualified domain name (be sure to set it that way in the hostname and /etc/hosts):

[domain_realm]
# ...
        .cslabs.clarkson.edu = CSLABS.CLARKSON.EDU
        cslabs.clarkson.edu = CSLABS.CLARKSON.EDU

With all the configuration done, as root, use your administrative principal (assuming that's username/admin@CSLABS.CLARKSON.EDU--if you don't have one of these, sudo kadmin.local on Talos and addprinc username/admin, and set the password):

# kadmin -p username/admin
...
kadmin:  addprinc -randkey host/myhost.cslabs.clarkson.edu
...
kadmin:  ktadd host/myhost.cslabs.clarkson.edu
...
kadmin:  q

Then add the following mountpoint to /etc/fstab:

bacon.cslabs.clarkson.edu:/storage/      /mnt        nfs4         sec=krb5i,nolock         0         0

Now would be a good time to apt install nfs-common, if you haven't already. If that did just install, you'll probably need to systemctl start rpc-gssd as well before going on.

Try the following:

mount /mnt

...if all went well, your configuration was successful! If it specifies an "incorrect mount option", make sure your keytab has the host key (klist -k, look for host/myhost.cslabs.clarkson.edu), and restart rpc.gssd (usually systemctl restart rpc-gssd) before trying again.

Assigning LDAP Groups to Local Groups

External resource: [1]

It's commonly the case that UNIX (local) groups are used as "roles" for access control--for example, disk can access block devices, dialout TTYs, libvirt can administer libvirt through virsh as a user, lxd can access LXC containers as a user...

The normally-recommended setup is to supplant the local groups with LDAP groups entirely. However, for stability reasons, we recommend keeping the local groups and using the LDAP groups to "imply" local group membership (if you're a member of LDAP group A, then you're a member of local group B).

First, as root, edit or create /etc/security/group.conf and add lines similar to the following:

*;*;%admins;Al0000-2400;groupa,groupb
*;*;%maintainers;Al0000-2400;groupa

(To be clear, this adds all users which are a member of admins to local groups groupa and groupb, and all users which are a member of maintainers to groupa only, across all services (first *), all TTYs (second *), and at all times (Al0000-2400).)

Debian doesn't put the required PAM module, pam_group.so, into common-auth by default. To add the module, copy this config into some (non-dot) file under /usr/share/pam-configs/ (I used /usr/share/pam-configs/groupconf):

Name: activate /etc/security/group.conf always
Default: yes 

Priority: 900 
Auth-Type: Primary
Auth:
    required    pam_group.so

Then, as root, run pam-auth-update. Ensure that the checkbox next to activate /etc/security/group.conf always is checked (it should be by default).

Try logging in as your user account (or get someone to test theirs--it only works in auth phase) to verify that the local group implications succeeded; if they did, you're all set!

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    required    pam_group.so
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

Note: the presence of pam_group.so here is specifically for the section on Assigning LDAP Groups to Local Groups above.

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