Доверие между доменами windows

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

Тестовый стенд:
— Хостовой сервер: Intel i7 4700, 32 GB RAM, AMD R7 200, Windows 10 1803 + Hyper-V
— VM1, Intel i7 4700 x2, 4 GB RAM, Windows Server 2016, exonix.ru
— VM2, Intel i7 4700 x2, 4 GB RAM. Windows Server 2008 R2, beta.com

BETA.COM

EXONIX.RU

Для того, чтобы клиенты разрешали доменные имена доверенного домена, необходимо или делегировать ДНС-зону для ДНС сервера в доверенном домене и затем подключить зону как «stub» или «secondary» или использовать «Условные пересылки». Я буду использовать условные пересылки. На WS 2016 добавим условную пересылку с помощью PowerShell:

На WS 2008 R2 добавляем условную пересылку в оснастке DNS:

После настройки ДНС необходимо проверить разрешение имём с помощью nslookup. Если всё успешно — можно приступать к настройке доверительных отношений. Настройка будет производиться на сервере WS 2016 с помощью утилиты netdom:

После этого на серверах добавятся нетранзитивные двухсторонние доверительные отношение.

Нетранзитивные отношения означают доверия только между двумя доменами. Если в лесу exonix.ru будет создан ещё один домен, например, alpha.de, то доверий между beta.com и alpha.deне будет. Доменная аутентификация означает, что все пользователи будут доступны для поиска и аутентификации в доверенном домене.

Другой вариант доверий. Односторонние, выборочные (Selective): exonix.ru доверяет beta.com. Данные доверия требуются, когда домен beta.com является доменом-бастионом для домена exonix.ru:

В домене exonix.ru появится возможность предоставлять доступ пользователям домена beta.com:

В обратном направлении такого не будет:

17.11.2012
новая статья 03.06.2018

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Восстанавливаем доверительные отношения в домене

Восстанавливаем доверительные отношения в домене

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

Учетные записи компьютеров, также, как и учетные записи пользователей, являются участниками безопасности домена. Каждому участнику безопасности автоматически присваивается идентификатор безопасности (SID) на уровне которого осуществляется доступ к ресурсам домена.

Перед тем как предоставить учетной записи доступ к домену необходимо проверить ее подлинность. Каждый участник безопасности должен иметь свою учетную запись и пароль, учетная запись компьютера не исключение. При присоединении компьютера к Active Directory для него создается учетная запись типа «Компьютер» и устанавливается пароль. Доверие на этом уровне обеспечивается тем, что данная операция производится администратором домена или иным пользователем, имеющим для этого явные полномочия.

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

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

Доверительные отношения нарушаются в том случае, если компьютер пытается аутентифицироваться в домене с недействительным паролем. Как такое может произойти? Самый простой способ — это откатить состояние компьютера, например, штатной утилитой восстановления системы. Такой же эффект может быть достигнут при восстановлении из образа, снапшота (для виртуальных машин) и т.п.

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

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

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

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

Пользователи и компьютеры Active Directory

Это самый простой, но не самый быстрый и удобный способ. Открываем на любом контроллере домена оснастку Пользователи и компьютеры Active Directory, находим необходимую учетную запись компьютера и, щелкнув правой кнопкой мыши, выбираем Переустановить учетную запись.

Затем входим на потерявшем доверительные отношения компьютере под локальным администратором и выводим машину из домена.

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

Недостаток этого способа, что машину требуется выводить из домена, а также необходимость двух (одной) перезагрузки.

Утилита Netdom

Данная утилита входит в состав Windows Server начиная с редакции 2008, на пользовательские ПК ее можно установить из состава пакета RSAT (Средства удаленного администрирования сервера). Для ее использования войдите на целевой системе локальным администратором и выполните команду:

Разберем опции команды:

• Server — имя любого доменного контроллера
• UserD — имя учетной записи администратора домена
• PasswordD — пароль администратора домена

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

Командлет PowerShell 3.0

В отличие от утилиты Netdom, PowerShell 3.0 входит в состав системы начиная с Windows 8 / Server 2012, для более старых систем его можно установить вручную, поддерживаются Windows 7, Server 2008 и Server 2008 R2. В качестве зависимости требуется Net Framework не ниже 4.0.

Точно также войдите на системе, для которой нужно восстановить доверительные отношения, локальным администратором, запустите консоль PowerShell и выполните команду:

• Server — имя любого контроллера домена
• Credential — имя домена / учетной записи администратора домена

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

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

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

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Как работают отношения доверия для лесов ресурсов в доменных службах Azure Active Directory How trust relationships work for resource forests in Azure Active Directory Domain Services

Домен Active Directory Services (AD DS) обеспечивает безопасность в нескольких доменах или лесах с помощью отношений доверия между доменами и лесами. Active Directory Domain Services (AD DS) provides security across multiple domains or forests through domain and forest trust relationships. Перед проверкой подлинности в отношениях доверия Windows должна сначала проверить, имеет ли домен, запрашиваемый пользователем, компьютером или службой, отношение доверия с доменом запрашивающей учетной записи. Before authentication can occur across trusts, Windows must first check if the domain being requested by a user, computer, or service has a trust relationship with the domain of the requesting account.

Чтобы проверить это отношение доверия, система безопасности Windows вычислит путь доверия между контроллером домена (DC) для сервера, получающего запрос, и КОНТРОЛЛЕРом домена в домене запрашивающей учетной записи. To check for this trust relationship, the Windows security system computes a trust path between the domain controller (DC) for the server that receives the request and a DC in the domain of the requesting account.

Механизмы управления доступом, предоставляемые AD DS и распределенной моделью безопасности Windows, предоставляют среду для работы отношений доверия между доменами и лесами. The access control mechanisms provided by AD DS and the Windows distributed security model provide an environment for the operation of domain and forest trusts. Для правильной работы этих отношений доверия каждый ресурс или компьютер должен иметь прямой доверенный путь к КОНТРОЛЛЕРу домена в домене, в котором он находится. For these trusts to work properly, every resource or computer must have a direct trust path to a DC in the domain in which it is located.

Путь доверия реализуется службой сетевого входа в систему с использованием подключения удаленного вызова процедур (RPC), прошедшего проверку подлинности, в доверенном центре домена. The trust path is implemented by the Net Logon service using an authenticated remote procedure call (RPC) connection to the trusted domain authority. Защищенный канал также распространяется на другие домены AD DS через междоменные отношения доверия. A secured channel also extends to other AD DS domains through interdomain trust relationships. Этот защищенный канал используется для получения и проверки сведений о безопасности, включая идентификаторы безопасности (SID) для пользователей и групп. This secured channel is used to obtain and verify security information, including security identifiers (SIDs) for users and groups.

Общие сведения о том, как отношения доверия применяются к AD DS Azure, см. в статье Основные понятия и компоненты леса ресурсов. For an overview of how trusts apply to Azure AD DS, see Resource forest concepts and features.

Чтобы приступить к использованию отношений доверия в Azure AD DS, создайте управляемый домен, использующий отношения доверия лесов. To get started using trusts in Azure AD DS, create a managed domain that uses forest trusts.

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

Поток защищенной связи через доверия определяет эластичность доверия. The flow of secured communications over trusts determines the elasticity of a trust. Как вы создаете или настраиваете доверие, определяет, насколько далеко взаимодействуют между лесами. How you create or configure a trust determines how far the communication extends within or across forests.

Поток обмена данными между отношениями доверия определяется направлением доверия. The flow of communication over trusts is determined by the direction of the trust. Отношения доверия могут быть односторонними или двусторонними и могут быть транзитивными или нетранзитивными. Trusts can be one-way or two-way, and can be transitive or non-transitive.

На следующей схеме показано, что по умолчанию все домены в дереве 1 и дереве 2 имеют транзитивные отношения доверия. The following diagram shows that all domains in Tree 1 and Tree 2 have transitive trust relationships by default. В результате пользователи в дереве 1 могут получить доступ к ресурсам в доменах дерева 2 , а пользователи в дереве 1 могут получить доступ к ресурсам в дереве 2, если в ресурсе назначены соответствующие разрешения. As a result, users in Tree 1 can access resources in domains in Tree 2 and users in Tree 1 can access resources in Tree 2, when the proper permissions are assigned at the resource.

Одностороннее и двустороннее доверие One-way and two-way trusts

Отношения доверия обеспечивают доступ к ресурсам одним или двумя способами. Trust relationships enable access to resources can be either one-way or two-way.

Одностороннее отношение доверия — это однонаправленный путь проверки подлинности, созданный между двумя доменами. A one-way trust is a unidirectional authentication path created between two domains. При одностороннем доверии между доменом а и доменом б пользователи в домене a могут обращаться к ресурсам в домене б. Однако пользователи в домене б не могут получить доступ к ресурсам в домене а. In a one-way trust between Domain A and Domain B, users in Domain A can access resources in Domain B. However, users in Domain B can’t access resources in Domain A.

Некоторые односторонние отношения доверия могут быть нетранзитивными или транзитивными в зависимости от типа создаваемого доверия. Some one-way trusts can be either non-transitive or transitive depending on the type of trust being created.

В двустороннем доверии домен a доверяет домену b , а домен б доверяет домену а. Такая конфигурация означает, что запросы проверки подлинности могут передаваться между двумя доменами в обоих направлениях. In a two-way trust, Domain A trusts Domain B and Domain B trusts Domain A. This configuration means that authentication requests can be passed between the two domains in both directions. Некоторые двусторонние связи могут быть нетранзитивными или транзитивными в зависимости от типа создаваемого доверия. Some two-way relationships can be non-transitive or transitive depending on the type of trust being created.

Все доверительные отношения доменов в лесу AD DS являются двусторонними транзитивными отношениями доверия. All domain trusts in an AD DS forest are two-way, transitive trusts. При создании нового дочернего домена между дочерним доменом и родительским доменом автоматически создается двустороннее транзитивное доверие. When a new child domain is created, a two-way, transitive trust is automatically created between the new child domain and the parent domain.

Транзитивные и нетранзитивные отношения доверия Transitive and non-transitive trusts

Транзитивность определяет, можно ли расширить отношение доверия за пределами двух доменов, с которыми он был сформирован. Transitivity determines whether a trust can be extended outside of the two domains with which it was formed.

• Транзитивное доверие можно использовать для расширения отношений доверия с другими доменами. A transitive trust can be used to extend trust relationships with other domains.
• Нетранзитивное доверие можно использовать для запрета доверительных отношений с другими доменами. A non-transitive trust can be used to deny trust relationships with other domains.

Каждый раз при создании нового домена в лесу автоматически создается двустороннее транзитивное отношение доверия между новым доменом и его родительским доменом. Each time you create a new domain in a forest, a two-way, transitive trust relationship is automatically created between the new domain and its parent domain. Если дочерние домены добавляются в новый домен, путь доверия передается вверх через иерархию доменов, расширяя исходный путь доверия, созданный между новым доменом и его родительским доменом. If child domains are added to the new domain, the trust path flows upward through the domain hierarchy extending the initial trust path created between the new domain and its parent domain. Транзитивные отношения доверия движутся вверх по доменному дереву по мере его формирования, создавая транзитивное доверие между всеми доменами доменного дерева. Transitive trust relationships flow upward through a domain tree as it is formed, creating transitive trusts between all domains in the domain tree.

Запросы проверки подлинности следуют этим путям доверия, поэтому учетные записи из любого домена леса могут проходить проверку подлинности любым другим доменом в лесу. Authentication requests follow these trust paths, so accounts from any domain in the forest can be authenticated by any other domain in the forest. В процессе единого входа учетные записи с соответствующими разрешениями могут получать доступ к ресурсам в любом домене леса. With a single sign in process, accounts with the proper permissions can access resources in any domain in the forest.

Отношения доверия для леса Forest trusts

Отношения доверия лесов помогают управлять сегментированными AD DS инфраструктурами и поддерживают доступ к ресурсам и другим объектам в нескольких лесах. Forest trusts help you to manage a segmented AD DS infrastructures and support access to resources and other objects across multiple forests. Отношения доверия лесов полезны для поставщиков услуг, компаний, осуществляющих слияние или приобретение, совместный бизнес в экстрасети и компании, которые ищут решение для административной автономности. Forest trusts are useful for service providers, companies undergoing mergers or acquisitions, collaborative business extranets, and companies seeking a solution for administrative autonomy.

С помощью отношений доверия лесов можно связать два леса, чтобы сформировать одностороннее или двустороннее транзитивное отношение доверия. Using forest trusts, you can link two different forests to form a one-way or two-way transitive trust relationship. Доверие лесов позволяет администраторам подключать два AD DS лесов с единым отношением доверия для обеспечения эффективной проверки подлинности и авторизации в лесах. A forest trust allows administrators to connect two AD DS forests with a single trust relationship to provide a seamless authentication and authorization experience across the forests.

Доверие лесов можно создать только между корневым доменом леса в одном лесу и корневым доменом леса в другом лесу. A forest trust can only be created between a forest root domain in one forest and a forest root domain in another forest. Отношения доверия лесов могут быть созданы только между двумя лесами и не могут быть неявно расширены до третьего леса. Forest trusts can only be created between two forests and can’t be implicitly extended to a third forest. Это означает, что если доверие лесов создано между лесами 1 и лесом 2, а между лесами 2 и лесом 3 создается другое доверие лесов, лес 1 не имеет неявного отношения доверия с лесом 3. This behavior means that if a forest trust is created between Forest 1 and Forest 2, and another forest trust is created between Forest 2 and Forest 3, Forest 1 doesn’t have an implicit trust with Forest 3.

На следующей схеме показаны два отдельных отношения доверия лесов между тремя AD DS лесами в одной организации. The following diagram shows two separate forest trust relationships between three AD DS forests in a single organization.

Этот пример конфигурации предоставляет следующий доступ: This example configuration provides the following access:

• Пользователи в лесу 2 могут получать доступ к ресурсам в любом домене леса 1 или леса 3 . Users in Forest 2 can access resources in any domain in either Forest 1 or Forest 3
• Пользователи в лесу 3 могут получать доступ к ресурсам в любом домене леса 2 . Users in Forest 3 can access resources in any domain in Forest 2
• Пользователи в лесу 1 могут получать доступ к ресурсам в любом домене леса 2 . Users in Forest 1 can access resources in any domain in Forest 2

Эта конфигурация не позволяет пользователям леса 1 обращаться к ресурсам в лесу 3 и наоборот. This configuration doesn’t allow users in Forest 1 to access resources in Forest 3 or vice versa. Чтобы разрешить пользователям в лесах 1 и лесу 3 доступ к ресурсам, необходимо создать двустороннее транзитивное доверие между двумя лесами. To allow users in both Forest 1 and Forest 3 to share resources, a two-way transitive trust must be created between the two forests.

Если между двумя лесами создается одностороннее доверие лесов, члены доверенного леса могут использовать ресурсы, расположенные в доверяющем лесу. If a one-way forest trust is created between two forests, members of the trusted forest can utilize resources located in the trusting forest. Однако доверие действует только в одном направлении. However, the trust operates in only one direction.

Например, при создании одностороннего отношения доверия между лесами 1 (доверенный лес) и лесом 2 (лес доверия): For example, when a one-way, forest trust is created between Forest 1 (the trusted forest) and Forest 2 (the trusting forest):

• Члены леса 1 могут обращаться к ресурсам, расположенным в лесу 2. Members of Forest 1 can access resources located in Forest 2.
• Члены леса 2 не могут получить доступ к ресурсам, расположенным в лесу 1 , используя одно и то же отношение доверия. Members of Forest 2 can’t access resources located in Forest 1 using the same trust.

Лес ресурсов доменных служб Azure AD поддерживает односторонние отношения доверия лесов с локальными Active Directory. Azure AD Domain Services resource forest only supports a one-way forest trust to on-premises Active Directory.

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

Прежде чем можно будет создать доверие лесов, необходимо убедиться в наличии правильной инфраструктуры системы доменных имен (DNS). Before you can create a forest trust, you need to verify you have the correct Domain Name System (DNS) infrastructure in place. Отношения доверия лесов можно создавать только при наличии одной из следующих конфигураций DNS: Forest trusts can only be created when one of the following DNS configurations is available:

Единственный корневой DNS-сервер — это корневой DNS-сервер для обоих пространств имен DNS леса. Корневая зона содержит делегирования для каждого пространства имен DNS, а корневые ссылки всех DNS-серверов включают корневой DNS-сервер. A single root DNS server is the root DNS server for both forest DNS namespaces — the root zone contains delegations for each of the DNS namespaces and the root hints of all DNS servers include the root DNS server.

Если нет общего корневого DNS-сервера и корневых DNS-серверов в каждом лесу DNS-пространство имен используют DNS-серверы условной пересылки для каждого пространства имен DNS для маршрутизации запросов имен в другом пространстве имен. When there is no shared root DNS server and the root DNS servers in each forest DNS namespace use DNS conditional forwarders for each DNS namespace to route queries for names in the other namespace.

Лес ресурсов доменных служб Azure AD должен использовать эту конфигурацию DNS. Azure AD Domain Services resource forest must use this DNS configuration. Размещение пространства имен DNS, отличного от пространства имен DNS леса ресурсов, не является компонентом доменных служб Azure AD. Hosting a DNS namespace other than the resource forest DNS namespace is not a feature of Azure AD Domain Services. Условные серверы пересылки являются правильной конфигурацией. Conditional forwarders is the proper configuration.

Если общий корневой DNS-сервер отсутствует, а корневые DNS-серверы в каждом из пространств имен DNS леса используют дополнительные зоны DNS, настраиваются в каждом пространстве имен DNS для маршрутизации запросов имен в другом пространстве имен. When there is no shared root DNS server and the root DNS servers in each forest DNS namespace are use DNS secondary zones are configured in each DNS namespace to route queries for names in the other namespace.

Чтобы создать доверие лесов, необходимо быть членом группы «Администраторы домена» (в корневом домене леса) или группы «Администраторы предприятия» в Active Directory. To create a forest trust, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory. Каждому доверию назначается пароль, который должны быть знакомы администраторам в обоих лесах. Each trust is assigned a password that the administrators in both forests must know. Участники корпоративных администраторов в обоих лесах могут одновременно создавать отношения доверия в обоих лесах, и в этом случае пароль, криптографически случайный, автоматически создается и записывается для обоих лесов. Members of Enterprise Admins in both forests can create the trusts in both forests at once and, in this scenario, a password that is cryptographically random is automatically generated and written for both forests.

В портал Azure создается исходящее доверие лесов для доменных служб Azure AD. The outbound forest trust for Azure AD Domain Services is created in the Azure portal. Вы не создаете доверие вручную с самим управляемым доменом. You don’t manually create the trust with the managed domain itself. Входящее доверие лесов должно быть настроено пользователем с привилегиями, которые ранее были указаны в локальной Active Directory. The incoming forest trust must be configured by a user with the privileges previously noted in the on-premises Active Directory.

Процессы доверия и взаимодействия Trust processes and interactions

Многие транзакции между доменами и между лесами зависят от отношений доверия между доменами и лесами для выполнения различных задач. Many inter-domain and inter-forest transactions depend on domain or forest trusts in order to complete various tasks. В этом разделе описываются процессы и взаимодействия, происходящие, когда доступ к ресурсам осуществляется по отношениям доверия и по ссылкам проверки подлинности. This section describes the processes and interactions that occur as resources are accessed across trusts and authentication referrals are evaluated.

Общие сведения об обработке ссылок для проверки подлинности Overview of authentication referral processing

Если запрос на проверку подлинности называется доменом, контроллер домена в этом домене должен определить, существует ли отношение доверия с доменом, из которого поступает запрос. When a request for authentication is referred to a domain, the domain controller in that domain must determine whether a trust relationship exists with the domain from which the request comes. Кроме того, необходимо определить, является ли доверие транзитивным или нетранзитивным, прежде чем проверять подлинность пользователя для доступа к ресурсам в домене. The direction of the trust and whether the trust is transitive or nontransitive must also be determined before it authenticates the user to access resources in the domain. Процесс проверки подлинности, который происходит между доверенными доменами, зависит от используемого протокола проверки подлинности. The authentication process that occurs between trusted domains varies according to the authentication protocol in use. Протоколы Kerberos V5 и NTLM обрабатывают ссылки для проверки подлинности в домене по-разному. The Kerberos V5 and NTLM protocols process referrals for authentication to a domain differently

Обработка ссылок Kerberos V5 Kerberos V5 referral processing

Протокол проверки подлинности Kerberos V5 зависит от службы сетевого входа в систему на контроллерах домена для проверки подлинности и авторизации клиента. The Kerberos V5 authentication protocol is dependent on the Net Logon service on domain controllers for client authentication and authorization information. Протокол Kerberos подключается к сетевому центр распространения ключей (KDC) и хранилищу учетных записей Active Directory для билетов сеансов. The Kerberos protocol connects to an online Key Distribution Center (KDC) and the Active Directory account store for session tickets.

Протокол Kerberos также использует отношения доверия для служб предоставления билетов (TGS) между сферами и для проверки сертификатов атрибутов привилегий (PAC) в защищенном канале. The Kerberos protocol also uses trusts for cross-realm ticket-granting services (TGS) and to validate Privilege Attribute Certificates (PACs) across a secured channel. Протокол Kerberos выполняет проверку подлинности между сферами только с помощью сфер Kerberos операционной системы, отличных от Windows, таких как область Kerberos, и не требует взаимодействия со службой сетевого входа в систему. The Kerberos protocol performs cross-realm authentication only with non-Windows-brand operating system Kerberos realms such as an MIT Kerberos realm and does not need to interact with the Net Logon service.

Если клиент использует Kerberos V5 для проверки подлинности, он запрашивает билет на сервере в целевом домене из контроллера домена в домене учетной записи. If the client uses Kerberos V5 for authentication, it requests a ticket to the server in the target domain from a domain controller in its account domain. Kerberos KDC выступает в качестве доверенного посредника между клиентом и сервером и предоставляет ключ сеанса, позволяющий двум сторонам проходить проверку подлинности друг друга. The Kerberos KDC acts as a trusted intermediary between the client and server and provides a session key that enables the two parties to authenticate each other. Если целевой домен отличается от текущего домена, KDC следует логическому процессу определить, можно ли ссылаться на запрос на проверку подлинности: If the target domain is different from the current domain, the KDC follows a logical process to determine whether an authentication request can be referred:

Является ли текущий домен доверенным непосредственно доменом запрашиваемого сервера? Is the current domain trusted directly by the domain of the server that is being requested?

• Если да, отправьте клиенту ссылку на запрошенный домен. If yes, send the client a referral to the requested domain.
• Если нет, перейдите к следующему шагу. If no, go to the next step.

Существует ли между текущим доменом и следующим доменом по пути доверия отношение взаимного доверия? Does a transitive trust relationship exist between the current domain and the next domain on the trust path?

• Если да, отправьте клиенту ссылку на следующий домен в пути доверия. If yes, send the client a referral to the next domain on the trust path.
• Если нет, отправьте клиенту сообщение об отклонении входа. If no, send the client a sign-in denied message.

Обработка ссылок NTLM NTLM referral processing

Протокол проверки подлинности NTLM зависит от службы сетевого входа в систему на контроллерах домена для проверки подлинности клиента и авторизации. The NTLM authentication protocol is dependent on the Net Logon service on domain controllers for client authentication and authorization information. Этот протокол проверяет подлинность клиентов, не использующих проверку подлинности Kerberos. This protocol authenticates clients that do not use Kerberos authentication. NTLM использует отношения доверия для передачи запросов проверки подлинности между доменами. NTLM uses trusts to pass authentication requests between domains.

Если клиент использует NTLM для проверки подлинности, первоначальный запрос проверки подлинности переходит непосредственно от клиента к серверу ресурсов в целевом домене. If the client uses NTLM for authentication, the initial request for authentication goes directly from the client to the resource server in the target domain. Этот сервер создает запрос, на который отвечает клиент. This server creates a challenge to which the client responds. Затем сервер отправляет ответ пользователя на контроллер домена в домене учетной записи компьютера. The server then sends the user’s response to a domain controller in its computer account domain. Этот контроллер домена проверяет учетную запись пользователя на соответствие базе данных учетных записей безопасности. This domain controller checks the user account against its security accounts database.

Если учетная запись не существует в базе данных, контроллер домена определяет, следует ли выполнить сквозную аутентификацию, перенаправить запрос или отклонить запрос с помощью следующей логики: If the account does not exist in the database, the domain controller determines whether to perform pass-through authentication, forward the request, or deny the request by using the following logic:

Имеет ли текущий домен отношение прямого доверия с доменом пользователя? Does the current domain have a direct trust relationship with the user’s domain?

• Если да, контроллер домена отправляет учетные данные клиента на контроллер домена в домене пользователя для сквозной проверки подлинности. If yes, the domain controller sends the credentials of the client to a domain controller in the user’s domain for pass-through authentication.
• Если нет, перейдите к следующему шагу. If no, go to the next step.

Имеет ли текущий домен транзитивное отношение доверия с доменом пользователя? Does the current domain have a transitive trust relationship with the user’s domain?

• Если да, передайте запрос на проверку подлинности в следующий домен в пути доверия. If yes, pass the authentication request on to the next domain in the trust path. Этот контроллер домена повторяет процесс, проверяя учетные данные пользователя по собственной базе данных учетных записей безопасности. This domain controller repeats the process by checking the user’s credentials against its own security accounts database.
• Если нет, отправьте клиенту сообщение с запретом входа. If no, send the client a logon-denied message.

Обработка запросов проверки подлинности на основе Kerberos через доверия лесов Kerberos-based processing of authentication requests over forest trusts

Когда два леса соединяются отношением доверия лесов, запросы на проверку подлинности, созданные с помощью протоколов Kerberos V5 или NTLM, можно перенаправлять между лесами, чтобы предоставить доступ к ресурсам в обоих лесах. When two forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests.

При первом установлении доверия между лесами каждый лес собирает все доверенные пространства имен в своем лесу партнера и сохраняет информацию в объекте доверенного домена. When a forest trust is first established, each forest collects all of the trusted namespaces in its partner forest and stores the information in a trusted domain object. К доверенным пространствам имен относятся имена доменных деревьев, суффиксы имени участника-пользователя, суффиксы имени субъекта-службы и пространства имен ИДЕНТИФИКАТОРов безопасности (SID), используемые в другом лесу. Trusted namespaces include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces used in the other forest. Объекты TDO реплицируются в глобальный каталог. TDO objects are replicated to the global catalog.

Прежде чем протоколы проверки подлинности могут следовать пути доверия лесов, имя участника-службы (SPN) компьютера ресурсов должно быть разрешено в расположение в другом лесу. Before authentication protocols can follow the forest trust path, the service principal name (SPN) of the resource computer must be resolved to a location in the other forest. Имя субъекта-службы может иметь одно из следующих имен: An SPN can be one of the following names:

• DNS-имя узла. The DNS name of a host.
• DNS-имя домена. The DNS name of a domain.
• Различающееся имя объекта точки подключения службы. The distinguished name of a service connection point object.

Когда Рабочая станция в одном лесу пытается получить доступ к данным на компьютере ресурса в другом лесу, процесс проверки подлинности Kerberos обращается к контроллеру домена для получения билета службы к имени участника-службы компьютера с ресурсами. When a workstation in one forest attempts to access data on a resource computer in another forest, the Kerberos authentication process contacts the domain controller for a service ticket to the SPN of the resource computer. После того как контроллер домена запрашивает глобальный каталог и определит, что имя субъекта-службы не находится в том же лесу, что и контроллер домена, контроллер домена отправляет ссылку для своего родительского домена обратно на рабочую станцию. Once the domain controller queries the global catalog and determines that the SPN is not in the same forest as the domain controller, the domain controller sends a referral for its parent domain back to the workstation. На этом этапе Рабочая станция запрашивает у родительского домена билет службы и продолжит следовать цепочке ссылок до тех пор, пока не достигнет домена, в котором находится ресурс. At that point, the workstation queries the parent domain for the service ticket and continues to follow the referral chain until it reaches the domain where the resource is located.

Приведенная ниже схема и шаги содержат подробное описание процесса проверки подлинности Kerberos, используемого при попытке компьютеров, работающих под управлением Windows, получить доступ к ресурсам с компьютера, находящегося в другом лесу. The following diagram and steps provide a detailed description of the Kerberos authentication process that’s used when computers running Windows attempt to access resources from a computer located in another forest.

Пользователь1 входит в компьютере Workstation1 , используя учетные данные из домена Europe.tailspintoys.com . User1 signs in to Workstation1 using credentials from the europe.tailspintoys.com domain. Затем пользователь пытается получить доступ к общему ресурсу в FileServer1 , расположенном в лесу USA.wingtiptoys.com . The user then attempts to access a shared resource on FileServer1 located in the usa.wingtiptoys.com forest.

Компьютере Workstation1 связывается с центром распространения ключей Kerberos на контроллере домена в своем домене, ChildDC1 и запрашивает билет службы для SPN FileServer1 . Workstation1 contacts the Kerberos KDC on a domain controller in its domain, ChildDC1, and requests a service ticket for the FileServer1 SPN.

ChildDC1 не находит имя субъекта-службы в своей базе данных домена и запрашивает глобальный каталог, чтобы узнать, содержат ли какие-либо домены в лесу tailspintoys.com это имя участника-службы. ChildDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the tailspintoys.com forest contain this SPN. Поскольку глобальный каталог ограничен его собственным лесом, имя субъекта-службы не найдено. Because a global catalog is limited to its own forest, the SPN is not found.

Затем глобальный каталог проверяет свою базу данных на наличие сведений о доверии лесов, установленных с лесом. The global catalog then checks its database for information about any forest trusts that are established with its forest. Если он найден, он сравнивает суффиксы имен, перечисленные в объекте доверенного домена доверия лесов, с суффиксом целевого имени субъекта-службы для поиска соответствия. If found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match. После обнаружения совпадения глобальный каталог предоставляет указание маршрутизации обратно в ChildDC1. Once a match is found, the global catalog provides a routing hint back to ChildDC1.

Указания маршрутизации помогают направить запросы проверки подлинности в целевой лес. Routing hints help direct authentication requests toward the destination forest. Указания используются только в том случае, если все традиционные каналы проверки подлинности, например локальный контроллер домена и глобальный каталог, не могут наыскать имя участника-службы. Hints are only used when all traditional authentication channels, such as local domain controller and then global catalog, fail to locate an SPN.

ChildDC1 отправляет ссылку для своего родительского домена обратно в компьютере Workstation1. ChildDC1 sends a referral for its parent domain back to Workstation1.

Компьютере Workstation1 связывается с контроллером домена в ForestRootDC1 (его родительским доменом) для ссылки на контроллер домена (ForestRootDC2) в корневом домене леса wingtiptoys.com . Workstation1 contacts a domain controller in ForestRootDC1 (its parent domain) for a referral to a domain controller (ForestRootDC2) in the forest root domain of the wingtiptoys.com forest.

Компьютере Workstation1 Contacts ForestRootDC2 в лесу wingtiptoys.com для билета службы к запрошенной службе. Workstation1 contacts ForestRootDC2 in the wingtiptoys.com forest for a service ticket to the requested service.

ForestRootDC2 связывается со своим глобальным каталогом, чтобы найти имя субъекта-службы, а глобальный каталог находит совпадение для имени SPN и отправляет его обратно в ForestRootDC2. ForestRootDC2 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it back to ForestRootDC2.

Затем ForestRootDC2 отправляет ссылку на USA.wingtiptoys.com обратно в компьютере Workstation1. ForestRootDC2 then sends the referral to usa.wingtiptoys.com back to Workstation1.

Компьютере Workstation1 связывается с центром распространения ключей на ChildDC2 и согласовывает билет для User1 , чтобы получить доступ к FileServer1. Workstation1 contacts the KDC on ChildDC2 and negotiates the ticket for User1 to gain access to FileServer1.

Когда у компьютере Workstation1 есть билет службы, он отправляет билет службы в FileServer1, который считывает учетные данные безопасности пользователя User1 и соответствующим образом формирует маркер доступа. Once Workstation1 has a service ticket, it sends the service ticket to FileServer1, which reads User1‘s security credentials and constructs an access token accordingly.

Объект доверенного домена Trusted domain object

Каждое доверие домена или леса в организации представляется доверенным объектом домена (TDO), хранящимся в контейнере System в своем домене. Each domain or forest trust within an organization is represented by a Trusted Domain Object (TDO) stored in the System container within its domain.

Содержимое TDO TDO contents

Сведения, содержащиеся в объекте TDO, зависят от того, был ли объект TDO создан доверием домена или доверием леса. The information contained in a TDO varies depending on whether a TDO was created by a domain trust or by a forest trust.

При создании доверительных отношений домена атрибуты, такие как доменное имя DNS, идентификатор безопасности домена, тип доверия, транзитивность доверия и имя обратного домена, представлены в объекте TDO. When a domain trust is created, attributes such as the DNS domain name, domain SID, trust type, trust transitivity, and the reciprocal domain name are represented in the TDO. Доверительные отношения лесов ТДОС хранят дополнительные атрибуты для обнаружения всех доверенных пространств имен из леса партнера. Forest trust TDOs store additional attributes to identify all of the trusted namespaces from the partner forest. Эти атрибуты включают имена деревьев доменов, суффиксы имени участника-пользователя (UPN), суффиксы имени участника-службы (SPN) и ИДЕНТИФИКАТОРы безопасности (SID). These attributes include domain tree names, user principal name (UPN) suffixes, service principal name (SPN) suffixes, and security ID (SID) namespaces.

Так как отношения доверия хранятся в Active Directory как ТДОС, все домены в лесу имеют знания о доверительных отношениях, которые используются в лесу. Because trusts are stored in Active Directory as TDOs, all domains in a forest have knowledge of the trust relationships that are in place throughout the forest. Аналогично, если два или несколько лесов объединены через доверия лесов, корневые домены леса в каждом лесу имеют знания о доверительных отношениях, которые применяются во всех доменах в доверенных лесах. Similarly, when two or more forests are joined together through forest trusts, the forest root domains in each forest have knowledge of the trust relationships that are in place throughout all of the domains in trusted forests.

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

Оба домена в отношении доверия совместно используют пароль, который хранится в объекте TDO в Active Directory. Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory. В рамках процесса обслуживания учетной записи каждые 30 дней контроллер домена доверия изменяет пароль, хранящийся в объекте TDO. As part of the account maintenance process, every 30 days the trusting domain controller changes the password stored in the TDO. Так как все двусторонние отношения доверия фактически являются 2 1-сторонними отношениями доверия в противоположных направлениях, процесс выполняется дважды для двустороннего доверия. Because all two-way trusts are actually two one-way trusts going in opposite directions, the process occurs twice for two-way trusts.

Доверие имеет доверие и доверенную сторону. A trust has a trusting and a trusted side. На доверенной стороне для процесса можно использовать любой доступный для записи контроллер домена. On the trusted side, any writable domain controller can be used for the process. На стороне доверия эмулятор основного контроллера домена выполняет смену пароля. On the trusting side, the PDC emulator performs the password change.

Чтобы изменить пароль, контроллеры домена выполняют следующий процесс: To change a password, the domain controllers complete the following process:

Эмулятор основного контроллера домена (PDC) в доверяющем домене создает новый пароль. The primary domain controller (PDC) emulator in the trusting domain creates a new password. Контроллер домена в доверенном домене никогда не инициирует смену пароля. A domain controller in the trusted domain never initiates the password change. Он всегда инициируется эмулятором доверенного основного контроллера домена. It’s always initiated by the trusting domain PDC emulator.

Эмулятор основного контроллера домена в доверяющем домене задает поле OldPassword объекта TDO для текущего поля newPassword . The PDC emulator in the trusting domain sets the OldPassword field of the TDO object to the current NewPassword field.

Эмулятор основного контроллера домена в доверяющем домене задает для поля newPassword объекта TDO новый пароль. The PDC emulator in the trusting domain sets the NewPassword field of the TDO object to the new password. Сохранение копии предыдущего пароля позволяет вернуться к старому паролю, если контроллер домена в доверенном домене не сможет получить изменение или если изменение не реплицируется до выполнения запроса, использующего новый пароль доверия. Keeping a copy of the previous password makes it possible to revert to the old password if the domain controller in the trusted domain fails to receive the change, or if the change is not replicated before a request is made that uses the new trust password.

Эмулятор основного контроллера домена в доверяющем домене выполняет удаленный вызов контроллера домена в доверенном домене с просьбой установить для пароля учетной записи доверия новый пароль. The PDC emulator in the trusting domain makes a remote call to a domain controller in the trusted domain asking it to set the password on the trust account to the new password.

Контроллер домена в доверенном домене изменяет пароль доверия на новый пароль. The domain controller in the trusted domain changes the trust password to the new password.

На каждой стороне доверия обновления реплицируются на другие контроллеры домена в домене. On each side of the trust, the updates are replicated to the other domain controllers in the domain. В доверяющем домене это изменение активирует срочное репликация объекта доверенного домена. In the trusting domain, the change triggers an urgent replication of the trusted domain object.

Теперь пароль изменен на обоих контроллерах домена. The password is now changed on both domain controllers. Обычная репликация распространяет объекты TDO на другие контроллеры домена в домене. Normal replication distributes the TDO objects to the other domain controllers in the domain. Однако контроллер домена в доверяющем домене может изменить пароль без успешного обновления контроллера домена в доверенном домене. However, it’s possible for the domain controller in the trusting domain to change the password without successfully updating a domain controller in the trusted domain. Такая ситуация может возникнуть из-за того, что защищенный канал, необходимый для обработки изменения пароля, не удалось установить. This scenario might occur because a secured channel, which is required to process the password change, couldn’t be established. Также возможно, что контроллер домена в доверенном домене может быть недоступен в некоторый момент во время процесса и может не получить обновленный пароль. It’s also possible that the domain controller in the trusted domain might be unavailable at some point during the process and might not receive the updated password.

Для работы с ситуациями, когда изменение пароля не прошло успешно, контроллер домена в доверяющем домене никогда не изменяет новый пароль, если он не прошел проверку подлинности (Настройка защищенного канала) с помощью нового пароля. To deal with situations in which the password change isn’t successfully communicated, the domain controller in the trusting domain never changes the new password unless it has successfully authenticated (set up a secured channel) using the new password. Это объясняется тем, почему старый и новый пароли хранятся в объекте TDO доверяющего домена. This behavior is why both the old and new passwords are kept in the TDO object of the trusting domain.

Изменение пароля не завершается до тех пор, пока проверка подлинности с помощью пароля завершается с ошибкой. A password change isn’t finalized until authentication using the password succeeds. Старый, сохраненный пароль может использоваться по защищенному каналу до тех пор, пока контроллер домена в доверенном домене не получит новый пароль, что обеспечивает непрерывную работу службы. The old, stored password can be used over the secured channel until the domain controller in the trusted domain receives the new password, thus enabling uninterrupted service.

Если проверка подлинности с использованием нового пароля завершается неудачей из-за недействительного пароля, доверенный контроллер домена пытается пройти проверку подлинности с использованием старого пароля. If authentication using the new password fails because the password is invalid, the trusting domain controller tries to authenticate using the old password. Если проверка подлинности прошла успешно с прежним паролем, процесс смены пароля возобновляется в течение 15 минут. If it authenticates successfully with the old password, it resumes the password change process within 15 minutes.

Доверенные обновления паролей должны реплицироваться на контроллеры домена обеих сторон доверия в течение 30 дней. Trust password updates need to replicate to the domain controllers of both sides of the trust within 30 days. Если пароль доверия изменен через 30 дней, а контроллер домена имеет только пароль N-2, он не сможет использовать доверие с доверяющей стороны и не сможет создать безопасный канал на доверенной стороне. If the trust password is changed after 30 days and a domain controller only has the N-2 password, it cannot use the trust from the trusting side and cannot create a secure channel on the trusted side.

Сетевые порты, используемые отношениями доверия Network ports used by trusts

Так как отношения доверия должны развертываться в различных границах сети, они могут занимать один или несколько брандмауэров. Because trusts must be deployed across various network boundaries, they might have to span one or more firewalls. В этом случае можно либо подать трафик о доверии через брандмауэр, либо открыть определенные порты в брандмауэре, чтобы разрешить передачу трафика. When this is the case, you can either tunnel trust traffic across a firewall or open specific ports in the firewall to allow the traffic to pass through.

Домен Active Directory Services не поддерживает ограниченный трафик RPC Active Directory на определенные порты. Active Directory Domain Services does not support restricting Active Directory RPC traffic to specific ports.

Ознакомьтесь с разделом служба поддержки Майкрософт Windows Server 2008 и более поздних версий этой статьи, как настроить брандмауэр для Active Directory доменов и отношений доверия , чтобы узнать о портах, необходимых для доверия лесов. Read the Windows Server 2008 and later versions section of the Microsoft Support Article How to configure a firewall for Active Directory domains and trusts to learn about the ports needed for a forest trust.

Вспомогательные службы и средства Supporting services and tools

Для поддержки отношений доверия и проверки подлинности используются некоторые дополнительные функции и средства управления. To support trusts and authentication, some additional features and management tools are used.

Вход в сеть Net Logon

Служба сетевого входа в систему поддерживает защищенный канал с компьютера под управлением Windows на контроллер домена. The Net Logon service maintains a secured channel from a Windows-based computer to a DC. Он также используется в следующих процессах, связанных с отношениями доверия: It’s also used in the following trust-related processes:

Настройка доверия и управление — служба входа в сеть помогает поддерживать Доверенные пароли, собирает сведения о доверии и проверяет отношения доверия путем взаимодействия с процессом LSA и объектом TDO. Trust setup and management — Net Logon helps maintain trust passwords, gathers trust information, and verifies trusts by interacting with the LSA process and the TDO.

Для доверий лесов сведения о доверии включают запись о доверии лесов (фтинфо), включающую в себя набор пространств имен, которым должны управлять утверждения доверенного леса, с добавлением поля, которое указывает, доверяет ли каждое утверждение доверяющему лесу. For Forest trusts, the trust information includes the Forest Trust Information (FTInfo) record, which includes the set of namespaces that a trusted forest claims to manage, annotated with a field that indicates whether each claim is trusted by the trusting forest.

Проверка подлинности — предоставляет учетные данные пользователя по защищенному каналу на контроллер домена и возвращает идентификаторы SID домена и права пользователя для пользователя. Authentication – Supplies user credentials over a secured channel to a domain controller and returns the domain SIDs and user rights for the user.

Расположение контроллера домена — помогает найти или найти контроллеры домена в домене или в нескольких доменах. Domain controller location – Helps with finding or locating domain controllers in a domain or across domains.

Сквозная проверка — учетные данные пользователей в других доменах обрабатываются с помощью команды Net Logon. Pass-through validation – Credentials of users in other domains are processed by Net Logon. Если доверяющему домену необходимо проверить подлинность пользователя, он передает учетные данные пользователя с помощью команды Net Logon в доверенный домен для проверки. When a trusting domain needs to verify the identity of a user, it passes the user’s credentials through Net Logon to the trusted domain for verification.

Проверка сертификата атрибута прав доступа (PAC). когда сервер, использующий протокол Kerberos для проверки подлинности, должен проверить ключ PAC в билете службы, он отправляет PAC по безопасному каналу на контроллер домена для проверки. Privilege Attribute Certificate (PAC) verification – When a server using the Kerberos protocol for authentication needs to verify the PAC in a service ticket, it sends the PAC across the secure channel to its domain controller for verification.

Локальная система безопасности Local Security Authority

Локальный администратор безопасности (LSA) — это защищенная подсистема, которая хранит информацию обо всех аспектах локальной безопасности в системе. The Local Security Authority (LSA) is a protected subsystem that maintains information about all aspects of local security on a system. В совокупности называется локальной политикой безопасности, LSA предоставляет различные службы для перевода между именами и идентификаторами. Collectively known as local security policy, the LSA provides various services for translation between names and identifiers.

Подсистема безопасности LSA предоставляет службы как в режиме ядра, так и в пользовательском режиме для проверки доступа к объектам, проверки прав пользователей и создания сообщений аудита. The LSA security subsystem provides services in both kernel mode and user mode for validating access to objects, checking user privileges, and generating audit messages. LSA отвечает за проверку допустимости всех билетов сеансов, представленных службами в доверенных или недоверенных доменах. LSA is responsible for checking the validity of all session tickets presented by services in trusted or untrusted domains.

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

Администраторы могут использовать Active Directory домены и отношения доверия, netdom и nltest для предоставления, создания, удаления или изменения отношений доверия. Administrators can use Active Directory Domains and Trusts, Netdom and Nltest to expose, create, remove, or modify trusts.

• Active Directory домены и отношения доверия — это консоль управления (MMC), которая используется для управления доверительными отношениями домена, функциональными уровнями домена и леса и суффиксами имени участника-пользователя. Active Directory Domains and Trusts is the Microsoft Management Console (MMC) that is used to administer domain trusts, domain and forest functional levels, and user principal name suffixes.
• Программы командной строки netdom и nltest можно использовать для поиска, просмотра, создания и управления отношениями доверия. The Netdom and Nltest command-line tools can be used to find, display, create, and manage trusts. Эти средства напрямую взаимодействуют с полномочиями LSA на контроллере домена. These tools communicate directly with the LSA authority on a domain controller.

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

Дополнительные сведения о лесах ресурсов см . в статье как работают отношения доверия лесов в Azure AD DS? To learn more about resource forests, see How do forest trusts work in Azure AD DS?

Чтобы приступить к созданию управляемого домена с лесом ресурсов, см. статью Создание и Настройка управляемого домена AD DS Azure. To get started with creating a managed domain with a resource forest, see Create and configure an Azure AD DS managed domain. Затем можно создать исходящее доверие лесов для локального домена. You can then Create an outbound forest trust to an on-premises domain.