Вопрос или проблема
Работаю над проблемой установки доверия между двумя доменами с несколькими межсетевыми экранами между ними и маршрутизацией с минимальными правилами между двумя серверами.
newdc.newdomain.com – это сервер 2012 года в совершенно новом домене. admt.olddomain.local – это сервер 2008R2 в существующем домене, с двумя существующими контроллерами домена dc1.olddomain.local и dc2.olddomain.local. Этот сервер будет использоваться, как вы могли догадаться, для инструментов миграции Active Directory (ADMT).
Существует правило межсетевого экрана, которое позволяет newdc.newdomain.com устанавливать связь с Active Directory только с admt.olddomain.local в обоих направлениях. Все тесты DNS в порядке, как и DCDIAG на обеих сторонах.
При создании доверия на admt.olddomain.local я получил следующую ошибку:
Входящее доверие было проверено. Оно установлено и активно. Проверка исходящего доверия завершилась неудачей с следующими ошибками: Тест проверки пароля доверия оказался неубедительным. Будет предпринята попытка сброса защищенного канала. Сброс защищенного канала завершился неудачей с ошибкой 1311: В настоящее время нет доступных серверов для входа, чтобы выполнить запрос на вход.
Тем не менее, доверия были созданы, входящее и исходящее, в обоих доменах. Проверка доверия (в обоих направлениях) на newdc.newdomain.com возвращает успешную проверку. Однако, когда я пытаюсь проверить доверие с сервера admt.olddomain.local, я получаю следующую ошибку:
Сброс защищенного канала (SC) на контроллере домена Active Directory \dc1.olddomain.local домена olddomain.local к домену newdomain.com не удался с ошибкой: В настоящее время нет доступных серверов для входа, чтобы выполнить запрос на вход.
Входящее доверие было успешно проверено.
Я вижу проблему здесь, хотя я выполняю проверку с admt.olddomain.local, она на самом деле пытается проверить защищенный канал с dc1.olddomain.local, который не можетCommunicate with newdc.newdomain.com, но является ли это действительно проблемой? Есть ли способ заставить проверку выполняться с admt.olddomain.local? Сможем ли мы использовать ADMT с этой конфигурацией? (мы собираемся скоро попробовать тестовую копию с ее использованием, просто чтобы увидеть, что происходит в текущей конфигурации)
В конечном итоге мы собираемся перестроить этот сервер admt.olddomain.local в контроллер домена только для чтения для newdomain.com, используя тот же сетевой адрес и настройки межсетевого экрана/маршрутизацию, и это будет единственная машина, способная общаться с dc01.olddomain.local и dc02.olddomain.local, но будем ли мы иметь ту же проблему, поскольку newdc.newdomain.com не может непосредственно маршрутизировать к dc01/dc02 для проверки доверия?
Спасибо за любые мысли по этому поводу!
Итак, вот что мы в итоге сделали: перестроили структуру AD так, чтобы newdomain.com имел сервер ADMT/DC в той же сети, что и серверы AD olddomain.com, затем перенесли роли FSMO на новый сервер домена, чтобы два домена могли общаться напрямую между мастерами FSMO, без всех промежуточных межсетевых экранов, мешающих всему. Если у вас все наладено для DNS, межсетевых экранов и т. д., и вы все еще получаете ошибки, начните проверять, могут ли мастера ролей FSMO общаться друг с другом напрямую!
Ответ или решение
Ошибка проверки доверия безопасного канала в Active Directory
Введение
Проблема, описанная в вашем запросе, касается настройки взаимного доверия между двумя доменами в условиях наличия нескольких сетевых фаерволов и ограниченной маршрутизации. Эта ситуация может ставить под угрозу миграцию Active Directory с использованием Active Directory Migration Tool (ADMT).
Проблема
Вы столкнулись с ошибкой проверки доверия, когда попытались создать и подтвердить связи между доменами newdomain.com и olddomain.local. Несмотря на успешное создание доверия, возникли ошибки при попытке установить безопасный канал (Secure Channel) между контроллерами домена, в частности:
- Ошибка 1311: «В настоящее время нет доступных серверов входа для обработки запроса на вход».
- «Проверка пароля доверия была неоднозначной».
Анализ проблемы
Проблемы связаны с тем, что сервер admt.olddomain.local, на котором запускается ADMT, не может корректно взаимодействовать с контроллерами домена dc1.olddomain.local и dc2.olddomain.local из-за ограничений маршрутизации и правил фаервола. Важно отметить, что валидировать доверие необходимо не только с одной стороны, но и с обеих, и ошибки возникают в том числе из-за сложности сетевой архитектуры.
Доверительные отношения требуют, чтобы оба домена могли напрямую взаимодействовать через протоколы Kerberos и LDAP. Если ваш контроллер dc1.olddomain.local не может установить связь с newdc.newdomain.com из-за firewall, это приводит к сбоям в безопасном канале.
Рекомендации по решению
-
Проверка маршрутизации и настроек фаервола:
- Убедитесь, что фаерволы настроены должным образом для разрешения всех необходимых портов (например, 88 для Kerberos, 389 для LDAP).
- Проверьте настройки маршрутизации, чтобы убедиться, что все домены могут обмениваться данными напрямую.
-
Тестирование безопасного канала:
- Рекомендуется временно отключить фаерволы во время тестовых операций с ADMT для устранения потенциальных проблем.
- Используйте команды, такие как
nltestиTest-Connection, для тестирования соединений и безопасного канала.
-
Перенос FSMO ролей:
- Как вы уже упомянули во втором сообщении, перенос ролей FSMO на контроллер нового домена может значительно упростить коммуникацию.
- Роли, такие как PDC Emulator, могут оказывать значительное влияние на управление безопасными каналами, поэтому их актуальность следует оценивать.
-
Предварительный тест миграции:
- Проведите тестовые миграции на изолированных серверах, прежде чем переключаться на продакшен-системы.
- Убедитесь, что план перехода учитывает возможные проблемы с безопасными каналами и выполняет тесты перед фактической миграцией данных.
Заключение
Проблемы с доверительными отношениями между доменами могут быть сложными в сценариях с ограниченной маршрутизацией и наличием фаерволов. Рекомендуется следить за тем, чтобы оба домена могли свободно обмениваться данными, особенно в отношении контроллеров домена, ответственных за роли FSMO. Если вы сможете обеспечить хорошие сетевые условия, то успешная миграция с помощью ADMT будет более вероятной. Помните, что даже при наличии правильной настройки DNS и фаервола, проблемы могут возникнуть из-за нерадивой маршрутизации.
Надеюсь, эти рекомендации помогут вам разрешить ситуацию и успешно завершить миграцию.