Единый вход с использованием SSSD против сервера OpenLDAP с Kerberos SASL / GSSAPI

У меня работает аутентификация по протоколу Kerberos и авторизация по каталогу LDAP. Теперь я ищу настройку клиента на Debian Buster с использованием sssd .

Я начал с аутентификации LDAP с помощью nss-pam-ldapd , используя авторизацию прокси-сервера SASL на Сервер OpenLDAP и Кэширование учетных данных OpenLDAP с помощью ccreds . Но поскольку я постоянно использую systemd и его среду, эта традиционная установка не очень подходит для него, и я столкнулся с некоторыми проблемами с systemd-resolved вместе с nsswitch ] и / или pam , как показано в разделе «Некоторые дополнительные сведения» о запросе NSS к серверу OpenLDAP .

Из-за этого я взглянул на sssd и увидел, что он может делать все в одном и что он основан на systemd , а также использует межпроцессное взаимодействие dbus . Поэтому я решил использовать его вместо этого. Но в Debian рекомендуемый пакет sssd устанавливает все возможные службы, например для активного каталога и прочего мне не нужно. Я хочу, чтобы мои клиенты были максимально компактными без неиспользуемого программного обеспечения, поэтому мой вопрос:

Какие только пакеты Debian мне нужно установить, чтобы получить единый вход с использованием sssd против сервера OpenLDAP с Kerberos SASL / GSSAPI и как его настроить?

0
задан 2 March 2020 в 02:18
1 ответ

Аннотация

После некоторых попыток и ошибок я обнаружил, что мне нужен один пакет для gssapi и четыре пакета для sssd. Я хочу иметь централизованную общую конфигурацию, поэтому я использую локальный частный DNS-сервер для разрешения имени, имени сервера и имени службы. Итак, сначала я проверяю это на клиенте. Если у вас его нет на DNS-сервере, вы можете определить его локально для каждого клиента. Я это прокомментировал. Чтобы избежать установки ненужных дополнительных пакетов, я всегда использую опцию - no-install-рекомендует для Debian apt .

Подготовьте клиент Kerberos

Сначала убедитесь, что у вас есть действующий /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-сервер, и происходит сбой входа с сообщением об ошибке Ошибка аутентификации . Иногда это может сработать из-за кешированных данных входа в систему, но с неверными данными билета 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 --autoclean purge 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

# Установите sssd

Нам нужно всего четыре пакеты для предоставления всех необходимых служб для ldap, krb5, службы имен и 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
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, а не в локальных файлах / etc / passwd и / etc / group :

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

Если это не работает на при первой попытке просто перезапустите службу sssd.service еще раз. Я не знаю, зачем это нужно.

Установите аутентификацию 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
0
ответ дан 30 March 2020 в 01:31

Теги

Похожие вопросы