Вход:  Пароль:  
FreeSource: AltLinux/Dokumentacija/samba/idmapldap ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

задача: получить единые uidnumber/gidnumber на PDC и рядовых серверах домена.


в openldap находится база пользователей:
ou=People и ou=Groups. на PDC пользователей в систему поставляет nss_ldap, samba использует ldap passdb backend.


замечание: ab@ утверждает что nss_winbind уже способен работать на pdc и поставлять пользователей из ldap backend в систему. Однако, мне вообще не удалось заставить winbind работать на pdc в 3.0.14 и последней 3.0.21rc1.


На domain members штатно предлагается использовать winbind для трансляции SID'ов в uid, и nss_winbind как поставщик uid'ов в систему. он выделяет uid из idmap uid range (допустим, 10000–20000).


пусть существует учетная запись uid=kolya,ou=People, o=example. У нее есть uidNumber: 510, и objectclass: posixAccount, sambaSAMAccount. При подключении под этим логином по сети:
– на pdc – smbd euid будет 510 (account из nss_ldap)
– на domain member с winbind – «какой-то» uid, предоставленный nss_winbind, полученный из заданного диапазона (очевидно, отличающийся от 510).


(далее под словом сервер понимается domain member server)


Предположим, что на PDC включена опция unix extensions = yes, и монтируем сетевой ресур по cifs (а не smbfs). В этом случае, будут виден настоящий owner uid (510), который не имеет никакого смысла для member не использующего nss_ldap.


Используя idmap backend = ldap, можно добиться единых uid'ов на всех серверах входящих в домен – кроме pdc. Это приемлемо только если сам pdc не предоставляет сетевых ресурсов.


Я вижу проблему: winbind выделяет числовые uid непредсказуемо (хотя возможно и постоянные). Не существует способа гарантировать что выделенный uid будет равен gidNumber, заданному в uid=kolya,ou=People; даже наверняка будет не равен. Существуют idmap_rid. Однако его алгоритм хотя и предсказуем, но страдает тем же.


Я предположил что можно на всех машинах входящих в домен использовать nss_ldap, поместив его в nsswitch.conf. Этим мы добьемся того, что на каждом сервере будут существовать kolya с uid 510 (из nss_ldap) и еще один kolya с uid 10021 (из nss_winbind). Для смонтированных ресурсов – будут видны настоящие имена пользователей, но это ничего не даст для member server предоставляющего ресурсы: по прежнему подключения к нему будут работать с «левым» uid полученным от nss_winbind/idmap.


Сделаем еще один шаг: уберем winbind из nsswitch.conf.

Теперь подключиться к серверу под доменной учетной записью вообще нельзя. В логах winbind при этом:

угу. Дальше изучаем исходники в районе nsswitch/winbindd_util.c и sam/idmap_ldap.c и пытаемся понять как это работает. Думаем еще, смотрим лдап-клиентом на ветку idmap. В голову приходит синхронизировать uid/gid в Idmap с ветками People / Groups?.


.... еще смотрим на исходники и логи slapd и наконец понимаем:
idmap_ldap ищет objectClass: sambaIdmapEntry, и создает новую запись если не находит. Причем в запросе стоит: (sambaSID="XXXX") – для sid_to_gid, (uidNumber=XXX) – для uid_to_sid, и т.д. Причем все аттрибуты: SID и необязательные uidnumber/gidnumber – уже содержатся в записи для каждой группы и каждого пользователя.


задаем
idmap suffix =
(пустой) и пробуем еще раз. Это не работает как хотелось, но теперь все уже понятно: в «листьях» ldap, представляющих пользователей (objectclass: posixaccount) и группы (objectclass: posixgroup) пишем дополнительный objectClass: sambaIdmapEntry. После этого обманутый idmap смотрит в корень ldap-дерева и делает запрос. И таки находит ;) uid/gid в них – те же самые которые видит nss_ldap, а SID – по определению правильный.


чтобы теперь так было всегда, smbldap-{user,group}add из smbldap-tools учим добавлять одну строчку: objectClass=sambaIdmapEntry.


Теперь nss_winbind выдает в точности такие uid как nss_ldap. Я не до конца разобрался, почему без nss_winbind wbinfo какой-то неполноценный, но вообще можно отказаться от nss_ldap на domain member в пользу nss_winbind (однако pam_winbind для моих задач не подходит – на рабочих станциях линуксы, и нужна авторизация входа на каждый хост).


хинт: экспериментируя с idmap, всегда удаляйте /var/lib/samba/winbindd_cache.tdb и /var/lib/samba/winbindd_idmap.tdb. В некоторых случаях даже при наличии idmapentry в ldap, используется сохраненный мапинг из winbindd_cache.tdb.


хинт2: скрипт smbldap-populate из smbldap-tools создает не все группы из BUILTIN (SID S-1–5-32-xxx). В частности, не создаются группы System Operators, Guests, Users, Power Users. Но в выводе wbinfo -g (или getent group, если winbind используется в nss) они присутствуют с gid в духе 20001,20002; причем idmap затем записывает этот мапинг в ldap в ветке idmap suffix (т.е. в нашем случае – в корень). Лучше их все же создать заранее в Groups и выдать нормальные gid вручную.


на самом деле, записи для этих групп есть в smbldap-populate, но закомментированы (?). В «местной» сборке 0.9.1 я их вернул.


хинт3: хотя мы сделали стабильный маппинг, все же idmap gid / idmap uid продолжают действовать: в нашем случае они ограничивают допустимый диапазон uid/gid, и если указанные в ldap не попадают в него, winbind назначает «левые». В частности, Administrator (uid=0) у меня имеет локально uid 20001. Задать же range с нуля невозможно : в логе будет “idmap range missing or invalid”. Исправить это можно только захачив проверку диапазона:
param/loadparm.c:2875
param/loadparm.c:2889
... но подумав, я согласился что это фича – в самом деле, зачем работать под рутом/админом? ;) Можно сразу задать Администратору «правильный» uid/gid, это не помешает вводить машины в домен (начиная с 3.0.11pre2 samba использует систему привилегий). А больше ни для чего root не нужен ;)


внеклассное чтение:
http://samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html


обсуждение ldapsam:trusted:

Jeremy Allison

Volker Lendecke


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]