FreeSource : AltLinux/Sisyphus/admin/LdapWinbindUsers

Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

хранение пользователей в ldap/winbind:
оригинал был тут: http://gns-linux.narod.ru/ldap-about.html

хранение системных пользователей в LDAP
(а вообще – в чем угодно :-)

лирическое наступление:
писать еще одну хаутушку неинтересно. хотя бы потому что – «а ты врубись откуда я все это знаю» (c) «Выход».
читая бесконечные хауту «а вот еще одна инструкция по настройке ldap» и убеждаясь что половина из этого не работает в моем дистрибутиве, а вторая половина безнадежно устарела, остается только одно – читать их много, разных. и тогда в какой-то момент 1) все получается и даже 2) начинаешь _понимать_.
описывать пошагово действия приводящие к пункту 1 неинтересно, потому что часто за деревьями не видно леса, и просто станет одной хаутушкой больше (см. предыдущий абзац). но можно попытаться описать карту которую мозг строит (30 бинарников под разные платформы и разные версии редхата vs. исходник компилируемый на любой из них).
линия отреза

Ближе к делу

1. в незапамятные времена существовал единственный файл /etc/passwd где хранились все пользователи с их аттрибутами и паролями. позже появился /etc/shadow для паролей.
на сегодняшний день мы имеем две логических сущности:
passwd – база пользователей содержащая аттрибуты такие как uid, основной gid, gecos, homedir и все такое.
shadow – база парольных хэшей пользователей.
ну и еще есть groups – список системных групп, и пользователей в них входящих.
(в принципе можно смотреть на это как на реляционную базу данных).
самое важное – что эти компоненты не обязательно должны находиться в одноименных файлах. для управления этим существует 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 только группы).
соответсвенно, для прикручивания нестандартной идентификации/аутентификации делаются две вещи:
настраивается _идентификация_ пользователей (passwd) и групп (groups).
настраивается _аутентификация_ пользователей – pam и shadow.

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 настроен? прекрасно.
рисуем nsswitch.conf – раз.
в /etc/pam.d делаем system-auth симлинком на system-auth-winbind – два.
все.

когда-то давно кто-то обещал сделать на control рулилку источников аутентификации. воз все там же