Trusts
Страница в состоянии разработки.
Представлен перевод статьи - Stefan Kania "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. Далее в таблице указаны параметры которыен потребуются для примера.
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:/home/vagrant# 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:/home/vagrant# 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:/home/vagrant# samba-tool domain trust list Type[Forest] Transitive[Yes] Direction[BOTH] Name[s2.example.com]
В разных доменах могут быть разные результаты. Результат зависит от типа траста который установлен с этим доменом. Если у вас после настройки траста возникли проблемы с доступом пользователей из трастового домен в свой домен, тогда вы должны проверить, действительно ли установлен траст. Вы можете проверить действительно ли установлен траст:
root@addc-01:/home/vagrant# 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:/home/vagrant# wbinfo -u --domain=s2 S2\administrator S2\guest S2\krbtgt S2\user1 S2\user2 S2\user3 S2\user4 root@addc-02:/home/vagrant# wbinfo -u —domain=s1 root@addc-02:/home/vagrant# 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:/home/vagrant# wbinfo -g —domain=s1
Причина в том, что, возможно, вы не увидите всех пользователей и группы из доверяющего домена, из-за некоторых настроек безопасности (особенно если доверяющий домен - это Windows-домен), поэтому в актуальной Samba-версии команда была отключена для контроллера домена. Чтобы увидеть всех Пользователей, вы можете выполнить LDAP-запрос с помощью samba-tool, как показано:
root@addc-02:/home/vagrant# 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:/home/vagrant# 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:/home/vagrant# wbinfo --all-domains BUILTIN S2 S1 root@addc-02:/home/vagrant# wbinfo --own-domain S2 root@addc-02:/home/vagrant# wbinfo --trusted-domains BUILTIN S2 S1 root@addc-02:/home/vagrant# wbinfo --online-status BUILTIN : active connection S2 : active connection S1 : active connection
Теперь давайте посмотрим, как можно получить SID пользователей и групп. В примере 8.4 вы видите все необходимая команды:
root@addc-02:/home/vagrant# wbinfo -n s1\\ktom S-1-5-21-3126357314-3577825812-2501707040-1104 SID_USER (1) root@addc-02:/home/vagrant# wbinfo -n s2\\user1 S-1-5-21-2406301074-2875553281-1464783146-1104 SID_USER (1) root@addc-02:/home/vagrant# wbinfo -n s1\\dom1-g1 S-1-5-21-3126357314-3577825812-2501707040-1108 SID_DOM_GROUP (2) root@addc-02:/home/vagrant# wbinfo -n s2\\dom2-g1 S-1-5-21-2406301074-2875553281-1464783146-1108 SID_DOM_GROUP (2) root@addc-02:/home/vagrant# wbinfo -i s1\\hhirsch S1\hhirsch:*:3000018:3000019::/home/S1/hhirsch:/bin/false root@addc-02:/home/vagrant# wbinfo -i s2\\user2S2\user2:*:3000020:100::/home/S2/user2:/bin/false
Как видите, вы получите всю информацию обо всех пользователях из обоих доменов.
ТЕСТИРОВАНИЕ АУТЕНТИФИКАЦИИ
- С помощью wbinfo вы можете протестировать процесс аутентификации разных пользователей из обоих доменов.
Вы увидите два типа аутентификации. Первым тестом будет пароль в виде открытого текста. Этот тип аутентификации всегда имеет место, когда пользователь входит в локальную систему, открытый текст не означает, что пароль будет отправлен без шифрования. это просто название процесса входа в систему. Второй тип - вызов/ответ пароля аутентификации. Этот тип аутентификации использует NTLM или Kerberos. В примере вы увидите результат обоих процессов аутентификации:
root@addc-02:/home/vagrant# 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:/home/vagrant# 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:/home/vagrant# wbinfo --ping-dc checking the NETLOGON for domain[S2] dc connection to "addc-02.s2.example.com" \ succeeded root@addc-02:/home/vagrant# 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:/home/vagrant# wbinfo -n s1\\ktom S-1-5-21-3126357314-3577825812-2501707040-1104 SID_USER (1) root@addc-02:/home/vagrant# samba-tool group addmembers dom2-g1 \ S-1-5-21-3126357314-3577825812-2501707040-1104 Added members to group dom2-g1 root@addc-02:/home/vagrant# wbinfo -n s1\\dom1-g1 S-1-5-21-3126357314-3577825812-2501707040-1108 SID_DOM_GROUP (2) root@addc-02:/home/vagrant# samba-tool group addmembers dom2-g1 \ S-1-5-21-3126357314-3577825812-2501707040-1108 Added members to group dom2-g1 root@addc-02:/home/vagrant# 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:/home/vagrant# 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:/home/vagrant# net ads testjoin Join is OK
После перезапуска smbd, nmbd и winbind вы можете проверить, можете ли вы просмотреть пользователей из обоих доменов с wbinfo. В примере 9.3 вы видите несколько тестов с wbinfo на клиенте:
root@linux-client:/home/vagrant# wbinfo -m BUILTIN LINUX-CLIENT S1 S2 root@linux-client:/home/vagrant# wbinfo --online-status BUILTIN : online LINUX-CLIENT : online S1 : online S2 : online root@linux-client:/home/vagrant# 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:/home/vagrant# wbinfo -n s1\\ktom S-1-5-21-3126357314-3577825812-2501707040-1104 SID_USER (1) root@linux-client:/home/vagrant# 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
После настройки в nsswich.conf вы можете протестировать пользователей и группы с помощью getent как вы можете видеть в примере:
root@linux-client:/home/vagrant# getent group s1\\dom1-g1 S1\dom1-g1:x:1001108: root@linux-client:/home/vagrant# getent group s2\\dom2-g1 S2\dom2-g1:x:10001108: root@linux-client:/home/vagrant# getent passwd s1\\ktom S1\ktom:*:1001104:1000513:ktom:/home/S1/ktom:/bin/bash root@linux-client:/home/vagrant# 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:~$
Теперь вы можете начать создавать несколько общих ресурсов и использовать свою систему в качестве файлового сервера для обоих доменов.