Назад | Перейти на главную страницу

Запрос NSS к серверу OpenLDAP с использованием GSSAPI с авторизацией прокси

SASL / GSSAPI требует проверки подлинности Kerberos на сервере LDAP с авторизацией прокси при использовании Аутентификация LDAP с помощью nss-pam-ldapd в операционной системе Debian Buster. Я пытаюсь настроить это на своем Raspberry Pis для единого входа, но не могу заставить его работать.

У меня настроен сервер ldap с Как настроить авторизацию прокси-сервера SASL с сервером OpenLDAP в Debian. Я назвал прокси-пользователя прокси-пользователь так что его выдающееся имя uid=proxyuser,ou=people,ou=home,dc=hoeft-online,dc=de.

В соответствии с Аутентификация LDAP с помощью nss-pam-ldapd в системе Debian мне нужно установить пакеты libnss-ldapd и libpam-ldapd в дополнение к плагину GSSAPI libsasl2-modules-gssapi-mit. Но я буду использовать libpam-krb5 вместо того libpam-ldapd:

rpi ~$ sudo apt install libsasl2-modules-gssapi-mit libnss-ldapd ldap-utils

При установке был представлен диалог конфигурации, в котором хранятся настройки. /etc/nslcd.conf и /etc/nsswitch.conf. Мне нужно снова настроить с помощью

rpi ~$ sudo dpkg-reconfigure nslcd
rpi ~$ sudo dpkg-reconfigure libnss-ldapd

Мои настройки, указанные в диалоговых окнах:

rpi ~$ sudo cat /etc/nslcd.conf
# /etc/nslcd.conf
# nslcd configuration file. See nslcd.conf(5)
# for details.

# The user and group nslcd should run as.
uid nslcd
gid nslcd

# The location at which the LDAP server(s) should be reachable.
uri ldap://kdc-master.home.hoeft-online.de

# The search base that will be used for all queries.
base ou=home,dc=hoeft-online,dc=de

# The LDAP protocol version to use.
#ldap_version 3

# The DN to bind with for normal lookups.
#binddn cn=annonymous,dc=example,dc=net
#bindpw secret

# The DN used for password modifications by root.
#rootpwmoddn cn=admin,dc=example,dc=com

# SSL options
#ssl off
#tls_reqcert never
tls_cacertfile /etc/ssl/certs/ca-certificates.crt

# The search scope.
#scope sub

sasl_mech GSSAPI
krb5_ccname /var/run/nslcd/nslcd.tkt
sasl_authzid dn:uid=proxyuser,ou=people,ou=home,dc=hoeft-online,dc=de


~$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files ldap
group:          files ldap
shadow:         files ldap
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Теперь с getent passwd Я ожидаю получить полномочия Ingo с сервера LDAP. Он не хранится в локальном /etc/passwd. Но я получаю только локальные записи из /etc/passwd. В журналах LDAP-сервера я вижу, что попыток BIND к прокси-пользователь. Что мне здесь не хватает?
Зачем getent не получает учетные данные от сервера LDAP?

Краткий ответ

Убедитесь, что у вас есть действующий /etc/krb5.keytab с вашим host/* главный, например делать:

rpi ~$ sudo kadmin -p user/admin
kadmin:  addprinc -policy host -randkey host/<hostname>.home.hoeft-online.de
kadmin:  ktadd -k /etc/krb5.keytab host/<hostname>.home.hoeft-online.de
kadmin:  q

Отключить демон кеширования nscd если доступно с sudo systemctl disable --now nscd.service. Не путайте это с nslcd. Тогда проверьте Прокси-авторизация:

rpi ~$ sudo apt install libsasl2-modules-gssapi-mit ldap-utils
rpi ~$ kinit -p ingo
rpi ~$ ldapwhoami -Y GSSAPI -H ldap://kdc-master.home.hoeft-online.de -D "uid=proxyuser,ou=people,ou=home,dc=hoeft-online,dc=de"
SASL/GSSAPI authentication started
SASL username: ingo@HOME.HOEFT-ONLINE.DE
SASL SSF: 256
SASL data security layer installed.
dn:uid=ingo,ou=people,ou=home,dc=hoeft-online,dc=de

Затем установите:

rpi ~$ sudo apt install libnss-ldapd kstart

Просто примите настройки по умолчанию в диалоговом окне установки. Мы перезаписываем их этими файлами конфигурации. Используйте их со своими настройками:
nslcd.conf

~$ sudo cat /etc/nslcd.conf
# /etc/nslcd.conf
# nslcd configuration file. See nslcd.conf(5)
# for details.

# The user and group nslcd should run as.
uid nslcd
gid nslcd

# Logging options, default is info
#log syslog debug

# The location at which the LDAP server(s) should be reachable.
uri ldap://kdc-master.home.hoeft-online.de

# The search base that will be used for all queries.
base ou=home,dc=hoeft-online,dc=de

# The DN to bind with for normal lookups.
binddn uid=proxyuser,ou=people,ou=home,dc=hoeft-online,dc=de

# Timing/reconnect options
# You may optimize this for your environment
#bind_timelimit 10
timelimit 30
idle_timelimit 3600
reconnect_sleeptime 2
#reconnect_retrytime 10

# SSL options
#ssl off
#tls_reqcert never
tls_cacertfile /etc/ssl/certs/ca-certificates.crt

# SASL options
sasl_mech GSSAPI
krb5_ccname /var/run/nslcd/nslcd.tkt

# Other options
nss_initgroups_ignoreusers ALLLOCAL

nsswitch.conf

~$ cat /etc/nsswitch.conf
passwd:         files ldap
group:          files ldap
shadow:         files
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Перезапускаем сервис и проверяем. Быть уверенным Ingo не имеет локальной учетной записи unix в /etc/passwd.

rpi ~$ sudo systemctl restart nslcd.service
rpi ~$ getent passwd | grep ingo

настроить вход в PAM с аутентификацией Kerberos:

rpi ~$ sudo apt install libpam-krb5
rpi ~$ sudo pam-auth-update
# select what you need
[*] Kerberos authentication
[*] Unix authentication
[*] Create home directory on login

# check
rpi ~$ kdestroy
rpi ~$ su -l ingo
password:
ingo@rpi ~$ klist
ingo@rpi ~$ logout
rpi ~$

Установите демон кэширования nscd (или включите его, если он уже доступен):

rpi ~$ sudo apt install nscd

Вот и все.

Еще немного подробностей

Мне потребовалось несколько дней, чтобы выяснить, что не так с настройкой. Для устранения неполадок вы можете увеличить ведение журнала до вывода отладки на сервере LDAP до olcLogLevel: any:

slapd ~$ echo 'dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: any' > /tmp/in.ldif

slapd ~$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/in.ldif

На клиентском устройстве просто раскомментируйте строку журнала отладки в /etc/nslcd.conf.

Перезапустите службу и отключите демон кеширования. nscd (не путайте с nslcd) так как nscd может запутать тестирование:

rpi ~$ sudo systemctl restart nslcd.service
rpi ~$ sudo systemctl disable --now nscd.service

Не забудьте вернуть ведение журнала отладки и включить NSCD когда закончите. Выполнение getent passwd вы увидите в журнале клиента, что он даже не начинается с GSSAPI client step 1, ничего. Я понял, что служба nslcd.service не получает никаких учетных данных в /var/run/nslcd/nslcd.tkt для его аутентификации. Я нашел в /etc/default/nslcd что там должно начаться /usr/bin/k5start но это не установлено и нигде не задокументировано. Так что просто установите его с помощью:

rpi ~$ sudo apt install kstart

Теперь журнал показывает, что GSSAPI начинается с шага 1, но затем прерывается.

Больше всего сбивает с толку представленный диалог установки при установке libnss-ldapd. Он запрашивает записи, которые не подходят для моей настройки с GSSAPI, в частности, отличительное имя для пользователя прокси (sasl_authzid). Это не годится. Вместо этого вы должны использовать обычный binddn. Просто примите настройки по умолчанию в диалоговом окне настройки, а затем используйте файлы конфигурации из краткого ответа.

я использую systemd-networkd вместе с systemd-разрешено. С преобразователем systemd я получил раздражающую задержку в 60 секунд при входе в систему, что было неприемлемо. В journal -b показывает мне, что запрос к серверу ldap на предмет членства в группе истек через 60 секунд:

Feb 26 01:25:45 titan systemd[1]: Reached target Network is Online.
Feb 26 01:25:45 titan systemd[1]: Starting LSB: LDAP connection daemon...
Feb 26 01:25:45 titan nslcd[441]: Starting Keep alive Kerberos ticket: k5start.
Feb 26 01:25:45 titan nslcd[455]: version 0.9.10 starting
Feb 26 01:25:45 titan nslcd[455]: accepting connections
Feb 26 01:25:45 titan nslcd[441]: Starting LDAP connection daemon: nslcd.
Feb 26 01:25:45 titan systemd[1]: Started LSB: LDAP connection daemon.
Feb 26 01:25:46 titan login[435]: pam_krb5(login:auth): authentication failure; logname=local uid=0 euid=0 tty=/dev/tty1 ruser= rhost=
Feb 26 01:25:46 titan login[435]: pam_unix(login:session): session opened for user local by LOGIN(uid=0)
Feb 26 01:25:46 titan systemd[1]: Created slice User Slice of UID 65533.
Feb 26 01:25:46 titan systemd[1]: Starting User Runtime Directory /run/user/65533...
Feb 26 01:25:46 titan systemd-logind[428]: New session 1 of user local.
Feb 26 01:25:46 titan systemd[1]: Started User Runtime Directory /run/user/65533.
Feb 26 01:25:46 titan systemd[1]: Starting User Manager for UID 65533...

Feb 26 01:26:11 titan login[435]: pam_systemd(login:session): Failed to create session: Connection timed out
Feb 26 01:26:46 titan dbus-daemon[426]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 60060ms)
Feb 26 01:26:46 titan nslcd[455]: [8b4567] <group/member="local"> failed to bind to LDAP server ldap://kdc-master.home.hoeft-online.de: Can't contact LDAP server: Invalid argument
Feb 26 01:26:46 titan nslcd[455]: [8b4567] <group/member="local"> no available LDAP server found: Can't contact LDAP server: Invalid argument

Feb 26 01:26:46 titan nslcd[455]: GSSAPI client step 1
Feb 26 01:26:46 titan systemd[468]: pam_unix(systemd-user:session): session opened for user local by (uid=0)
Feb 26 01:26:46 titan nslcd[455]: [3c9869] <group/member="local"> connected to LDAP server ldap://kdc-master.home.hoeft-online.de
Feb 26 01:26:46 titan systemd[1]: Started User Manager for UID 65533.
Feb 26 01:26:46 titan systemd[1]: Started Session 1 of user local.

После нескольких дней поиска ошибок я нашел этот вариант nss_initgroups_ignoreusers ALLLOCAL в /etc/nslcd.conf исправил эту ошибку. Эта опция предотвращает поиск членства в группах через LDAP пользователей, не использующих LDAP. Это означает, что локальные зарегистрированные пользователи, такие как системные учетные записи, не будут искать сервер LDAP.