Вопрос или проблема
Я управляю многоузловым Active Directory. 4 площадки в конфигурации звездочка (hub/spoke).
Топология площадок:
На каждом узле есть 2 контроллера домена. PDC находится в узле A. Я буду ссылаться на узлы B, C и D как на удаленные площадки. Все удаленные площадки имеют полное соединение с узлом A, но не напрямую с другими удаленными площадками. Большинство рабочих станций находятся на удаленных площадках, узел A по сути является серверным хабом. Каналы связи настроены правильно, связывая A со всеми удаленными площадками, но без объединения всех каналов связи.
Проблема:
У нас возникают трудности на удаленных площадках с добавлением рабочих станций в домен и доступом к общим сетевым ресурсам, таким как SYSVOL для GPO. Поэтому каждый раз, когда мы ссылаемся на наш “mydomain.com”, мы наблюдаем непостоянное поведение. Это, похоже, влияет на все удаленные площадки.
Что я сделал:
- Подтвердил, что schannels работают правильно.
- Подтвердил с помощью команд repadmin, что репликация происходит корректно и не отстает от графика.
- Подтвердил, что все компьютеры могут запрашивать и разрешать домен.
- Подтвердил с помощью dcdiag, что нет текущих ошибок в Active Directory на любом из узлов.
- Проанализировал журналы событий на затронутых машинах, чтобы определить проблему.
- Редактировать: Я могу подтвердить, что сетевые подсети добавлены к правильным узлам в Sites and Services.
- Редактировать: Я могу подтвердить с помощью
nltest /dsgetsite, что рабочие станции находятся на правильном узле.
Возможная причина: Моя лучшая догадка заключается в том, что это может быть связано с A-записями для домена. По умолчанию Active Directory создает A-запись для домена верхнего уровня для каждого контроллера домена, так что при запросе “mydomain.com” будет разрешаться IP всех контроллеров домена. Из информации, собранной в журналах, компьютеры иногда будут пытаться обратиться к другим удаленным узлам для таких вещей, как групповая политика (что просто не удается, поскольку нет сетевого соединения).
Кто-нибудь сталкивался с чем-то подобным или знает какие-то методы устранения неполадок, которые я мог бы применить для поиска первопричины?
Active Directory создает A-запись для домена верхнего уровня для каждого контроллера домена, так что при запросе “mydomain.com” будет разрешаться IP всех контроллеров домена. Из информации, собранной в журналах, компьютеры иногда будут пытаться обратиться к другим удаленным узлам для таких вещей, как групповая политика (что просто не удается, поскольку нет сетевого соединения). Кто-нибудь сталкивался с чем-то подобным?
Да, так в Active Directory было всегда.
Вы можете использовать DNS Mnemonics, чтобы предотвратить регистрацию A-записи (и других типов) контроллерами домена на узлах B, C и D. Конкретный мнемоник называется “LdapIpAddress”.
Учтите, что отсутствие A-записи не влияет на Windows-клиентов на удаленных узлах.
Кроме того, приложения, использующие A-запись для домена, должны учитывать это и фильтровать потенциальные множественные результаты для доменной записи, удалять нежелательные адреса или выбирать предпочтительные адреса.
Существует несколько известных сценариев, при которых могут быть возвращены некорректные или недопустимые результаты, и слепое использование случайно изменяющегося адреса наверняка однажды приведет к сбою.
.
Ответ или решение
В описанной вами ситуации с многосайтовой активной директорией имеются некоторые признаки, указывающие на использование неправильных записей DNS, что может оказывать влияние на связь рабочих станций в удалённых сайтах с доменом. Рассмотрим данную ситуацию более подробно и предложим возможные решения.
Теория
Когда мы имеем дело с многосайтовой конфигурацией Active Directory (AD), особенно с архитектурой hub/spoke, одной из важных задач является обеспечение правильной маршрутизации запросов DNS и планирования репликации данных. В данной конфигурации у вас есть 4 сайта — один основной (A) и три удалённых (B, C и D). Как упоминается в описании, каждая из удалённых площадок имеет полноценное соединение с сайтом A, но не с другими удалёнными сайтами. Это типично для таких конфигураций, где сайт A является центральным узлом для хранения серверов, а остальные концентрируются на обслуживании клиентов.
Проблема с разрешением DNS имен, такая как неудачная попытка подключения к другим удалённым сайтам при взаимодействии с "mydomain.com", может возникать в результате регистрации нескольких A-записей в Active Directory DNS для всех контроллеров домена на всех сайтах. Когда рабочие станции отправляют запросы к домену "mydomain.com", они могут пытаться обратиться к контроллерам домена в других удалённых сайтах, что и вызывает проблемы.
Пример
Каждый контроллер домена в ваших удалённых сайтах также регистрирует A-запись, привязывающую IP-адрес контроллера домена к доменному имени "mydomain.com". Это поведение по умолчанию в AD может привести к ситуации, когда рабочие станции в одном удалённом сайте, пытаясь воспользоваться общими ресурсами, такими как SYSVOL для GPO, сталкиваются с ситуацией, когда система пытается взаимодействовать с контроллером, находящимся в другом удалённом сайте без прямого соединения. Это, в свою очередь, приводит к сбоевым или замедленным операциям, поскольку рабочие станции не могут достичь контроллеров домена, к которым они пытаются подключиться.
Применение
1. Использование DNS-микропрограмм: Рекомендуется отключить регистрацию A-записей на дополнительных удалённых DCs, чтобы избежать подобных конфликтов. В вашем случае, можно использовать параметр DNS "LdapIpAddress". Данный параметр позволяет контроллерам домена не регистрировать свои IP-адреса на уровне доменного имени, и тем самым предотвращает рабочие станции от неправомерного разрешения имен.
Конфигурация:
- Откройте
regeditна сервере контроллера домена. - Переходите по пути:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters. - Создайте новое
DWORDзначение с именемDnsAvoidRegisterRecordsи установите его значение на0x4. - Перезапустите службу
NetLogonна контроллере домена.
2. Настройка клиента: Убедитесь, что рабочие станции настроены для поиска расположенного поблизости контроллера домена. Чтобы сделать это, нужно удостовериться, что DNS сервер сконфигурирован корректно и отвечает на запросы с ближайшей площадки. Используйте инструмент nltest /dsgetsite, чтобы проверить корректность настройки сайта для рабочей станции.
3. Пользовательская фильтрация: Рассмотрите возможность пользовательской фильтрации адресов, возворачиваемых в результате запроса A-записи, чтобы запретить подключение к нежелательным адресам.
Следуя этим рекомендациям, вы улучшите стабильность соединений рабочих станций в удалённых сайтах с доменом, обеспечивая надёжную и целенаправленную маршрутизацию запросов DNS и управление доступом к сетевым ресурсам. Важно также регулярно проверять настройку сетевых политик и конфигурацию доменных контроллеров, чтобы предотвратить возможные сбои в будущем.