как проверить доверительные отношения с доменом
Настройка доверительных отношений между доменами Active Directory
Для возможности аутентификации с использованием учетных записей из нескольких доменов, необходимо, чтобы были доверительные отношения между последними. При создании домена в структуре леса, доверие выстраивается автоматически. Но если мы хотим объединить два домена разных организаций или которые раньше работали независимо друг от друга, то необходимо настроить доверительные отношения.
Мы будем рассматривать процесс настройки на примере двустороннего транзитивного доверия между доменами primary.local (192.168.0.15) и secondary.local (192.168.0.16). Саму настройку разделим на 2 этапа — конфигурирование DNS и создания доверий. В качестве операционной системы по данной инструкции можно настроить Windows Server 2008 / 2012 / 2016 / 2019.
Определяемся с типом доверительных отношений
Доверительные отношению могут быть разных типов. Перед тем, как их настроить, нужно понять, какие нам требуются.
Одностороннее или двустороннее
Определяют направление доверия одного домена к другому.
В односторонних отношениях, только один домен доверяет другому. В результате, на компьютерах одного из доменов можно будет авторизоваться с использованием пользователей другого. При создании такого доверия нужно указать также направление (входящее или исходящее) — оно определяет чьи пользователи смогут проходить аутентификацию на чьем домене.
В двусторонних отношениях домены доверяют друг другу. Таким образом, аутентификация выполняется на всех компьютерах под пользователями любого из доменов.
Внешнее или доверие леса
Внешнее или нетранзитивное отношение устанавливается между двумя доменами напрямую вне леса.
Доверие леса или транзитивное отношение связывает леса и все их домены.
Настройка DNS
Для построения доверия необходимо, чтобы контроллеры домена видели друг друга. Все запросы на поиск узлов в AD выполняются через службы доменных имен. Таким образом, в нашем примере, мы должны сконфигурировать условную пересылку на DNS обоих доменов. Также важно, чтобы между контроллерами была сетевая доступность — по сети они должны видеть друг друга.
На DNS домена primary.local
Открываем командную строку и вводим команду:
Мы должны получить ответ на подобие:
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: secondary.local
Address: 192.168.0.16
На DNS домена secondary.local
Действия, которые делаем на втором сервере DNS, во многом, аналогичны.
В командной строке второго сервера проверяем настройку:
Мы должны получить ответ на подобие:
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: primary.local
Address: 192.168.0.15
Настройка доверительных отношений
После настройки DNS можно переходить к созданию доверительных отношений.
В окне «Направление отношения доверия» выбираем Двустороннее:
. и нажимаем Далее.
В следующем окне выбираем, на каком из доменов мы применяем настройку — если у нас есть права администратора для обоих доменов, то выбираем Для данного и указанного доменов:
* если мы являемся администратором одного из доменов, а вторым доменом управляет другой специалист, то выбираем Только для данного домена. Подобные действия должен выполнить второй администратор в своем домене.
На следующем этапе система свяжется со вторым контроллером домена, и если он доступен, запросит логин и пароль от пользователя с правами установки доверительных отношений во втором домене. Вводим данные пользователя и нажимаем Далее.
Далее нужно выбрать «Уровень проверки подлинности исходящего доверия» — если оба домена принадлежат нашей организации, предпочтительнее выбрать Проверка подлинности в лесу, чтобы предоставить доступ ко всем ресурсам:
В окне «Подтверждение исходящего доверия» оставляем Нет, не подтверждаю это исходящее доверие, так как на другой стороне нами не создавалось доверия.
Тоже самое в окне «Подтверждение входящего доверия».
Нажимаем Готово — доверительные отношения созданы.
Восстановление доверительных отношений между рабочей станцией и доменом AD
В этой статье мы рассмотрим проблему нарушения доверительных отношений между рабочей станцией и доменом Active Directory, из-за которой пользователь не может авторизоваться на компьютере. Рассмотрим причину проблемы и простой способ восстановления доверительных отношений компьютера с контроллером домена по безопасному каналу без перезагрузки компьютера.
Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом
Как проявляется проблема: пользователь пытается авторизоваться на рабочей станции или сервере под своей учетной запись и после ввода пароля появляется ошибка:
Также ошибка может выглядеть так:
Пароль учетной записи компьютера в домене Active Directory
Когда компьютер вводится в домен Active Directory, для него создается отдельная учетная запись типа computer. У каждого компьютера в домене, как и у пользователей есть свой пароль, который необходим для аутентификации компьютера в домене и установления доверенного подключения к контроллеру домена. Однако, в отличии от паролей пользователя, пароли компьютеров задаются и меняются автоматически.
Несколько важных моментов, касающихся паролей компьютеров в AD:
Если хэш пароля, который компьютер отправляет контроллеру домена не совпадает с паролем учетной записи компьютера, компьютер не может установить защищённое подключение к DC и выдает ошибки о невозможности установить доверенное подключение.
Почему это может произойти:
Классический способ восстановить доверительных отношений компьютера с доменом в этом случае:
Этот метод кажется простым, но слишком топорный и требует, как минимум двух перезагрузок компьютера, и 10-30 минут времени. Кроме того, могут возникнуть проблемы с использованием старых локальных профилей пользователей.
Есть более элегантный способ восстановить доверительные отношения с помощью PowerShell без перевключения в домен и без перезагрузок компьютера.
Проверка и восстановление доверительного отношения компьютера с доменом с помощью PowerShell
Если вы не можете аутентифицироваться на компьютере под доменной учетной записью с ошибкой “Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом”, вам нужно войти на компьютер под локальной учетной записью с правами администратора. Также можно отключить сетевой кабель и авторизоваться на компьютере под доменной учетной записью, которая недавно заходила на этот компьютер, с помощью кэшированных учетных данных (Cached Credentials).
Откройте консоль PowerShell и с помощью командлета Test-ComputerSecureChannel проверьте соответствует ли локальный пароль компьютера паролю, хранящемуся в AD.
Не удалось установить доверительные отношения
Оглавление
Введение
Привет! Бывает такое, что требуется восстановить компьютер или сам контроллер домена из точки восстановления/снэпшота (если это виртуальная машина). И частенько это приводит к потере доверительных отношений между компьютером и доменом. Мы получаем ошибку:
Не удалось восстановить доверительные отношения между рабочей станцией и доменом.
Или в английском варианте: The trust relationship between this workstation and the primary domain failed.
База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией.
В английском варианте: The security database on the server does not have a computer account for this workstation trust relationship.
Для того, чтобы восстановить доверительные отношения можно пойти тремя способами. Давайте их рассмотрим ниже.
Да, для того чтобы восстановить доверительные отношения с доменом необходимо на компьютер зайти под локальной учётной записью. Если доступа к локальной учётной записи нет, то необходимо сбросить пароль Windows.
Восстановить доверительные отношения путём повторного ввода в домен
Самый долгий, но самый верный способ, который поможет восстановить доверительные отношения с доменом при любом раскладе! Работет железебетонно 😎.
Как восстановить доверительные отношения через PowerShell
Если компьютеру не удалось установить доверительные отношения с доменом, то их можно восстановить без перезагрузки компьютера прямо из PowerShell.
У этого способа есть один минус. Он не работает на старых системах, так что у кого до сих пор Windows XP 😨, то сносите это гавно мамонта и установите нормальную ось переходите сразу к следующему способу.
Если False – то нет доверия этому компьютеру 😆; если True – то всё в порядке. Если у вас ошибка: не удалось установить доверительные отношения то скорее всего вы увидите False. Для того, чтобы восстановить доверительные отношения в домене необходмио cбросить канал между локальным компьютером и его доменом командой:
Если не сработала команда выше, то используйте другую команду (с запросом учётных данных):
В этом случае будет запрошен логин и пароль администратора домена. Вводим его и подтверждаем сброс канала.
Поздавляю! Вам удалось восстановить доверительные отношения в домене. Это можно проверить выполнив эту же команду с ключом –verbose:
И в заключение хочу добавить:
Если в у вас несколько контроллеров домена, то проверить канал между локальным компьютером и конкретным контроллером домена можно выполнив команду:
Где dc-03.itlocate.ru – ваш контроллер домена.
Как восстановить доверительные отношения через командную строку (cmd)
Где dc-03 – контроллер домена; admin – учётная запись администратора домена; pass – пароль от этой учётной записи.
Теперь ошибка Не удалось установить доверительные отношения устарнена до следующего отката системы с точки восстановления 😅.
Восстанавливаем доверие в домене
Как и учетные записи пользователей, учетные записи компьютеров в домене имеют свой пароль. Пароль этот нужен для установления так называемых «доверительных отношений» между рабочей станцией и доменом. Пароли для компьютеров генерируются автоматически и также автоматически каждые 30 дней изменяются.
Для восстановления доверительных отношений существует несколько способов. Рассмотрим их все по порядку.
Способ первый
Открываем оснастку «Active Directory Users and Computers» и находим в ней нужный компьютер. Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «Reset Account». Затем заходим на компьютер под локальной учетной записью и заново вводим его в домен.
Примечание. Кое где встречаются рекомендации удалить компьютер из домена и заново завести. Это тоже работает, однако при этом компьютер получает новый SID и теряет членство в группах, что может привести к непредсказуемым последствиям.
Способ этот довольно громоздкий и небыстрый, т.к. требует перезагрузки, однако работает в 100% случаев.
Способ второй
Заходим на компьютер, которому требуется сбросить пароль, открываем командную консоль обязательно от имени администратора и вводим команду:
Netdom Resetpwd /Server:SRV1 /UserD:Administrator /PasswordD:*
где SRV1 — контролер домена, Administrator — административная учетная запись в домене. Дополнительно можно указать параметр /SecurePasswordPrompt, который указывает выводить запрос пароля в специальной форме.
В открывшемся окне вводим учетные данные пользователя и жмем OK. Пароль сброшен и теперь можно зайти на компьютер под доменной учетной записью. Перезагрузка при этом не требуется.
Что интересно, в рекомендациях по использованию и в справке написано, что команду Netdom Resetpwd можно использовать только для сброса пароля на контролере домена, другие варианты использования не поддерживаются. Однако это не так, и команда также успешно сбрасывает пароль на рядовых серверах и рабочих станциях.
Еще с помощью Netdom можно проверить наличие безопасного соединения с доменом:
Netdom Verify WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*
Или сбросить учетную запись компьютера:
Netdom Reset WKS1 /Domain:Contoso.com /UserO:Administrator /PasswordO:*
где WKS1 — рабочая станция, которой сбрасываем учетку.
Способ достаточно быстрый и действенный, однако есть одно но: по умолчанию утилита Netdom есть только на серверах с установленной ролью Active Directory Domain Services (AD DS). На клиентских машинах она доступна как часть пакета удаленного администрирования Remote Server Administration Tools (RSAT).
Способ третий
Еще одна утилита командной строки — Nltest. На компьютере, который потерял доверие, выполняем следующие команды:
Nltest /query — проверить безопасное соединение с доменом;
Nltest /sc_reset:Contoso.com — сбросить учетную запись компьютера в домене;
Nltest /sc_change_pwd:Contoso.com — изменить пароль компьютера.
Самый быстрый и доступный способ, ведь утилита Nltest по умолчению есть на любой рабочей станции или сервере. Однако, в отличие от Netdom, в которой предусмотрен ввод учетных данных, Nltest работает в контексте запустившего ее пользователя. Соответственно, зайдя на компьютер под локальной учетной записью и попытавшись выполнить команду можем получить ошибку доступа.
Способ четвертый
PowerShell тоже умеет сбрасывать пароль копьютера и восстанавливать безопасное соеднение с доменом. Для этого существует командлет Test-ComputerSecureChannel . Запущенный без параметров он выдаст состояние защищенного канала — True или False.
Для сброса учетной записи компьютера и защищенного канала можно использовать такую команду:
где SRV1 — контролер домена (указывать не обязательно).
Для сброса пароля также можно также воспользоваться такой командой:
Как видите, способов восстановления доверительных отношений более чем достаточно. Однако если проблема приобретает постоянный характер, то проще подойти к ее решению с другой стороны.
Изменение параметров смены пароля компьютера
Смена пароля в домене происходит следующим образом:
Каждые 30 дней рабочая станция отправляет ближайшему контролеру домена запрос на изменение пароля учетной записи компьютера. Контролер принимает запрос, пароль изменяется, а затем изменения передаются на все контролеры в домене при следующей репликации.
Некоторые параметры смены пароля можно изменять. Например, можно изменить временной интервал или совсем отключить смену паролей. Сделать это можно как для отдельных компьютеров, так и для групп.
Если настройки необходимо применить к группе компьютеров, то проще всего использовать групповую политику. Настройки, отвечающие за смену паролей, находятся в разделе Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options. Нас интересуют следующие параметры:
Disable machine account password change — отключает на локальной машине запрос на изменение пароля;
Maximum machine account password age — определяет максимальный срок действия пароля компьютера. Этот параметр определяет частоту, с которой член домена будет пытаться изменить пароль. По умолчанию срок составляет 30 дней, максимально можно задать 999 дней;
Refuse machine account password changes — запрещает изменение пароля на контролерах домена. Если этот параметр активировать, то контролеры будут отвергать запросы компьютеров на изменение пароля.
Для одиночной машины можно воспользоваться настройками реестра. Для этого в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters есть два параметра :
DisablePasswordChange — если равен 1, то запрос на обновление пароля компьютера отключен, 0 — включен.
И в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, только у контролеров домена, параметр:
RefusePasswordChange — если равен 1, то запрещает контролеру домена принимать запрос на изменение пароля. Этот параметр надо задать на всех контролерах в домене.
Вот вроде и все про доверительные отношения. Как видите, доверие в домене — штука тонкая, так что старайтесь его не терять.
Принцип действия отношений доверия для лесов ресурсов в доменных службах Azure Active Directory
Доменные службы Active Directory (AD DS) обеспечивают безопасность в нескольких доменах или лесах с помощью отношений доверия между доменами и лесами. Перед проверкой подлинности в отношениях доверия операционная система Windows должна сначала проверить, имеет ли домен, запрашиваемый пользователем, компьютером или службой, отношение доверия с доменом запрашивающей учетной записи.
Чтобы проверить это отношение доверия, система безопасности Windows вычислит путь доверия между контроллером домена для сервера, получающего запрос, и контроллером домена в домене запрашивающей учетной записи.
Механизмы управления доступом, предусмотренные в AD DS и распределенной модели безопасности Windows, предоставляют среду для работы отношений доверия между доменами и лесами. Для правильной работы этих отношений доверия каждый ресурс или компьютер должен иметь прямой путь доверия к контроллеру домена в том домене, где он находится.
Путь доверия реализуется службой сетевого входа в систему с помощью подключения удаленного вызова процедур (RPC), прошедшего проверку подлинности, к центру доверенного домена. Защищенный канал также распространяется на другие домены AD DS через междоменные отношения доверия. Этот защищенный канал используется для получения и проверки сведений о безопасности, в том числе идентификаторов безопасности (SID) для пользователей и групп.
Общие сведения о том, как отношения доверия применяются к Azure AD DS, см. в статье Основные понятия и компоненты леса ресурсов.
Чтобы приступить к использованию отношений доверия в Azure AD DS, создайте управляемый домен, использующий отношения доверия лесов.
Потоки отношений доверия
Поток передаваемых защищенных данных через отношения доверия определяет эластичность доверия. От того, как вы создаете или настраиваете отношения доверия, зависит, насколько далеко распространяется связь между лесами.
Поток данных, передаваемых через отношения доверия, определяется направлением доверия. Отношения доверия могут быть односторонними или двусторонними, транзитивными или нетранзитивными.
На следующей схеме показано, что по умолчанию все домены в дереве 1 и дереве 2 имеют транзитивные отношения доверия. В результате пользователи в дереве 1 могут получить доступ к ресурсам в доменах дерева 2, а пользователи в дереве 1 могут получить доступ к ресурсам в дереве 2, если в ресурсе назначены соответствующие разрешения.
Односторонние и двусторонние отношения доверия
Отношения доверия обеспечивают доступ к ресурсам в одном или двух направлениях.
Одностороннее доверие — это однонаправленный путь проверки подлинности, который создается между двумя доменами. При одностороннем доверии между доменом А и доменом Б пользователи в домене А могут получить доступ к ресурсам в домене Б. Однако пользователи в домене Б не могут получить доступ к ресурсам в домене А.
В зависимости от типа создаваемого доверия некоторые односторонние отношения доверия могут быть нетранзитивными или транзитивными.
При двустороннем доверии домен А доверяет домену Б, а домен Б доверяет домену А. Такая конфигурация означает, что запросы проверки подлинности могут передаваться между двумя доменами в обоих направлениях. В зависимости от типа создаваемого доверия некоторые двусторонние отношения доверия могут быть нетранзитивными или транзитивными.
Любое доверие домена в лесу AD DS является двусторонним транзитивным доверием. При создании нового дочернего домена между дочерним доменом и родительским доменом автоматически создается двустороннее транзитивное доверие.
Транзитивные и нетранзитивные отношения доверия
Транзитивность определяет, можно ли расширить доверие за пределы двух доменов, для которых оно сформировано.
При создании нового домена в лесу между новым доменом и его родительским доменом автоматически создается двустороннее транзитивное отношение доверия. Если к новому домену добавляются дочерние домены, путь доверия ведет вверх по иерархии доменов, расширяя начальный путь доверия, который создается между новым доменом и его родительским доменом. Транзитивные отношения доверия движутся вверх по доменному дереву по мере его формирования, создавая транзитивное доверие между всеми доменами доменного дерева.
Запросы проверки подлинности следуют этим путям доверия, поэтому учетные записи из любого домена леса могут проходить проверку подлинности в любом другом домене в лесу. С помощью процесса единого входа учетные записи с соответствующими разрешениями получают доступ к ресурсам любого домена в составе леса.
Отношения доверия для леса
Отношения доверия в лесу помогают управлять сегментированными инфраструктурами AD DS и поддерживают доступ к ресурсам и другим объектам в нескольких лесах. Доверие леса полезно для поставщиков услуг, организаций в процессе слияния или поглощения, совместных деловых экстрасетей и компаний, которым необходимо решение для автономного управления.
С помощью отношений доверия лесов можно связать два леса, чтобы сформировать одностороннее или двустороннее транзитивное отношение доверия. Доверие лесов позволяет администраторам подключать два леса AD DS с одним отношением доверия для обеспечения эффективной проверки подлинности и авторизации в этих лесах.
Доверие лесов можно создать только между корневым доменом леса в одном лесу и корневым доменом леса в другом лесу. Отношения доверия лесов могут быть созданы только между двумя лесами и не могут быть неявно расширены на третий лес. Такими образом, если между лесом 1 и лесом 2 создано одно отношение доверия лесов, а между лесом 2 и лесом 3 — другое, лес 1 не имеет неявного отношения доверия с лесом 3.
На следующей схеме показаны два отдельных отношения доверия лесов между тремя лесами AD DS в одной организации.
В этом примере конфигурации предоставляется следующий доступ:
Эта конфигурация не позволяет пользователям леса 1 получить доступ к ресурсам в лесу 3 и наоборот. Чтобы разрешить пользователям в лесу 1 и лесу 3 общий доступ к ресурсам, необходимо создать двустороннее транзитивное отношение доверия между этими двумя лесами.
Если между двумя лесами создается одностороннее доверие лесов, члены доверенного леса могут использовать ресурсы, расположенные в доверяющем лесу. Однако доверие действует только в одном направлении.
Например, при создании одностороннего отношения доверия между лесом 1 (доверенный лес) и лесом 2 (доверяющий лес) справедливо следующее:
Лес ресурсов доменных служб Azure AD поддерживает односторонние отношения доверия лесов с локальной службой Active Directory.
Требования к доверию лесов
Чтобы можно было создать доверие лесов, необходимо убедиться в наличии правильной инфраструктуры службы доменных имен (DNS). Отношения доверия лесов можно создавать только при наличии одной из следующих конфигураций DNS:
Единственный корневой DNS-сервер — это корневой DNS-сервер для обоих пространств имен DNS леса. Корневая зона содержит делегирования для каждого пространства имен DNS, а корневые указания всех DNS-серверов включают корневой DNS-сервер.
Если общий корневой DNS-сервер и корневые DNS-серверы для каждого из пространств имен DNS леса отсутствуют, используйте серверы условной пересылки для каждого из пространств имен DNS, чтобы маршрутизировать запросы имен к другому пространству имен.
Именно эта конфигурация DNS должна использоваться для леса ресурсов доменных служб Azure AD. Размещение пространства имен DNS, отличного от пространства имен DNS леса ресурсов, не является компонентом доменных служб Azure AD. Серверы условной пересылки — это правильная конфигурация.
Если общий корневой DNS-сервер и корневые DNS-серверы для каждого из пространств имен DNS леса отсутствуют, используют дополнительные зоны DNS, настроенные в каждом из пространств имен DNS, для маршрутизации запросов имен к другому пространству имен.
Чтобы создать отношение доверия лесов, необходимо быть членом группы «Администраторы домена» (в корневом домене леса) или группы «Администраторы предприятия» в Active Directory. Каждому отношению доверия назначается пароль, который должен быть известен администраторам в обоих лесах. Участники группы «Администраторы предприятия» в обоих лесах могут создавать отношения доверия в обоих лесах одновременно. В этом случае для обоих лесов автоматически создается и записывается криптографически случайный пароль.
Лес ресурсов управляемого домена поддерживает до 5 односторонних исходящих отношений доверия с локальными лесами. Исходящее отношение доверия лесов для доменных служб Azure AD создается на портале Azure. Вы не создаете вручную отношение доверия с самим управляемым доменом. Входящее отношение доверия лесов должно быть настроено пользователем с привилегиями, которые ранее были указаны в локальной службе 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) в другом лесу. Объекты доверенного домена реплицируются в глобальный каталог.
Альтернативные суффиксы имени участника-пользователя в отношениях доверия не поддерживаются. Если локальный домен использует тот же суффикс имени участника-пользователя, что и Azure AD DS, вход должен использовать sAMAccountName.
Чтобы протоколы проверки подлинности могли следовать пути доверия лесов, имя субъекта-службы (SPN) компьютера ресурсов должно быть разрешено в расположение в другом лесу. Имя субъекта-службы может принадлежать к одному из следующих типов:
Когда рабочая станция в одном лесу пытается получить доступ к данным на компьютере ресурсов в другом лесу, процесс проверки подлинности 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.
Дальнейшие действия
Дополнительные сведения о лесах ресурсов см. в статье Принцип действия отношений доверия лесов в Azure AD DS.