Что такое доверительные отношения между доменами
Настройка доверительных отношений между доменами Active Directory
Для возможности аутентификации с использованием учетных записей из нескольких доменов, необходимо, чтобы были доверительные отношения между последними. При создании домена в структуре леса, доверие выстраивается автоматически. Но если мы хотим объединить два домена разных организаций или которые раньше работали независимо друг от друга, то необходимо настроить доверительные отношения.
Мы будем рассматривать процесс настройки на примере двустороннего транзитивного доверия между доменами 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
Открываем командную строку и вводим команду:
Мы должны получить ответ на подобие:
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: secondary.local
Address: 192.168.0.16
На DNS домена secondary.local
Действия, которые делаем на втором сервере DNS, во многом, аналогичны.
В командной строке второго сервера проверяем настройку:
Мы должны получить ответ на подобие:
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: primary.local
Address: 192.168.0.15
Настройка доверительных отношений
После настройки DNS можно переходить к созданию доверительных отношений.
В окне «Направление отношения доверия» выбираем Двустороннее:
. и нажимаем Далее.
В следующем окне выбираем, на каком из доменов мы применяем настройку — если у нас есть права администратора для обоих доменов, то выбираем Для данного и указанного доменов:
* если мы являемся администратором одного из доменов, а вторым доменом управляет другой специалист, то выбираем Только для данного домена. Подобные действия должен выполнить второй администратор в своем домене.
На следующем этапе система свяжется со вторым контроллером домена, и если он доступен, запросит логин и пароль от пользователя с правами установки доверительных отношений во втором домене. Вводим данные пользователя и нажимаем Далее.
Далее нужно выбрать «Уровень проверки подлинности исходящего доверия» — если оба домена принадлежат нашей организации, предпочтительнее выбрать Проверка подлинности в лесу, чтобы предоставить доступ ко всем ресурсам:
В окне «Подтверждение исходящего доверия» оставляем Нет, не подтверждаю это исходящее доверие, так как на другой стороне нами не создавалось доверия.
Тоже самое в окне «Подтверждение входящего доверия».
Нажимаем Готово — доверительные отношения созданы.
Атаки на трасты между доменами
Рано или поздно в ходе пентеста встает задача компрометации всего леса — при условии, что есть какие-либо права в одном из доменов. В такие моменты возникает куча вопросов о трастах, их свойствах и самих атаках. Попробуем во всем этом разобраться.
Доверие между доменами используется для прохождения аутентификации пользователей одного домена на контроллере другого домена. Иначе говоря, чтобы пользователи с домена А могли иметь доступ к ресурсам домена Б. Доменная структура может быть двух видов:
При создании дерева доменов между доменами по умолчанию устанавливаются транзитивные доверительные отношения. Все компьютеры имеют общие:
| № | Trust Type | Transitivity | Direction | Authentication Mechanism | Description |
| 1 | External | Non-transitive | One-way or two-way | NTLM Only | Устанавливаются между доменами, принадлежащими к разным лесам, либо c доменом Windows NT 4.0. |
| 2 | Realm | Transitive or non-transitive | One-way or two-way | Kerberos Only | Устанавливаются между Windows и не Windows доменами, использующими протокол Kerberos. Данный тип доверительных отношений может использоваться для обеспечения сквозной аутентификации на Windows и UNIX-системах. |
| 3 | Forest | Transitive | One-way or two-way | Kerberos or NTLM | Устанавливаются между лесами. При этом администраторы сами решают, какими будут отношения — двусторонними или односторонними. |
| 4 | Shortcut | Transitive | One-way or two-way | Kerberos or NTLM | Устанавливаются между доменами различных деревьев, принадлежащих к одному лесу. Используются для уменьшения пути доверия, тем самым повышая эффективность взаимодействия между двумя доменами. |
| 5 | Parent-Child | Transitive | Two-way | Kerberos or NTLM | Устанавливаются автоматически при создании в дереве нового домена. В рамках дерева доменов отношения описываются схемой Parent-Child. |
| 6 | Tree-Root Trust | Transitive | Two-way | Kerberos or NTLM | Устанавливаются автоматически при создании в существующем лесе нового дерева доменов. Фактически доверительные отношения устанавливаются между корневым доменом леса и создаваемым доменом, который будет являться корневым для нового дерева. |
Более наглядно типы доверий между доменами проиллюстрированы на картинке ниже.
Транзитивность (Transitivity)
Транзитивность нужна для определения доверия за пределами двух доменов, между которыми оно было сформировано, и используется для расширения отношений доверия с другими доменами. Если мы добавляем к домену дочерний домен, между родительским и дочерним доменами устанавливаются двусторонние доверительные отношения. Эти отношения транзитивны, т.е. если домен A доверяет домену D и домен D доверяет домену E, то домен A доверяет и домену E.
Нетранзитивное доверие можно использовать для отказа доверия с другими доменами.
Направление (Direction)
Путь доверительных отношений — это ряд доверительных отношений между доменами, к которому должны поступать запросы на проверку подлинности. Иными словами, прежде чем аутентифицировать пользователя, определяется доверие между доменами. Чтобы пользователи домена A могли получить доступ к ресурсам домена D, домен D должен доверять домену A.
Направление доверия бывает двух типов:
Двустороннее доверие — это комбинация двух однонаправленных доверительных отношений. В двунаправленном доверии между доменами A и B их пользователи имеют доступ к ресурсам обоих доменов. Такой тип доверия транзитивен.
Направление доверия всегда противоположно направлению доступа. Показательная схема от Microsoft ниже:
Ссылки для более глубокого ознакомления с типами доверий:
Kerberos между доверенными доменами
Рассмотрим пример. Client пытается получить доступ к Server.
Изменения начинаются с пункта 4: появляется inter-realm TGT-тикет, так называемый реферальный тикет, который шифруется/подписывается inter-realm ключом, создаваемым из доверенного пароля. Доверенный пароль задается при установке доверительных отношений и известен обоим контроллерам домена. Используя inter-realm TGT-тикет, пользователь домена 1 может запросить TGS-тикет для доступа к ресурсам домена 2.
NTLM между доверенными доменами
Атаки на трасты между доменами
Итак, для проведения атаки нам потребуется информация о доверительных отношениях в нашем домене.
Перечисление трастов
Существует 3 основных метода для перечисления трастов в домене:
Перечисление осуществляется с помощью вызова функции DsEnumerateDomainTrusts, которая возвращает структуру DS_DOMAIN_TRUSTSA. При использовании данного метода возвращается SID и GUID целевого домена, флаги и атрибуты, характеризующие текущие доверительные отношения в домене.
| DS_DOMAIN_DIRECT_INBOUND | Enumerate domains that directly trust the domain which has ServerName as a member. |
| DS_DOMAIN_DIRECT_OUTBOUND | Enumerate domains directly trusted by the domain which has ServerName as a member. |
| DS_DOMAIN_IN_FOREST | Enumerate domains that are a member of the same forest which has ServerName as a member. |
| DS_DOMAIN_NATIVE_MODE | Enumerate domains where the primary domain is running in Windows 2000 native mode. |
| DS_DOMAIN_PRIMARY | Enumerate domains that are the primary domain of the domain which has ServerName as a member. |
| DS_DOMAIN_TREE_ROOT | Enumerate domains that are at the root of the forest which has ServerName as a member. |
| TRUST_ATTRIBUTE_NON_TRANSITIVE | Disallow transitivity. |
| TRUST_ATTRIBUTE_UPLEVEL_ONLY | The trust link is not valid for client operating systems earlier than Windows 2000. |
| TRUST_ATTRIBUTE_FILTER_SIDS | Quarantine domains. |
| TRUST_ATTRIBUTE_FOREST_TRANSITIVE | The trust link may contain forest trust information. |
| TRUST_ATTRIBUTE_CROSS_ORGANIZATION | This trust is to a domain/forest that is not part of this enterprise. |
| TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL | Trust is treated as external for trust boundary purposes. |
| TRUST_ATTRIBUTE_WITHIN_FOREST | Trust is internal to this forest. |
BloodHound собирает информацию с помощью метода Win32 API.
Используется метод GetCurrentDomainиз пространства имен [System.DirectoryServices.ActiveDirectory.Domain], который возвращает экземпляр класса System.DirectoryServices.ActiveDirectory.Domain. В этом классе реализован метод GetAllTrustRelationships, который возвращает все доверительные отношения для текущего домена.
Использование данного метода реализовано в модуле Get-DomainTrust в PowerView.
Одним из преимуществ этого метода является его простота. Информацию легко читать и понимать, но ее объем значительно меньше, чем при выполнении перечисления другими методами.
Информация о доверительных отношениях домена хранится в Active Directory как objectClass класса trustedDomain.
PowerView по умолчанию использует данный метод.
Имея информацию о доменах и типах доверия, можно переходить непосредственно к самой атаке. Рассмотрим 2 варианта:
С правами администратора одного из доменов
В зависимости от домена, который был скомпрометирован, можно выделить несколько векторов атак:
| № | Стартовый домен. Позиция атакующего | Атакуемый домен | Техника атаки | Доверительные отношения |
| 1 | Root | Child | Golden Ticket + Enterprise Admin Group | Inter-realm (2-way) |
| 2 | Child | Child | Эксплуатация SID History | Inter-realm Parent-Child (2-way) |
| 3 | Child | Root | Эксплуатация SID History Эксплуатация билетов доверия | Inter-realm Tree-Root(2-way) |
| 4 | Forest 1 | Forest 2 | Printer Bug | Inter-realm Forest or External trust (2-way) |
Стоит отметить, что для успешной реализации всех векторов необходимо двустороннее доверие между доменами.
1. Эксплуатация SID History
SID History был введен для облегчения миграции пользователей из одного домена в другой. Атрибут cодержит в себе предыдущие SID объекты. Каждый раз, когда объект перемещается из одного домена в другой, создается новый SID, который становится objectSID. Предыдущий SID добавляется в свойство sIDHistory.
В каждом лесу есть группа пользователей Enterprise Admins, которая существует только в root-домене и имеет права локального администратора на контроллерах домена всех Child-доменов леса. Впервые данная атака был продемонстрирована Sean Metcalf на BlackHat USA 2015. Суть атаки в том, что мы выпускаем Golden-тикет с добавлением дополнительного SID группы Enterprise Admins. Это выполняется путем добавления ExtraSids в структуре KERB_SID_AND_ATTRIBUTES, которая отправляется в структуре KERB_VALIDATION_INFO.
В impacket есть скрипт, который все это автоматизирует.
2. Golden Ticket + Enterprise Admin Group
Имея права администратора в Root-домене, мы можем создать Golden Ticket с добавлением пользователя в группу Enterprise Admins (519).
Как было написано выше, Enterprise Admin имеет права локального администратора на DC Child-доменов. Таким образом нам удастся скомпрометировать в лесу все Child-домены.
3. Эксплуатация билетов доверия
Атака особенно актуальна, когда служба ИБ заметила угрозу и сменила пароль krbtgt 2 раза. В этом случае мы сможем создавать golden-тикеты, используя доверенный пароль между доменами.
4. Printer Bug
В Windows Print System Remote Protocol (MS-RPRN) есть метод RpcRemoteFindFirstPrinterChangeNotification(Ex), включенный по умолчанию, который позволяет принудительно выполнить аутентификацию на любом компьютере с запущенной службой Spooler на указанном хосте по протоколу Kerberos либо NTLM. В случае c NTLM мы можем выполнить NTLM-relay, либо начать брутить пароль компьютера (никогда не сбрутите). В случае с Kerberos необходима скомпрометированная машина с неограниченным делегированием. Тогда мы сможем забрать TGT-тикет и развить атаку.
Рисунок ниже демонстрирует этапы, показанные на видео.
У нас нет прав администратора домена
Немного теории. Carlos Garsia в своем докладе привел отличную таблицу, которая иллюстрирует свойства разных типов групп.
Because of the way that groups are enumerated by the Global Catalog, the results of a back-link [i.e. memb search can vary, depending on whether you search the Global Catalog (port 3268) or the domain (port 389), the kind of groups the user belongs to (global groups vs. domain local groups).
1. Пользователи другого домена, которые имеют права локального администратора на машинах в нашем домене
Поиск пользователей из другого домена, являющихся локальными администраторами на хостах в нашем домене в BloodHound:
2. Пользователи из других доменов, состоящие в группах домена пользователя. Группы, содержащие пользователей из другого домена
Как уже говорилось выше, в глобальный каталог реплицируются пользователи, состоящие только в группах типа Universal. Для демонстрации этой особенности выполним запрос групп в глобальном каталоге, содержащих хотя бы одного пользователя и прямой ldap-запрос к контроллеру домена.
При выполнении запроса к глобальному каталогу, мы видим только одну группу Universal Group c типом AD Universal из домена one.jet.lab.
Если мы выполним прямой LDAP-запрос к домену one.jet.lab, то увидим другие группы с типом AD Domain local и AD Global.
Это важно учитывать при выполнении перечисления пользователей и групп.
Заметки системного администратора Windows Server
Поиск по этому блогу
Active Directory. Понимание доверительных отношений.
Многие предприятия имеют в своей сети несколько доменов Windows. Доверительные отношения между ними порой очень сложны, особенно в случае иерархических структур Active Directory. Я вам расскажу о функционировании доверительных отношений, о способах их установления, а также о том, какая базовая информация для этого необходима.
Доверительные отношения в Active Directory еще важнее, чем в NT 4.0. При создании доменов в «лесу доменов» такие отношения устанавливаются автоматически, но, в отличие от NT 4.0, они «транзитивны». Это важное понятие мы разъясним ниже. Кстати, Windows Server 2008 хоть и предлагает множество новинок, но доверительные отношения по-прежнему действуют так же, как в Windows Server 2003.
Для большинства администраторов процесс установления доверительных отношений все еще требует привыкания, поскольку отдельные понятия немного запутаны. В результате в техническом плане возможность связи доменов Windows друг с другом представляется более «загадочной», чем есть на самом деле.
Поэтому сначала остановимся на основных понятиях.
В Active Directory существует два различных вида доверительных отношений: «однонаправленные» и «двунаправленные». В первом случае один домен доверяет другому, но не наоборот. Пользователи Домена 1 могут получить доступ к ресурсам Домена 2, однако у пользователей Домена 2 нет доступа к ресурсам Домена 1. Естественно, возможен и обратный случай. Другие варианты доверительных отношений: «исходящие» и «входящие». При исходящих доверительных отношениях Домен 1 доверяет Домену 2, т. е. пользователи Домена 2 могут обращаться к ресурсам Домена 1.
При таком процессе домен, от которого доверительные отношения исходят, является доверяющим доменом (Trusting Domain). Домен с входящими доверительными отношениями — доверенный домен (Trusted Domain), в нем создаются учетные записи пользователей, обладающих правами в доверяющем домене.
В Windows NT 4.0 тоже можно было устанавливать доверительные отношения, но не транзитивные. Если в Windows NT 4.0 создавались доверительные отношения между доменами А и В, а также между доменами В и С, то это не значило, что домен А автоматически будет доверять домену С или, наоборот, домен С — домену А. Эту связь приходилось устанавливать вручную. В Active Directory делается иначе. Домены можно связывать практически без ограничений через домены, дочерние домены и деревья с автоматическим установлением между ними доверительных отношений. В Active Directory каждый домен доверяет любому другому домену, если является частью того же леса. Устанавливать доверительные отношения вручную возможно, но необходимости в этом уже нет (ключевая фраза: урезанные доверительные отношения).
В отдельном лесу существует определенный регулирующий алгоритм: доверительные отношения автоматически создаются между выше- и ниже-стоящими доменами. Microsoft обозначает этот тип как «подчиненные доверительные отношения». Кроме того, доверительные отношения автоматически создаются между корневыми доменами отдельных деревьев. Однако доверительных отношений между подчиненными доменами различных деревьев не существует. Они доверяют друг другу на основе транзитивных доверительных отношений.
Доверительные отношения между корневыми доменами различных лесов называются «доверительными отношениями между лесами» (Forest Trust).
Как уже говорилось, дополнительные доверительные отношения можно определять и вручную. Это требуется по различным причинам. Так, возможны, к примеру, внешние доверительные отношения к доменам Windows NT 4.0 или отдельным доменам другого леса.
В Windows Server 2003 появились сохранившиеся в Windows Server 2008 доверительные отношения между лесами, когда связываются корневые домены двух различных лесов. В результате все домены обеих структур связаны автоматически транзитивными доверительными отношениями. Доверительные отношения можно создавать между подчиненными доменами разных деревьев в пределах одного леса. Они называются «прямыми доверительными отношениями» (Shortcut Trusts). Этот вид доверительных отношений часто используется, чтобы ускорить доступ к ресурсам между подчиненными доменами различных деревьев в одном лесу.
При создании нескольких деревьев в одном лесу особое значение имеет путь доверительных отношений. Поскольку доверительные отношения между подчиненными доменами разных деревьев не создаются, при доступе к ресурсам может потребоваться оптимизация аутентификации. При попытке обратиться к данным, находящимся в подчиненных доменах разных деревьев, аутентификация должна пройти путь до корневого домена собственного дерева, затем до корневого домена другого дерева и, наконец, к подчиненному домену. Для ускорения этого процесса можно вручную установить доверительные отношения между двумя подчиненными доменами.
Управление доверительными отношениями осуществляется с помощью дополнительного модуля (Snap-in) «Домены Active Directory и доверительные отношения». Если вызвать в нем свойства какого-либо домена, то на соответствующей вкладке можно найти все его доверительные отношения и задать новые. Если требуется создать доверительное отношение с внешним доменом, то сначала нужно убедиться в том, что распознавание имен между доменами осуществляется без ошибок. Лишь когда обеспечено стабильное и надежное разрешение имен, можно устанавливать доверительные отношения. Здесь будет полезна оптимальная инфраструктура серверов DNS/WINS. Дело в том, что если нужно создать доверительные отношения с доменом Windows NT 4.0, то сервер WINS подходит лучше, чем DNS. В принципе, связь между доменом Windows NT 4.0 и доменом Active Directory можно установить и без WINS, но она будет нестабильной и сложно реализуемой.
Чтобы создать доверительные отношения, в дополнительном модуле «Домены Active Directory и доверительные отношения» необходимо вызвать свойства того домена, от которого они должны исходить. Во вкладке «Доверительные отношения» нужно нажать на кнопку «Новое доверительное отношение». Windows запускает ассистента. На второй странице отображается имя домена, к которому будет устанавливаться доверительное отношение. Если это домен Active Directory, то следует использовать имя DNS, в то время как для соединения с доменом Windows NT 4.0 лучшим выбором будет имя NetBIOS. Затем ассистент проверяет, возможна ли связь с доменом и должны ли доверительные отношения быть однонаправленными или двунаправленными.
При двунаправленном соединении пользователи каждого из доменов могут аутентифицироваться в другом домене для получения доступа к ресурсам. При выборе «Однонаправленные: входящие» устанавливается, что данный домен является доверенным,
т. е. пользователь этого домена может аутентифицироваться в другом домене и обращаться к его ресурсам. В варианте «Однонаправленные: исходящие» пользователи другого домена могут регистрироваться в нем, а вот пользователи этого домена в другом — нет.
Затем определяется область аутентификации доверительных отношений. Большинство администраторов используют вариант «Общедоменная аутентификация». При этом пользователи одного домена получают доступ к ресурсам другого через групповое членство или прямое разрешение. Если же выбирается вариант «Избирательная аутентификация», то для каждого сервера, к которому разрешен доступ пользователей другого домена, в локальных настройках безопасности или правилах должна активироваться опция «Может аутентифицировать». Такая настройка повышает безопасность, но одновременно усложняется структура распределения прав. Пользователям другого домена автоматически отказывается в доступе к отдельным серверам предприятия.
Теперь следует отменить отказ для каждого отдельного сервера, а затем установить пароль для доверительных отношений, который позднее потребуется для верификации и установления доверительных отношений в другом направлении. В следующем окне нужно выбрать, будет ли доверительное отношение проверяться. При создании доверительных отношений с доменом Windows NT 4.0 необходимо сначала установить их со стороны этого домена. Пользователи получают доступ к ресурсам лишь после верификации доверительных отношений как активных. Если создание доверительных отношений не удается, то обычно это происходит из-за проблем с разрешением имен или наличием прав.
ФИЛЬТРАЦИЯ SID В ДОВЕРИТЕЛЬНЫХ ОТНОШЕНИЯХ
После завершения установления внеш-них доверительных отношений автоматически высвечивается указание, что для этих отношений был активирован фильтр идентификаторов пользователей (SID). Это происходит автоматически, если доверительные отношения создаются контроллером домена под управлением Windows Server 2003 или Windows Server 2000 (SP4 и выше). Фильтрация SID защищает исходящие доверительные отношения. Она призвана воспрепятствовать раздаче администраторами доверенных доменов неправомерных полномочий в пределах доверяющих доменов. Фильтр SID следит за тем, чтобы в доверяющем домене аутентифицировались только те пользователи доверенного домена, чьи SID содержат SID этого домена. Если деактивировать фильтрацию SID, то внешний пользователь, обладающий правами администратора в доверенном домене, сможет прослушать сетевой трафик доверяющего домена, определить SID администратора, а затем присоединить этот SID к своей истории SID и заполучить права администратора в доверяющем домене.
Однако при активации фильтра SID может случиться так, что будет игнорироваться история SID пользователей, получивших ее из других доменов в результате миграции. Тогда возникнут проблемы с аутентификацией при доступе к ресурсам, поэтому фильтр SID не всегда можно использовать. Если фильтр применяется для укрепления доверительных отношений Windows NT 4.0, то здесь проблемы возникают реже, чем при построении внешних доверительных отношений к домену в Active Directory. Если универсальной группе из Active Directory доверенного домена выдаются разрешения на ресурсы доверяющего домена, то нужно убедиться в том, что эта группа была создана именно в доверенном домене, а не в каком-либо другом домене Active Directory. В противном случае она не содержит SID доверенного домена, и фильтр SID не разрешит доступ к ресурсам доверяющего домена.
Иногда возникают проблемы с установлением доверительных отношений. Виной тому — ошибочное распознавание имен, защищенные маршрутизаторы между различными подсетями или ошибки на серверах WINS. Если не получается создать доверительные отношения между двумя контроллерами доменов, то часто помогает создание файла lmhosts на обоих серверах. Этот файл находится в папке Windows/system32/drivers/etc. Для обеспечения распознавания имен файл нужно переименовать в lmhosts без расширения. В указанном файле настраивается разрешение доменов, так что серверы DNS или WINS будут пропускаться. Для этого нужно добавить в файл следующие строки:
При создании доверительных отношений между корневыми доменами двух лесов можно выбрать опцию «доверительные отношения между лесами». Ее преимущество заключается в том, что все подчиненные домены всех деревьев в задействованных лесах сразу же начинают транзитивно доверять друг другу. Для доверительных отношений между лесами должны быть соблюдены некоторые предпосылки: такой тип отношений поддерживается только в лесах Windows Server 2003/2008. Кроме того, важно, чтобы функциональные уровни домена и леса находились в однородном режиме Windows Server 2003 или 2008. Естественно, между лесами должно функционировать разрешение имен. Специфическую для доменов переадресацию лучше всего создавать на отдельных серверах DNS лесов.
Создание доверительных отношений между лесами идентично созданию доверительных отношений других типов. Для них точно так же можно установить, будут ли отношения одно- или двунаправленные, а кроме того, предоставить права отдельным доменам или всему лесу. Если в лесах используется несколько деревьев, то можно определить, какие диапазоны имен, а следовательно, и деревья, смогут пользоваться установленными доверительными отношениями. Но имена NetBIOS и DNS отдельных доменов должны быть разными. Если в лесах встречаются совпадающие имена NetBIOS или DNS, то эти домены взаимно лишаются доступа к ресурсам другого леса. Для управления различными деревьями в свойствах доверительных отношений используется вкладка «Маршрутизация суффиксов имен».