у нас есть пара серверов с PAM + LDAP.
Конфигурация стандартная (см. http://arthurdejong.org/nss-pam-ldapd/setup или http://wiki.debian.org/LDAP/PAM). Например, /etc/pam.d/common-auth содержит:
auth sufficient pam_unix.so nullok_secure
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
И, конечно же, это работает как для ldap, так и для локальных пользователей. Но каждый вход сначала идет в pam_unix.so, терпит неудачу, и только потом успешно пытается выполнить pam_ldap.so. В результате у нас есть хорошо известное сообщение об ошибке для каждого входа пользователя ldap:
pam_unix(<some_service>:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<some_host> user=<some_user>
У меня до 60000 таких сообщений журнала в день, и я хочу изменить конфигурацию, чтобы PAM сначала попробовал аутентификацию ldap, и только в случае сбоя - попробуйте pam_unix.so (я думаю, что это может улучшить производительность ввода-вывода сервер). Но если я изменю common-auth на следующее:
auth sufficient pam_ldap.so use_first_pass
auth sufficient pam_unix.so nullok_secure
auth required pam_deny.so
Тогда я просто не могу больше войти в систему с локальным (не-ldap) пользователем (например, через ssh).
Кто-нибудь знает правильную конфигурацию? Почему в Debian и nss-pam-ldapd сначала по умолчанию есть pam_unix.so? Неужели нет возможности изменить это?
Заранее спасибо.
P.S. Я не хочу отключать логи, но хочу в первую очередь установить аутентификацию ldap.
Если локальные и сетевые пользователи находятся в разных диапазонах uid (что является хорошей идеей), вы можете добавить строку, подобную этой (предположим, что локальные пользователи находятся в диапазоне 0-4999):
auth [success=1 default=ignore] pam_succeed_if.so uid >= 5000 quiet
перед pam_unix.so линия. Он передаст 1 строку, если uid> = 4999. Он перейдет непосредственно в pam_ldap.so.
И тебе нужно изменить pam_ldap.so use_first_pass к pam_ldap.so или pam_ldap.so try_first_pass если у вас нет строки с запросом пароля перед pam_ldap.so.
Я бы тестировал:
auth [success=1 default=ignore] pam_succeed_if.so uid >= 4999 quiet
auth sufficient pam_unix.so nullok_secure
auth requisite pam_succeed_if.so uid >= 4999 quiet
auth sufficient pam_ldap.so
auth required pam_deny.so
hayalci ответил на это в комментарии:
auth sufficient pam_ldap.so
auth sufficient pam_unix.so nullok_secure try_first_pass
auth required pam_deny.so
Ваш:
auth sufficient pam_unix.so nullok_secure
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
Измените на: (use_first_pass означает использование пароля из предыдущего модуля, которым является pam_ldap.so)
auth sufficient pam_ldap.so
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth sufficient pam_unix.so use_first_pass nullok_secure
auth required pam_deny.so
Disavantage (для hpux): если ваш ldap-сервер завис (синхронизация атаки; см. https://fedorahosted.org/389/ticket/47554 ) ваш клиент тоже зависнет, это происходит с серверами HPUX (не linux и aix; процесс hpux с именем ldapclientd). Это означает, что любой вход в систему (даже как root из ILO / MP) заблокирован. Решение - перезагрузить сервер :-(. Поэтому я предпочитаю pam_unix перед pam_ldap на hpux
Я хочу сказать, что это решение сработало для меня! У меня была такая же проблема с использованием free-ipa, и использование этой настройки в моем файле /etc/pam.d/system-auth позволило избежать дополнительных ошибок "ошибки аутентификации":
auth required pam_env.so
auth sufficient pam_sss.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth required pam_deny.so