Difference between revisions of "Enrolling in Central Authentication using SSSD"
Line 179: | Line 179: | ||
...if all went well, your configuration was successful! If it specifies an "incorrect mount option", make sure your keytab has the host key (<code>klist -k</code>, look for <code>host/myhost.cslabs.clarkson.edu</code>), and restart <code>rpc.gssd</code> (usually <code>systemctl restart rpc-gssd</code>) before trying again. |
...if all went well, your configuration was successful! If it specifies an "incorrect mount option", make sure your keytab has the host key (<code>klist -k</code>, look for <code>host/myhost.cslabs.clarkson.edu</code>), and restart <code>rpc.gssd</code> (usually <code>systemctl restart rpc-gssd</code>) before trying again. |
||
+ | |||
+ | === Assigning LDAP Groups to Local Groups === |
||
+ | |||
+ | :''External resource: [https://help.ubuntu.com/community/LDAPClientAuthentication#Assign_local_groups_to_users]'' |
||
+ | |||
+ | It's commonly the case that UNIX (local) groups are used as "roles" for access control--for example, <code>disk</code> can access block devices, <code>dialout</code> TTYs, <code>libvirt</code> can administer libvirt through <code>virsh</code> as a user, <code>lxd</code> 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 <code>/etc/security/group.conf</code> and add lines similar to the following: |
||
+ | |||
+ | <pre> |
||
+ | *;*;%admins;Al0000-2400;groupa,groupb |
||
+ | *;*;%maintainers;Al0000-2400;groupa |
||
+ | </pre> |
||
+ | |||
+ | (To be clear, this adds all users which are a member of <code>admins</code> to local groups <code>groupa</code> and <code>groupb</code>, and all users which are a member of <code>maintainers</code> to <code>groupa</code> only, across all services (first <code>*</code>), all TTYs (second <code>*</code>), and at all times (<code>Al0000-2400</code>).) |
||
+ | |||
+ | Debian doesn't put the required PAM module, <code>pam_group.so</code>, into <code>common-auth</code> by default. To add the module, copy this config into some (non-dot) file under <code>/usr/share/pam-configs/</code> (I used <code>/usr/share/pam-configs/groupconf</code>): |
||
+ | |||
+ | <pre> |
||
+ | Name: activate /etc/security/group.conf always |
||
+ | Default: yes |
||
+ | |||
+ | Priority: 900 |
||
+ | Auth-Type: Primary |
||
+ | Auth: |
||
+ | required pam_group.so |
||
+ | </pre> |
||
+ | |||
+ | Then, as <code>root</code>, run <code>pam-auth-update</code>. Ensure that the checkbox next to <code>activate /etc/security/group.conf always</code> 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! |
||
Line 197: | Line 230: | ||
<pre> |
<pre> |
||
# here are the per-package modules (the "Primary" block) |
# 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=2 default=ignore] pam_unix.so nullok_secure |
||
auth [success=1 default=ignore] pam_sss.so use_first_pass |
auth [success=1 default=ignore] pam_sss.so use_first_pass |
||
Line 209: | Line 243: | ||
# end of pam-auth-update config |
# end of pam-auth-update config |
||
</pre> |
</pre> |
||
+ | :''Note: the presence of <code>pam_group.so</code> here is specifically for the section on [[#Assigning LDAP Groups to Local Groups|Assigning LDAP Groups to Local Groups]] above.'' |
||
* <code>common-password</code> |
* <code>common-password</code> |
Latest revision as of 13:34, 20 September 2019
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.
Contents
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.