Trusts

Страница в состоянии разработки.

Представлен перевод статьи - Stefan Kania(https://www.kania-online.de) "Seting up trusts between two Samba-domains"(https://www.kania-online.de/wp-content/uploads/2019/06/trusts-tutorial-en.pdf ).

Предисловие

В данной статье мы рассмотрим доверительное управление между двумя Active Directory-доменами. Будет рассмотрено какие бывают трасты, и о различных видах трастов, которые вы можете создать. Пример создания двух доменов, каждый со своим пространством имен. Настройка DNS-прокси с помощью bind9 для управления разрешением имен SRV-записи между этими двумя доменами. После создания трастов расссмотрим как управлять пользователями и группами между этими доменами.

Основные определения

Прежде чем мы начнем создавать траст, мы начнем с некоторых основ. Давайте сначала поговорим о некоторых общих определениях:

Доверяющий домен

В доверяющем домене A вы можете получить доступ к пользователям и группам из доверенного домена Б. Пользователи и домены-группы из домена B могут использоваться администратором домена A, чтобы предоставить этим пользователям и группам разрешения на доступ к ресурсам в домене А. Если траст является односторонним, администратор домена A должен пройти проверку подлинности с его учетными данными в домене B. Это означает, что администратор домена B должен настроить учетную запись администратора из домена А. Эта учетная запись будет использоваться администратор из домена A для аутентификации в домене B, чтобы получить доступ к пользователи и группы из домена B.

Доверенный домен

Пользователи и домены-группы из доверенного домена B могут использоваться доверяющим доменом А. Пользователи из домена B не увидят никого из пользователей из домена A, если трасты — односторонние. Пользователи из домена A не могут получить доступ к каким-либо ресурсам из домена Б.

Одностороннее доверие

Одностороннее доверие устанавливается только в одном направлении от домена A к домену B или наоборот. Если домен A доверяет домену B, то домен B будет не доверять домену A.

Двустороннее доверие

Если установлено двустороннее доверие в обоих направлениях, тогда все пользователи и домены-группы из любого домена могут иметь доступ к ресурсам из другого домена. Двустороннее доверие — доверие по умолчанию в Active Directory.

Переходное (транзитивное) доверие

Если у вас более двух доменов, илиActive Directory-дерево, или Active Directory-лес для проверки подлинности используется Kerberos, вы можете установить транзитивное доверие. Преимущество транзитивного доверия состоит в том, что Kerberos управляет аутентификацией между трастами. Все клиенты из домена A всегда будут отправлять туда аутентификационный запрос к собственному контроллеру домена (который всегда является Kerberos-сервером), затем контроллер домена будет управлять билетами. Если теперь пользователь из домена A получит доступ к общему ресурсу на файловом сервере в домене B, он получит билет от своего собственного контроллера домена для домена B. Файловый сервер в домене B проверит билет на своем собственном Kerberos-сервере в домен B. Таким образом, клиенты с обеих сторон ничего не знают о доверии. В инфраструктуре Active Directory у вас всегда будет транзитивное двустороннее доверие, поэтому все домены будут доверять друг другу.

Виды трастов

После того, как мы поговорили об общих определениях, мы теперь рассмотрим различные типы трастов. Доверительные отношения, о которых Microsoft упоминает в своей документации, не означают, что Samba поддерживает все эти трасты. После разговора о разных типах трастов, мы поговорим о трастах, которые Samba поддерживает в настоящее время, и ограничениях которые остались у Samba.

Траст (доверие) между доменами

Если есть одно дерево доменов с доменом верхнего уровня, который обрабатывает основное пространство имён (например example.net). Тогда все домены будут использовать поддомен из домена верхнего уровня. Под верхним уровнем domain есть еще два домена dom1.example.net и dom2.example.net. В этом случае все три домена будут доверять друг другу в обоих направлениях. Это называется трастом домена.

Внешние трасты (External trust)

Внешнее доверие впервые было введено в Windows-NT. Внешнее доверие - это доверие между двумя доменами, каждый со своим пространством имен. Во внешнем доверии Kerberos не используется, так как единый вход(single-sign-on) невозможен. Вы можете установить внешнее доверие между двумя доменами в стиле NT или между доменом в стиле NT и доменом Active Directory.

Доверие в лесе доменов (Forest trust)

Если у вас есть два активных дерева каталогов с разными пространствами имен, например example.net и example.com вы можете настроить доверительные отношения между двумя доменами верхнего уровня ваших деревьев, тогда все области обоих деревьев будут доверять друг другу. Вам не нужно создавать траст между каждым доменом двух деревьев, доверие будет настроено на уровне верхнего уровня. Доверие осуществляется на верхнем уровня, все остальные доверительные отношения будут установлены автоматически. Для лесного треста вам нужен Kerberos, для обработки всех аутентификаций между всеми доменами.

Самба и трасты

После того, как мы поговорили об основах, давайте посмотрим на возможности Samba. Как упоминалось ранее, не всё, что объясняет Microsoft, возможно с Samba. Итак, самый важный вопрос: что уже поддерживается?

• Доверие в лесе доменов — как двустороннее доверие так и транзитивное доверие. Это доверие может быть установленным между двумя Samba-доменами или Samba-доменом и Windows-доменом.

• Внешние доверительные отношения между активным доменом-каталогом и доменом в стиле NT.

• Добавление пользователей и групп доверенного домена в группы доверяющего домена. Но если вам необходимо использовать SID пользователей и группы, чтобы добавить их в свою группу, то это невозможно для пользователя, имени пользователя или имени группы.

• Внутри RSAT вы увидите foreignSecurityPrincipal для всех добавленных пользователей и групп. из доверенного домена. Таким образом Microsoft показывает, что пользователь или группа часть доверенного домена.

Некоторые вещи по-прежнему невозможны, если вы хотите использовать доверительные отношения вместе с Samba.

• Доверительные отношения между доменами в одном дереве с одним и тем же пространством имен верхнего уровня.

• Фильтрация SID для ограничения разрешений.

• Обе стороны траста должны полностью доверять друг другу. Это означает, что администратор из домен A может управлять всеми объектами в домене B и наоборот.

• Выборочная аутентификация в настоящий момент не поддерживается. Возможно создание таких доверий, но KDC и winbindd все равно их игнорируют.

Окружение

Поскольку основной интерес — настройка доверия и управление пользователями и группами, используйте Vagrant для настройки всех Linux-машин. Рассмотрим на примере: четыре Linux-машины и одна Windows-машина.

• Два контроллера домена Samba

Два контроллера домена, каждый с различным пространством имен. Домены используют внутренний DNS-сервер.

• Один Samba-Linux-клиент

Этот клиент будет участником одного из доменов для проверки входа в систему и настройки разрешения доступа.

• Одна Linux-система в качестве DNS-прокси

Чтобы настроить DNS-прокси для разрешения SRV-записей между двумя доменами, мы будем использовать bind9.

• Один Windows-клиент

Эта Windows-система будет членом одного из доменов для проверки входа в систему. Для всех Vagrant-машин существует пользовательский vagrant с паролем vagrant. Корень также имеет пароль vagrant. Далее в таблице указаны параметры которые потребуются для примера.

Data

Parameter	domain 1	domain 2
DNS-suffix	s1.example.net	s2.example.net
Realm	S1.EXAMPLE.NET	S2.EXAMPLE.NET
NetBios-Name	S1	S2
IP-address	192.168.56.41	192.168.56.42
DNS-search	s1.example.net	s2.example.net

Настройка DNS-прокси

Одна из самых важных вещей, которую вы должны сделать перед тем, как начать создавать траст — это управлять разрешением имен между двумя доменами. Недостаточно поставить домен — контроллеры во всех /etc/ домена, потому что вы также должны разрешить SRV-записи со всех доменах и всех контроллерах доменов. По этой причине самый простой способ заставить работать разрешение имен — это настроить DNS-прокси между двумя доменами. DNS-прокси будет перенаправлять запрос между доменами и всеми внешними DNS-серверами для разрешения любого другого имени хоста.

Для DNS-прокси мы будем использовать bind9 на одной из Linux-машин. Пакеты, которые вам нужны уже установлены и настроены в системе с IP-адресом 192.168.56.50. Для настройки DNS-прокси, вам нужно отредактировать файл /etc/bind/named.conf.option, как вы можете видеть в примере:

forwarders {
1.1.1.1;
};
forward only;
dnssec-validation no;
dnssec-enable no;
allow-recursion { any; };

После настройки параметров вам необходимо настроить переадресацию зоны в файле /etc/bind/named.conf.local, как вы можете видеть в примере:

zone "s1.example.net" in {
type forward;
forwarders { 192.168.56.41; };
};
zone "s2.example.com" in {
type forward;
forwarders { 192.168.56.42; };
};

В файлах /etc/samba/smb.conf на обоих контроллерах доменов можно увидеть,что DNS-прокси является сервером пересылки для обоих контроллеров домена.

Теперь вы можете проверить, можете ли вы разрешить SRV-записи на обоих контроллерах домена. В примере 6.3 вы можете увидеть результат выполнения всех команд:

vagrant@addc-01:~$ host -t srv _kerberos._tcp.s1.example.net
_kerberos._tcp.s1.example.net has SRV record 0 100 88 addc-01.s1.example.net.

vagrant@addc-01:~$ host -t srv _kerberos._tcp.s2.example.com
_kerberos._tcp.s2.example.com has SRV record 0 100 88 addc-02.s2.example.com.

vagrant@addc-02:~$ host -t srv _kerberos._tcp.s1.example.net
_kerberos._tcp.s1.example.net has SRV record 0 100 88 addc-01.s1.example.net.

vagrant@addc-02:~$ host -t srv _kerberos._tcp.s2.example.com
_kerberos._tcp.s2.example.com has SRV record 0 100 88 addc-02.s2.example.com.

Следующая проверка, которую вам следует сделать — попытаться получить Kerberos-билет из любого домена.

Важно! Не забывай писать realm заглавными буквами.

vagrant@addc-02:~$ kinit administrator@S2.EXAMPLE.COM
administrator@S2.EXAMPLE.COM’s Password:

vagrant@addc-02:~$ klist
Credentials cache: FILE:/tmp/krb5cc_1000
	Principal: administrator@S2.EXAMPLE.COM
   Issued Expires Principal
Jan 2 18:19:28 2019 Jan 3 04:19:28 2019 krbtgt/S2.EXAMPLE.COM@S2.EXAMPLE.COM

vagrant@addc-02:~$ kinit administrator@S1.EXAMPLE.NET
administrator@S1.EXAMPLE.NET’s Password:

vagrant@addc-02:~$ klist
Credentials cache: FILE:/tmp/krb5cc_1000
	Principal: administrator@S1.EXAMPLE.NET

    Issued Expires Principal
Jan 2 18:20:00 2019 Jan 3 04:20:00 2019 krbtgt/S1.EXAMPLE.NET@S1.EXAMPLE.NET

Вы можете выполнить проверку с обоих контроллеров домена в обоих доменах. После этих проверок вы можно быть уверенным, что DNS-прокси запущен.

Создание траста

Теперь, когда вы выполнили все приготовления и прошли все тесты, можно приступить к настройке доверия с самба-инструментом. Вы можете настроить доверие с любого контроллера домена в любом из доменов. В моем примере 7.1 я сделаю это с контроллера домена. addc-01.s1.example.net:

root@addc-01:# samba-tool domain trust create s2 \
			--type=forest --direction=both \
			--create-location=both \
			-U administrator@S2.EXAMPLE.COM
LocalDomain Netbios[S1] DNS[s1.example.net] SID[S-1-5-21-3126357314-\
			3577825812-2501707040]
RemoteDC Netbios[ADDC-02] DNS[addc-02.s2.example.com] ServerType[PDC,\
			GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,\
			GOOD_TIMESERV,FULL_SECRET_DOMAIN_6]
Password for [administrator@S2.EXAMPLE.COM]:
RemoteDomain Netbios[S2] DNS[s2.example.com] SID[S-1-5-21-2406301074\
			-2875553281-1464783146]
Creating remote TDO.
Remote TDO created.
Setting supported encryption types on remote TDO.
Creating local TDO.
Local TDO created
Setting supported encryption types on local TDO.
Setup local forest trust information...
Namespaces[2] TDO[s2.example.com]:
TLN: Status[Enabled] DNS[*.s2.example.com]
DOM: Status[Enabled] DNS[s2.example.com] Netbios[S2] \
			SID[S-1-5-21-2406301074-2875553281-1464783146]
Setup remote forest trust information...
Namespaces[2] TDO[s1.example.net]:
TLN: Status[Enabled] DNS[*.s1.example.net]
DOM: Status[Enabled] DNS[s1.example.net] Netbios[S1] \
			SID[S-1-5-21-3126357314-3577825812-2501707040]
Validating outgoing trust...
OK: LocalValidation: DC[\\addc-02.s2.example.com] CONNECTION[WERR_OK] \
			TRUST[WERR_OK] VERIFY_STATUS_RETURNED
Validating incoming trust...
OK: RemoteValidation: DC[\\addc-01.s1.example.net] CONNECTION[WERR_OK] \
			TRUST[WERR_OK] VERIFY_STATUS_RETURNED
Success.

Не забудьте использовать заглавную букву для имени администратора из домена s2. С помощью команд из примера 7.1 вы создали траст в лесу доменов. Помните, что такое доверие всегда двунаправленное и транзитивное.

Проверка доверия : После того, как вы настроили траст, вы должны проверить, все ли в порядке. Итак, первое — чтобы показать траст между нашими двумя доменами выполните команды как тут:

root@addc-01:# samba-tool domain trust show s2
LocalDomain Netbios[S1] DNS[s1.example.net] SID[S-1-5-21-3126357314-\
			3577825812-2501707040]
TrustedDomain:

NetbiosName: S2
DnsName: s2.example.com
SID: S-1-5-21-2406301074-2875553281-1464783146
Type: 0x2 (UPLEVEL)
Direction: 0x3 (BOTH)
Attributes: 0x8 (FOREST_TRANSITIVE)
PosixOffset: 0x00000000 (0)
kerb_EncTypes: 0x18 (AES128_CTS_HMAC_SHA1_96,AES256_CTS_HMAC_SHA1_96)
Namespaces[2] TDO[s2.example.com]:
TLN: Status[Enabled] DNS[*.s2.example.com]
DOM: Status[Enabled] DNS[s2.example.com] Netbios[S2] \
			SID[S-1-5-21-2406301074-2875553281-1464783146]

Повторите тест с другого контроллера, результат должен быть таким же. Потому что вы можете иметь более одного траста, следующий тест покажет вам, как вы можете увидеть все трасты с вашего домена или на него:

root@addc-01:# samba-tool domain trust list
Type[Forest] Transitive[Yes] Direction[BOTH] Name[s2.example.com]

В разных доменах могут быть разные результаты. Результат зависит от типа траста который установлен с этим доменом. Если у вас после настройки траста возникли проблемы с доступом пользователей из трастового домен в свой домен, тогда вы должны проверить, действительно ли установлен траст. Вы можете проверить действительно ли установлен траст:

root@addc-01:# samba-tool domain trust validate s2 \
			-Uadministrator@S2.EXAMPLE.COM
LocalDomain Netbios[S1] DNS[s1.example.net] SID[S-1-5-21-3126357314-\
			3577825812-2501707040]
LocalTDO Netbios[S2] DNS[s2.example.com] SID[S-1-5-21-2406301074-\
			2875553281-1464783146]
OK: LocalValidation: DC[\\addc-02.s2.example.com] CONNECTION[WERR_OK] \
			TRUST[WERR_OK] VERIFY_STATUS_RETURNED
OK: LocalRediscover: DC[\\addc-02.s2.example.com] CONNECTION[WERR_OK]
RemoteDC Netbios[ADDC-02] DNS[addc-02.s2.example.com] ServerType[PDC,GC,\
			LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,\
			GOOD_TIMESERV,FULL_SECRET_DOMAIN_6]
Password for [administrator@S2.EXAMPLE.COM]:
OK: RemoteValidation: DC[\\addc-01.s1.example.net] CONNECTION[WERR_OK] \
			TRUST[WERR_OK] VERIFY_STATUS_RETURNED
OK: RemoteRediscover: DC[\\addc-01.s1.example.net] CONNECTION[WERR_OK]

Теперь вы можете быть уверены, что доверие работает. Вы можете выполнить этот тест с любого контроллера домена в обоих доменах.

Управление

Теперь мы находимся в точке, где мы можем назначать пользователей и группы из доверяющего домена в группу доверенного домена. Помните, здесь у нас есть двустороннее доверие, так что вы можете назначать пользователей и группы в обоих направлениях. Прежде чем мы сможем назначать пользователей и группы, вам необходимо создать несколько пользователей и групп в обоих доменах. Просто создайте несколько пользователей и групп с samba-tool.

Список пользователей и групп: теперь, когда доверие работает, вы можете перечислить всех пользователей и группы из обоих доменов с помощью wbinfo - <u|g> --domain = <domain> как вы можете видеть далее, вы не увидите пользователей и группы из доверяющего домена, вы видите только пользователей и группы из своего домена:

root@addc-02:# wbinfo -u --domain=s2
S2\administrator
S2\guest
S2\krbtgt
S2\user1
S2\user2
S2\user3
S2\user4
root@addc-02:# wbinfo -u —domain=s1

root@addc-02:# wbinfo -g --domain=s2
S2\cert publishers
S2\ras and ias servers
S2\allowed rodc password replication group
S2\denied rodc password replication group
S2\dnsadmins
S2\enterprise read-only domain controllers
S2\domain admins
S2\domain users
S2\domain guests
S2\domain computers
S2\domain controllers
S2\schema admins
S2\enterprise admins
S2\group policy creator owners
S2\read-only domain controllers
S2\dnsupdateproxy
S2\dom2-g1
S2\dom2-g2

root@addc-02:# wbinfo -g —domain=s1

Причина в том, что, возможно, вы не увидите всех пользователей и группы из доверяющего домена, из-за некоторых настроек безопасности (особенно если доверяющий домен - это Windows-домен), поэтому в актуальной Samba-версии команда была отключена для контроллера домена. Чтобы увидеть всех Пользователей, вы можете выполнить LDAP-запрос с помощью samba-tool, как показано:

root@addc-02:# samba-tool user list -H ldap://addc-01 \
-U administrator@S1.EXAMPLE.NET
Password for [administrator@S1.EXAMPLE.NET]:
Guest
hhirsch
ktom
Administrator
krbtgt
adent
ptau
root@addc-02:# samba-tool user list -H ldap://addc-02 \
-U administrator@S2.EXAMPLE.COM
Password for [administrator@S2.EXAMPLE.COM]:
user1
user2
Guest
user4
Administrator
user3
krbtgt

Здесь вы можете видеть, что все еще можно увидеть всех пользователей и группы из обоих доменов.

Использование wbinfo

После того, как вы сможете перечислить всех пользователей из обоих доменов, вам нужно найти SID пользователя или группы, и добавить SID в качестве члена к вашей группе. Первый шаг с wbinfo — получить дополнительную информацию о ваших доменах, как вы можете видеть:

root@addc-02:# wbinfo --all-domains
BUILTIN
S2
S1

root@addc-02:# wbinfo --own-domain
S2

root@addc-02:# wbinfo --trusted-domains
BUILTIN
S2
S1

root@addc-02:# wbinfo --online-status
BUILTIN : active connection
S2 : active connection
S1 : active connection

Теперь давайте посмотрим, как можно получить SID пользователей и групп. В примере 8.4 вы видите все необходимая команды:

root@addc-02:# wbinfo -n s1\\ktom
S-1-5-21-3126357314-3577825812-2501707040-1104 SID_USER (1)
root@addc-02:# wbinfo -n s2\\user1
S-1-5-21-2406301074-2875553281-1464783146-1104 SID_USER (1)
root@addc-02:# wbinfo -n s1\\dom1-g1
S-1-5-21-3126357314-3577825812-2501707040-1108 SID_DOM_GROUP (2)
root@addc-02:# wbinfo -n s2\\dom2-g1
S-1-5-21-2406301074-2875553281-1464783146-1108 SID_DOM_GROUP (2)
root@addc-02:# wbinfo -i s1\\hhirsch
S1\hhirsch:*:3000018:3000019::/home/S1/hhirsch:/bin/false
root@addc-02:# wbinfo -i s2\\user2S2\user2:*:3000020:100::/home/S2/user2:/bin/false

Как видите, вы получите всю информацию обо всех пользователях из обоих доменов.

Тестирование аутентификации

С помощью wbinfo вы можете протестировать процесс аутентификации разных пользователей из обоих доменов.

Вы увидите два типа аутентификации. Первым тестом будет пароль в виде открытого текста. Этот тип аутентификации всегда имеет место, когда пользователь входит в локальную систему, открытый текст не означает, что пароль будет отправлен без шифрования. это просто название процесса входа в систему. Второй тип — вызов/ответ пароля аутентификации. Этот тип аутентификации использует NTLM или Kerberos. В примере вы увидите результат обоих процессов аутентификации:

root@addc-02:# wbinfo -a s1\\hhirsch
Enter s1\hhirsch’s password:
plaintext password authentication succeeded
Enter s1\hhirsch’s password:
challenge/response password authentication succeeded

root@addc-02:# wbinfo -a s2\\user1
Enter s2\user1’s password:
plaintext password authentication succeeded
Enter s2\user1’s password:
challenge/response password authentication succeeded

Вы также можете проверить, какие контроллеры домена отвечают за аутентификацию. В примере 8.1.2 показан результат теста:

root@addc-02:# wbinfo --ping-dc
checking the NETLOGON for domain[S2] dc connection to "addc-02.s2.example.com" \
succeeded

root@addc-02:# wbinfo --ping-dc --domain=s1
checking the NETLOGON for domain[s1] dc connection to "addc-01.s1.example.net" \
succeeded

Назначение пользователя и групп

Теперь вы достигли точки, когда вы можете назначать пользователей и группы из доверенных доменов в любую из групп доверяющего домена. Как я уже упоминал ранее, вы не можете назначить пользователей и групп через имя, вы должны использовать SID. В примере 8.1.3 показаны все шаги:

root@addc-02:# wbinfo -n s1\\ktom
			S-1-5-21-3126357314-3577825812-2501707040-1104 SID_USER (1)
root@addc-02:# samba-tool group addmembers dom2-g1 \
			S-1-5-21-3126357314-3577825812-2501707040-1104
Added members to group dom2-g1

root@addc-02:# wbinfo -n s1\\dom1-g1
			S-1-5-21-3126357314-3577825812-2501707040-1108 SID_DOM_GROUP (2)

root@addc-02:# samba-tool group addmembers dom2-g1 \
			S-1-5-21-3126357314-3577825812-2501707040-1108
Added members to group dom2-g1

root@addc-02: samba-tool group listmembers dom2-g1
S-1-5-21-3126357314-3577825812-2501707040-1108
user2
S-1-5-21-3126357314-3577825812-2501707040-1104
user1

Членство в группе действительно для всех членов в доверенном домене, поэтому, если у вас есть файловый сервер в качестве члена вы можете назначить группу и дать ему разрешение.

Обзор трастов с WINDOWS

Windows демонстрирует доверие к RSAT

Членство в группе в ADUC RSAT

Использование трастов на LINUX-клиетах

Теперь, после настройки траста, мы рассмотрим Linux-клиент и то, как вам нужно настроить клиент для пользователей и групп из обоих доменов. Если вы хотите использовать пользователей из обоих доменов вы должны настроить winbind на всех своих клиентах, чтобы разрешить всех пользователей и группы из обоих доменов.

Присоединение к Linux-клиенту

Прежде чем вы сможете присоединиться к клиенту, вы должны настроить его через smb.conf. Вы должны установить ID-маппинг для обоих доменов в вашем smb.conf, как показано в примере 9.1:

[global]
	workgroup = s1
	realm = S1.EXAMPLE.NET
	security = ADS
	winbind refresh tickets = Yes
	template shell = /bin/bash
	idmap config * : range = 10000 - 19999
	idmap config S1 : backend = rid
	idmap config S1 : range = 1000000 - 1999999
	idmap config S2 : backend = rid
	idmap config S2 : range = 10000000 — 19999999

Теперь вы можете присоединить Linux-клиент к домену. На вашей Linux-машине файл smb.conf уже готов присоединить машину к домену s1. Таким образом, вы можете присоединиться к машине, как в примере:

root@linux-client:# net ads join -U administrator
Enter administrator’s password:
Using short domain name -- S1
Joined ’LINUX-CLIENT’ to dns domain ’s1.example.net’
root@linux-client:# net ads testjoin
Join is OK

После перезапуска smbd, nmbd и winbind вы можете проверить, можете ли вы просмотреть пользователей из обоих доменов с wbinfo. В примере 9.3 вы видите несколько тестов с wbinfo на клиенте:

root@linux-client:# wbinfo -m
BUILTIN
LINUX-CLIENT
S1
S2

root@linux-client:# wbinfo --online-status
BUILTIN : online
LINUX-CLIENT : online
S1 : online
S2 : online

root@linux-client:# net rpc trustdom list -Uadministrator
Enter administrator’s password:
Trusted domains list:

S2 S-1-5-21-2406301074-2875553281-1464783146

Trusting domains list:

S2 S-1-5-21-2406301074-2875553281-1464783146

root@linux-client:# wbinfo -n s1\\ktom
S-1-5-21-3126357314-3577825812-2501707040-1104 SID_USER (1)

root@linux-client:# wbinfo -n s2\\user1
S-1-5-21-2406301074-2875553281-1464783146-1104 SID_USER (1)

Если вы хотите видеть всех пользователей из любого домена, на клиенте Linux вы все равно можете использовать команду

wbinfo - <u | g> --domain = <domainname>

.

Использование пользователей и групп После того, как вы подключитесь к машине и сможете видеть всех пользователей и группы, вам необходимо отредактировать файл /etc/nsswitch.conf:

passwd: compat winbind
group: compat winbind

После настройки /etc/nsswitch.conf вы можете протестировать пользователей и группы с помощью getent как вы можете видеть в примере:

root@linux-client:# getent group s1\\dom1-g1
S1\dom1-g1:x:1001108:

root@linux-client:# getent group s2\\dom2-g1
S2\dom2-g1:x:10001108:

root@linux-client:# getent passwd s1\\ktom
S1\ktom:*:1001104:1000513:ktom:/home/S1/ktom:/bin/bash

root@linux-client:# getent passwd s2\\user1
S2\user1:*:10001104:10000513:user1:/home/S2/user1:/bin/bash

Если вы видите своих пользователей и группы из обоих доменов, вы можете приступить к настройке разрешений внутри файловой системы. Я создал несколько домашних каталогов для пользователей из разных доменов. чтобы проверить логин:

root@linux-client:/# mkdir /data-dom1

root@linux-client:/# mkdir /data-dom2

root@linux-client:/# chgrp s1\\dom1-g1 /data-dom1

root@linux-client:/# chgrp s2\\dom2-g1 /data-dom2

root@linux-client:/# chown s1\\ktom /data-dom1

root@linux-client:/# chown s2\\user2 /data-dom2

root@linux-client:/# ls -ld /data-dom1
drwxr-xr-x 2 S1\ktom S1\dom1-g1 4096 Jan 4 16:32 /data-dom1

root@linux-client:/# ls -ld /data-dom2
drwxr-xr-x 2 S2\user2 S2\dom2-g1 4096 Jan 4 16:32 /data-dom2

root@linux-client:/# mkdir /home/S1

root@linux-client:/# mkdir /home/S2

root@linux-client:/# chmod 755 /home/S*

root@linux-client:/# mkdir /home/S1/ktom

root@linux-client:/# chown s1\\ktom /home/S1/ktom/

root@linux-client:/# mkdir /home/S2/user1

root@linux-client:/# chown s2\\user1 /home/S2/user1

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

vagrant@linux-client:~$ ssh s1\\ktom@192.168.56.51
s1\ktom@192.168.56.51’s password:
...
Last login: Fri Jan 4 16:34:52 2019 from 192.168.56.51
S1\ktom@linux-client:~$
vagrant@linux-client:~$ ssh s2\\user1@192.168.56.51
s2\user1@192.168.56.51’s password:
...
Last login: Fri Jan 4 16:42:09 2019 from 192.168.56.51
S2\user1@linux-client:~$

Теперь вы можете начать создавать несколько общих ресурсов и использовать свою систему в качестве файлового сервера для обоих доменов.