писать еще одну хаутушку совершенно неинтересно. хотя бы потому что - "а ты врубись откуда я все это знаю" (c) "Выход".
читая бесконечные хауту "а вот еще одна инструкция по настройке ldap" и убеждаясь что половина из этого не работает в моем дистрибутиве, а вторая половина безнадежно устарела, остается только одно - читать их много, разных. и тогда в какой-то момент 1) все получается и даже 2) начинаешь _понимать_.
описывать пошагово действия приводящие к пункту 1 неинтересно, потому что часто за деревьями не видно леса, и просто станет одной хаутушкой больше (см. предыдущий абзац). но можно попытаться описать карту которую мозг строит (30 бинарников под разные платформы и разные версии редхата vs. исходник компилируемый на любой из них).
------------------- отрезать здесь ------------------1. в незапамятные времена существовал единственный файл /etc/passwd где хранились все пользователи с их аттрибутами и паролями. позже появился /etc/shadow для паролей.
на сегодняшний день мы имеем две логических сущности:
(в принципе можно смотреть на это как на реляционную базу данных).
самое важное - что эти компоненты не обязательно должны находиться в одноименных файлах. для управления этим существует nsswitch.conf, в котором для каждой "сущности" указан источник, или несколько в порядке предпочтения.
посмотрев в него, мы увидим не только passwd shadow groups, а еще и, скажем hosts - указания для резолвера и еще много чего.
2. в поставке ALT (у меня сизиф) по умолчанию стоит следующее:
passwd: files nisplus nis shadow: tcb files nisplus nis group: files nisplus nis
что означает: существование пользователей и группы проверять в файле, затем пытаться использовать nis.
_если_ пользователь существует - его пароль будет проверяться с использованим tcb, (если там не нашли - в файле shadow, и т.д.). но у нас вообще-то исопльзуется pam. важно то что если заданного пользователя не существует для libc, то его пароль уже никому не нужен - нет его, и все.
(еще важно: эти компоненты ортогональны. можно допустим хранить в ldap только группы).
соответсвенно, для прикручивания нестандартной идентификации/аутентификации делаются две вещи:
3. как бы все это сделать? на примере ldap.
поднятие самого ldap рассказывать не буду, это тривиально (maybe later). настройка клиента ldap - туда же (хотя источник проблем там бывает).
пусть в дереве ldap есть ветка где лежат аккаунты (имеющие класс posixaccount), и ветка где лежат группы (posixgroup)
когда мы это сделали, то остается только прописать в nsswitch.conf
passwd: files ldap ... ещечтото group: files ldap ... ещечтото------------------ линия отреза ------------------
Неочевидно: files и tcb должны быть в начале, а уже после них - ldap/winbind/smthelse. Что означает - локальные пользователи имеют приоритет над ldap'ными. Во-первых это правильно идеологически, во-вторых если ldap стоит первым то будут большие задержки, особенно когда ldap сервер недоступен.
возможно, будет соблазн оставить только ldap, а files вообще выкинуть. Делайте это только если вы знаете что делаете, потому что: а) существуют псевдопользователи, от имени которых запускаются сервисы; б) в runlevel 1 (single user) root не сможет войти в систему, потому что (локальный) ldap остановлен, а сеть не поднята.
------------------- отрезать здесь ------------------теперь _идентификация_ работает - пользователи из ldap могут владеть файлами, входить в системные группы (и /etc/groups, и ldap). root может сделать su в такого пользователя.
но если этот пользователь попытается залогиниться то его пнут, и в логе скажут что user is unknown to underlying auth module.
если нам все же нужно чтобы ldap-юзеры могли аутентифитцироваться, надо настраивать аутентификацию.(а тут кстати, у объектов "юзер" в дереве лдап должен быть дополнительный objectclass shadowaccount.)
в /etc/nsswitch.conf мы запишем
shadow: tcb files ldap .. еще что-то
....и попытаемся разобраться с pam :-)
берем system-auth-winbind. в нем заменяем "include system-auth" на "include system-auth-standard" (чтобы избежать бесконечной рекурсии). затем копируем его как system-auth-ldap, и трудолюбиво заменям слово winbind на слово ldap.
system-auth переименовываем как system-auth-standard и делаем симлинк system-auth на system-auth-ldap. (а если захочется восстановит все как было - слинкуем на system-auth-standard)
поскольку в pam.d все ссылаются (не все, vsftpd например system-auth-use_first_pass. не знаю почему) на system-auth - все службы автоматически будут использовать ldap.
4. как бы все это сделать? на примере winbind
samba вошла в домен? winbind настроен? прекрасно.
ну вот пока все. комменты можно мылом gns на altlinux.ru