Авторизация пользователей через LDAP.
Все настроил строго по этому мануалу:
http://www.gentoo.org/doc/en/ldap-howto.xml
Тем не менее пользователи не авторизуются. Такое ощущение что проблема именно в "pam_ldap", так как следующая команда, после ввода пароля, без проблем возвращает uid и userPassword:
ldapsearch -H ldap://ldap_server:389 -x -W \ -b "ou=testuser,ou=People,dc=genfic,dc=com" \ -D "uid=testuser,ou=People,dc=genfic,dc=com" \ "objectclass=PosixAccount" uid userPassword
Да и: "getent passwd/group" тоже показывает группы и пользователей заведенных в ldap, если конечно залогиниться (временно добавил binddn/bindpw в /etc/ldap.conf, чтобы залогиниться).
Опыта у меня пока маловато - подскажите - куда копать?
- Для комментирования войдите или зарегистрируйтесь
Всем спасибо!
Обнаружил я свой косяк. Глаз замылился и пропустил такую дурацкую ошибку... В system-auth вместо "auth sufficient pam_unix.so ...", оставил "required".
Благодарю откликнувшихся.
- Для комментирования войдите или зарегистрируйтесь
???
Обнаружил я свой косяк. Глаз замылился и пропустил такую дурацкую ошибку... В system-auth вместо "auth sufficient pam_unix.so ...", оставил "required".
Интересное утверждение.
Для FreeBSD встречал несколько иные рекомендации (в части /etc/pam.d/ отличий быть не должно):
auth sufficient /usr/local/lib/pam_ldap.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass nullok
--
Live free or die
- Для комментирования войдите или зарегистрируйтесь
А ты точно
А ты точно поставил pam_ldap и pam_nss? Как то раз я забыл это сделать и, конечно, авторизация не работала, несмотря на все остальное.
Покажи конфиги
Покажи конфиги /etc/pam.d/system-auth, /etc/ldap.conf, /etc/nsswitch.conf.
_______________________
From Siberia with Love!
Конфиги
Конфиги идентичные этой доки: "Gentoo Guide to OpenLDAP Authentication" все строки переносились copy/paste. За исключением, само собой, сервера, suffix'а и rootdn.
nss_ldap и pam_ldap работают, за исключением авторизации. Т.е. я взял первую ACL-схему (да и со второй (4.2) и с дефолтной - тоже проверял) из той доки:
но авторизации не происходит. Если anonymous auth заменить на read - то все работает и getent и login и ssh - т.о. - это показывает что и nss_ldap и pam_ldap работают, но авторизация по каким-то причинам не проходит.
access to dn.base="" by
access to dn.base=""
by self write
by * auth
access to attrs=userPassword
by self write
by * auth
acces to attrs=shadowLastChange
by self write
by * read
access to *
by * read
by anonymous auth
P.S.: должно быть так (у ну по кр.мере работает) :)
Нет, увы, так не
Нет, увы, так не работает. Авторизации не происходит. И работает только если позволить анонимнусам читать базу.
Я попробовал включить отладку, но за отсутствием должного опыта ничего полезного увидеть не смог.
Подскажите хоть - на что обратить внимание?..
Конфиги
Конфиги покажешь или нет?
_______________________
From Siberia with Love!
Вот конфиги:
# grep -v "#" /etc/openldap/slapd.conf
# grep -v "#" /etc/openldap/ldap.conf
# cat /etc/pam.d/system-auth
# grep -v "#" /etc/ldap.conf
grep -v "#" /etc/nsswitch.conf
Повторяем
Повторяем мантру "Чем выше ACL, тем раньше он будет исполняться" до просветелния.
Смотри что у тебя.
Первая ACL, которая лимитирует доступ ко всем объектам дерева, заставляет анонимусов аутентифицироваться, что справедливо. Однако вторая ACLка никак не лимитирует доступ к атрибуту userPassword анонимусам. Поэтому они стройными рядами идут мимо, бо политика по умолчанию - ничего не давать. Соответственно, они и получить доступ ко всему дереву не могут.
Теперь как надо. Во-первых, поменяй ACL местами. Заклинание "access to * ..." является политикой по умолчанию для доступа всех пользователей ко всем объектам. Во-вторых, разреши анонимусам получать userPassword при аутентификации.
В итоге получаем вот что:
_______________________
From Siberia with Love!
Доку для случая Gentoo не читал...
...и не собираюсь.
Ну ты блин даёшь!!!
1. Анонимусам- фиг.
2. Простым смертным - не более, чем авторизация (т.е. тоже не больше чем необходимо), даже хэш своего пароля читать низзя!
3. Авторизованному пользователю типа админ - полный доступ.
Да...
Читаемость логов OpenLDAP оставляет желать лучшего.
На FreeBSD оно выглядит следующим образом (на необходимость установки пакетов pam_ldap и nss_ldap уже указали):
Конфиги клиента лдап для авторизации и просто клиента - не совпадают.
nss_ldap.conf симлинком на ldap.conf (конфиг клиента авторизации) или наоборот.
Необходимо модифицировать /etc/nsswitch.conf.
Если под одинаковым UID'ом в системной базе пользователей и в LDAP'е живут разные пользователи, приоритет отдаётся тому, что в /etc/passwd.
Если в /etc/passwd прописах хэш пароля root'а, то возможна авторизация как с паролем из /etc/passwd, так и с паролем из лдапа (аналогично для адина LDAP, с той только разницей, что его пароль прописывается в slapd.conf.
Научить работать систему когда в ldap.secret прописывается не-cleartext пароль не удалось :(
И главное: для того, чтобы оно всё работало необходимо заменить скрипты (дописать использование LDAP) в
/etc/pam.d/
.--
Live free or die
Куда копать дальше?..
Это само собой. Этим я только показал что LDAP отчасти работает и клиенты успешно логинятся, за исключением авторизации.
Это как?.. Не совсем понял, вернее, совсем не понял.
Симлинк сделал - не помогло. /etc/nsswitch.conf - само собой модифицирован.
Все пользователи кроме root и системных находятся только в LDAP.
Это для меня пока не актуально.
Изменено согласно документации.
.
Это само собой. Этим я только показал что LDAP отчасти работает и клиенты успешно логинятся, за исключением авторизации.
Теперь я не понял.
Это как?
В смысле ldap.conf используемый библиотечкой авторизации и ldap.conf используемый [например] ldapmodify - это разные конфиги.
Что у тебя в ldap.conf?
И сколько их у тебя (в FreeBSD это используемый библиотеками авторизации /usr/local/etc/ldap.conf и используемый клиентом /usr/local/etc/openldap/ldap.conf)?
Кстати, согласно моим наблюдениям системные пользователи в LDAP'е тоже должны быть, без этого не работает.
Как так не актуально, когда предполагается, что туда прописывается пароль пользователя, с которым производится подключение к LDAP при отработке запроса на авторизацию?
--
Live free or die
Вот так можно сделать…
Оно и видно. :) Потому и советы… несколько странные.
Вполне достаточно сделать что-то такое
чтобы работать спокойно.
Не стоит путать человека ФриБСД ;)
Для того, чтобы заработала авторизация в лдап, надо:
На сервере прописать соответствующие разрешения, примерно так, как я показал.
Запустить демон slapd, причем, в конфиге /etc/conf.d/slapd надо раскомментировать и обозначить одну строку примерно так:
OPTS="-h 'ldap://ANY_IP ldap://127.0.0.1 ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"
После запуска демона проверить, слушаются ли ANY_IP и localhost.
Создай в каталоге пользователя для бинда, без прав, с домашним каталогом /dev/null, оболочкой /bin/false и с простым паролем. Вовсе не обязательно коннектиться с рутовыми правами к лдап, можно такого
cn=bind,ou=Users,dc=ph,dc=com
, с простым паролем. коннектится к базе и позволяет прочитать нужные записи. При необходимости его доступ можно еще урезать. Этот пользователь также используется в остальных программах, использующих лдап: почтовике, прокси и тд.Всё. Остальное делается на клиенте.
Устанавливается pam_ldap и nss_ldap.
Исправляется 3 (три!) конфигурационных файла:
/etc/ldap.conf
Если сделать бинд так, как здесь рекомендовано: через пользователя с минимальными правами, то можно не волноваться относительно паролей.
Далее, редактируем /etc/nsswitch.conf
И, наконец, редактируем /etc/pam.d/system-auth
Все. Этого достаточно, чтобы данные для авторизации на компьютерах брались из лдап.
PS Давал свои рабочие конфиги, а не голословные изобретения.
PPS Не поборол проблему с группой wheel. Если она есть в лдап и есть юзер, ей принадлежащий, то пока на клиентском компьютере эта группа будет в /etc/group, сделать su или sudo не удается. Проблему решил удалением этой группы из файла /etc/group.
=
Да обычные советы-то :)
Угу.
В качестве одного из частных решений - вполне.
Там страшного не больше чем в Gentoo :)
Не просто запустить, а прописать автоматический запуск
rc-update add slapd default
На фига слушать сокет я не понял.
По моему опыту, самбе таки правильнее дать права на запись - следовательно отдельный пользователь.
Я считаю правильным специальных пользователей LDAP'а держать отдельно и по одному на рыло (в смысле приложение):
uid=samba,ou=Services,dc=mydomain,dc=ru
uid=squid,ou=Services,dc=mydomain,dc=ru
uid=apache,ou=Services,dc=mydomain,dc=ru
В сборке Gentoo nss_ldap не просит персонального конфига?
Это, насколько я понял, фича пересечения системных конфигов и LDAP'а.
--
Live free or die
Quote: PPS Не
Как ты думаешь, для чего в sudo есть USE-флаг ldap? sudo реализует собственное подключение к ldap, не связанное с системными настройками ldap. Это сделано ради безопасности. sudo не доверяет никаким подсунутым конфигам, предпочитая обращаться напрямую к источнику. Соотвественно, sudo требует дополнительной схемы и необходимой настройки в дереве. Не все так просто.
_______________________
From Siberia with Love!
Прочитал тебя и
Прочитал тебя и решил поискать по теме.
Вот, http://gentoo-wiki.com/HOWTO_LDAP_SAMBA_PDC_Basic_Setup#.2Fetc.2Fpam.d.2Fsu про su. Как оказалось, мое решение тоже вполне годится.