Доверительные отношения службы каталогов active directory windows используют протокол

Опубликовано: 18.06.2019

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

Мы будем рассматривать процесс настройки на примере двустороннего транзитивного доверия между доменами primary.local (192.168.0.15) и secondary.local (192.168.0.16). Саму настройку разделим на 2 этапа — конфигурирование DNS и создания доверий. В качестве операционной системы по данной инструкции можно настроить Windows Server 2008 / 2012 / 2016 / 2019.

Определяемся с типом доверительных отношений

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

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

Определяют направление доверия одного домена к другому.

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

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

Внешнее или доверие леса

Внешнее или нетранзитивное отношение устанавливается между двумя доменами напрямую вне леса.

Доверие леса или транзитивное отношение связывает леса и все их домены.

Настройка DNS

Для построения доверия необходимо, чтобы контроллеры домена видели друг друга. Все запросы на поиск узлов в AD выполняются через службы доменных имен. Таким образом, в нашем примере, мы должны сконфигурировать условную пересылку на DNS обоих доменов. Также важно, чтобы между контроллерами была сетевая доступность — по сети они должны видеть друг друга.

На DNS домена primary.local

Открываем Диспетчер серверов — кликаем по Средства — DNS:

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

В «DNS-домен» пишем второй домен (в нашем случае, secondary.local), затем задаем его IP-адрес, ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицировать ее следующим образом — выбираем Все DNS-серверы в этом домене:

Открываем командную строку и вводим команду:

nslookup secondary.local

Мы должны получить ответ на подобие:

На DNS домена secondary.local

Действия, которые делаем на втором сервере DNS, во многом, аналогичны.

Открываем Диспетчер серверов — Средства — DNS:

Раскрываем сервер — Серверы условной пересылки — Создать сервер условной пересылки:

На данном шаге небольшие изменения. В «DNS-домен» пишем первый домен (primary.local), затем задаем его IP-адрес (192.168.0.15), ставим галочку Сохранять условный сервер пересылки в Active Directory и реплицивовать ее следующим образом — выбираем Все DNS-серверы в этом домене:

В командной строке второго сервера проверяем настройку:

nslookup primary.local

Мы должны получить ответ на подобие:

Настройка доверительных отношений

После настройки DNS можно переходить к созданию доверительных отношений.

В домене primary.local открываем Диспетчер серверов — кликаем по Средства — Active Directory — домены и доверие:

В открывшемся окне кликаем правой кнопкой по нашему домену — Свойства:

Переходим на вкладку Отношения доверия — кликаем по Создать отношение доверия…:

Нажимаем Далее — вводим имя для второго домена (secondary.local) и кликаем Далее:

Выбираем Доверие леса (если нам не нужно внешнее доверие) — Далее:

В окне «Направление отношения доверия» выбираем Двустороннее:

… и нажимаем Далее.

В следующем окне выбираем, на каком из доменов мы применяем настройку — если у нас есть права администратора для обоих доменов, то выбираем Для данного и указанного доменов:

* если мы являемся администратором одного из доменов, а вторым доменом управляет другой специалист, то выбираем Только для данного домена. Подобные действия должен выполнить второй администратор в своем домене.

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

Далее нужно выбрать «Уровень проверки подлинности исходящего доверия» — если оба домена принадлежат нашей организации, предпочтительнее выбрать Проверка подлинности в лесу, чтобы предоставить доступ ко всем ресурсам:

После последуют два окна — «Выбор доверия завершен» — Далее — «Создание доверия завершено» — Далее.

В окне «Подтверждение исходящего доверия» оставляем Нет, не подтверждаю это исходящее доверие, так как на другой стороне нами не создавалось доверия.

Тоже самое в окне «Подтверждение входящего доверия».

Нажимаем Готово — доверительные отношения созданы.

Домены, леса и опасность доверительных отношений

Доверительные отношения — эффективный способ ограничить число учетных записей и реализовать единую процедуру регистрации (single sign-on — SSO) в лесах Active Directory (AD), доменах Windows NT и AD и даже в областях Kerberos на платформах, отличных от Windows. Но за доверие приходится платить. В лесу с доменами, связанными отношениями доверия, есть где развернуться недобросовестным администраторам, а физически уязвимые контроллеры домена (DC) представляют собой угрозу для всего леса. В данной статье рассматриваются основы доверительных отношений и потенциальные опасности, связанные с такими отношениями. Затем объясняется, как снизить риск для различных типов доверительных отношений, применяемых в современных системах Windows Server 2003 и Windows 2000.

Оптимальный уровень разделения

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

К сожалению, по разным причинам в организации часто оказывается несколько лесов. Если одна компания приобретает другую или две компании объединяются, часто возникает сеть с двумя лесами. Некоторые администраторы считают, что домены в лесу не обеспечивают достаточного разделения административных полномочий, поэтому формируют несколько лесов. Иногда необходимость структуры со многими лесами диктуется требованиями отраслевых стандартов или закона.

Простой вопрос доверия

Рассмотрим простейший вариант доверительных отношений: односторонние нетранзитивные отношения между двумя доменами. Домен A доверяет домену Б, но домен A не доверяет любому домену, которому доверяет домен Б. На рис. 1 показана сравнительная картина нетранзитивных и транзитивных отношений. О проблеме безопасности при различных видах доверительных отношений рассказано во врезке «Типы доверительных отношений». Что происходит, если домен A доверяет домену Б? Кому в действительности доверяет домен A? Получают ли пользователи домена Б автоматический доступ к ресурсам домена A? Имеют ли администраторы домена Б права доступа к домену A?

Прежде всего, выясним, что происходит при доверительных отношениях? В данном случае домен A — доверяющий (trusting), а домен Б — доверенный (trusted). Для домена A направление доверительных отношений — исходящее. Компьютеры в домене A доверяют контроллерам домена в домене Б, которые аутентифицируют учетные записи пользователей и компьютеров, и определяют членство в группах. Если администратор в домене A открывает список управления доступом (ACL) файла или папки и выбирает новые учетные записи и группы, чтобы добавить их в ACL, то администратор видит учетные записи и группы как домена Б, так и домена A. Администратор может сделать учетные записи и группы домена Б членами групп домена A, и в целом может использовать учетные записи и группы домена Б всюду, где применимы учетные записи и группы домена A. Пользователи домена Б могут обращаться к ресурсам в домене A, для которых у них имеются соответствующие полномочия.

Кому в действительности доверяет домен A? Пользователям домена Б? Администраторам домена Б? Если установлены доверительные отношения, в соответствии с которыми домен A доверяет домену Б, то, очевидно, желательно, чтобы пользователи домена Б получили доступ к определенным ресурсам домена A. Доступ можно обеспечить, предоставив соответствующие полномочия группам домена Б после установления доверительных отношений. Но получат ли администраторы домена Б дополнительные права в домене A? Очевидный ответ — администраторы домена Б получают такие же права доступа, как и другие пользователи домена Б, за исключением права добавлять и удалять пользователей групп домена Б, имеющих доступ к ресурсам домена A. Другими словами, если администратор домена A предоставляет какие-нибудь права доступа группе домена Б, то администратор домена Б может предоставить или отменить эти права для пользователей домена Б, просто изменив членство в группе домена Б. Поэтому на первый взгляд доверительные отношения не несут серьезной опасности. Однако у администраторов домена Б есть документированный способ незаконно получить административный доступ к домену A. Этот способ будет описан в следующем разделе.

Подводные камни доверительных отношений

Одна из опасностей отношений доверия с другим доменом связана с управлением разрешениями в ситуациях, когда необходимо предоставить всем пользователям домена доступ к определенному ресурсу. Часто для этой цели используется группа Everyone или Authenticated Users. Однако состав группы Authenticated Users изменяется при добавлении доверенного домена. Если домен A не доверяет ни одному другому домену, то в группу Authenticated Users входят только пользователи домена A; если разрешения на доступ к объектам заданы на автономных серверах и рабочих станциях — то локальные пользователи этих компьютеров. Но если домен A доверяет домену Б, то группа Authenticated Users автоматически расширяется и охватывает всех пользователей домена Б. Поэтому любые файлы и другие объекты, в ACL которых есть записи, предоставляющие доступ группе Authenticated Users, становятся доступными и пользователям домена Б. Если доверие домена A домену Б транзитивное, то доверительные отношения распространяются на пользователей всех доменов, которым доверяет домен Б.

В зависимости от типа доверительных отношений, Windows может использовать Kerberos или NT LAN Manager (NTLM) в качестве протокола аутентификации для обработки запросов регистрации между двумя доменами. Проанализировать пакеты и разгадать пароли пользователей можно с помощью любого протокола, но расшифровать информацию NTLM проще и быстрее. Наиболее уязвимые места NTLM можно защитить, если внедрить стандарт NTLMv2 на всех DC и рабочих станциях в доверенном домене и на всех компьютерах в доверяющем домене, но Kerberos все равно надежнее.

Устранить технические препятствия значительно проще, чем главную опасность доверительных отношений с другим доменом: доверие к администраторам другого домена. Если домен A доверяет домену Б, то администраторы домена Б должны выполнять свою работу профессионально и честно. Если домен Б подвергся нападению, то под угрозой оказываются все ресурсы домена A, доступные домену Б. Например, предположим, что Боб имеет учетную запись в домене Б и доступ к важной базе данных в домене A. Если взломщик попытается разгадать пароль Боба путем повторных попыток регистрации, то уровень надежности политики блокировки домена A не имеет значения, и преградой для доступа взломщика к базе данных в домене A служит лишь политика блокировки домена Б. Кроме того, только администраторы домена Б могут обнаружить неудачные попытки регистрации в журнале безопасности контроллера домена. Хотя, если взломщик напрямую атакует один из компьютеров домена A с учетной записью Боба, то неудачные попытки локальной регистрации будут отражены в журнале безопасности атакуемого компьютера. Поэтому, если администраторы в доверенном домене не смогут защитить свои учетные записи, отслеживать попытки несанкционированного доступа или уязвимые места, своевременно устанавливать исправления или принимать другие меры обеспечения безопасности, то доверяющий домен (по крайней мере, его ресурсы, доступные пользователям доверенного домена) подвергается такой же опасности, как домен, которому он доверяет.

Кроме того, всегда существует опасность присутствия непорядочного администратора в доверенном домене. Администраторы могут манипулировать учетными записями и группами по-разному, в том числе действовать от лица пользователя, которому был предоставлен доступ. Конечно, та же опасность существует и внутри доверяющего домена. Поэтому, отвечая на вопрос, можно ли доверять другому домену, следует спросить себя, заслуживают ли доверия администраторы того домена. Однако альтернатива доверительным отношениям между доменами, пользователям которых необходимо предоставить доступ к ресурсам, также не лишена риска. Если не доверять домену, то нужно создать учетные записи для его пользователей. Можно быть уверенным, что эти учетные записи защищены в соответствии с требованиями, действующими внутри домена. Однако нужно предусмотреть меры на случай увольнения или изменения служебных обязанностей пользователей — а может быть, у администраторов домена, с которым установлены отношения доверия, больше возможностей блокировать учетные записи и менять членство в группах при должностных изменениях?

Еще одна опасность заключается в том, что доверенные DC не только аутентифицируют пользователей, но и предоставляют доверяющим DC информацию о членстве в группах. Внутри леса DC доверяет всем SID, назначенным пользователю доверенным DC. Поэтому злоумышленник-администратор в домене Б (при наличии достаточной квалификации и программы, составленной умелым хакером), может заставить DC в домене Б указать, что администратор домена Б принадлежит к группе Administrators домена A, и домен A предоставит ему административные полномочия (см. «Facts about Directory Structures and Directory Structure Owners» в «Design Considerations for Delegation of Administration in Active Directory» по адресу http://www.microsoft.com/ windows2000/docs/addeladmin.doc).

Взломщик мог воспользоваться этим уязвимым местом при доверительных отношениях любого типа. В ответ на угрозу разработчики Microsoft дополнили все версии Windows функцией фильтрации SID. В режиме фильтрации SID доверяющий DC анализирует SID, поступающие от доверенного DC, и отфильтровывает те из них, которые соответствуют учетным записям и группам вне доверенного домена. Однако фильтрация SID невозможна между доменами внутри одного леса, так как нарушает репликацию.

Администратор доверяющего домена должен применить фильтрацию SID к домену, которому он доверяет. Например, с помощью следующей команды Netdom можно фильтровать SID из домена Jonescorp:

C:winnt>netdom /filtersids yes

jonescorp

Доверяй, но проверяй

Каким образом можно уменьшить опасность того, что доверенный администратор-злоумышленник вставит SID внутри леса? На первый взгляд единственное решение — создать отдельный лес для каждого домена. Допустим, Acme — международная компания со штаб-квартирой в США и офисами по всему миру. Доменами в лесу Acme управляют администраторы американских и иностранных офисов. Acme также выполняет секретные заказы правительства США, доступ к которым для иностранных граждан запрещен. Если просто перенести секретные ресурсы в «секретный» домен в лесу Acme, есть опасность, что доступ к ним получат иностранцы с административными полномочиями в других доменах леса. Безусловно, реальное и самое концептуально простое решение — создать отдельный «секретный» лес.

Однако у Acme есть другой выход, который позволит сохранить преимущества единственного леса. Лишь немногие пользователи доменов AD действительно нуждаются в административных полномочиях. Высокодетализированная модель безопасности AD позволяет делегировать фрагменты административных полномочий в соответствии с потребностями конкретного предприятия. Если уделить время идентификации различных ролей в ИТ-подразделении и разобраться в механизме делегирования AD, то можно организовать домены так, чтобы для повседневного администрирования никто не регистрировался в качестве членов групп Administrators, Domain Admins, Enterprise Admins или Schema Admins. Детализированное делегирование полномочий AD позволяет снизить остроту проблемы администраторов-злоумышленников, допуская в число членов групп Administrators, Domain Admins, Enterprise Admins и Schema Admins только граждан США. Благодаря такой мере иностранный сотрудник ИТ-подразделения не сможет вставить SID внутри леса.

Однако ограничение административных полномочий препятствует лишь одному из двух возможных способов вставки SID внутри леса. Другой метод состоит в физическом доступе. Лицо, которое получает физический доступ к DC, может изменить системные файлы при отключенной системе Windows. Физическая уязвимость представляет более сложную проблему для такой компании, как Acme, поскольку ей необходимо устанавливать DC за рубежом для обслуживания производственной деятельности. Единственный способ защититься от вставки SID внутри леса в результате физического проникновения злоумышленника — полностью удалить секретный домен из основного леса. Для связи между пользователями в секретном домене и остальной компанией можно организовать внешние доверительные отношения между специальными доменами основного и секретного лесов (рис. 2). Чтобы компенсировать отсутствие единого, унифицированного глобального каталога (Global Catalog — GC), можно задействовать Microsoft Identity Integration Server (MIIS), который публикует данные пользователей одного леса как объекты «контакт» в другом лесу.

Домены Windows 2003 и Windows 2000 — не такая непреодолимая граница административных полномочий, как в NT. Роль административной границы в AD отведена лесу. Следование принципу минимальных полномочий и ограничение административных прав могут существенно уменьшить опасность вставки SID внутри леса, но не устранить ее полностью. Нежелательно строить несколько лесов, так как это неудобно для пользователей и создает дополнительную работу для администраторов, которые должны предоставить пользователям унифицированный каталог. Помочь в этом могут такие инструменты, как MIIS. Проектирование лесов и доменов для организации связано с поиском баланса между удобством использования и риском при управлении.

Типы доверительных отношений

Внутри леса можно установить доверительные отношения родитель-потомок (parent-child), дерево-корень (tree-root) или с помощью указателей (shortcut). Все доверительные отношения внутри леса являются двусторонними и транзитивными. Указательные отношения могут быть односторонними, но они не влияют на безопасность. Принимая решение о создании домена внутри леса, следует учитывать несколько факторов. Все домены в лесу доверяют друг другу, поэтому в новом домене должны быть реализованы минимальные меры безопасности, соответствующие уровню остального леса. Кроме того, по умолчанию все домены относятся к ведению группы Administrators корневого домена леса в силу полномочий, по умолчанию назначаемых группе Enterprise Admins. Следует ли оставить в силе эти полномочия, учитывая особенности ресурсов нового домена? И наконец, хотя официально у администраторов одного домена нет полномочий в других доменах леса, в Active Directory (AD) есть уязвимое место, через которое администраторы одного домена потенциально могут получить административные полномочия в другом. Отдельные подразделения некоторых компаний (например, выполняющие секретные правительственные заказы) должны быть строго недоступны для других администраторов. Для секретного подразделения можно организовать отдельный лес, вместо того чтобы строить отдельный домен в том же лесу.

Внешние, лесные и областные (realm) доверительные отношения расширяют сферу доверия за пределы леса. Внешние связи позволяют установить одностороннее и двухстороннее доверие с доменом в другом лесу или унаследованным доменом Windows NT 4.0. Внешние доверительные отношения нетранзитивны (ограничены двумя доменами, напрямую связанными друг с другом). Внешние отношения ограничены сравнительно ненадежным протоколом аутентификации NT LAN Manager (NTLM), но уровень защиты от анализа пакетов и разгадывания пароля можно повысить, если использовать NTLMv2 вместо NTLM для настройки конфигурации контроллеров домена и клиентских компьютеров в доверенном домене и DC и серверов — в доверяющем домене. Доверяющие домены уязвимы для манипуляций с SID администраторами доверяемого домена. Если фильтрация SID не активизирована, то администратор доверенного домена может вставлять фальшивые SID в свойство предыстории SID учетной записи, которое соответствует SID группы (например, Administrators, Domain Admins и Enterprise Admins) леса доверяющего домена. Если для доверительного отношения активизирована SID-фильтрация, то доверяющий DC фильтрует фальшивые SID, получаемые в составе запросов аутентификации из доверенного домена.

Доверительные отношения между лесами — новшество лесов в Windows Server 2003. Двусторонние доверительные отношения между лесами Windows 2003 расширяют изначальное доверие, обычно существующее между всеми доменами в лесу, распространяя его на оба леса. Одностороннее доверие между лесами означает, что все домены в доверяющем лесу доверяют всем доменам в доверенном лесу, но не наоборот. Лесные доверительные отношения поддерживают как NTLM, так и Kerberos, поэтому вновь возникает потребность в реализации NTLMv2 между двумя участниками доверительных отношений. Лесные доверительные отношения уязвимы к тем же манипуляциям с SID, что и внешние домены, поэтому следует активизировать фильтрацию SID. Посредством доверительных отношений между лесами можно добиться одинакового уровня доверия между всеми доменами двух лесов, не опасаясь кражи административных полномочий одного домена администраторами второго домена в другом, доверенном лесу.

Однако домены, соединенные межлесными доверительными отношениями, не разделяют двух ресурсов AD, общих для всех доменов леса: Global Catalog (GC) и схемы. Изменения схемы в одном лесу не выходят за границу леса. В большинстве случаев это не представляет серьезной проблемы, так как при необходимости можно просто соответствующим образом изменить схему другого леса. Труднее компенсировать отсутствие единого, унифицированного GC. Именно благодаря GC границы домена прозрачны для пользователей, которым нужно найти других пользователей, группы рассылки, серверы и другие ресурсы. Если организация разделена на несколько лесов, то пользователи должны знать границы лесов, а также пользователей, подразделения и ресурсы, принадлежащие конкретным лесам. Для восстановления прозрачности в среде со многими лесами можно синхронизировать объекты между лесами с помощью бесплатного пакета Microsoft Identity Integration Server (MIIS) Feature Pack for Windows Server Active Directory. Например, если есть два леса, A и Б, то можно установить MIIS Feature Pack, чтобы опубликовать учетные записи пользователей леса A в качестве контактов в лесу Б и учетные записи пользователей леса Б в качестве контактов леса A. В результате пользователи смогут отыскать друг друга и общаться через Microsoft Exchange Server.

Редактор Windows IT Pro и ведущий инструктор и разработчик курсов для программы по безопасности Windows NT/2000 института MIS Training. Его компания, Monterey Technology Group, занимается консалтингом в области информационной безопасности. Связаться с ним можно по адресу: rsmith@monterey techgroup.com

Поддержка доверительных отношений с Samba

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

• Доверительное отношение между лесами доменов (forest trust). Это доверие может быть установленным между двумя Samba-доменами или Samba-доменом и Windows-доменом.
• Внешние доверительные отношения (external trust). Это доверие может быть установленным между двумя Samba-доменами или Samba-доменом и Windows-доменом.
• Добавление пользователей и групп доверенного домена в группы доверяющего домена, но при этом необходимо использовать SID пользователей и групп, чтобы добавить их в свою группу (имя пользователя или имя группы использовать невозможно).

Особенности и ограничения:

• Не применяются правила фильтрации SID.
• Доверительные отношения должны быть двусторонними.
• Выборочная аутентификация в настоящий момент не поддерживается. Возможно создание таких доверий, но KDC и winbindd всё равно будут их игнорировать.
• Нельзя создать доверительные отношения между доменами с одинаковыми NetBIOS именами.
• В RSAT появится контейнер ForeignSecurityPrincipal для всех добавленных пользователей и групп из доверенного домена. Таким образом Microsoft показывает, что пользователь или группа являются частью доверенного домена.
• Winbind на клиентских машинах не распознаёт доверенные домены, что приводит к проблемам с обновлением паролей учетных записей доверенного домена после их истечения. Чтобы устранить эту проблему, необходимо внести изменения в конфигурационный файл smb.conf на Linux-клиентах, подключенных через Winbind. В секции [global] этого файла следует добавить соответствующую опцию:

  winbind scan trusted domains = yes

  Перезапустить сервис winbind:

  # systemctl restart winbind.service
  

• В версиях Samba ниже 4.19.9-alt3 при использовании групповой политики (на контроллерах в win-домене) «Сетевая безопасность: минимальная сеансовая безопасность для серверов на базе NTLM SSP (включая безопасный RPC)» с опцией «требовать сеансовую безопасность NTLMv2» в разделе «Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности» не строится траст между win-доменом и samba-доменом. При включении этой политики после построения траста некорректно работают доверительные отношения между windows-доменом и samba-доменом. Не выполняется проверка траста (samba-tool domain trust validate) и не выполняется вход на пользователями из доверенного домена на машинах с winbind. Примечание: После редактирования политики и ее применения на win-домене необходимо перезапустить сервис samba.

Инструменты управления доверием:

Для управления доверием можно использовать инструмент командной строки samba-tool. ⁠

Настройка DNS

Служба DNS в Active Directory необходима для таких функций как:

1. Разрешение имен;
2. Обнаружение служб;
3. Обнаружение контроллеров домена;

Для управления службой DNS Samba поддерживает работу с двумя DNS-бэкендами:

• SAMBA_INTERNAL (—dns-backend=SAMBA_INTERNAL) — встроенный сервер имен:

  Поддерживает базовую функциональность, необходимую для работы AD;

  Используется по умолчанию при инициализации нового домена, а также при присоединении к существующему домену;

  Не поддерживает следующий функционал:

  • Роль кеширующего DNS-сервера (caching resolver);
  • Обработку рекурсивных запросов (но может пересылать их другому рекурсивному серверу DNS);
  • Аутентификацию DNS-транзакций с использованием общих ключей (TSIG);
  • Работу с зонами-заглушками (stub zones);
  • Балансировку нагрузки циклического перебора между контроллерами домена (Round Robin load balancing among DC’s);
  • Условную пересылку DNS-запросов (conditional DNS forwarding).

• BIND9_DLZ (—dns-backend=BIND9_DLZ) рекомендуется для настроек DNS, которые не поддерживаются внутренним DNS-сервером Samba.

Чтобы определить, какой вариант развертывания DNS-сервера выбрать, необходимо учесть следующие факторы:

• Необходимость условной пересылки DNS-запросов. Если не требуется — можно использовать встроенный сервер имен (SAMBA_INTERNAL). Если требуется и при этом нежелательно использовать выделенный DNS-сервер — DNS-сервер на основе BIND 9.
• Уже имеющаяся инфраструктура. В случае, если уже есть настроенные DNS-серверы, на которые могут быть возложены функции перенаправления, можно использовать выделенный DNS-сервер на основе BIND 9.

Пересылка — это механизм, который позволяет серверу направлять запросы на разрешение доменных имён на другие DNS-серверы, если он сам не может их обработать.

Пересылка настраивается в конфигурации DNS-сервера в файле /etc/bind/ddns.conf (или /etc/bind/options.conf):

options {
 forwarders { 8.8.8.8; };
};

При использовании доверительных отношений системы в одном домене должны уметь находить ресурсы и аутентифицировать пользователей из другого домена. Для этого им нужно корректно определять IP-адреса ресурсов другого домена. Однако, если один DNS-сервер не знает, как разрешить запросы для другого домена, запросы просто не смогут обрабатываться. Решением является условная пересылка, которая перенаправляет запросы для второго домена на соответствующий DNS-сервер.

Условная пересылка (conditional forwarding) — метод, который позволяет направлять запросы на разные серверы в зависимости от домена.

Указывается в файле /etc/bind/ddns.conf (или /etc/bind/options.conf):

zone "trust.dom" in {
 type forward;
 forwarders { 10.64.224.10; };
};

Доверительные отношения между Samba DC и Windows Server с Active Directory

Установка доверительных отношений будет продемонстрирована на примере между доменом Linux c Samba DC и доменом Windows с Active Directory со следующими характеристиками:

Samba DC

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

BIND9_DLZ

Для создания условной пересылки для службы DNS при использовании DNS бэкенда BIND9_DLZ необходимо добавить в конец файла /etc/bind/ddns.conf (или /etc/bind/options.conf) строки:

zone "win.dom" in {
 type forward;
 forwarders { 10.64.224.116; };
};

И перезапустить DNS-сервер BIND9:

# systemctl restart bind.service

# systemctl restart bind.service

SAMBA_INTERNAL

Если используется DC с DNS бэкенд SAMBA_INTERNAL, одним из способов заставить работать разрешение имен является настройка DNS-прокси между двумя доменами. DNS-прокси будет перенаправлять запрос между доменами и внешним DNS-серверами. В примере, в качестве DNS-прокси используется отдельно выделенный сервер (IP-адрес 10.64.224.105) с настроенным bind9.

На контроллере домена необходимо выполнить следующие действия:

1. Указать DNS-прокси, как сервер пересылки в файле /etc/samba/smb.conf (в параметре dns forwarder). Например:

    dns forwarder = 10.64.224.105 8.8.8.8
   

2. Перезапустить службу samba:

   # systemctl restart samba
   

На выделенном DNS-сервере:

1. Отредактировать файл /etc/bind/options.conf:

   Так как SAMBA_INTERNAL не имеет функционала расширения безопасности DNS, то необходимо отключить проверку DNSSEC, для этого в секцию options нужно добавить параметр:

   В конец файла /etc/bind/ddns.conf (или /etc/bind/options.conf) добавить информацию о зонах:

   zone "win.dom" in {
     type forward;
     forwarders { 10.64.224.116; };
   };
   

2. Перезапустить DNS-сервер BIND9:

   # systemctl restart bind.service
   

Windows Server с AD

На AD сервере необходимо создать сервер условной пересылки для зоны Samba домена.

В графическом интерфейсе:

1. Открыть Диспетчер DNS (DNS Manager).
2. В разделе Серверы условной пересылки (Conditional Forwarders) добавить новый сервер пересылки, указав FQDN или IP-адрес сервера Samba:

   

   Картинка с сайта: www.altlinux.org

3. Сохранить настройки.

В командной строке:

PS$ Add-DnsServerConditionalForwarderZone -Name test.alt -MasterServers 10.64.224.108 -ReplicationScope Forest

Проверка конфигурации DNS

На Samba DC:

1. DNS-записи, отвечающие за предоставление списка доступных серверов Kerberos и LDAP для домена test.alt:

   # dig +short -t SRV _kerberos._udp.test.alt
   0 100 88 dc1.test.alt.
   # dig +short -t SRV _ldap._tcp.test.alt
   0 100 389 dc1.test.alt.
   

2. DNS-записи, отвечающие за предоставление списка доступных серверов Kerberos и LDAP для домена win.dom:

   # dig +short -t SRV _kerberos._tcp.dc._msdcs.win.dom
   0 100 88 dc1.win.dom.
   # dig +short -t SRV _ldap._tcp.dc._msdcs.win.dom
   0 100 389 dc1.win.dom.
   

3. Возможность получения билета Kerberos для пользователей домена WIN.DOM:

   # kinit Администратор@WIN.DOM
   # klist
    Ticket cache: FILE:/tmp/krb5cc_500
    Default principal: Администратор@WIN.DOM
    
    Valid starting       Expires              Service principal
    09.09.2024 15:49:11  10.09.2024 01:49:11  krbtgt/WIN.DOM@WIN.DOM
    	renew until 10.09.2024 15:49:01
   

На Windows Server с AD:

1. Запуск утилиты nslookup.exe в режиме поиска SRV DNS-записей:

   C:\> nslookup.exe
   > set type=SRV
   

2. Получение DNS-записей типа SRV для служб, связанных с доменом test.alt:

   > _kerberos._udp.test.alt
    _kerberos._udp.test.alt       SRV service location:
    	priority                = 0
    	weight                  = 100
    	port                    = 88
    	svr hostname            = dc1.test.alt
    …
    test.alt
    	primary name server = dc1.test.alt
    	responsible mail addr = hostmaster.test.alt
    	serial = 7
    	refresh = 900 (15 mins)
    	retry = 600 (10 mins)
    	expire = 86400 (1 days)
    	default TTL = 3600 (1 hours)
   > _ldap._tcp.test.alt
    _ldap._tcp.test.alt       SRV service location:
    	priority                = 0
    	weight                  = 100
    	port                    = 389
    	svr hostname            = dc1.test.alt
   

Доверительные отношения между двумя доменами на основе Samba

Установка доверительных отношений будет продемонстрирована на примере между двумя доменами Linux со следующими характеристиками:

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

BIND9_DLZ

Чтобы создать условную пересылку для службы DNS, необходимо добавить информацию о зоне в конец файла /etc/bind/options.conf:

1. На контроллере домена dc1.test.alt добавить строки:

   zone "example.alt" {
     type forward;
     forwarders { 10.64.224.117; };
   };
   

2. На контроллере домена dc2.example.alt:

   zone "test.alt" {
     type forward;
     forwarders { 10.64.224.118; };
   };
   

3. Перезапустить службу DNS:

    # systemctl restart bind.service
   

   Примечание: Если удалённый DNS-сервер не использует DNSSEC и включить проверку DNSSEC на удаленном DNS-сервере нельзя, можно отключить проверку DNSSEC на сервере AD. Для этого необходимо в файле /etc/bind/options.conf в секцию options добавить параметр:

   И перезапустить службу DNS:

   # systemctl restart bind.service
   

SAMBA_INTERNAL

Если используется DC с DNS бэкенд SAMBA_INTERNAL, одним из способов заставить работать разрешение имен является настройка DNS-прокси между двумя доменами. DNS-прокси будет перенаправлять запрос между доменами и внешним DNS-серверами. В примере, в качестве DNS-прокси используется отдельно выделенный сервер (IP-адрес 192.168.0.150) с настроенным bind9.

На каждом контроллере домена необходимо:

1. Указать DNS-прокси, как сервер пересылки в файле /etc/samba/smb.conf (в параметре dns forwarder). Например:

   dns forwarder = 10.64.224.105 8.8.8.8
   

2. Перезапустить службу samba:

   # systemctl restart samba
   

На выделенном DNS-сервере отредактировать файл /etc/bind/options.conf:

1. Так как SAMBA_INTERNAL не имеет функционала расширения безопасности DNS, то необходимо отключить проверку DNSSEC, для этого в секцию options нужно добавить параметр:
2. В конец файла /etc/bind/options.conf (или /etc/bind/ddns.conf) добавить информацию о зонах:

   zone "example.alt" {
     type forward;
     forwarders { 10.64.224.117; };
   };
   zone "test.alt" {
     type forward;
     forwarders { 10.64.224.118; };
   };
   

3. Перезапустить службу DNS:

    # systemctl restart bind.service
   

Проверка конфигурации DNS

Для проверки настройки следует убедиться, что на обоих контроллерах домена разрешаются SRV-записи:

1. На контроллере домена dc1.test.alt:

   # host -t srv _kerberos._tcp.example.alt
   _kerberos._tcp.example.alt has SRV record 0 100 88 dc2.example.alt.
   # host -t srv _kerberos._tcp.test.alt
   _kerberos._tcp.test.alt has SRV record 0 100 88 dc1.test.alt.
   

2. На контроллере домена dc2.example.alt:

   # host -t srv _kerberos._tcp.example.alt
   _kerberos._tcp.test.alt has SRV record 0 100 88 dc2.example.alt.
   # host -t srv _kerberos._tcp.test.alt
   _kerberos._tcp.test.alt has SRV record 0 100 88 dc1.test.alt.
   

Проверка возможности получения билета Kerberos:

1. На контроллере домена dc1.test.alt:

   # kinit administrator@EXAMPLE.ALT
     Password for administrator@EXAMPLE.ALT:
   # klist
     Ticket cache: FILE:/tmp/krb5cc_0
     Default principal: administrator@EXAMPLE.ALT
    
     Valid starting       Expires              Service principal
     10.09.2024 16:48:51  11.09.2024 02:48:51  krbtgt/EXAMPLE.ALT@EXAMPLE.ALT
     	renew until 11.09.2024 16:48:47
   

2. На контроллере домена dc1.test.alt:

   # kinit administrator@TEST.ALT
     Password for administrator@TEST.ALT:
   # klist
     Ticket cache: KEYRING:persistent:0:0
     Default principal: administrator@TEST.ALT
    
     Valid starting       Expires              Service principal
     10.09.2024 14:02:21  11.09.2024 00:02:21  krbtgt/TEST.ALT@TEST.ALT
     	renew until 17.09.2024 14:02:17
   

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

Создание доверительного отношения

Перед тем как создавать доверительные отношения между доменами, важно правильно выбрать тип доверительных отношений в зависимости от ваших целей и архитектуры сети.

Доверительные отношения могут быть односторонние и двусторонние.

• Односторонние доверительные отношения (One-way trust): один домен доверяет другому, но не наоборот. Например, домен A доверяет домену B, что позволяет пользователям домена B получать доступ к ресурсам домена A, но пользователи домена A не могут получить доступ к ресурсам домена B.
• Двусторонние доверительные отношения (Two-way trust): оба домена доверяют друг другу, что позволяет пользователям в каждом домене получать доступ к ресурсам другого домена.

Домены в свою очередь становятся доверяющими или доверенными.

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

• Доверенный домен — домен, которому доверяет другой домен и пользователи которого могут получать доступ к ресурсам доверяющего домена

Транзитивные доверительные отношения — форма доверительных отношений между доменами, при которой доверие распространяется через несколько доменов, соединённых доверительными отношениями. Например, если домен A доверяет домену B, а домен B доверяет домену C, то благодаря транзитивности домен A также может доверять домену C.

Внешнее доверительное отношение (External Trust) — это нетранзитивное доверительное отношение между доменами напрямую вне леса, которое может быть как односторонним, так и двусторонним.

Доверие леса (Forest Trust) — это транзитивное доверительное отношение, которое может быть как односторонним, так и двусторонним. Создается при необходимости установить транзитивное доверие между двумя лесами доменов для обмена данными и доступом между всеми доменами в этих лесах. При данном режиме доверия пользователи из любого домена леса A могут обращаться к любому домену леса B и наоборот.

Между Samba DC и Windows Server с Active Directory

Windows Server с AD

В домене win.dom открываем «Диспетчер серверов», и выбираем «Средства» — «Active Directory — Домены и Доверие»:

Картинка с сайта: www.altlinux.org

В открывшемся окне в контекстном меню домена WIN.DOM необходимо выбрать «Свойства». Откроется окно свойств, в котором нужно перейти во вкладку «Отношения доверия» и нажать на «Создать отношение доверия»:

В открывшемся мастере создания отношения доверия вводим имя домена Samba DC. В данном случае TEST.ALT:

На следующей вкладке «Тип доверия» выбираем «Доверие леса»:

Далее во кладке «Направление отношения доверия» выбираем «Двухстороннее»:

В открывшемся окне «Стороны отношения доверия» необходимо выбрать, на каком из доменов будет применена настройка. В нашем случае у нас есть права администратора для обоих доменов, поэтому выбираем пункт «Для данного и указанного домена».

Если был выбран параметр «Только для данного домена», то необходимо будет задать Trust Secret Key, который в дальнейшем будет использоваться при создании доверительного отношения на стороне Samba DC.

На следующем этапе мастер свяжется с доменом TEST.ALT (если он доступен), и запросит логин и пароль от пользователя с правами установки доверительных отношений в домене TEST.ALT:

Далее на вкладке «Уровень проверки подлинности исходящего доверия — Локальный лес» выбираем «Проверка подлинности в лесу»:

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

После очередного нажатия на кнопку «Далее» мастер в окне «Выбор доверия завершен» выдаст уведомление о том, что готов создать новое отношение доверия, и покажет краткую сводку по выбранным параметрам. Соглашаемся с параметрами, после чего должно появиться уведомление о том, что создание доверия успешно завершено:

После нажатия на «Далее» появится окно «Подтверждение исходящего доверия», а после него «Подтверждение входящего отношения доверия». Здесь и в первом и во втором окне оставляем «Нет, не подтверждаю это исходящее/входящее отношение доверие», так как на стороне Samba DC доверие нами еще не создавалось:

Отношение доверия успешно создано:

Samba DC

Для создания доверительных отношений между доменами Samba и другими доменами используется команда:

# samba-tool domain trust create

Она позволяет установить как внешние доверительные отношения (external trust), так и отношения между лесами (forest trust).

Формат команды:

# samba-tool domain trust create <домен> --type=<тип доверия> --direction=<направление> --create-location=<место создания> -U <пользователь>

Аргументы команды и их описание:

1. <домен> — указывается имя удалённого домена, с которым создаётся доверие.
2. —type=<тип доверия>-определяет тип доверия:

   • external: используется для внешнего доверия между доменами, не находящимися в одном лесу. Рекомендуется, если вы используете SSSD для Linux-клиентов.
   • forest: используется для создания доверия между лесами доменов, включая все их дочерние домены. Рекомендуется, если вы используете Winbind для Linux-клиентов.

3. —direction=<направление> — определяет направление доверия:

   • incoming — доверие только со стороны удалённого домена к вашему.
   • outgoing — доверие только от вашего домена к удалённому.
   • both — двустороннее доверие.

4. —create-location — указывает место создания доверительного отношения.

   • local — объект доверенного домена будет создан только в локальном домене, доверительные отношения будут зарегистрированы и настроены только со стороны вашего домена, без внесения изменений в конфигурацию удаленного домена.
   • both — объект доверенного домена будет создан в обоих доменах.

5. -U <пользователь> — имя пользователя с правами администратора для удалённого домена.

В данном примере будет создано доверие леса на контроллере домена dc1.test.alt:

# samba-tool domain trust create win.dom --type=forest --direction=both --create-location=both  -U Администратор@WIN.DOM

При появлении запроса необходимо ввести пароль администратора.

Примечание: В случае использования Trust Secret Key в параметре –create-location нужно заменить опцию both на local. Samba DC прежде чем создать доверительные отношения сначала запросит Trust Key (Incoming Trust Password/Outgoing Trust Password), созданный ранее при настройке в Windows.

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

Проверка доверия с dc1.test.alt:

1. Вывод информации о доверительном отношении:

   # samba-tool domain trust show WIN.DOM
     LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3099202228-3607437695-3279060739]
     TrustedDomain:
    
     NetbiosName:    WIN-DOM
     DnsName:        win.dom
     SID:            S-1-5-21-3096440084-565096806-4224734732
     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[win.dom]:
     TLN: Status[Enabled]                  DNS[*.win.dom]
     DOM: Status[Enabled]                  DNS[win.dom] Netbios[WIN-DOM] SID[S-1-5-21-3096440084-565096806-4224734732]
   

2. Список трастов:

   # samba-tool domain trust list
    Type[Forest]   Transitive[Yes] Direction[BOTH]     Name[win.dom]
   

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

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

# samba-tool domain trust validate win.dom -U Администратор@WIN.DOM
 LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3099202228-3607437695-3279060739]
 LocalTDO Netbios[WIN-DOM] DNS[win.dom] SID[S-1-5-21-3096440084-565096806-4224734732]
 OK: LocalValidation: DC[\\DC2.win.dom] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
 OK: LocalRediscover: DC[\\DC2.win.dom] CONNECTION[WERR_OK]
 RemoteDC Netbios[DC2] DNS[DC2.win.dom] 				 	 
   ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,FULL_SECRET_DOMAIN_6,ADS_WEB_SERVICE,DS_8,DS_9]
 Password for [Администратор@WIN.DOM]:
 OK: RemoteValidation: DC[\\dc1.test.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
 OK: RemoteRediscover: DC[\\dc1.test.alt] CONNECTION[WERR_OK]

Проверка доверия с dc2.win.dom:

Проверку можно осуществить в свойствах домена WIN.DOM во вкладке «Отношения доверия».

Необходимо выбрать домен, который вы хотите проверить и нажать «Свойства»:

Для подтверждения или сброса состояния этого отношения доверия и для обновления его суффиксов маршрутизируемых имен необходимо нажать «Проверка»:

Между двумя доменами на основе Samba

Пример для входа в доверенный домен через Winbind:

На контроллере домена dc1.test.alt:

#  samba-tool domain trust create EXAMPLE.ALT --type=forest --direction=both --	create-location=both -U administrator@EXAMPLE.ALT
 LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3099202228-3607437695-3279060739]
 RemoteDC Netbios[DC2] DNS[dc2.example.alt]
 ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV,FULL_SECRET_DOMAIN_6]
 Password for [administrator@EXAMPLE.ALT]:
 RemoteDomain Netbios[EXAMPLE] DNS[example.alt] SID[S-1-5-21-2126352409-2047936676-1054754669]
 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[example.alt]:
 TLN: Status[Enabled]                  DNS[*.example.alt]
 DOM: Status[Enabled]                  DNS[example.alt] Netbios[EXAMPLE] SID[S-1-5-21-2126352409-2047936676-1054754669]
 Setup remote forest trust information...
 Namespaces[2] TDO[test.alt]:
 TLN: Status[Enabled]                  DNS[*.test.alt]
 DOM: Status[Enabled]                  DNS[test.alt] Netbios[TEST] SID[S-1-5-21-3099202228-3607437695-3279060739]
 Validating outgoing trust...
 OK: LocalValidation: DC[\\dc2.example.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
 Validating incoming trust...
 OK: RemoteValidation: DC[\\dc1.test.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
 Success.

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

1. Просмотр доверия с dc1.test.alt:

   [root@dc1 ~]# samba-tool domain trust show EXAMPLE.ALT
    LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3099202228-3607437695-3279060739]
    TrustedDomain:
    
    NetbiosName:    EXAMPLE
    DnsName:        example.alt
    SID:            S-1-5-21-2126352409-2047936676-1054754669
    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[example.alt]:
    TLN: Status[Enabled]                  DNS[*.example.alt]
    DOM: Status[Enabled]                  DNS[example.alt] Netbios[EXAMPLE] SID[S-1-5-21-2126352409-2047936676-1054754669]
   

2. Просмотр доверия с dc2.example.alt:

   [root@dc2 ~]# samba-tool domain trust show TEST.ALT
    LocalDomain Netbios[EXAMPLE] DNS[example.alt] SID[S-1-5-21-2126352409-2047936676-1054754669]
    TrustedDomain:
    
    NetbiosName:    TEST
    DnsName:        test.alt
    SID:            S-1-5-21-3099202228-3607437695-3279060739
    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[test.alt]:
    TLN: Status[Enabled]                  DNS[*.test.alt]
    DOM: Status[Enabled]                  DNS[test.alt] Netbios[TEST] SID[S-1-5-21-3099202228-3607437695-3279060739]
   

3. Список трастов:

   [root@dc1 ~]# samba-tool domain trust list
    Type[Forest]   Transitive[Yes] Direction[BOTH]     Name[example.alt]
   

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

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

[root@dc1 ~]# samba-tool domain trust validate EXAMPLE.ALT -Uadministrator@EXAMPLE.ALT
 LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3099202228-3607437695-3279060739]
 LocalTDO Netbios[EXAMPLE] DNS[example.alt] SID[S-1-5-21-2126352409-2047936676-1054754669]
 OK: LocalValidation: DC[\\dc2.example.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
 OK: LocalRediscover: DC[\\dc2.example.alt] CONNECTION[WERR_OK]
 RemoteDC Netbios[DC2] DNS[dc2.example.alt]
	ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV,FULL_SECRET_DOMAIN_6]
 Password for [administrator@EXAMPLE.ALT]:
 OK: RemoteValidation: DC[\\dc1.test.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
 OK: RemoteRediscover: DC[\\dc1.test.alt] CONNECTION[WERR_OK]

Управление пользователями и группами

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

Список пользователей и групп

C помощью команды wbinfo можно получить список пользователей и групп только из своего домена (нельзя получить список пользователей и групп из доверяющего домена). Пример получения списка пользователей:

• на контроллере домена dc1.test.alt:

  # wbinfo -u --domain=TEST.ALT
    TEST\administrator
    TEST\guest
    TEST\krbtgt
    TEST\dns-dc1
    TEST\ivanov
  

• на контроллере домена dc2.example.alt:

  # wbinfo -u --domain=EXAMPLE.ALT
    EXAMPLE\administrator
    EXAMPLE\guest
    EXAMPLE\krbtgt
    EXAMPLE\dns-dc2
    EXAMPLE\petrov
  

Для получения списка всех пользователей можно выполнить LDAP-запрос с помощью команды samba-tool. Пример получения списка пользователей из обоих доменов на контроллере домена dc1.test.alt:

samba-tool user list -H ldap://dc1 -Uadministrator@TEST.ALT
 Password for [administrator@TEST.ALT]:
 dns-dc1
 krbtgt
 Guest
 Administrator
 ivanov
samba-tool user list -H ldap://dc2 -Uadministrator@EXAMPLE.ALT
 Password for [administrator@EXAMPLE.ALT]:
 petrov
 Administrator
 krbtgt
 dns-dc2
 Guest

Получение дополнительной информации о доменах (в примере команды выполняются на контроллере домена dc1.test.alt):

1. Получение списка всех доменов, включая доверяющие и доверенные:

   # wbinfo --all-domains
    BUILTIN
    TEST
    EXAMPLE
   

2. Вывод основного домена(домен, к которому в данный момент подключена система):

   # wbinfo --own-domain
    TEST
   

3. Вывод списка доменов, которые находятся в состоянии доверия с текущим доменом:

   # wbinfo --trusted-domains
    BUILTIN
    TEST
    EXAMPLE
   

4. Отображение текущего состояния подключения winbind к различным доменам:

   # wbinfo --online-status
    BUILTIN : active connection
    TEST : active connection
    EXAMPLE : active connection
   

Получение SID пользователей и групп (в примере команды выполняются на контроллере домена dc1.test.alt):

# wbinfo -n TEST\\ivanov
 S-1-5-21-3099202228-3607437695-3279060739-1106 SID_USER (1)
 
# wbinfo -n EXAMPLE\\petrov
 S-1-5-21-2126352409-2047936676-1054754669-1105 SID_USER (1)
 
# wbinfo -n TEST\\office
 S-1-5-21-3099202228-3607437695-3279060739-1109 SID_DOM_GROUP (2)
 
# wbinfo -n EXAMPLE\\office2
 S-1-5-21-3274802069-598906262-3677769431-1107 SID_DOM_GROUP (2)
 
# wbinfo -i TEST\\ivanov
 TEST.ALT\ivanov:*:3000029:100::/home/TEST.ALT/ivanov:/bin/false
 
# wbinfo -i EXAMPLE\\petrov
 EXAMPLE\petrov:*:3000019:100::/home/EXAMPLE/petrov:/bin/false

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

Samba DC

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

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

Проверка методов аутентификации (в примере команды выполняются на контроллере домена dc1.test.alt):

# wbinfo -a TEST\\ivanov
 Enter TEST\ivanov's password:
 plaintext password authentication succeeded
 Enter TEST\ivanov's password:
 challenge/response password authentication succeeded
 
# wbinfo -a EXAMPLE\\petrov
 Enter EXAMPLE\petrov's password:
 plaintext password authentication succeeded
 Enter EXAMPLE\petrov's password:
 challenge/response password authentication succeeded

Посмотреть какие контроллеры домена отвечают за аутентификацию:

# wbinfo --ping-dc
 checking the NETLOGON for domain[TEST] dc connection to "dc1.test.alt" succeeded
 
# wbinfo --ping-dc --domain=EXAMPLE.ALT
 checking the NETLOGON for domain[EXAMPLE.ALT] dc connection to "dc2.example.alt" succeeded

Назначение пользователей и групп из доверенных доменов в группу доверяющего домена:

# wbinfo -n EXAMPLE\\petrov
 S-1-5-21-2126352409-2047936676-1054754669-1105 SID_USER (1)
 
# samba-tool group addmembers office S-1-5-21-2126352409-2047936676-1054754669-1105
 Added members to group office
 
# wbinfo -n EXAMPLE\\office2
 S-1-5-21-2126352409-2047936676-1054754669-1106 SID_DOM_GROUP (2)
 
# samba-tool group addmembers office S-1-5-21-2126352409-2047936676-1054754669-1106
 Added members to group office
 
# samba-tool group listmembers office
 S-1-5-21-2126352409-2047936676-1054754669-1105
 S-1-5-21-2126352409-2047936676-1054754669-1106

Windows Server

В модуле RSAT «Active Directory — пользователи и компьютеры» («Active Directory — Users and Computers») можно просмотреть список пользователей группы:

Для этого необходимо сменить домен:

Выбираем «Пользователи и компьютеры Active Directory» и через «Действие» или правую кнопку мыши «Сменить домен…»:

Картинка с сайта: www.altlinux.org

И просматриваем необходимую информацию:

Картинка с сайта: www.altlinux.org

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

Примечание: Если необходимо использовать пользователей из обоих доменов (установлены двухсторонние доверительные отношения с типом связи Лес), то рабочую станцию с ОС Альт следует вводить в домен с помощью Winbind см. Подключение к AD с помощью Samba Winbind.

Winbind

Важно правильно спланировать диапазоны идентификаторов (UID и GID), назначаемых пользователям и группам. Для чего это нужно и как это сделать, можно прочитать в статье IDMapping.

На машине, введённой в домен, необходимо в файле smb.conf установить ID-маппинг для обоих доменов.

Пример файла smb.conf на машине введённой в домен test.alt:

[global]
 security = ads
 realm = TEST.ALT
 workgroup = TEST
 netbios name = WS
 template shell = /bin/bash
 kerberos method = system keytab
 wins support = no
 winbind use default domain = yes
 winbind enum users = no
 winbind enum groups = no
 template homedir = /home/%D/%U
 winbind refresh tickets = yes
 winbind offline logon = yes
 idmap config * : range = 3000-7999
 idmap config * : backend = tdb

 idmap config TEST : backend = rid
 idmap config TEST : range = 10000-999999
 idmap config EXAMPLE : backend = rid
 idmap config EXAMPLE : range = 1000000-9999999

После перезапуска smb и winbind можно проверить, имеются ли доступные доверительные отношения между доменами:

# net rpc trustdom list -Uadministrator
 Password for [TEST\administrator]:
 Trusted domains list:
 
 EXAMPLE             S-1-5-21-2126352409-2047936676-1054754669
 
 Trusting domains list:
 
 EXAMPLE             S-1-5-21-3096440084-565096806-4224734732

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

# wbinfo -n TEST\\ivanov
 S-1-5-21-3099202228-3607437695-3279060739-1125 SID_USER (1)
# wbinfo -n EXAMPLE\\petrov
 S-1-5-21-2126352409-2047936676-1054754669-1105 SID_USER (1)
# wbinfo --online-status
 BUILTIN : active connection
 WS3 : active connection
 EXAMPLE : active connection
 TEST : no active connection

Для проверки доступности пользователей и групп из доверенных доменов, используйте команду getent:

# getent group TEST\\office
 office:*:11109:
  
# getent group EXAMPLE\\office2
 EXAMPLE\office2:*:1001106:
 
# getent passwd TEST\\ivanov
 ivanov:*:11125:10001:Иван Иванов:/home/TEST.ALT/ivanov:/bin/bash
 
# getent passwd EXAMPLE\\petrov
 EXAMPLE\petrov:*:1001105:1000513:Иван:/home/TEST.ALT/petrov:/bin/bash

Примечание: Для авторизации в доверенном домене следует вводить учётные данные пользователя в формате DOMAIN\user

SSSD

Особенности:

• SSSD требует ручного указания настроек для каждого трастового домена в клиентской конфигурации в файле /etc/sssd/sssd.conf.
• SSSD не поддерживает трасты уровня леса (Forest Trusts), что ограничивает его возможности при работе с многоуровневыми лесами доменов.
• По умолчанию пул UID/GID для сопоставления SID в SSSD имеет ограниченный размер. Для больших доменов с количеством пользователей более 200 тысяч этот пул необходимо расширять вручную. Подробности см. IDMapping.

На машине введённой в домен необходимо в файл /etc/sssd/sssd.conf добавить доверенный домен:

[domain/EXAMPLE.ALT/TEST.ALT]
use_fully_qualified_names = false

После перезапуска sssd можно проверить, есть ли возможность просматривать пользователей из обоих доменов:

# getent passwd ivanov
 ivanov:*:1855401105:1855400513:Иван Иванов:/home/TEST.ALT/ivanov:/bin/bash
# getent passwd kim

С помощью команды sssctl можно вывести все домены, с которыми готова взаимодействовать клиентская машина, а также их статусы:

# sssctl domain-list
 EXAMPLE.ALT
 TEST.ALT
# sssctl domain-status EXAMPLE.ALT
 Online status: Online

 Active servers:
 AD Global Catalog: dc2.example.alt
 AD Domain Controller: dc2.example.alt

 Discovered AD Global Catalog servers:
 - dc2.example.alt

 Discovered AD Domain Controller servers:
 - dc2.example.alt

Удаление доверия

На стороне Samba

Пример удаления доверия на контроллере домена dc1.test.alt:

# samba-tool domain trust delete EXAMPLE.ALT -U administrator@EXAMPLE.ALT
 LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3099202228-3607437695-3279060739]
 RemoteDC Netbios[DC2] DNS[dc2.example.alt]
 ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV,FULL_SECRET_DOMAIN_6]
 Password for [administrator@EXAMPLE.ALT]:
 RemoteDomain Netbios[EXAMPLE] DNS[example.alt] SID[S-1-5-21-2126352409-2047936676-1054754669]
 RemoteTDO deleted.

Проверка:

# samba-tool domain trust list

На стороне Windows Server с AD

1. Открыть Диспетчер серверов, выбрать Средства → Active Directory — Домены и Доверие:

Картинка с сайта: www.altlinux.org

2. В открывшемся окне в контекстном меню домена выбрать пункт Свойства:

Картинка с сайта: www.altlinux.org

Откроется окно свойств домена. Необходимо перейти во вкладку Отношения доверия:

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

4. В открывшемся окне выбрать где нужно удалить доверие и нажать кнопку ОК.

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

Ссылки

Trusts

Создание трастов. Виды и типы трастов.

Samba/InterdomainTrustRelationships

Установка доверительных отношений между Windows 2012R2 и SambaDC

Наличие доверительных отношений (trust) между доменами AD позволяют пользователям одного домена аутентифицироваться в другом домене. Чаще всего доверительные отношения настраиваются при объединении нескольких организации и при миграции между лесами AD.

Настроить доверительные отношения между только между корневыми доменами лесов Active Directory. В этом примере мы настроим двухсторонние доверительные отношения между независимыми лесами contoso.loc и test.loc

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

1. Откройте консоль DNS Manager (dnsmgmt.msc) в домене contoso.loc;
2. В консоли DNS выберите секцию Conditional Forwarding и создайте новое правило пересылке (New Conditional Forwarder);
3. Укажите имя второго домена (test.loc), IP адрес контроллера домена test.loc, включите опцию Store this conditional forwarder in Active Directory, and replicate it as follows и выберите All DNS servers in this domain;
   

   Картинка с сайта: vmblog.ru

4. Затем настройте аналогичную условную пересылку на DNS сервере домена test.loc (пересылку запросов для имени домена contoso.loc на IP адрес DC в этом домене).

После этого можно включить доверительные отношения.

1. Откройте консоль Active Directory Domains and Trusts (domain.msc);
2. Откройте свойства своего домена и перейдите на вкладку Trusts;
3. Нажмите New Trust;
4. Укажите имя леса, с которым вы хотите установить доверительные отношения (test.loc)
   

   Картинка с сайта: vmblog.ru

5. Далее нужно выбрать тип доверительных отношений. Доступно два типа доверия:

   External Trust (внешнее доверие) – прямое нетранзитивное доверие между доменами. Позволяет установить доверительные отношения только между корневыми доменами test.loc и contoso.loc

   Forest Trust – транзитивные доверительные отношения между лесами AD и всеми поддоменами в них.

   

   Картинка с сайта: vmblog.ru

6. Далее нужно выбрать направление доверия:

   Two – way — двухстороннее доверие между доменами;

   One – way: incoming –одностороннее доверие, при котором пользователи из домена A могут авторизовываться в домене B;

   One – way: outgoing –одностороннего доверия, при котором пользователи из домена B могут авторизовываться в домене A.

   

   Картинка с сайта: vmblog.ru

7. Затем нужно выбрать в каком домене нужно создать доверие:

   This domain only – создать доверите только в текущем домене;

   Both this domain and the specified domain – создать доверительную связь как в домена A, так и в B.

   

   Картинка с сайта: vmblog.ru

8. Мастер создания доверительных отношений запросит учетные данные пользователя из домена test.loc с правами администратора предпирятия.
9. Затем выберите тип аутентфикации пользователей из домена test.loc:

   Domain – wide authentication – разрешить пользователям аутентифицироваться на всех ресурсах вашего домена;

   Selective authentication – выбрать сервера, с которых пользователи домена test.loc могут аутентифицироваться в домене contoso.loc;

   

   Картинка с сайта: vmblog.ru

10. Затем нужно выбрать исходящие правила аутентфикации (для пользователей вашего домена)
11. Нажмите несколько раз Next -> Next и проверьте, что доверительные отношения между доменами созданы.

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

netdom trust contoso.loc /domain:test.loc /quarantine:No