smb+ldap | группа с членами из двух доменов доверящих друг другу

да, можно с множеством нюансов. Все зависит от того, как (для чего) впоследствии эта группа будет использоваться.

>Если это важно, то winbind работает.
еще бы он не работал, о каком trust'е тогда можно было бы говорить. :)

Ньюансы интересны конечно же =) Я пробовал вносить в виде

memberuid: DOMAIN\user

По поводу использования - будет использоваться в двух видах

• В винде как средство разграничения доступа в сетевых шарах
• В linux тоже самое но, для доступа на файловой системе

Привожу тут выжимку из уже готовой (переписывать лень), доки. Следует учесть, что во всех случаях дерево пользователей внутри ldap должно совпадать. Т.е. id username на обоих pdc должен возвращать пользователей и своего и чужого домена.

Samba InterDomain Trust Relationship

Функционал samba3/NT4 домена, дающий возможность использовать локальные ресурсы (ресурсы местного домена) пользователям другого домена. Доверительные отношения односторонние, поэтому для двухсторонних доверительных отношений эти рекомендации надо выполнить на каждом DC - участнике доверительных отношений.

Требования
Openldap
samba
winbind

Подготовка
DC связанных доменов должны «видеть» (резолвить через broadcast/wins/lmhosts) друг друга
DC связанных доменов должны обмениваться трафиком по портам 137/138/139/445
Клиенты должны «видеть» хотя бы по одному DC каждого домена
На samba должен быть наложен патч для исправления постоянного запроса на изменение пароля при входе пользователя в «чужой» компьютер (или «чужого» пользователя, кому как нравится)

Настройка
Добавить в smb.conf:
[Global]
...
#map remote domain users to local
username map = /usr/local/etc/sambausers.map
...
#assign remote users/groups to the next uids/gids
idmap uid=5000-5500
idmap gid=5000-5500
...
Warning
Не допускайте пересечений диапазона idmap uids/gids с аналогичным диапазоном «чужого» домена как и с постоянными uid/gid локального/«чужого» домена. Ни к чему хорошему вас это не приведет.
Итого у вас на 2 домена будет 4 области:
remote uid/gid's idmap
local uid/gid's idmap
local uid/gid's
remote uid/gid's
они должны быть уникальны.
Добавить в wins.dat:
«REMOTE_DOMAIN_NAME#1b» 0 dc_ip-address 66R
«REMOTE_DOMAIN_NAME#1c» 0 dc_ip-address 66R
«REMOTE_DC_NAME#03» 0 dc_ip-address 66R
«REMOTE_DC_NAME#20» 0 dc_ip-address 66R
«REMOTE_DC_NAME#00» 0 dc_ip-address 66R
На всех samba DC создать файл lmhosts со следующим содержимым:
dc_ip-address REMOTE_DOMAIN_NAME#1b
dc_ip-address REMOTE_DOMAIN_NAME#1c
dc_ip-address REMOTE_DC_NAME#03
dc_ip-address REMOTE_DC_NAME#20
dc_ip-address REMOTE_DC_NAME#00
создать на каждом общедоступном samba файл-сервере в periodic/daily скрипт 701.fs_userlist_export:
#!/usr/local/bin/bash
#Description: put users of remote domain to special file for correct
#mapping of permissions on samba fileserver.
#for correct work you need to add:
#
#<----->username map = /usr/local/etc/sambausers.map
#
#to /usr/local/etc/smb.conf [global]

#ENVs
RemoteDomain=«DOMAIN»
SambaMapFile=«/usr/local/etc/sambausers.map»

#
#
#prepare
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

cat /dev/null >$SambaMapFile

for remote_user in `wbinfo -u|grep $RemoteDomain`
do
fs_user=`echo $remote_user|cut -d\\\ -f2`
echo «$fs_user = $remote_user» >>$SambaMapFile
done
создавать специального пользователя с именем идентичным имени «чужого» домена:
# smbldap-useradd -a -i remote_domain_name
назначить этому пользователю пароль
smbldap-passwd remote_domain_name
на удаленном домене, где произведены аналогичные настройки, выполняем подтверждая доверительные отношения
net rpc trustdom establish remote_domain_name
Полная документация доступна по ссылке

Проверка
должны выдавать списки «чужих» пользователей и групп:
# wbinfo -u|grep REMOTE_DOMAIN_NAME
# wbinfo -g|grep REMOTE_DOMAIN_NAME
должно получаться авторизоваться пользователем чужого домена:
# wbinfo -a REMOTE_DOMAIN_NAME\\username
Выделение прав пользователю/группе «чужого» домена
Для Windows серверов права на пользователя/группы выделяются как обычно, выбирая в «расположении» другой домен. При этом группы и пользователи должны быть выбраны из другого домена.
Для FreeBSD серверов права на пользователя выдаются как обычно, при этом «чужие» пользователи помещаются в «родные» группы.

>никакой реакции (
а какой реакции вы ждали, всё само заработает? O_o

Все что вы описали, в общем есть и работает. А конкретно, id user1 - возвратит пользователя из родного домена, id YYYY\user1 возвратит пользователя из соседнего домена wbinfo -u также возвращает как местных, так и чужих

Но я все же я не совсем понял, как в группе ldap перечислять пользователей из разных доменов?

т.е. у меня есть домен XXXX в котором кроме штатных DomainUsers, DomainAdmins и прочих группа SomeUsers, в нее я хочу внести местных пользователей user1, user2, user3 и двух из домена YYYY, user4, user5

smbldap-groupadd -a SomeUsers
smbldap-groupmod -m user1,user2,user3,YYYY\user4,YYYY\user5 SomeUsers

так?

или мне нужно завести группу SomeUsers в обоих доменах, и заполнить ее членами user1,user2,user3,user4,user5 ? Без указания доменного расположения?

>id user1 - возвратит пользователя из родного домена, id YYYY\user1 возвратит пользователя из соседнего домена
Что используется в качестве источника данных для nss? winbind? или ldap?

>smbldap-groupmod -m user1,user2,user3,YYYY\user4,YYYY\user5 SomeUsers
Вероятней всего вернет ошибку. А как вас эта команда отрабатыват?

ldap

smbldap-groupmod -m sub,PGF\\sub sidgroupdemo
adding user sub to group sidgroupdemo
adding user PGF\sub to group sidgroupdemo

прошло успешно, в группу добавились. Другое дело, что толку от их членства там))

1) показывайте свой ldap для sub и PGF\\sub
2) показывайте nss_switch.conf на всех.
3) рассказывайте, как проверяли результат членства.

1) что именно? не понял

2) files, ldap, и, оказывается, winbind :)

cat /etc/nsswitch.conf | grep winbind
passwd:     files ldap winbind
shadow:     files ldap winbind
group:      files ldap winbind

3) сделал на виндовой машине папку, расшарил ее для группы sidgroupdemo, в группе числился лишь user1, попытался из другого домена, также из винды, зайти на эту папку пользователем YYYY\user1 - нет доступа

1) записи в ldap для пользователей 2х разных доменов
2) теперь хоть что-то встает на свои места
уберите winbind из nssswitch.conf и попробуйте еще раз отработать комманду:
smbldap-groupmod -m user1,user2,user3,YYYY\user4,YYYY\user5 SomeUsers

или id YYY\user4

3) Вы невнимательно читали документ, который я дал вам выше:

а) «Для Windows серверов права на пользователя/группы выделяются как обычно, выбирая в „расположении“ другой домен. При этом группы и пользователи должны быть выбраны из другого домена.»

б) Вы практически наверняка пропустили важную часть:

Добавить в smb.conf:

и все, что с этим ниже связано.

в) Вы не понимаете сути работы samba... даже не знаю, стоит ли начинать объяснять..

еще несколько вопросов, если можно.

1) вас интересуют значения значения uid, uidNumber, sambaSID и пр.? Если без ненужных полей то вот

# sub, Users, geo.org
dn: uid=sub,ou=Users,dc=geo,dc=org
sambaPrimaryGroupSID: S-1-5-21-2068682600-2350025889-3278183345-513
sambaSID: S-1-5-21-2068682600-2350025889-3278183345-3124
uid: sub
uidNumber: 1062
gidNumber: 513

#
dn: uid=sub,ou=Users,dc=pgf,dc=org
uid: sub
uidNumber: 1062
gidNumber: 513
sambaPrimaryGroupSID: S-1-5-21-380546886-153089709-895938721-513
sambaSID: S-1-5-21-380546886-153089709-895938721-3124

2) отключим winbind - не получим id YYYY\user, такая адресация работает при включенном winbind только

3а) Вот тут и встает все на свои места, т.е. тут получается все будет работать как и прежде. Я и сейчас могу дать дать права на папку в винде группам из разных доменов. Проблема не в этом. Я то думал, что можно в одну группу поместить членов разных доменов и на шару давать права только этой группе. Чуете разницу?

3б) Да, часть с sambamap я пропустил. почти сознательно т.к. показалось, что это костыль какойто =)

3в) Вероятно, я не столь в ней силен. Посему и вопрошаю и учусь :)

Я вижу вы вообще пропустили 9/10 того, что я вам написал.

1) У вас разные деревья LDAP, хотя я говорил про одно.
2) У вас используется winbind для резолва чужих пользователей. И само собой в LDAP пользователя чужой_домен\username нет и быть не могло - samba его при обратном резолве в LDAP не нашла и поэтому его наличие/отсутствие в группе не дает никакого результата. И не даст.

3а) Хотя я говорил про специфику использования, вы так и не поняли и даже после моего указания не прочли мой документ:
«Для FreeBSD серверов права на пользователя выдаются как обычно, при этом „чужие“ пользователи помещаются в „родные“ группы.»
3б) Да, это и есть костыль, но я по крайней мере знаю, зачем он нужен при определенных обстоятельствах.

Спасибо за все:). Просто я исхожу из существующей на предприятии схемы (две ветки, winbind и пр.). Выходит, что при таком раскладе оперировать группами с членами из других доменов невозможно.

Посмотрите в таком случае доки по механизму nested groups, возможно это поможет. Там как раз winbind используется и декларируется возможность добавлять туда пользователей через этот механизм:

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/groupmapping.html#...

Спасибо. Посмотрел. Настроил. Действительно практически то что надо, но не совсем.. Хотя может и остановлюсь на этом решении.

Будет совсем хорошо, если вы тоже потратите немного времени и коротко опишите, что именно проделано и как - многим, в т.ч. мне (руки не дошли, ng протестировать) будет интересно.

Собственно там вообще все просто.. если имеем рабочий winbind, и он указан в /etc/nsswitch.conf

то создаем группу к примеру demogroup (-L говорит, что это локальная группа (в англ. варианте nested) т.е. в ldap будет sambagroupType=4 а не 2 как у обычных доменных групп , если хотите можно добавить -Uusername%secret если локальный пользователь не может этого делать)

net rpc group add demogroup -L

затем заполняем ее членами

net rpc group addmem demogroup "user1" 
net rpc group addmem demogroup "DOM2\\user3" 
net rpc group addmem demogroup "DOM2\\user1" 
net rpc group addmem demogroup "user5" 

в ldap в ветке ou=groups создается создается ветка с dn: sambaSid=S-САМБА_СИД_МАШИНЫ_НА_КОТОРОЙ_ЭТИ_ГРУППЫ-NNNN если групп несколько то будет несколько таких записей

dn: sambaSid=S-САМБА_СИД_МАШИНЫ_НА_КОТОРОЙ_ЭТИ_ГРУППЫ-NNNN+1
dn: sambaSid=S-САМБА_СИД_МАШИНЫ_НА_КОТОРОЙ_ЭТИ_ГРУППЫ-NNNN+2

Внутри этой сущности описаны все наши члены , но не в виде memberUid, а виде SIDов т.е.

ldapsearch -x -h PDC -b 'sambaSid=S-1-5-21-2872347476-796650286-1315766164-1002,ou=groups,dc=geo,dc=org' sambaSIDList

sambaSIDList: S-1-5-21-380546886-153089709-895938721-3124
sambaSIDList: S-1-5-21-2068682600-2350025889-3278183345-4138
sambaSIDList: S-1-5-21-380546886-153089709-895938721-7216
sambaSIDList: S-1-5-21-380546886-153089709-895938721-4300

и уже этой группе даем право на запись в самбе, на файловой системе права остаются как и надо, т.е. конкретного пользователя

ll /tmp/demo/
итого 4
drwxr-xr-x 2 PGF\user1 PGF\domainusers 4096 Окт 19 11:12 New Folder

таким образом получаем обычную локальную группу, которая активна только на этой машине. Плюсы , то что можно включать кого угодно, минусы - не human readable совершенно ветка в ldap )) но с скриптом wbinfo -n\-m можно пошаманить и сделать прослойку.. Более печально, что у нас количество серверов где нужно такое решение постоянно растет и каждый раз делать локальные группы и следить за членами в них - гиммор какойто.. думаю пока))

как опыт - пригодиться