Как настроить доверительные отношения между доменами

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

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

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

Перед созданием доверия проверьте, что оба домена работают стабильно и имеют доступные контроллеры домена. На контроллерах должны быть исправны службы Active Directory Domain Services, DNS и Kerberos. Учетная запись администратора должна обладать правами для создания доверительных отношений на обеих сторонах либо необходимо организовать раздельное подтверждение операции.

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

Проверьте сетевые соединения между контроллерами и разрешите необходимые порты межсетевого экрана. Особое внимание уделите DNS, LDAP, LDAPS, Kerberos, SMB, RPC Endpoint Mapper и динамическим RPC-портам. Если RPC блокируется, мастер создания доверия может завершиться ошибкой даже при успешно работающем DNS.

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

Откройте на контроллере домена оснастку «Домены и доверие Active Directory». В контекстном меню нужного домена выберите пункт создания нового доверия и укажите DNS-имя удаленного домена. Мастер предложит выбрать направление, тип доверия и область применения.

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

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

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

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

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

Для критичных ресурсов не предоставляйте широкие разрешения вроде полного доступа всему домену. Используйте минимально необходимые права, разделяйте группы чтения и изменения, ограничивайте интерактивный вход и контролируйте вложенность групп. Если применяются SID-фильтрация, selective authentication или ограничения на делегирование, заранее протестируйте их влияние на приложения.

Начните проверку с DNS: убедитесь, что имена контроллеров разрешаются в обе стороны и записи служб каталога находятся корректно. Затем проверьте репликацию, состояние контроллеров и доступность служб. Для диагностики удобно использовать встроенные средства проверки DNS, контроллеров домена и доверительных отношений, а также журналы событий служб Directory Service, DNS Server, Kerberos и Netlogon.

Если доверие не создается, наиболее частые причины — неправильное DNS-направление, закрытые RPC-порты, неверный пароль доверия, отсутствие маршрута между сетями или рассинхронизация времени. Ошибка входа пользователя может быть связана уже не с доверием, а с отсутствием разрешений на ресурс, ограничением selective authentication или невозможностью получить билет Kerberos.

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

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