Аутентификация через SSSD, но журналы Unix Auth фиксируют сбой

Вопрос или проблема

У меня работает аутентификация WinAD на всех 20+ наших серверах с Debian 11. У нас также есть несколько серверов CentOS/Rocky, которые работают корректно. Вход на одну из машин Debian вызывает следующие логи:

Mar 22 07:53:06 pcap-1 sshd[1107]: pam_unix(sshd:auth): ошибка аутентификации; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.18.224.2  user=ross
Mar 22 07:53:06 pcap-1 sshd[1107]: pam_sss(sshd:auth): успешная аутентификация; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.18.224.2 user=ross

Я изменил nsswitch.conf (после настройки моего базового конфигурационного файла всего сервера, ‘sss’ генерируется в конце каждой строки, показанной ниже, я вручную переместил их в начало)

passwd:         sss files systemd
group:          sss files systemd
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
networks:       files

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

netgroup:       sss nis
automount:      sss

Мы хотим, чтобы аутентификация Unix оставалась на случай, если нам нужно войти с нашей локальной учетной записи администратора, но при этом позволяла пользователям AD входить.

Почему аутентификация Unix выполняется перед sss?

Подсказка на самом деле содержится в (очень полезном) логе, который вы привели: pam_unix и pam_sss. Эти логи приходят из системы PAM.

Если вы посмотрите в /etc/pam.d, вы увидите различные файлы, настраивающие работу входа, и я подозреваю, что во многих из них pam_unix появится перед pam_sss.

Давно я не имел дела с PAM, поэтому не буду советовать вам здесь, кроме как предостеречь, что изменение этих файлов без глубокого понимания может помешать вам войти в систему.

Нет ничего принципиально неправильного в том, что система пытается выполнить UNIX-вход перед AD. Я не уверен, что изменение порядка обеспечит какую-либо практическую выгоду, кроме подавления (безвредного) сообщения – пока вы не попытаетесь войти с учетной записью UNIX, в этом случае вы сначала получите (безвредное) сообщение о сбое входа в AD.

Ответ или решение

Судя по вашему запросу, вы сталкиваетесь с проблемами аутентификации в рамках архитектуры, где используется SSSD для Windows Active Directory (AD) на рядах серверов Debian 11 и CentOS/Rocky. Логи, которые вы предоставили, указывают на то, что сначала происходит попытка аутентификации через PAM с использованием pam_unix, а затем успешная аутентификация через pam_sss. Давайте рассмотрим, почему это может происходить и какие шаги можно предпринять для решения проблемы.

Причины проблемы

1. Настройка PAM:

Система PAM (Pluggable Authentication Modules) контролирует порядок, в котором выполняются методы аутентификации. Если в файлах конфигурации PAM, расположенных в /etc/pam.d/, модуль pam_unix стоит перед pam_sss, то сначала будет попытка аутентификации через локальные учетные записи (Unix), прежде чем будет проверка в AD через SSSD.

2. Конфигурация nsswitch.conf:

Хотя вы изменили nsswitch.conf для того, чтобы sss стоял в начале, это не обязательно влияет на порядок проверки в PAM. Важно понимать, что данные настройки относятся к механизму, где система ищет учетные записи пользователей, но порядок аутентификации определяется в конфигурации PAM.

Рекомендации по решению

1. Проверка конфигурации PAM:

Просмотрите файлы в /etc/pam.d/, такие как sshd, common-auth, login и убедитесь, что pam_sss размещен перед pam_unix. Пример для sshd:

auth required pam_env.so
auth required pam_unix.so nullok
auth required pam_sss.so

При этом важно не убивать локальную аутентификацию. Убедитесь, что вы оставляете необходимый порядок, чтобы сохранить доступ к локальным учетным записям.

2. Проверка SSSD:

Убедитесь, что SSSD настроен правильно. Проверьте файл конфигурации /etc/sssd/sssd.conf, дайте необходимым правам его выполнить (обычно это 600), и проверьте правильность секций [domain/...], [sssd], [pam] и других, относящихся к вашей настройке.

3. Логи и отладка:

После исправления порядка аутентификации протестируйте систему и наблюдайте за логами (например, journalctl -xe, cat /var/log/auth.log) для получения более подробной информации по всем попыткам аутентификации. Также вы можете включить уровень отладки для SSSD, изменив параметр debug_level в конфигурации SSSD.

Заключение

В данной ситуации следует сосредоточиться на порядке, в котором выполняются модули PAM, и убедиться, что SSSD правильно настроен для адекватной проверки учетных записей в Windows AD. Устранение проблем с порядком вызовов модулей аутентификации может не только улучшить логику аутентификации, но и уменьшить количество нежелательных сообщений об ошибках в логах. Это приведет к более плавному взаимодействию с вашей системой, обеспечивая пользователей как локальными, так и AD учетными записями, при этом ваша система останется защищенной и доступной в любое время.

Оцените материал
Добавить комментарий

Капча загружается...