Поделиться через

Как работают отношения доверия для лесов в Active Directory (предварительная версия)

  • Статья

Доменные службы Active Directory (AD DS) обеспечивают безопасность между несколькими доменами или лесами с помощью отношений доверия между доменами и лесами. Перед тем как проверка подлинности может произойти через доверительные отношения, Windows должна сначала проверить, имеет ли запрашиваемый домен доверительное отношение с доменом учетной записи, делающей запрос.

Чтобы проверить эту связь доверия, система безопасности Windows вычисляет путь доверия между контроллером домена (DC) для сервера, получающего запрос и контроллер домена в домене запрашивающей учетной записи.

Механизмы управления доступом, предоставляемые AD DS и распределенной моделью безопасности Windows, обеспечивают среду для функционирования отношений доверия на уровне домена и леса. Для правильной работы этих доверительных отношений каждый ресурс или компьютер должен иметь прямой путь доверия к контроллеру домена в том домене, в котором он расположен.

Служба Net Logon реализует путь доверия с помощью аутентифицированного подключения удаленного вызова процедуры (RPC) к доверенному доменному органу. Защищенный канал также распространяется на другие домены AD DS через отношения доверия между доменами. Этот защищенный канал используется для получения и проверки сведений о безопасности, включая идентификаторы безопасности (SID) для пользователей и групп.

Заметка

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

Общие сведения о том, как отношения доверия применяются к доменным службам, см. в разделе «Понятия и функции леса».

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

Потоки отношений доверия

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

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

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

схема отношений доверия между двумя лесами

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

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

Одностороннее доверие — это однонаправленный путь аутентификации, созданный между двумя доменами. Односторонняя связь между доменом A и доменом B, пользователи в домене A могут получить доступ к ресурсам в домене B. Однако пользователи в домене B не могут получить доступ к ресурсам в домене A.

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

В двустороннем доверии домен A доверяет домену B и домен B доверяет домену A. Эта конфигурация означает, что запросы проверки подлинности могут передаваться между двумя доменами в обоих направлениях. Некоторые двусторонние отношения могут быть не транзитивными или транзитивными в зависимости от типа создаваемого доверия.

Все отношения доверия домена в локальном лесу AD DS представляют собой двустороннее транзитивное доверие. При создании нового дочернего домена автоматически создается транзитивное доверие между новым дочерним доменом и родительским доменом.

Транзитивные и не транзитивные отношения доверия

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

  • Транзитивное доверие можно использовать для расширения отношений доверия с другими доменами.
  • Не транзитивное доверие можно использовать для запрета отношений доверия с другими доменами.

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

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

Лесные трасты

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

С помощью доверительных отношений между лесами можно связать два разных леса, чтобы сформировать одностороннюю или двустороннюю транзитивную связь доверия. Доверие к лесу позволяет администраторам подключать два леса AD DS с одной связью доверия для обеспечения простой проверки подлинности и авторизации в лесах.

Доверие к лесу можно создать только между корневым доменом леса в одном лесу и корневом домене леса в другом лесу. Доверительные отношения лесов могут быть установлены только между двумя лесами и не могут быть неявно распространены на третий лес. Это означает, что если доверие между лесами создается между лесом 1 и лесом 2, и еще одно доверие создается между лесом 2 и лесом 3, лес 1 не обладает неявным доверием с лес 3.

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

схема отношений доверия леса в рамках одной организации

В этом примере конфигурации предоставляется следующий доступ:

  • Пользователи в лесу 2 могут получать доступ к ресурсам в любом домене в лесу 1 или лесу 3
  • Пользователи в лесу 3 могут получить доступ к ресурсам в любом домене леса 2
  • Пользователи в лесу 1 могут получить доступ к ресурсам в любом домене в лесу 2

Эта конфигурация не позволяет пользователям в Лесу 1 получать доступ к ресурсам в Лесу 3 или наоборот. Чтобы пользователи в Лесу 1 и Лесу 3 могли совместно использовать ресурсы, необходимо создать двустороннее транзитивное доверие между двумя лесами.

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

Например, когда создается одностороннее доверительное отношение между лесами Лесом 1 (доверенный лес) и Лесом 2 (доверяющий лес):

  • Члены Forest 1 могут получить доступ к ресурсам, расположенным в Forest 2 .
  • Члены лес 2 не могут получить доступ к ресурсам, расположенным в лес 1, используя ту же доверенность.

Важный

Доменные службы Microsoft Entra поддерживают несколько направлений для доверия лесов.

Требования к доверию леса

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

  • Один корневой DNS-сервер обслуживает оба пространства имен DNS леса. Корневая зона содержит делегирования для каждого из пространств имен DNS, а в корневых подсказках всех DNS-серверов фигурирует этот корневой DNS-сервер.

  • Когда отсутствует общий корневой DNS-сервер, и корневые DNS-серверы в каждом лесу DNS-пространства имен используют условные пересылатели DNS для маршрутизации запросов имен в другом пространстве имен.

    Важный

    Любой лес доменных служб Microsoft Entra с доверием должен использовать эту конфигурацию DNS. Размещение пространства имен DNS, отличного от пространства имен DNS леса, не является функцией доменных служб Microsoft Entra. Условные пересылки — это правильная конфигурация.

  • Если нет общего корневого DNS-сервера, и корневые DNS-серверы в каждом пространстве имен леса используют вторичные зоны DNS, то в каждом пространстве имен DNS настраиваются вторичные зоны для маршрутизации запросов к именам в другом пространстве имен.

Чтобы создать доверие леса в AD DS, необходимо быть членом группы администраторов домена (в корневом домене леса) или группой администраторов предприятия в Active Directory. Каждому доверию присваивается пароль, который должны знать администраторы в обоих лесах. Администраторы предприятия в обоих лесах могут одновременно создавать доверительные отношения, и в этом сценарии для обоих лесов автоматически создается и записывается криптографически случайный пароль.

Лес управляемого домена поддерживает до пяти односторонних исходящих доверительных отношений с локальными лесами. Доверие к исходящему лесу для доменных служб Microsoft Entra создается в Центре администрирования Microsoft Entra. Пользователь с привилегиями, ранее отмеченными в локальной среде Active Directory, должен настроить доверие входящего леса.

Отношения доверия и взаимодействия

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

Обзор обработки ссылок на проверку подлинности

Когда запрос на проверку подлинности ссылается на домен, контроллер домена в этом домене должен определить, существует ли отношение доверия с доменом, из которого поступает запрос. Направление доверия и то, является ли доверие транзитивным или нетранстивным, также необходимо определить, прежде чем он проходит проверку подлинности пользователя для доступа к ресурсам в домене. Процесс проверки подлинности, происходящий между доверенными доменами, зависит от используемого протокола проверки подлинности. Протоколы Kerberos V5 и NTLM по-разному обрабатывают перенаправления для аутентификации в домен.

Обработка перенаправлений в Kerberos версии 5

Протокол проверки подлинности Kerberos версии 5 зависит от службы net Logon на контроллерах домена для проверки подлинности и авторизации клиента. Протокол Kerberos подключается к центру распространения ключей в Сети (KDC) и хранилищу учетных записей Active Directory для билетов на сеанс.

Протокол Kerberos также использует доверительные отношения для служб выдачи билетов между областями (TGS) и проверки подлинности сертификатов атрибутов привилегий (PACs) по защищенному каналу. Протокол Kerberos выполняет проверку подлинности в нескольких областях только с областями Kerberos не на операционной системе Windows, такими как область Kerberos MIT, и не требует взаимодействия со службой Net Logon.

Если клиент использует Kerberos V5 для проверки подлинности, он запрашивает запрос на сервер в целевом домене из контроллера домена в домене учетной записи. KDC Kerberos выступает в качестве доверенного посредника между клиентом и сервером и предоставляет ключ сеанса, который позволяет двум сторонам проходить проверку подлинности друг друга. Если целевой домен отличается от текущего домена, KDC следует логическому процессу, чтобы определить, можно ли ссылаться на запрос проверки подлинности:

  1. Является ли текущий домен напрямую доверенным доменом сервера, у которого осуществляется запрос?

    • Если да, отправьте клиенту ссылку на запрошенный домен.
    • Если нет, перейдите к следующему шагу.

  2. Существует ли транзитивное отношение доверия между текущим доменом и следующим доменом в пути доверия?

    • Если да, отправьте клиенту ссылку на следующий домен в пути доверия.
    • Если нет, отправьте клиенту сообщение об отказе в входе.

Обработка перенаправлений NTLM

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

Если клиент использует NTLM для проверки подлинности, первоначальный запрос проверки подлинности передается непосредственно от клиента к серверу ресурсов в целевом домене. Этот сервер создает вызов, на который отвечает клиент. Затем сервер отправляет ответ пользователя на контроллер домена в домене учетной записи компьютера. Этот контроллер домена проверяет учетную запись пользователя в базе данных учетных записей безопасности.

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

  1. Имеет ли текущий домен прямую связь доверия с доменом пользователя?

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

  2. Имеет ли текущий домен транзитивное отношение доверия с доменом пользователя?

    • Если да, передайте запрос проверки подлинности на следующий домен в пути доверия. Этот контроллер домена повторяет процесс, проверяя учетные данные пользователя в собственной базе данных учетных записей безопасности.
    • Если нет, отправьте клиенту сообщение об отказе в входе.

Обработка запросов проверки подлинности на основе Kerberos через доверительные отношения между лесами

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

При первоначальном установлении доверительных отношений между лесами каждый лес собирает все доверенные пространства имен в лесу-партнере и сохраняет сведения в объекте доверенного домена . Доверенные пространства имен включают имена дерева доменов, суффиксы имени пользователя (UPN), суффиксы имени субъекта-службы (SPN) и пространства имен идентификатора безопасности (SID), используемые в другом лесу Active Directory. Объекты TDO реплицируются в глобальный каталог.

Заметка

Альтернативные суффиксы UPN для доверенные отношения не поддерживаются. Если локальный домен использует тот же UPN-суффикс, что и доменные службы, вход должен использовать sAMAccountName.

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

  • DNS-имя узла.
  • DNS-имя домена.
  • Различающееся имя объекта точки подключения службы.

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

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

схема процесса Kerberos по доверию леса

  1. User1 вошел в Workstation1 с помощью учетных данных домена europe.tailspintoys.com. Затем пользователь пытается получить доступ к общему ресурсу на FileServer1, расположенном в лесу доменов usa.wingtiptoys.com.

  2. Workstation1 обращается к KDC Kerberos на контроллере домена в своем домене, ChildDC1и запрашивает служебный билет для FileServer1 SPN.

  3. ChildDC1 не находит SPN в базе данных домена и запрашивает глобальный каталог, чтобы узнать, содержат ли домены в лес доменов tailspintoys.com этот SPN. Так как глобальный каталог ограничен собственным лесом, имя субъекта-службы не найдено.

    Затем глобальный каталог проверяет базу данных для получения сведений о любых довериях леса, установленных с его лесом. Если он найден, он сравнивает суффиксы имен, перечисленные в объекте доверенного домена доверия леса (TDO) с суффиксом целевого имени субъекта-службы для поиска соответствия. После обнаружения совпадения глобальный каталог предоставляет подсказку маршрутизации обратно в ChildDC1.

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

  4. ChildDC1 отправляет ссылку для родительского домена обратно в Workstation1.

  5. Workstation1 обращается к контроллеру домена в ForestRootDC1 (его родительский домен) для ссылки на контроллер домена (ForestRootDC2) в корневом домене леса wingtiptoys.com.

  6. Рабочая станция1 связывается с ForestRootDC2 в домене wingtiptoys.com для получения сервисного билета на запрошенную услугу.

  7. ForestRootDC2 обращается к глобальному каталогу, чтобы найти SPN, а глобальный каталог находит соответствие для SPN и отправляет его обратно в ForestRootDC2.

  8. ForestRootDC2 затем отправляет ссылку на usa.wingtiptoys.com обратно в Workstation1.

  9. Workstation1 обращается к KDC на ChildDC2 и договаривается о билете для User1, чтобы получить доступ к FileServer1.

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

Доверенный объект домена

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

Содержимое TDO

Сведения, содержащиеся в TDO, зависят от того, было ли оно создано с использованием доменного доверия или доверия леса.

При создании доверия к домену атрибуты, такие как DNS-имя домена, идентификатор безопасности домена, тип доверия, транзитивность доверия и взаимное доменное имя представлены в TDO. TDO доверительных доменов хранят дополнительные атрибуты для идентификации всех доверенных пространств имен из леса партнерской системы. К этим атрибутам относятся имена деревьев домена, суффиксы имени пользователя (UPN), суффиксы имени службы (SPN) и пространства имен идентификатора безопасности (SID).

Так как доверия хранятся в Active Directory как TDOs, все домены в лесу имеют знания о отношениях доверия, которые находятся на месте во всем лесу. Аналогичным образом, если два или более леса объединяются через доверительные отношения лесов, корневые домены леса в каждом лесу имеют знания об отношениях доверия, которые существуют во всех доменах доверенных лесов.

Изменения пароля TDO

Оба домена в отношениях доверия используют пароль, который хранится в объекте TDO в Active Directory. В рамках процесса обслуживания учетной записи каждые 30 дней доверенный контроллер домена изменяет пароль, хранящийся в TDO. Поскольку все двусторонние доверия на самом деле представляют собой два односторонних доверия, направленных в противоположные стороны, процесс происходит дважды для двусторонних доверий.

У доверительного фонда есть доверяющая и доверенная сторона. На доверенной стороне для процесса можно использовать любой записываемый контроллер домена. На доверяющей стороне эмулятор PDC выполняет изменение пароля.

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

  1. Эмулятор основного контроллера домена (PDC) в доверенном домене создает новый пароль. Контроллер домена в доверенном домене никогда не инициирует изменение пароля. Инициатором всегда выступает эмулятор PDC доверенного домена.

  2. Эмулятор PDC в доверяющем домене устанавливает поле OldPassword объекта TDO равным текущему значению из поля NewPassword.

  3. Эмулятор PDC в доверенном домене задает поле NewPassword объекта TDO новым паролем. Сохранение копии предыдущего пароля позволяет вернуться к старому паролю, если контроллер домена в доверенном домене не получит изменения или если изменение не реплицируется до того, как будет выполнен запрос, использующий новый пароль доверия.

  4. Эмулятор PDC в доверенном домене выполняет удаленный вызов контроллера домена в доверенном домене с просьбой задать пароль для учетной записи доверия новым паролем.

  5. Контроллер домена в доверенном домене изменяет пароль доверия на новый пароль.

  6. На каждой стороне доверия обновления реплицируются на другие контроллеры домена. В доверенном домене изменение активирует срочную репликацию доверенного объекта домена.

Теперь пароль изменяется на обоих контроллерах домена. Обычная репликация распределяет объекты TDO на другие контроллеры домена в домене. Однако контроллер домена в доверенном домене может изменить пароль без успешного обновления контроллера домена в доверенном домене. Этот сценарий может произойти, так как защищенный канал, который требуется для обработки изменения пароля, не удалось установить. Кроме того, возможно, контроллер домена в доверенном домене может быть недоступен в какой-то момент во время процесса и может не получить обновленный пароль.

Чтобы справиться с ситуациями, в которых изменение пароля не было успешно передано, контроллер домена в доверенном домене никогда не изменяет новый пароль, если он не прошел проверку подлинности (настройка защищенного канала) с помощью нового пароля. Именно поэтому старые и новые пароли хранятся в объекте TDO доверенного домена.

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

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

Обновления паролей доверия должны реплицироваться на контроллеры домена обеих сторон доверия в течение 30 дней. Если пароль доверия изменяется через 30 дней, а контроллер домена имеет только пароль доверия N-2, он не может использовать доверие со стороны доверяющей стороны и не может создать безопасный канал на доверяемой стороне.

Порты сети, используемые доверительными отношениями

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

Важный

Доменные службы Active Directory не поддерживают ограничение трафика RPC Active Directory на определенные порты.

Ознакомьтесь с разделом Windows Server 2008 и более поздних версий статьи поддержки Майкрософт Как настроить брандмауэр для доменов и доверительных отношений Active Directory, чтобы узнать о портах, необходимых для доверительных отношений леса.

Поддержка служб и инструментов

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

Вход в сеть

Служба Net Logon поддерживает защищенный канал между компьютером под управлением Windows и контроллером домена. Он также используется в следующих процессах, связанных с доверием:

  • Настройка доверия и управление . Net Logon помогает поддерживать пароли доверия, собирать сведения о доверии и проверять доверие путем взаимодействия с процессом LSA и TDO.

    Для трастов леса информация о трастах включает запись "Сведения о трастах леса" (FTInfo), которая содержит набор пространств имен, право управления которыми заявляет доверенный лес, аннотированный полем, указывающим, является ли каждое заявление доверенным данным лесом.

  • Проверка подлинности — предоставляет учетные данные пользователя через защищенный канал контроллеру домена и возвращает идентификаторы домена и права пользователя для пользователя.

  • Расположение контроллера домена — помогает находить контроллеры домена в домене или в разных доменах.

  • Сквозная проверка — учетные данные пользователей в других доменах обрабатываются Net Logon. Когда доверенный домен должен проверить удостоверение пользователя, он передает учетные данные пользователя через Net Logon в доверенный домен для проверки.

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

Локальный центр безопасности

Локальный центр безопасности (LSA) — это защищенная подсистема, которая поддерживает сведения обо всех аспектах локальной безопасности в системе. Совместно известная как локальная политика безопасности, LSA предоставляет различные службы для перевода между именами и идентификаторами.

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

Средства управления

Администраторы могут использовать домены и отношения доверия Active Directory, Netdom и Nltest для раскрытия, создания, удаления или изменения отношений доверия.

  • Домены и отношения доверия Active Directory — это Консоль управления Microsoft (MMC), которая используется для администрирования отношений доверия домена, уровней функциональности доменов и лесов, а также суффиксов имени субъекта-пользователя.
  • С помощью средств командной строки Netdom и Nltest можно искать, отображать, создавать и управлять доверительными отношениями. Эти инструменты напрямую взаимодействуют с центром LSA на контроллере домена.

Дальнейшие действия

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