вернуть запись AD DNS того же сайта
У меня 2 сайта: BEZA (дата-центр) BEOM (офис)
На обоих сайтах по 2 контроллера домена (с установленным DNS). Я назначил контроллеры домена определенному сайту.
Когда я пытаюсь разрешить домен, я получаю случайные записи от 1 из 4 контроллеров домена. Так что может случиться так, что когда вы пытаетесь аутентифицироваться с помощью ldap на сайте BEZA, он фактически использует DC на BEOM. Сегодня у нас возникла проблема с нашими DC в BEOM. Все приложения в BEZA больше не могут аутентифицироваться. Если я сделаю пару ipconfig / flushdns, я получу правильный (локальный) ip постоянного тока. Как я могу «заставить», чтобы DNS возвращал запись DC на том же сайте, что и приложение / пользователь?
Спасибо!
возможно, я неправильно объяснил, но это была скорее проблема DNS, чем обычная проблема AD.
У меня есть программное обеспечение, которое выполняет запросы LDAP к моему доменному имени (intra.mydomain.com). Когда я выполняю nslookup для intra.mydomain.com в BEOM, в результате я ожидаю получить DC для BEOM. Когда я выполняю nslookup для intra.mydomain.com в BEZA, я ожидаю получить в результате DC BEZA.
Это не сработало. Но, очевидно, это связано с тем, что мой приоритет подсети не работал должным образом, и это было связано с тем, что он соответствует неправильной части IP-адреса. 10.101. 1 .1 вместо 10. 101 .1.1. Это можно исправить с помощью следующей команды:
Dnscmd /Config /LocalNetPriorityNetMask 0x0000FFFF
Теперь, когда я запрашиваю intra.mydomain.com, в результате я получаю DC из того же места.
Когда я пытаюсь разрешить домен, я получаю случайные записи от 1 из 4 DC. Так что может случиться так, что когда вы пытаетесь аутентифицироваться по ldap на сайте BEZA, он фактически использует DC на BEOM - это отвлекающий маневр. Запрос имени домена в DNS с использованием чего-то вроде nslookup или dig - это не то же самое, что поиск контроллера домена для проверки подлинности. Запрос имени домена в DNS через nslookup или dig должен вернуть все контроллеры домена независимо от сайта. Это нормальное и ожидаемое поведение. Это НЕ означает, что ваши клиенты или приложения будут использовать случайный DC для аутентификации.
Созданы ли у вас подсети и связаны с соответствующим сайтом в Active Directory Sites and Services?
Контроллеры домена будут регистрироваться специфичные для сайта записи в DNS при правильной настройке ADS&S. Когда клиент AD запрашивает в DNS расположение контроллера домена, будет возвращен локальный контроллер домена на основе подсети клиента, если эти подсети были определены в ADS&S. Затем клиент создаст «привязку» к этому сайту, чтобы при последующих входах в систему использовались контроллеры домена на этом сайте. Это относится к процессу поиска контроллера домена. Другое дело, как ведут себя ваши приложения.
Ответ - нет. Можно не регистрировать записи DNS для офиса (BEOM), поэтому приложения в центре обработки данных всегда будут иметь только свои локальные записи DNS. И клиенты на сайте BEOM всегда будут сначала использовать свои DC, потому что они используют эти DC для DNS. Но если контроллер домена зарегистрирован в DNS, эти записи будут возвращены в запросе для домена. Этот подход очень распространен для топологий «ступица и спица».
Маловероятно, что проблема вызвана прямым поиском DNS, потому что процесс DC Locator намного сложнее, чем просто запрос DNS.
Как оптимизировать расположение контроллера домена или глобального каталога, который находится за пределами сайта клиента
https://support.microsoft.com/en-us/kb/306602
«DNS-записи локатора DC не зарегистрирован групповой политикой службы Net Logon DC.