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: как Samba обрабатывает доверительные отношения (трасты), какие бывают трасты и виды трастов, которые вы можете создать. Рассмотрен пример создания двух доменов, каждый со своим пространством имен. С помощью bind9 будет настроен DNS-прокси для управления разрешением имен SRV-записей между этими двумя доменами. После создания трастов расссмотрим как управлять пользователями и группами между этими доменами.

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

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

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

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

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

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

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

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

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

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

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

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

Виды трастов

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

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

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

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

Внешнее доверие впервые было введено в Windows-NT. Внешнее доверие — это доверие между двумя доменами, каждый со своим собственным пространством имен. Аутентификация, как и в случае Forest Trust, будет выполнена с использованием протокола Kerberos, а в случае неудачи произойдет переключение на NTLM. Пример внешнего доверия:

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

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

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

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

Поддерживается:

• Доверие в лесу доменов — как двустороннее доверие так и транзитивное доверие. Это доверие может быть установленным между двумя Samba-доменами или Samba-доменом и Windows-доменом.
• Внешние доверительные отношения между доменом AD и доменом в стиле NT.
• Добавление пользователей и групп доверенного домена в группы доверяющего домена. Но при этом необходимо использовать SID пользователей и групп, чтобы добавить их в свою группу (имя пользователя или имя группы использовать невозможно).
• В RSAT вы увидите foreignSecurityPrincipal для всех добавленных пользователей и групп из доверенного домена. Таким образом Microsoft показывает, что пользователь или группа являются частью доверенного домена.

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

• Доверительные отношения между доменами в одном дереве с одним и тем же пространством имён верхнего уровня.
• Фильтрация SID для ограничения разрешений.
• Обе стороны траста должны полностью доверять друг другу. Это означает, что администратор из домена A может управлять всеми объектами в домене Б и наоборот.
• Выборочная аутентификация в настоящий момент не поддерживается. Возможно создание таких доверий, но KDC и winbindd всё равно будут их игнорировать.

Окружение

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

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

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

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

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

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

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

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

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

Далее в таблице указаны параметры которые используются в примере.

Информация о двух доменах

Параметр	Домен 1	Домен 2
DNS-суффикс	s1.example.net	s2.example.net
Realm	S1.EXAMPLE.NET	S2.EXAMPLE.NET
Имя NetBios	S1	S2
IP-адрес	192.168.56.41	192.168.56.42
DNS-search	s1.example.net	s2.example.net

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

Одна из самых важных вещей, которую нужно сделать, прежде чем приступить к настройке доверия, — это настроить разрешение имён между двумя доменами. Недостаточно поместить контроллеры домена во все /etc/hosts всех других контроллеров домена, поскольку также должна быть возможность разрешать 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-записи на обоих контроллерах домена:

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-билет из любого домена:

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

Внимание! realm необходимо указывать заглавными буквами

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

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

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

# 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.

Не забудьте использовать заглавные буквы при указании realm в имени администратора из домена s2.

В данном примере мы создали траст в лесу доменов. Помните, что такое доверие всегда двунаправленное и транзитивное.

Проверка доверия

Первым тестом будет проверка доверия между двумя доменами (команда выполняется на контроллера домена addc-01.s1.example.net):

# 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]

Повторите тест с другого контроллера домена, результат должен быть таким же.

Поскольку у вас может быть более одного доверия, следующий тест покажет список всех доверительных отношений от или к вашему домену (команда выполняется на контроллера домена addc-01.s1.example.net):

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

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

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

В разных доменах могут быть разные результаты. Результат зависит от типа траста который установлен с этим доменом. Если у вас после настройки траста возникли проблемы с доступом пользователей из трастового домен в свой домен, тогда вы должны проверить, действительно ли установлен траст. Проверка траста (команда выполняется на контроллера домена addc-01.s1.example.net):

# 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, можно получить список пользователей и групп только из своего домена:

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 пользователей и групп:

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\\user2
S2\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

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

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.

Использование трастов на 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:~$

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