0

Authentication against Kerberos and authorization against an LDAP directory is working for me. Now I'm looking for the client setup on Debian Buster using sssd.

I started with LDAP authentication with nss-pam-ldapd using SASL Proxy Authorization on an OpenLDAP server and Caching OpenLDAP credentials with ccreds. But because I consistent use systemd and its environment, that traditional setup does not fit very well to it and I run into some problems with systemd-resolved together with nsswitch and/or pam as shown in section "Some more details" about NSS query against OpenLDAP server.

Because of this I had a look at sssd and saw that it can do it all in one and that it is based on systemd and also uses dbus interprocess communication. So I decided to use it instead. But on Debian the recommended package sssd installs all possible services, e.g. for active directory and other things I do not need. I want to have my clients as lean as possible without unused software, so my question is:

What Debian packages only I have to install to get a single sign on using sssd against OpenLDAP server with Kerberos SASL/GSSAPI and how to configure it?

0

Abstract

After some tries and error I found that I need one package for gssapi and four packages for sssd. I want to have general configuration centralized so I use a local private dns server for name-, servername- and servicename-resolution. So first I check this on the client. If you don't have it on a DNS server you can define it all local on every client. I have commented it. To avoid installation of unneeded additional packages I always use option `--no-install-recommends` for Debian **apt**.

Prepare Kerberos client

First ensure that you have a valid `/etc/krb5.keytab` with `sudo klist -ke`. If not available then create one:
rpi ~$ sudo kadmin -p user/admin
kadmin:  addprinc -policy host -randkey host/<hostname>.example.com
kadmin:  ktadd host/<hostname>.example.com
kadmin:  q

After installing a Graphical User Interface like GNOME, or Xfce, I run into problems with name resolution. sssd wasn't able to resolve the DNS domain example.com with my extended DNS name resolution, so it does not find the Kerberos- and LDAP-server and login fails with error message Authentication failure. This may work sometimes because of cached login data but with invalid kerberos ticket data 1970-01-01 shown with klist. According to Debian hostname resolution you should have an entry in /etc/hosts like this:

127.0.1.1    <hostname>.example.com    <hostname>

If you have the nscd cache running for name service then deinstall it. We must not use it because sssd will do the same.

~$ sudo systemctl disable --now nscd.service
~$ sudo apt purge nscd
~$ sudo apt-mark hold nscd

Install SASL/GSSAPI modules and helpers we need for authentication against Kerberos and tests:

~$ sudo apt --no-install-recommends install libsasl2-modules-gssapi-mit dnsutils ldap-utils

# check DNS resolution; must resolve full qualified dns names
~$ dig +noall +answer $(hostname -f)
~$ dig +noall +answer -x $(hostname -I)

# Check Kerberos server and LDAP server
~$ dig +noall +answer ldap-primary.example.com
~$ dig +noall +answer kdc-master.example.com

# Query for kerberos service (response: kdc10-1.example.com on port 88)
~$ dig +noall +answer SRV _kerberos._udp.example.com
_kerberos._udp.example.com 38400 IN SRV   0 0 88 kdc10-1.example.com.
# Query for ldap service (response: kdc10-1.example.com on port 389)
~$ dig +noall +answer SRV _ldap._tcp.example.com
_ldap._tcp.example.com. 38400 IN SRV   0 0 389 kdc10-1.example.com.

# Check if the sssd.service can access the LDAP-server. It uses this principal
~$ sudo kinit -k host/<hostname>.example.com
~$ sudo ldapsearch -Y GSSAPI -LLL -H ldap://ldap-primary.example.com -b "ou=home,dc=example,dc=com" "(cn=ingo)" uid cn
SASL/GSSAPI authentication started
SASL username: host/<hostname>.example.com@EXAMPLE.COM
SASL SSF: 256
SASL data security layer installed.
dn: cn=ingo,ou=group,ou=home,dc=example,dc=com
cn: ingo

dn: uid=ingo,ou=people,ou=home,dc=example,dc=com
uid: ingo
cn: Ingo

Install sssd


We need just four packages to provide all needed services for ldap, krb5, name service and pam:

~$ sudo apt --no-install-recommends install sssd-ldap sssd-krb5 libnss-sss libpam-sss

The only what's left over is to configure /etc/sssd/sssd.conf. I use this one:

~$ sudo cat /etc/sssd/sssd.conf
[sssd]
# debug log files in /var/log/sssd/
#debug_level = 7
config_file_version = 2
domains = HOME
# don't set services on Debian Bullseye. It's managed there
# by sssd-nss.socket and sssd-pam-priv.socket
services = nss, pam

[nss]
#debug_level = 7

[pam]
#debug_level = 7

[domain/HOME]
#debug_level = 7
# Set enumerate only for debugging, never for production!
#enumerate = TRUE

id_provider = ldap
# If you haven't a SRV record in DNS for the server then set it here
#ldap_uri = ldap://ldap-primary.example.com
# SRV record for backup server isn't supported. We have to set it always.
ldap_backup_uri = ldap://ldap-secondary.example.com
ldap_search_base = ou=home,dc=example,dc=com
ldap_sasl_mech = gssapi

auth_provider = krb5
chpass_provider = krb5
# Maybe I want to use the .k5login file in the home directory of the user
access_provider = krb5

# If you haven't a SRV record in DNS for the server then set it here
#krb5_server = kdc-master.example.com
# SRV record for backup server isn't supported. We have to set it always.
krb5_backup_server = kdc-replica.example.com
# If the authid isn't the first entry in /etc/krb5.keytab then set it here
#ldap_sasl_authid = host/<hostname>.example.com@EXAMPLE.COM
# krb5_realm must always be set here. There is no look at `/etc/krb5.conf`
krb5_realm = EXAMPLE.COM
#krb5_renewable_lifetime = 3d
krb5_renew_interval = 1h

# I don't use this
sudo_provider = none
autofs_provider = none

cache_credentials = TRUE

Don't forget to protect sssd.conf, otherwise sssd will not start:

~$ sudo chmod 600 /etc/sssd/sssd.conf
~$ sudo systemctl restart sssd.service

Check if the operating system gets the account information from the ldap directory. Be sure the queried user account is only in the ldap directory, not in local files. The source of the query is indicated by the character behind the user id.

:x:   from local files (/etc/passwd and /etc/group)
:*:   from the ldap directory

Be sure you get :*:.

~$ getent passwd ingo
ingo:*:1000:1000:Ingo:/home/ingo:/bin/bash
~$ getent group ingo
ingo:*:1000:

Set pam authentication for login:

~$ sudo pam-auth-update
[*] Unix authentication
[*] SSS authentication
[*] Register user sessions in the systemd control group hierarchy
[*] Create home directory on login

and check login with a new user:

~$ ~$ su -l ingo
Password:
Creating directory '/home/ingo'.
ingo:~$ klist
ingo:~$ logout
~$

For testing settings in sssd.conf you have to know that sssd is caching many data so changes will not immediately have an effect. This is very confusing. So I deleted the files in /var/lib/sss/db/ with the cached information after a modification of sssd.conf. I used this one-liner as root:

~# systemctl stop sssd.service && rm /var/lib/sss/db/* && systemctl start sssd.service

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.