У меня работает аутентификация по Kerberos и авторизация по каталогу LDAP. Теперь я ищу установку клиента на Debian Buster, используя sssd.
Я начал с Аутентификация LDAP с помощью nss-pam-ldapd с помощью Авторизация прокси SASL на сервере OpenLDAP и Кэширование учетных данных OpenLDAP с помощью ccreds. Но поскольку я постоянно использую systemd и его окружение, эта традиционная установка не очень подходит к нему, и я столкнулся с некоторыми проблемами с systemd-разрешено вместе с nsswitch и / или пам как показано в раздел «Подробнее» о запросе NSS к серверу OpenLDAP.
Из-за этого я взглянул на sssd и увидел, что все это можно сделать в одном и что он основан на systemd а также использует dbus межпроцессного взаимодействия. Поэтому я решил использовать его вместо этого. Но в Debian рекомендуемый пакет sssd устанавливает все возможные службы, например для активного каталога и прочего мне не нужно. Я хочу, чтобы мои клиенты были максимально экономичными без неиспользуемого программного обеспечения, поэтому мой вопрос:
Какие пакеты Debian нужно установить только мне, чтобы получить единый вход с помощью sssd против сервера OpenLDAP с Kerberos SASL / GSSAPI и как его настроить?
После нескольких попыток и ошибок я обнаружил, что мне нужен один пакет для gssapi и четыре пакета для sssd. Я хочу иметь централизованную общую конфигурацию, поэтому я использую локальный частный DNS-сервер для разрешения имени, имени сервера и имени службы. Итак, сначала я проверяю это на клиенте. Если у вас его нет на DNS-сервере, вы можете определить его локально для каждого клиента. Я это прокомментировал. Чтобы избежать установки ненужных дополнительных пакетов, я всегда использую опцию --no-install-recommends для Debian подходящий.
Сначала убедитесь, что у вас есть действующий /etc/krb5.keytab с участием sudo klist -ke. Если он недоступен, создайте его:
rpi ~$ sudo kadmin -p user/admin
kadmin: addprinc -policy host -randkey host/<hostname>.example.com
kadmin: ktadd host/<hostname>.example.com
kadmin: q
После установки графического интерфейса пользователя, такого как GNOME или Xfce, я столкнулся с проблемами с разрешением имен. sssd не удалось разрешить домен DNS example.com с моим расширенным разрешением DNS-имен, поэтому он не находит Kerberos- и LDAP-сервер, а вход в систему не выполняется с сообщением об ошибке Authentication failure. Иногда это может сработать из-за кешированных данных для входа в систему, но с неверными данными тикета Kerberos. 1970-01-01 показано с klist. В соответствии с Разрешение имени хоста Debian у вас должна быть запись в /etc/hosts как это:
127.0.1.1 <hostname>.example.com <hostname>
Если у вас есть NSCD кеш запущен для службы имен, затем удалите его. Мы не должны использовать это, потому что sssd будет делать то же самое.
~$ sudo systemctl disable --now nscd.service
~$ sudo apt purge nscd
~$ sudo apt-mark hold nscd
Установите модули и помощники SASL / GSSAPI, необходимые для аутентификации по протоколу Kerberos и тестов:
~$ 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
Нам нужно всего четыре пакета для предоставления всех необходимых сервисов для ldap, krb5, name service и pam:
~$ sudo apt --no-install-recommends install sssd-ldap sssd-krb5 libnss-sss libpam-sss
Осталось только настроить /etc/sssd/sssd.conf. Я использую такой:
~$ 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
# I don't use this
sudo_provider = none
autofs_provider = none
cache_credentials = TRUE
Не забудьте защитить sssd.conf, иначе sssd не запустится:
~$ sudo chmod 600 /etc/sssd/sssd.conf
~$ sudo systemctl restart sssd.service
Проверьте, получает ли операционная система информацию об учетной записи из каталога ldap. Убедитесь, что запрашиваемая учетная запись пользователя находится только в каталоге ldap, а не в локальных файлах. Источник запроса обозначается символом за идентификатором пользователя.
:x: from local files (/etc/passwd and /etc/group)
:*: from the ldap directory
Убедитесь, что вы получите :*:.
~$ getent passwd ingo
ingo:*:1000:1000:Ingo:/home/ingo:/bin/bash
~$ getent group ingo
ingo:*:1000:
Установите аутентификацию pam для входа:
~$ sudo pam-auth-update
[*] Unix authentication
[*] SSS authentication
[*] Register user sessions in the systemd control group hierarchy
[*] Create home directory on login
и проверьте логин с новым пользователем:
~$ ~$ su -l ingo
Password:
Creating directory '/home/ingo'.
ingo:~$ klist
ingo:~$ logout
~$
Для тестирования настроек в sssd.conf вы должны знать, что sssd кэширует много данных, поэтому изменения не вступят в силу немедленно. Это очень сбивает с толку. Поэтому я удалил файлы в /var/lib/sss/db/ с кэшированной информацией после модификации sssd.conf. Я использовал этот однострочник как root:
~# systemctl stop sssd.service && rm /var/lib/sss/db/* && systemctl start sssd.service