Вопрос или проблема
У меня работает аутентификация 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 учетными записями, при этом ваша система останется защищенной и доступной в любое время.