Принцип действия отношений доверия для лесов в Active Directory
Доменные службы Active Directory (AD DS) обеспечивают безопасность в нескольких доменах или лесах с помощью отношений доверия между доменами и лесами. Перед проверкой подлинности в отношениях доверия операционная система Windows должна сначала проверить, имеет ли домен, запрашиваемый пользователем, компьютером или службой, отношение доверия с доменом запрашивающей учетной записи.
Чтобы проверить это отношение доверия, система безопасности Windows вычислит путь доверия между контроллером домена для сервера, получающего запрос, и контроллером домена в домене запрашивающей учетной записи.
Механизмы управления доступом, предусмотренные в AD DS и распределенной модели безопасности Windows, предоставляют среду для работы отношений доверия между доменами и лесами. Для правильной работы этих отношений доверия каждый ресурс или компьютер должен иметь прямой путь доверия к контроллеру домена в том домене, где он находится.
Путь доверия реализуется службой сетевого входа в систему с помощью подключения удаленного вызова процедур (RPC), прошедшего проверку подлинности, к центру доверенного домена. Защищенный канал также распространяется на другие домены AD DS через междоменные отношения доверия. Этот защищенный канал используется для получения и проверки сведений о безопасности, в том числе идентификаторов безопасности (SID) для пользователей и групп.
Примечание.
Доменные службы поддерживают несколько направлений доверия леса, включая двустороннее доверие и односторонняя доверия, которые могут быть входящими или исходящими.
Общие сведения о том, как отношения доверия применяются к доменным службам, см . в разделе "Основные понятия и функции леса".
Чтобы приступить к использованию доверия в доменных службах, создайте управляемый домен, использующий доверие леса.
Потоки отношений доверия
Поток передаваемых защищенных данных через отношения доверия определяет эластичность доверия. От того, как вы создаете или настраиваете отношения доверия, зависит, насколько далеко распространяется связь между лесами.
Поток данных, передаваемых через отношения доверия, определяется направлением доверия. Отношения доверия могут быть односторонними или двусторонними, транзитивными или нетранзитивными.
На следующей схеме показано, что по умолчанию все домены в дереве 1 и дереве 2 имеют транзитивные отношения доверия. В результате пользователи в дереве 1 могут получить доступ к ресурсам в доменах дерева 2, а пользователи в дереве 1 могут получить доступ к ресурсам в дереве 2, если в ресурсе назначены соответствующие разрешения.
Односторонние и двусторонние отношения доверия
Отношения доверия обеспечивают доступ к ресурсам в одном или двух направлениях.
Одностороннее доверие — это однонаправленный путь проверки подлинности, который создается между двумя доменами. При одностороннем доверии между доменом А и доменом Б пользователи в домене А могут получить доступ к ресурсам в домене Б. Однако пользователи в домене Б не могут получить доступ к ресурсам в домене А.
В зависимости от типа создаваемого доверия некоторые односторонние отношения доверия могут быть нетранзитивными или транзитивными.
При двустороннем доверии домен А доверяет домену Б, а домен Б доверяет домену А. Такая конфигурация означает, что запросы проверки подлинности могут передаваться между двумя доменами в обоих направлениях. В зависимости от типа создаваемого доверия некоторые двусторонние отношения доверия могут быть нетранзитивными или транзитивными.
Все отношения доверия домена в локальном лесу 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 (доверяющий лес) справедливо следующее:
- члены леса 1 могут получить доступ к ресурсам, расположенным в лесу 2;
- члены леса 2 не могут получить доступ к ресурсам, расположенным в лесу 1, используя то же отношение доверия.
Важно!
Доменные службы Microsoft Entra поддерживают несколько направлений для доверия лесов.
Требования к доверию лесов
Чтобы можно было создать доверие лесов, необходимо убедиться в наличии правильной инфраструктуры службы доменных имен (DNS). Отношения доверия лесов можно создавать только при наличии одной из следующих конфигураций DNS:
Единственный корневой DNS-сервер — это корневой DNS-сервер для обоих пространств имен DNS леса. Корневая зона содержит делегирования для каждого пространства имен DNS, а корневые указания всех DNS-серверов включают корневой DNS-сервер.
Если общий корневой DNS-сервер и корневые DNS-серверы для каждого из пространств имен DNS леса отсутствуют, используйте серверы условной пересылки для каждого из пространств имен DNS, чтобы маршрутизировать запросы имен к другому пространству имен.
Важно!
Любой лес доменных служб Microsoft Entra с доверием должен использовать эту конфигурацию DNS. Размещение пространства имен DNS, отличного от пространства имен DNS леса, не является функцией доменных служб Microsoft Entra. Серверы условной пересылки — это правильная конфигурация.
Если общий корневой DNS-сервер и корневые DNS-серверы для каждого из пространств имен DNS леса отсутствуют, используют дополнительные зоны DNS, настроенные в каждом из пространств имен DNS, для маршрутизации запросов имен к другому пространству имен.
Чтобы создать доверие леса в AD DS, необходимо быть членом группы доменных Администратор (в корневом домене леса) или группой корпоративных Администратор в Active Directory. Каждому отношению доверия назначается пароль, который должен быть известен администраторам в обоих лесах. Участники группы "Администраторы предприятия" в обоих лесах могут создавать отношения доверия в обоих лесах одновременно. В этом случае для обоих лесов автоматически создается и записывается криптографически случайный пароль.
Лес управляемого домена поддерживает до пяти односторонних исходящих отношений доверия с локальными лесами. Доверие к исходящему лесу для доменных служб Microsoft Entra создается в Центре администрирования Microsoft Entra. Входящее отношение доверия лесов должно быть настроено пользователем с привилегиями, которые ранее были указаны в локальной службе Active Directory.
Процессы и взаимодействия доверия
Выполнение различных задач в рамках многих транзакций между доменами и лесами зависит от отношений доверия между ними. В этом разделе описываются процессы и взаимодействия, происходящие при доступе к ресурсам с использованием различных отношений доверия и проверке ссылок для проверки подлинности.
Общие сведения об обработке ссылок для проверки подлинности
Если запрос на проверку подлинности пересылается в домен, контроллер домена в этом домене должен определить, существует ли отношение доверия с доменом, из которого этот запрос поступил. Кроме того, прежде чем проверять подлинность пользователя для доступа к ресурсам в домене, необходимо определить, является ли доверие транзитивным или нетранзитивным. Процесс проверки подлинности, который выполняется между доверенными доменами, зависит от используемого протокола проверки подлинности. Протоколы Kerberos версии 5 и NTLM обрабатывают ссылки для проверки подлинности в домене по-разному.
Обработка ссылок в Kerberos версии 5
Протокол проверки подлинности Kerberos версии 5 зависит от службы сетевого входа в систему на контроллерах домена, используемых для получения сведений о проверке подлинности и авторизации клиента. Протокол Kerberos подключается к сетевому центру распространения ключей (KDC) и хранилищу учетных записей Active Directory для получения билетов сеансов.
Протокол Kerberos также использует отношения доверия для служб предоставления билетов (TGS) между областями и проверки сертификатов атрибутов привилегий (PAC) в защищенном канале. Протокол Kerberos выполняет проверку подлинности между областями только при использовании областей Kerberos операционных систем, отличных от Windows, таких как область MIT Kerberos, и не требует взаимодействия со службой сетевого входа в систему.
Если клиент использует Kerberos версии 5 для проверки подлинности, он запрашивает билет для сервера в целевом домене у контроллера домена в домене учетной записи. Kerberos KDC выступает в качестве доверенного посредника между клиентом и сервером и предоставляет ключ сеанса, позволяющий двум сторонам проходить проверку подлинности друг у друга. Если целевой домен отличается от текущего, KDC следует приведенному ниже логическому процессу, позволяющему определить, можно ли ссылаться на запрос на проверку подлинности.
Является ли текущий домен доверенным непосредственно для запрашиваемого домена сервера?
- Если да, клиенту отправляется ссылка на запрошенный домен.
- Если нет, выполняется переход к следующему шагу.
Существует ли между текущим доменом и следующим по пути доверия доменом отношение транзитивного доверия?
- Если да, клиенту отправляется ссылка на следующий домен по пути доверия.
- Если нет, клиенту отправляется сообщение об отклонении входа.
Обработка ссылок NTLM
Протокол проверки подлинности NTLM зависит от службы сетевого входа в систему на контроллерах домена, используемых для получения сведений о проверке подлинности и авторизации клиента. Этот протокол применяется для проверки подлинности клиентов, не использующих проверку подлинности Kerberos. NTLM использует отношения доверия для передачи запросов проверки подлинности между доменами.
Если клиент использует NTLM для проверки подлинности, первоначальный запрос на проверку подлинности передается непосредственно от клиента к серверу ресурсов в целевом домене. Этот сервер создает запрос защиты, на который отвечает клиент. Затем сервер отправляет ответ пользователя на контроллер домена в домене учетной записи его компьютера. Этот контроллер домена проверяет учетную запись пользователя по базе данных учетных записей системы безопасности.
Если учетная запись в базе данных отсутствует, контроллер домена определяет, следует ли выполнить сквозную проверку подлинности, перенаправить запрос или отклонить его, придерживаясь приведенной ниже логики.
Имеет ли текущий домен отношение прямого доверия с доменом пользователя?
- Если да, контроллер домена отправляет учетные данные клиента на контроллер домена в домене пользователя для сквозной проверки подлинности.
- Если нет, выполняется переход к следующему шагу.
Имеет ли текущий домен отношение транзитивного доверия с доменом пользователя?
- Если да, запрос на проверку подлинности передается в следующий домен по пути доверия. Этот контроллер домена повторяет процесс, проверяя учетные данные пользователя по собственной базе данных учетных записей системы безопасности.
- Если нет, клиенту отправляется сообщение об отклонении входа.
Обработка запросов на проверку подлинности на основе Kerberos через отношения доверия лесов
Если между двумя лесами существуют отношения доверия, между ними можно направлять запросы на проверку подлинности по протоколам Kerberos версии 5 и NTLM для предоставления доступа к ресурсам в обоих лесах.
При первом установлении доверия между лесами каждый лес собирает информацию обо всех доверенных пространствах имен в лесу своего партнера и сохраняет ее в объекте доверенного домена. Доверенные пространства имен включают в себя имена доменных деревьев, суффиксы имени субъекта-пользователя, суффиксы имени субъекта-службы и пространства имен идентификаторов безопасности (SID) в другом лесу. Объекты доверенного домена реплицируются в глобальный каталог.
Примечание.
Альтернативные суффиксы имени участника-пользователя в отношениях доверия не поддерживаются. Если локальный домен использует тот же суффикс имени участника-пользователя, что и доменные службы, вход должен использовать sAMAccountName.
Чтобы протоколы проверки подлинности могли следовать пути доверия лесов, имя субъекта-службы (SPN) компьютера ресурсов должно быть разрешено в расположение в другом лесу. Имя субъекта-службы может принадлежать к одному из следующих типов:
- DNS-имя узла;
- DNS-имя домена;
- различающееся имя объекта точки подключения службы.
Когда рабочая станция в одном лесу пытается получить доступ к данным на компьютере ресурсов в другом лесу, процесс проверки подлинности Kerberos обращается к контроллеру домена для получения билета службы на имя субъекта-службы компьютера ресурсов. Когда контроллер домена отправляет запрос в глобальный каталог и определяет, что имя субъекта-службы не находится в том же лесу, что и контроллер домена, он отправляет ссылку для своего родительского домена обратно на рабочую станцию. На этом этапе рабочая станция запрашивает у родительского домена билет службы и продолжает следовать по цепочке ссылок, пока не достигнет домена, в котором находится ресурс.
Приведенная ниже схема и шаги содержат подробное описание процесса проверки подлинности Kerberos, используемого при попытке компьютеров с ОС Windows получить доступ к ресурсам с компьютера, находящегося в другом лесу.
Пользователь User1 входит на рабочую станцию Workstation1, используя учетные данные из домена europe.tailspintoys.com. Затем пользователь пытается получить доступ к общему ресурсу на сервере FileServer1, расположенном в лесу usa.wingtiptoys.com.
Рабочая станция Workstation1 связывается с центром распространения ключей Kerberos на контроллере домена ChildDC1 в своем домене и запрашивает билет службы на имя субъекта-службы FileServer1.
ChildDC1 не находит имя субъекта-службы в базе данных своего домена и запрашивает глобальный каталог, чтобы определить, есть ли такое имя субъекта-службы в каких-либо других доменах в лесу tailspintoys.com. Поскольку глобальный каталог ограничивается собственным лесом, имя субъекта-службы не найдено.
Затем глобальный каталог проверяет свою базу данных на наличие сведений об отношениях доверия лесов, установленных с его лесом. Если они найдены, он сравнивает суффиксы имен, перечисленные в объекте доверенного домена в отношении доверия лесов, с суффиксом целевого имени субъекта-службы для поиска соответствия. После обнаружения совпадения глобальный каталог предоставляет указание для маршрутизации обратно в ChildDC1.
Указания для маршрутизации помогают направлять запросы проверки подлинности в лес назначения. Указания используются только в случае, если ни один из традиционных каналов проверки подлинности, например локальный контроллер домена и глобальный каталог, не позволили отыскать имя субъекта-службы.
ChildDC1 отправляет ссылку на свой родительский домен обратно на рабочую станцию Workstation1.
Workstation1 связывается с контроллером домена в ForestRootDC1 (его родительском домене) для получения ссылки на контроллер домена (ForestRootDC2) в корневом домене леса wingtiptoys.com.
Workstation1 связывается с ForestRootDC2 в лесу wingtiptoys.com, чтобы получить билет службы для запрошенной службы.
ForestRootDC2 связывается со своим глобальным каталогом, чтобы найти имя субъекта-службы, а глобальный каталог находит совпадение для имени субъекта-службы и отправляет его обратно в ForestRootDC2.
Затем ForestRootDC2 отправляет ссылку на usa.wingtiptoys.com обратно на рабочую станцию Workstation1.
Workstation1 связывается с центром распространения ключей в ChildDC2 и согласовывает билет для пользователя User1, чтобы получить доступ к FileServer1.
Когда рабочая станция Workstation1 получает билет службы, она отправляет его на сервер FileServer1, который считывает учетные данные для обеспечения безопасности пользователя User1 и соответствующим образом формирует маркер доступа.
Объект доверенного домена
Каждое отношение доверия домена или леса в организации представляется объектом доверенного домена, хранящимся в системном контейнере в своем домене.
Содержимое объекта доверенного домена
Сведения, содержащиеся в объекте доверенного домена, зависят от того, на какой основе отношения доверия создан этот объект: домена или леса.
При создании отношения доверия домена в объекте доверенного домена указываются такие атрибуты, как доменное имя DNS, идентификатор безопасности домена, тип доверия, транзитивность доверия и доменное имя для возврата. Объекты доверенного домена в отношениях доверия леса хранят дополнительные атрибуты для идентификации всех доверенных пространств имен из партнерского леса. Эти атрибуты включают в себя имена доменных деревьев, суффиксы имени субъекта-пользователя, суффиксы имени субъекта-службы и пространства имен идентификатора безопасности (SID).
Так как все отношения доверия в лесу хранятся в Active Directory в виде объектов доверенных доменов, о них известно всем доменам в этому лесу. Аналогично, если два или более лесов объединены отношениями доверия лесов, корневым доменам леса в каждом лесу известно об отношениях доверия, установленных между всеми доменами в доверенных лесах.
Изменения пароля объекта доверенного домена
Для обоих доменов в отношении доверия используется один и тот же пароль, который хранится в объекте доверенного домена в Active Directory. В рамках процесса обслуживания учетной записи каждые 30 дней контроллер домена доверия изменяет пароль, хранящийся в объекте доверенного домена. Так как все двусторонние отношения доверия фактически являются двумя односторонними отношениями доверия с противоположными направлениями, для двустороннего доверия процесс выполняется дважды.
Отношение доверия имеет доверяющую и доверенную стороны. На доверенной стороне для процесса можно использовать любой доступный для записи контроллер домена. На доверяющей стороне смену пароля выполняет эмулятор основного контроллера домена.
Чтобы изменить пароль, контроллеры домена выполняют следующий процесс:
Эмулятор основного контроллера домена в доверяющем домене создает новый пароль. Контроллер домена в доверенном домене никогда не инициирует смену пароля. Она всегда инициируется эмулятором основного контроллера домена доверяющего домена.
Эмулятор основного контроллера домена в доверяющем домене задает в качестве значения поля OldPassword объекта доверенного домена значение текущего поля NewPassword.
Эмулятор основного контроллера домена в доверяющем домене задает в качестве значения поля NewPassword объекта доверенного домена новый пароль. Сохранение копии предыдущего пароля позволяет вернуться к прежнему паролю, если контроллер домена в доверенном домене не сможет получить изменение или если изменение не реплицируется до выполнения запроса, использующего новый пароль отношения доверия.
Эмулятор основного контроллера домена в доверяющем домене выполняет удаленный вызов контроллера домена в доверенном домене, запрашивая замену пароля для учетной записи доверия на новый пароль.
Контроллер домена в доверенном домене изменяет пароль отношения доверия на новый.
На каждой стороне отношения доверия обновления реплицируются на другие контроллеры домена в домене. В доверяющем домене это изменение активирует срочную репликацию объекта доверенного домена.
Теперь пароль изменен на обоих контроллерах домена. Обычная репликация распространяет объекты доверенного домена на другие контроллеры домена в домене. Однако при изменении пароля контроллером домена в доверяющем домене может не обновиться нужным образом пароль на контроллере домена в доверенном домене. Такая ситуация может возникнуть, если не удалось установить защищенный канал, необходимый для обработки изменения пароля. Кроме того, контроллер домена в доверенном домене может оказаться недоступным на каком-то этапе выполнения процесса и не получить обновленный пароль.
Чтобы избежать ситуаций, когда не удается уведомить об изменении пароля, контроллер домена в доверяющем домене никогда не изменяет новый пароль, если он не прошел проверку подлинности (настройку защищенного канала) с помощью этого нового пароля. Именно поэтому в объекте доверенного домена доверяющего домена хранятся и прежний, и новый пароли.
Изменение пароля не завершается до тех пор, пока не будет успешно пройдена проверка подлинности с помощью этого пароля. Прежний сохраненный пароль может использоваться по защищенному каналу до тех пор, пока контроллер домена в доверенном домене не получит новый пароль, что обеспечивает непрерывную работу службы.
Если проверка подлинности с использованием нового пароля завершается сбоем из-за недействительного пароля, контроллер доверяющего домена пытается пройти проверку подлинности с использованием прежнего пароля. Если проверка подлинности с прежним паролем прошла успешно, процесс смены пароля возобновляется в течение 15 минут.
Обновления пароля отношения доверия должны реплицироваться на контроллеры домена обеих сторон доверия в течение 30 дней. Если пароль доверия изменен через 30 дней, а на контроллере домена имеется только пароль N–2, он не сможет использовать доверие доверяющей стороны и не сможет создать защищенный канал на доверенной стороне.
Сетевые порты, используемые отношениями доверия
Так как отношения доверия должны развертываться с пересечением границ сетей, они могут распространяться на один или несколько брандмауэров. В этом случае можно либо туннелировать доверенный трафик через брандмауэр, либо открыть определенные порты в брандмауэре, чтобы разрешить его передачу.
Важно!
Доменные службы Active Directory не поддерживают ограничение трафика удаленного вызова процедур Active Directory определенными портами.
Ознакомьтесь с разделом Windows Server 2008 и более поздних версий статьи службы поддержки Майкрософт Настройка брандмауэра для доменов и отношений доверия Active Directory, чтобы узнать о портах, необходимых для доверия лесов.
Вспомогательные службы и средства
Для поддержки отношений доверия и проверки подлинности используются дополнительные функции и средства управления.
Вход в сеть
Служба сетевого входа в систему поддерживает установку защищенного канала с компьютера с ОС Windows к контроллеру домена. Она также используется в следующих процессах, связанных с отношениями доверия:
Настройка доверия и управление им. Служба сетевого входа в систему помогает поддерживать пароли отношения доверия в актуальном состоянии, собирает сведения о доверии и проверяет отношения доверия путем взаимодействия с процессом локальной системы безопасности и объектом доверенного домена.
Для отношений доверия лесов сведения о доверии содержат запись о доверии лесов (FTInfo), включающую в себя набор пространств имен, на управление которыми с помощью утверждений претендует доверенный лес, с добавлением поля, которое указывает, доверяет ли доверяющий лес каждому такому утверждению.
Проверка подлинности. При ее выполнении учетные данные пользователя предоставляются контроллеру домена по защищенному каналу, а в ответ возвращаются идентификаторы SID домена и права пользователя.
Определение расположения контроллера домена. Этот процесс помогает найти контроллеры домена в одном или нескольких доменах или определить их расположение.
Сквозная проверка. Учетные данные пользователей в других доменах обрабатываются функцией сетевого входа. Если доверяющему домену необходимо проверить удостоверение пользователя, он передает в доверенный домен учетные данные этого пользователя для проверки с помощью функции сетевого входа в систему.
Проверка сертификата атрибутов привилегий (PAC). Когда серверу, использующему протокол Kerberos для проверки подлинности, необходимо проверить сертификат атрибутов привилегий в билете службы, он отправляет этот сертификат по защищенному каналу на контроллер домена для проверки.
Локальная система безопасности
Локальная система безопасности — это защищенная подсистема, которая хранит информацию обо всех аспектах локальной безопасности в системе. В совокупности она называется локальной политикой безопасности. Локальная система безопасности предоставляет различные службы для преобразования имен и идентификаторов.
Подсистема безопасности локальной системы безопасности предоставляет службы для проверки доступа к объектам, проверки прав пользователей и создания сообщений аудита как в режиме ядра, так и в пользовательском режиме. Локальная система безопасности отвечает за проверку допустимости всех билетов сеансов, представленных службами в доверенных или недоверенных доменах.
Средства управления
Для предоставления, создания, удаления или изменения отношений доверия администраторы могут использовать домены Active Directory и отношения доверия, Netdom и Nltest.
- Домены Active Directory и отношения доверия — это консоль управления (MMC), которую можно использовать для администрирования отношений доверия доменов, уровней работы домена и леса, а также суффиксов имени субъекта-пользователя.
- Программы командной строки Netdom и Nltest можно использовать для поиска, просмотра и создания отношений доверия и управления ими. Эти средства напрямую взаимодействуют с Локальной системой безопасности на контроллере домена.
Следующие шаги
Чтобы приступить к созданию управляемого домена с доверием леса, см. статью "Создание и настройка управляемого домена доменных служб". Затем можно создать исходящее отношение доверия леса с локальным доменом.