Вопрос или проблема
Я могу переключиться на упомянутого доменного пользователя с помощью команды su с сервера, но вход через ssh не удается. Группа доменных пользователей уже добавлена в файл sssd.conf под параметром “simple_allow_groups”.
Ошибки в /var/log/secure выглядят следующим образом:
Jan 18 04:10:18 m1-vlp0006 sshd[6420]: pam_sss(sshd:auth): аутентификация успешна; logname= uid=0 euid=0 tty=ssh ruser= rhost=138.35.x.x user=postl\u522660
Jan 18 04:10:18 m1-vlp0006 sshd[6420]: pam_sss(sshd:account): Доступ запрещен для пользователя postl\u522660: 6 (Доступ запрещен)
Jan 18 04:10:18 m1-vlp0006 sshd[6420]: Неверный пароль для postl\\u522660 с 138.35.x.x порт 57903 ssh2
Jan 18 04:10:18 m1-vlp0006 sshd[6420]: фатальная ошибка: доступ запрещен для пользователя postl\\\\u522660 по конфигурации PAM [preauth]
Понял, что там говорится о неверном пароле. Но на самом деле это не так, я успешно могу войти на другой Windows-машине с этим доменным пользователем. Те же учетные данные я ввожу и здесь. Таким образом, мои введенные учетные данные верны, но я не уверен, почему это отображается именно так. Далее я вижу успешную аутентификацию вначале, но в конечном итоге получаю отказ в доступе. Есть ли какая-либо конфигурация, которой не хватает для того, чтобы разрешить конкретному AD пользователю или группе войти на этот сервер, помимо добавления соответствующей группы этого пользователя в “simple_allow_groups”?
Конфигурация выглядит следующим образом:
[[email protected] ~]# realm list --all
POSTLl.xxxx.xxx
тип: kerberos
имя-реалма: POSTL.xxxx.xxx
имя-домена: POSTL.xxxx.xxx
настроен: kerberos-member
серверное ПО: active-directory
клиентское ПО: sssd
требуемый пакет: oddjob
требуемый пакет: oddjob-mkhomedir
требуемый пакет: sssd
требуемый пакет: adcli
требуемый пакет: samba-common-tools
форматы-входа: %[email protected]
политика-входа: разрешить-разрешенные-входы
разрешенные-входы:
разрешенные-группы: gu-adm-infra-unix-systems, gu-adm-esm%unix, gu-adm-epicon, domain%users
Сегодня я столкнулся с аналогичной проблемой, не знаю, чем это может помочь вам.
Я смог войти с помощью su (после входа как root), но не смог осуществить ssh-доступ непосредственно с пользователями ActiveDirectory.
Я прочитал несколько статей в интернете и просто перезапустил службу SSSD, и она стала работать.
systemctl restart sssd
Это известная проблема у Red Hat. Это простое упущение одной строки в файле /etc/sssd/sssd.conf
и ожидается, что она будет исправлена в версии Red Hat V6.4.
Следующая строка должна быть добавлена в секцию домена, которая используется для доступа к серверу AD:
krb5_canonicalize = false
Затем sssd нужно перезапустить…
service sssd restart
На самом деле, я столкнулся с той же проблемой в окружении Centos 8 NIS и, следуя модулю pam, я прокомментировал в следующих 2 файлах, и теперь я могу войти с аутентификацией kerberos. Это может помочь кому-то, у кого есть проблемы с входом из-за следующих логов ошибок.
Unix_chkpwd: не удалось получить информацию о пользователе (Пользователь) sshd[19550]: Неверный пароль для [пользователь] по IP фатальная ошибка: доступ запрещен для пользователя [пользователь] по конфигурации PAM [preauth]
vi /etc/pam.d/password-auth #auth sufficient pam_unix.so nullo try_first_pass #account required pam_unix.so #password sufficient pam_unix.so sha512 shadow #session required pam_unix.so
vi system-auth #auth sufficient pam_unix.so nullok try_first_pass #account required pam_unix.so #password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok #session required pam_unix.so
Ответ или решение
Проблема, с которой вы столкнулись, действительно может быть вызвана несколькими факторами, связанными с конфигурацией SSSD для аутентификации пользователей Active Directory (AD) в RHEL 7. Из вашего описания видно, что вы можете переключаться на указанного доменного пользователя через команду su
, но аутентификация через SSH не проходит. Давайте разберёмся с возможными решениями.
1. Проверка конфигурации SSSD
Сначала убедитесь, что файл конфигурации SSSD находитесь в корректном состоянии. Откройте файл /etc/sssd/sssd.conf
и убедитесь, что в разделе вашего домена присутствует строка:
krb5_canonicalize = false
Эта строка помогает предотвратить проблемы с канонизацией имен в Kerberos для пользователей, что может быть причиной отказа в доступе.
2. Перезапуск службы SSSD
После внесения изменений в конфигурацию, обязательно перезапустите SSSD для применения изменений:
systemctl restart sssd
3. Проверьте группы и разрешения
Убедитесь, что группа, к которой принадлежит ваш доменный пользователь, добавлена в параметр simple_allow_groups
в конфигурации /etc/sssd/sssd.conf
и что она соответствует всем требованиям, указанным в конфигурации:
simple_allow_groups = имя_вашей_группы
Если вы добавили группу, но аутентификация все еще не проходит, попробуйте добавить разрешения на SSH для данной группы:
- Убедитесь, что файл
/etc/ssh/sshd_config
разрешает вход для групп, определенных вAllowGroups
.
AllowGroups имя_вашей_группы
После изменения конфигурации SSH необходимо перезапустить службу SSH:
systemctl restart sshd
4. Проверка PAM
Иногда проблема может быть связана с конфигурацией PAM, в частности, с файлами /etc/pam.d/password-auth
и /etc/pam.d/system-auth
. Если вы видите сообщения об ошибках, такие как:
fatal: Access denied for user [user] by PAM account configuration [preauth]
Можно попробовать закомментировать строки, относящиеся к pam_unix.so
, в вышеуказанных файлах:
#auth sufficient pam_unix.so nullok try_first_pass
#account required pam_unix.so
#password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
#session required pam_unix.so
После внесения изменений в файлы PAM также обязательно сохраните и закройте их, а затем попробуйте снова войти в систему.
5. Логи и диагностика
Также стоит внимательно просмотреть логи /var/log/secure
и другие связанные логи, чтобы найти возможные подсказки о том, почему именно аутентификация не проходит. Используйте команду tail -f /var/log/secure
для мониторинга событий в реальном времени во время входа пользователя через SSH.
Заключение
Если все указанное выше не решит проблему, возможно, стоит проверить наличие известных ошибок или обновлений для вашей версии RHEL в официальной документации Red Hat. Если проблема будет повторяться, рассмотрите возможность обращения в техническую поддержку Red Hat для получения дополнительной помощи.
Надеюсь, что эти шаги помогут вам найти и устранить причину проблемы с доступом к учетной записи AD в RHEL 7.