доверительные отношения между доменами active directory
Настройка доверительных отношений между доменами 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 можно переходить к созданию доверительных отношений.
В окне «Направление отношения доверия» выбираем Двустороннее:
. и нажимаем Далее.
В следующем окне выбираем, на каком из доменов мы применяем настройку — если у нас есть права администратора для обоих доменов, то выбираем Для данного и указанного доменов:
* если мы являемся администратором одного из доменов, а вторым доменом управляет другой специалист, то выбираем Только для данного домена. Подобные действия должен выполнить второй администратор в своем домене.
На следующем этапе система свяжется со вторым контроллером домена, и если он доступен, запросит логин и пароль от пользователя с правами установки доверительных отношений во втором домене. Вводим данные пользователя и нажимаем Далее.
Далее нужно выбрать «Уровень проверки подлинности исходящего доверия» — если оба домена принадлежат нашей организации, предпочтительнее выбрать Проверка подлинности в лесу, чтобы предоставить доступ ко всем ресурсам:
В окне «Подтверждение исходящего доверия» оставляем Нет, не подтверждаю это исходящее доверие, так как на другой стороне нами не создавалось доверия.
Тоже самое в окне «Подтверждение входящего доверия».
Нажимаем Готово — доверительные отношения созданы.
Заметки системного администратора Windows Server
Поиск по этому блогу
Active Directory. Понимание доверительных отношений.
Многие предприятия имеют в своей сети несколько доменов Windows. Доверительные отношения между ними порой очень сложны, особенно в случае иерархических структур Active Directory. Я вам расскажу о функционировании доверительных отношений, о способах их установления, а также о том, какая базовая информация для этого необходима.
Доверительные отношения в Active Directory еще важнее, чем в NT 4.0. При создании доменов в «лесу доменов» такие отношения устанавливаются автоматически, но, в отличие от NT 4.0, они «транзитивны». Это важное понятие мы разъясним ниже. Кстати, Windows Server 2008 хоть и предлагает множество новинок, но доверительные отношения по-прежнему действуют так же, как в Windows Server 2003.
Для большинства администраторов процесс установления доверительных отношений все еще требует привыкания, поскольку отдельные понятия немного запутаны. В результате в техническом плане возможность связи доменов Windows друг с другом представляется более «загадочной», чем есть на самом деле.
Поэтому сначала остановимся на основных понятиях.
В Active Directory существует два различных вида доверительных отношений: «однонаправленные» и «двунаправленные». В первом случае один домен доверяет другому, но не наоборот. Пользователи Домена 1 могут получить доступ к ресурсам Домена 2, однако у пользователей Домена 2 нет доступа к ресурсам Домена 1. Естественно, возможен и обратный случай. Другие варианты доверительных отношений: «исходящие» и «входящие». При исходящих доверительных отношениях Домен 1 доверяет Домену 2, т. е. пользователи Домена 2 могут обращаться к ресурсам Домена 1.
При таком процессе домен, от которого доверительные отношения исходят, является доверяющим доменом (Trusting Domain). Домен с входящими доверительными отношениями — доверенный домен (Trusted Domain), в нем создаются учетные записи пользователей, обладающих правами в доверяющем домене.
В Windows NT 4.0 тоже можно было устанавливать доверительные отношения, но не транзитивные. Если в Windows NT 4.0 создавались доверительные отношения между доменами А и В, а также между доменами В и С, то это не значило, что домен А автоматически будет доверять домену С или, наоборот, домен С — домену А. Эту связь приходилось устанавливать вручную. В Active Directory делается иначе. Домены можно связывать практически без ограничений через домены, дочерние домены и деревья с автоматическим установлением между ними доверительных отношений. В Active Directory каждый домен доверяет любому другому домену, если является частью того же леса. Устанавливать доверительные отношения вручную возможно, но необходимости в этом уже нет (ключевая фраза: урезанные доверительные отношения).
В отдельном лесу существует определенный регулирующий алгоритм: доверительные отношения автоматически создаются между выше- и ниже-стоящими доменами. Microsoft обозначает этот тип как «подчиненные доверительные отношения». Кроме того, доверительные отношения автоматически создаются между корневыми доменами отдельных деревьев. Однако доверительных отношений между подчиненными доменами различных деревьев не существует. Они доверяют друг другу на основе транзитивных доверительных отношений.
Доверительные отношения между корневыми доменами различных лесов называются «доверительными отношениями между лесами» (Forest Trust).
Как уже говорилось, дополнительные доверительные отношения можно определять и вручную. Это требуется по различным причинам. Так, возможны, к примеру, внешние доверительные отношения к доменам Windows NT 4.0 или отдельным доменам другого леса.
В Windows Server 2003 появились сохранившиеся в Windows Server 2008 доверительные отношения между лесами, когда связываются корневые домены двух различных лесов. В результате все домены обеих структур связаны автоматически транзитивными доверительными отношениями. Доверительные отношения можно создавать между подчиненными доменами разных деревьев в пределах одного леса. Они называются «прямыми доверительными отношениями» (Shortcut Trusts). Этот вид доверительных отношений часто используется, чтобы ускорить доступ к ресурсам между подчиненными доменами различных деревьев в одном лесу.
При создании нескольких деревьев в одном лесу особое значение имеет путь доверительных отношений. Поскольку доверительные отношения между подчиненными доменами разных деревьев не создаются, при доступе к ресурсам может потребоваться оптимизация аутентификации. При попытке обратиться к данным, находящимся в подчиненных доменах разных деревьев, аутентификация должна пройти путь до корневого домена собственного дерева, затем до корневого домена другого дерева и, наконец, к подчиненному домену. Для ускорения этого процесса можно вручную установить доверительные отношения между двумя подчиненными доменами.
Управление доверительными отношениями осуществляется с помощью дополнительного модуля (Snap-in) «Домены Active Directory и доверительные отношения». Если вызвать в нем свойства какого-либо домена, то на соответствующей вкладке можно найти все его доверительные отношения и задать новые. Если требуется создать доверительное отношение с внешним доменом, то сначала нужно убедиться в том, что распознавание имен между доменами осуществляется без ошибок. Лишь когда обеспечено стабильное и надежное разрешение имен, можно устанавливать доверительные отношения. Здесь будет полезна оптимальная инфраструктура серверов DNS/WINS. Дело в том, что если нужно создать доверительные отношения с доменом Windows NT 4.0, то сервер WINS подходит лучше, чем DNS. В принципе, связь между доменом Windows NT 4.0 и доменом Active Directory можно установить и без WINS, но она будет нестабильной и сложно реализуемой.
Чтобы создать доверительные отношения, в дополнительном модуле «Домены Active Directory и доверительные отношения» необходимо вызвать свойства того домена, от которого они должны исходить. Во вкладке «Доверительные отношения» нужно нажать на кнопку «Новое доверительное отношение». Windows запускает ассистента. На второй странице отображается имя домена, к которому будет устанавливаться доверительное отношение. Если это домен Active Directory, то следует использовать имя DNS, в то время как для соединения с доменом Windows NT 4.0 лучшим выбором будет имя NetBIOS. Затем ассистент проверяет, возможна ли связь с доменом и должны ли доверительные отношения быть однонаправленными или двунаправленными.
При двунаправленном соединении пользователи каждого из доменов могут аутентифицироваться в другом домене для получения доступа к ресурсам. При выборе «Однонаправленные: входящие» устанавливается, что данный домен является доверенным,
т. е. пользователь этого домена может аутентифицироваться в другом домене и обращаться к его ресурсам. В варианте «Однонаправленные: исходящие» пользователи другого домена могут регистрироваться в нем, а вот пользователи этого домена в другом — нет.
Затем определяется область аутентификации доверительных отношений. Большинство администраторов используют вариант «Общедоменная аутентификация». При этом пользователи одного домена получают доступ к ресурсам другого через групповое членство или прямое разрешение. Если же выбирается вариант «Избирательная аутентификация», то для каждого сервера, к которому разрешен доступ пользователей другого домена, в локальных настройках безопасности или правилах должна активироваться опция «Может аутентифицировать». Такая настройка повышает безопасность, но одновременно усложняется структура распределения прав. Пользователям другого домена автоматически отказывается в доступе к отдельным серверам предприятия.
Теперь следует отменить отказ для каждого отдельного сервера, а затем установить пароль для доверительных отношений, который позднее потребуется для верификации и установления доверительных отношений в другом направлении. В следующем окне нужно выбрать, будет ли доверительное отношение проверяться. При создании доверительных отношений с доменом Windows NT 4.0 необходимо сначала установить их со стороны этого домена. Пользователи получают доступ к ресурсам лишь после верификации доверительных отношений как активных. Если создание доверительных отношений не удается, то обычно это происходит из-за проблем с разрешением имен или наличием прав.
ФИЛЬТРАЦИЯ SID В ДОВЕРИТЕЛЬНЫХ ОТНОШЕНИЯХ
После завершения установления внеш-них доверительных отношений автоматически высвечивается указание, что для этих отношений был активирован фильтр идентификаторов пользователей (SID). Это происходит автоматически, если доверительные отношения создаются контроллером домена под управлением Windows Server 2003 или Windows Server 2000 (SP4 и выше). Фильтрация SID защищает исходящие доверительные отношения. Она призвана воспрепятствовать раздаче администраторами доверенных доменов неправомерных полномочий в пределах доверяющих доменов. Фильтр SID следит за тем, чтобы в доверяющем домене аутентифицировались только те пользователи доверенного домена, чьи SID содержат SID этого домена. Если деактивировать фильтрацию SID, то внешний пользователь, обладающий правами администратора в доверенном домене, сможет прослушать сетевой трафик доверяющего домена, определить SID администратора, а затем присоединить этот SID к своей истории SID и заполучить права администратора в доверяющем домене.
Однако при активации фильтра SID может случиться так, что будет игнорироваться история SID пользователей, получивших ее из других доменов в результате миграции. Тогда возникнут проблемы с аутентификацией при доступе к ресурсам, поэтому фильтр SID не всегда можно использовать. Если фильтр применяется для укрепления доверительных отношений Windows NT 4.0, то здесь проблемы возникают реже, чем при построении внешних доверительных отношений к домену в Active Directory. Если универсальной группе из Active Directory доверенного домена выдаются разрешения на ресурсы доверяющего домена, то нужно убедиться в том, что эта группа была создана именно в доверенном домене, а не в каком-либо другом домене Active Directory. В противном случае она не содержит SID доверенного домена, и фильтр SID не разрешит доступ к ресурсам доверяющего домена.
Иногда возникают проблемы с установлением доверительных отношений. Виной тому — ошибочное распознавание имен, защищенные маршрутизаторы между различными подсетями или ошибки на серверах WINS. Если не получается создать доверительные отношения между двумя контроллерами доменов, то часто помогает создание файла lmhosts на обоих серверах. Этот файл находится в папке Windows/system32/drivers/etc. Для обеспечения распознавания имен файл нужно переименовать в lmhosts без расширения. В указанном файле настраивается разрешение доменов, так что серверы DNS или WINS будут пропускаться. Для этого нужно добавить в файл следующие строки:
При создании доверительных отношений между корневыми доменами двух лесов можно выбрать опцию «доверительные отношения между лесами». Ее преимущество заключается в том, что все подчиненные домены всех деревьев в задействованных лесах сразу же начинают транзитивно доверять друг другу. Для доверительных отношений между лесами должны быть соблюдены некоторые предпосылки: такой тип отношений поддерживается только в лесах Windows Server 2003/2008. Кроме того, важно, чтобы функциональные уровни домена и леса находились в однородном режиме Windows Server 2003 или 2008. Естественно, между лесами должно функционировать разрешение имен. Специфическую для доменов переадресацию лучше всего создавать на отдельных серверах DNS лесов.
Создание доверительных отношений между лесами идентично созданию доверительных отношений других типов. Для них точно так же можно установить, будут ли отношения одно- или двунаправленные, а кроме того, предоставить права отдельным доменам или всему лесу. Если в лесах используется несколько деревьев, то можно определить, какие диапазоны имен, а следовательно, и деревья, смогут пользоваться установленными доверительными отношениями. Но имена NetBIOS и DNS отдельных доменов должны быть разными. Если в лесах встречаются совпадающие имена NetBIOS или DNS, то эти домены взаимно лишаются доступа к ресурсам другого леса. Для управления различными деревьями в свойствах доверительных отношений используется вкладка «Маршрутизация суффиксов имен».
Принцип действия отношений доверия для лесов ресурсов в доменных службах 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.