аутентификация через LDAP перестала работать после обновления до SLES 11.4 рекомендованным методом (загрузка с DVD). К сожалению, с SLES я не могу предоставить вам какой-либо значимый вывод журнала, поскольку ни PAM, ни клиент ldap не предоставляют вам ничего, а pam_debug недоступен на SLES.
Мы подозреваем, что все сводится к требованию пользовательского фильтра inetOrgPerson. Конечно, мы устанавливаем этот фильтр в /etc/ldap.conf. Он отлично работал в 10.4, но теперь вы получаете «неверный пароль».
Используя tcpdump, я смог определить, что, в отличие от версии 10.4, клиент ldap теперь сначала запрашивает сервер с помощью фильтра inetOrgPerson (который работает и возвращает результаты), а затем (!) Запрашивает сервер с фильтром posixAccount. Теперь последний не работает, потому что этот атрибут не используется сервером LDAP (IBM Tivoli Directory Server). Поскольку запрос пароля теперь выполняется с неправильным фильтром пользователей - пароль никогда не проверяется по LDAP (насколько я могу судить), и поэтому вход в систему не выполняется.
Есть ли способ заставить LDAP-клиент придерживаться настроенного пользовательского фильтра (inetOrgPerson) вместо того, чтобы переключаться на (жестко запрограммированный?) Неверный для запросов о пароле и оболочке? Дело в том, что мы не используем пароли для входа в систему через ssh, поэтому нам нужен только этот PAM + LDAP, чтобы он работал, чтобы приложения могли проверять пароли пользователей на его обратное (приложение не имеет собственной поддержки LDAP). Таким образом, нам не нужны записи в LDAP для пользовательской оболочки и всего остального, что обычно назначается posixAccount.
Насколько я могу судить, модификация производственного LDAP-сервера не является вариантом.
FWIW Метод тестирования - это ssh'ing в поле (с помощью pubkey), а затем попытка su для нашего собственного пользователя для запроса пароля. / var / log / messages сообщает только "failed su ..." без каких-либо подробностей