[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: passwd -> ldap



Nikita V. Youshchenko wrote:
А также потому, что доступ до userPassword в LDAP средствами nss
- очевидная дыра в безопасности. Всё равно что /etc/shadow на
чтение открывать.

Не понимаю чем вас rootbinddn в ldap.conf не устраивает?

При чём тут ldap.conf я не очень понимаю, но общий смысл такой. getpwnam() действительно не знает про LDAP ничего. Байнд к LDAP
осуществляет libnss_ldap, причём пароль не спрашивается, а значит
должен храниться в /etc/libnss-ldap.conf.

Виноват. Конечно речь шла о /etc/libnss-ldap.conf (это ж debian).

Если этот файл доступен на чтение пользователям, то все пользователи
могут прочитать все хэши. Если этот файл доступен только руту, то
начинаются глюки. Без nscd вообще никто ничто из nss считать не
сможет, с nscd некоторые проги всё равно глючат - не работает finger,
~us<TAB> в bash и т.п. Хотя последнее может быть багом в glibc.

В отличие от nss, PAM действительно байндится к LDAP под тем
пользователем и с тем паролем, который вводится при аутентификации.

Все эти рассуждения безусловно верны, но вы не удосужились выяснить что
же я имел в виду, упоминая rootbinddn.  А это такая специальная опция,
предназначенная именно для решения описанной вами проблемы:

=== /etc/libnss-ldap.conf ===
# The distinguished name to bind to the server with
# if the effective user ID is root. Password is
# stored in /etc/ldap.secret (mode 600)
rootbinddn uid=nssadmin,o=org
===

Достаточно секьюрно? По-моему вполне.

Последняя маленькая тонкость - это ограничение на используемые алгоритмы
хэширования паролей, но по мне те MD5 хэши, что получаются через
slappasswd -h {CRYPT} -c '$1$%.8s' не хуже [s]sha и [s]md5.
Так что я не вижу ни одной причины использовать pam-ldap - с ним только
лишняя возня по настройке его же конфигов.

--
Any religion that rejects coffee worships false Gods!



Reply to: