Итак, у меня есть два леса, назовем ихальфа.example.comиbravo.example.com. Имена NETBIOS доменов — ALPHA и BRAVO соответственно. Это, казалось бы, подразумевает, что нет никаких проблем с именованием доменов, у них два разных имени, как с точки зрения DNS, так и с точки зрения NETBIOS.
У меня есть следующие серверы в качестве контроллеров домена:
- dc01.alpha.example.com
- dc02.alpha.example.com
- dc01.bravo.example.com
Когда я пытаюсь установить доверие леса между ALPHA и BRAVO таким образом, я получаю сообщение «Нет доступных серверов входа для обслуживания запроса на вход», когда дело доходит до фактической проверки доверия. Я обнаружилнекоторые темы форумав сети, а также слышал некоторые анекдотические свидетельства того, что есть проблемы при соединении двух доменов вместе, где есть одинаковые имена для контроллеров домена в обоих доменах. Это не кажется мне логичным, и это звучит как ошибка в инструментах Microsoft.
Я не думал, что это должно быть проблемой, поскольку dc01.alpha.example.com и dc01.bravo.example.com — это, очевидно, две разные машины, но Windows, похоже, со мной не согласна.
Я упускаю какую-то часть информации, которая позволила бы мне заставить эту настройку работать? Переименование контроллеров домена — плохой ответ для нас, к сожалению, потому что конечная цель — объединить множество лесов, все из которых имеют контроллеры домена с одинаковыми именами. Это означало бы переименование кучи DC:s.
Для справки, переименование одного из контроллеров домена позволяет мне установить доверительные отношения, но я действительно не хочу делать это в реальном мире, если могу себе это позволить.
Все машины в лаборатории работают под управлением Windows Server 2012 R2 с последними обновлениями, но без установленных специальных исправлений.
DNS настроен следующим образом: в домене ALPHA добавляется зона-заглушка для bravo.example.com, указывающая на IP-адрес dc01.bravo.example.com. В свою очередь, dc01.bravo.example.com использует dc01.alpha.example.com и dc01.bravo.example.com в качестве DNS-сервера верхнего уровня. Это немного хакерская настройка (потому что это лаборатория...), но в результате разрешение DNS работает правильно в обоих направлениях. dc01.bravo.example.com может разрешать имена в bravo.example.com (потому что он авторитетный), а имена alpha.exaple.com разрешаются правильно, потому что DNS-сервер верхнего уровня является для него авторитетным. Резолверы в alpha могут правильно разрешать имена bravo из-за зоны-заглушки (которая добавляется в AD, чтобы оба DNS-сервера ее получали.)
Я дополнительно попробовал:
- Изменение зоны-заглушки на условный переадресатор
- Управление лесным трастом вместо внешнего траста
Никаких изменений симптомов.
решение1
Ваши проблемы связаны с тем, что называется маршрутизацией суффикса имени. В следующей статье описывается проблема: https://technet.microsoft.com/en-us/library/cc784334%28v=ws.10%29.aspx В нем говорится, что для решения этой проблемы можно использовать netdom.
Статья частично гласит:
Маршрутизация суффиксов имен через леса
Маршрутизация суффикса имени — это механизм, используемый для управления маршрутизацией запросов аутентификации через леса Windows Server 2003, которые объединены доверительными отношениями леса. Для упрощения администрирования запросов аутентификации при первоначальном создании доверительного отношения леса все уникальные суффиксы имен маршрутизируются по умолчанию. Уникальный суффикс имени — это суффикс имени в пределах леса, например суффикс имени участника-пользователя (UPN), суффикс имени участника-службы (SPN) или имя леса DNS или доменного дерева, которое не подчиняется никакому другому суффиксу имени. Например, имя леса DNS microsoft.com — это уникальный суффикс имени в пределах леса microsoft.com.
Леса могут содержать несколько уникальных суффиксов имен, и все потомки уникальных суффиксов имен маршрутизируются неявно. В Active Directory Domains and Trusts суффиксы имен отображаются со звездочкой (*) в начале из-за этого. Например, если ваш лес использует.microsoft.com как уникальный суффикс имени, затем запросы на аутентификацию для всех дочерних элементов microsoft.com (.child.microsoft.com) будет маршрутизироваться, поскольку дочерние домены являются частью суффикса имени microsoft.com.
Если между двумя лесами существует доверие к лесу, то суффиксы имен, которые не существуют в одном лесу, могут использоваться для маршрутизации запросов аутентификации во второй лес. Когда новый суффикс имени ребенка (.child.widgets.com) добавляется к уникальному суффиксу имени (.widgets.com), суффикс дочернего имени унаследует конфигурацию маршрутизации уникального суффикса имени, к которому он принадлежит. Любые новые уникальные суффиксы имен, созданные после установления доверия леса, будут видны в диалоговом окне свойств доверия леса после проверки доверия. Однако маршрутизация для этих новых уникальных суффиксов имен будет отключена по умолчанию. Для получения дополнительной информации о том, как проверить доверие, см. Проверка доверия.
При обнаружении дублирующегося суффикса имени маршрутизация для новейшего суффикса имени будет отключена по умолчанию. Для получения дополнительной информации о маршрутизации суффиксов имени см. Включение или отключение существующего суффикса имени от маршрутизации. Администраторы могут использовать диалоговое окно свойств доверия леса, чтобы вручную запретить маршрутизацию запросов аутентификации для определенных суффиксов имени в лес.
Примечания • Не добавляйте знак @ к суффиксу UPN или имени пользователя. Когда запросы аутентификации направляются в доверенный лес, все символы до первого символа @ интерпретируются как имя пользователя, а все после первого символа @ — как суффикс UPN.
• Локальный орган безопасности (LSA) заблокирует маршрутизацию к любому суффиксу UPN, который не является допустимым именем DNS. Например, добавление символа @ к суффиксу UPN приведет к его автоматическому отключению.