Требуется ли указание DNS на контроллер домена для работы объектов групповой политики?

Question

Позвольте мне предвосхитить это, сказав, что я ни в коем случае не тренированный сисадмин, а, скажем, учусь на ходу. Извиняюсь, если ответ на мои вопросы очевиден, но я не смог найти его с помощью поиска Google/Superuser.

Так что я отвечаю за управление около 200 компьютерами под управлением Windows, где я работаю, и недавно я узнал об этом активном каталоге, чтобы легко вносить изменения на всех компьютерах, что просто замечательно. Поэтому я настроил контроллер домена и нашел скрипт .vbs для подключения компьютеров к домену. Отлично.

За исключением того, что установленные мной объекты групповой политики не переносятся на компьютеры. Я попытался запустить "gpupdate /force" на компьютере, и он показывает следующую ошибку

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

Обновление политики пользователя успешно завершено.

Чтобы диагностировать ошибку, просмотрите журнал событий или запустите GPRESULT /H GPReport.html из командной строки, чтобы получить информацию о результатах групповой политики.

Я осмотрелся еще немного, и, кажется, когда я указываю DNS клиентов на контроллер домена, обновления проходят (Запуск nsloookup {domain.com} возвращает неавторизованный ответ). Возможно, что указание DNS на DC является обязательным в AD. Но я никогда не видел, чтобы это упоминалось ни в одном из найденных мной уроков, что действительно странно. Так действительно ли это необходимо? Если да, могу ли я обновить DNS всех компьютеров в домене, не посещая физически каждый компьютер?

Это также поднимает другую проблему. Что если мне по какой-то причине придется сменить текущий IP DC. Нужно ли мне снова обновлять DNS на каждом компьютере?

Спасибо за ваше время и с нетерпением ждем вашего совета.

Answer 1

указание DNS на DC обязательно в AD

Нет.

Единственное реальное требование DNS ¹ состоит в том, что ваш домен AD (с поддоменами) должен разрешаться клиентами - но ничего не указано о точном пути, по которому он идет. («Неофициальный ответ» совершенно нормальный.)

Например, если следующие команды возвращают успешные результаты (SOA с информацией о зоне, SRV с подробностями службы), тогда конфигурация DNS должна быть хорошей.

nslookup -q=soa YOURDOMAIN
nslookup -q=srv _ldap._tcp.YOURDOMAIN
nslookup -q=srv _ldap._tcp.dc._msdcs.YOURDOMAIN

(SOA строго не требуется, но я включил его для динамических обновлений DNS. Существуют и другие обязательные записи, например, _kerberos._tcp , но, вероятно, нет необходимости проверять каждую из них.)

• Таким образом, если домен AD был выбран из глобального пространства имен, например, ad.example.com или corp.example.com , и если он был правильно делегирован (то есть родительский домен example.com имеет правильные записи NS), и если ваш обычный DNS серверы могут пересылать DNS-запросы на AD DC (т. е. порт 53 не защищен брандмауэром), этого достаточно.

  ( Порт DNS на контроллерах домена не должен быть доступен для всего мира , только для подключенных компьютеров. Исправление: он должен быть доступен для распознавателей DNS; то есть к серверам DNS, которые используют ваши ПК.)

• Если домен AD не может быть делегирован по какой-либо причине (например, если вы выбрали виртуальный домен верхнего уровня, например, example.corp), но ПК по-прежнему используют некоторые другие DNS-серверы с внутренним управлением, этого все равно достаточно для настройки "зона пересылки" или "зона заглушки" на этих DNS-серверах.

• Если вы не можете выполнить делегирование и не контролируете используемые DNS-серверы ... тогда у вас проблема. Вы все еще можете делать трюки, такие как NAT'-обработка всех DNS-запросов, чтобы они отправлялись на внутренний DNS-сервер; это работает, но это довольно уродливо в принципе.

• (Во всех трех приведенных выше случаях на самом деле есть только одно место для перенастройки на случай, если вы добавите или переместите контроллеры домена - будь то NS/glue records или конфигурация "stub zone" или что-то еще.)

Наведение DNS непосредственно на контроллеры домена используется только в редких случаях, например , при настройке "тестовый" домена с 2-3 ПК, или когда контроллеры домен делает фактически удваивается как главные DNS резольверы организации (которая, как я полагаю, были против все рекомендации до Server 2016).

---

¹ Конечно, есть и другие не связанные с DNS требования. Как минимум, ПК должны иметь возможность связаться с Kerberos на DC для аутентификации; LDAP (обычный и глобальный каталог) для поиска информации о GPO; и SMB (т.е. совместное использование файлов) для загрузки самих объектов групповой политики.

Для устранения неполадок я бы установил Wireshark на рабочую станцию, запустил мониторинг пакетов и посмотрел, что происходит при gpupdate /force . Существуют также различные ручки Windows для активации подробного ведения журнала обработки объектов групповой политики.

Answer 2

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

Вот несколько коротких ответов о том, как это работает.

1) Да, ваши компьютеры должны использовать контроллеры домена в качестве своих единственных DNS-серверов. Это правда, что вы можете использовать альтернативные DNS-серверы и либо пересылать запросы, либо дублировать / дублировать записи, но это будет редкостью в небольших организациях и потребует дополнительной административной работы. И независимо от того, откуда поступают записи, необходимо иметь возможность разрешать все записи, хранящиеся на контроллере домена. Обычно вы используете свои внутренние DNS-серверы AD для своих внутренних систем и настраиваете свои внутренние DNS-серверы для переадресации всех других запросов на DNS-серверы вашего интернет-провайдера - это делается в конфигурации "Пересылки".

2) DHCP - это то, что динамически передает информацию об IP-адресе системам. В типичной организации Active Directory вы отключите DHCP на любых маршрутизаторах / шлюзах и включите роль DHCP на одном из ваших серверов - обычно DC. Это связано с тем, что DHCP может работать вместе с вашим DNS-сервером, чтобы поддерживать актуальность записей. В вашей конфигурации DHCP вы будете указывать, какие DNS-серверы будут использоваться для ваших внутренних систем. Организация из 200 систем не будет или не должна использовать статическую IP-адресацию, поэтому настройки DNS не нужно менять в каждой системе. Вы управляете им централизованно, изменяя свою конфигурацию DHCP. У вас должен быть правильно настроенный DHCP-сервер во всех подсетях в вашей организации.

3) если вы меняете IP-адрес серверов DC/DNS, вы просто обновляете DHCP, чтобы отразить эти изменения для ваших систем. Однако вам следует планировать заранее, а не создавать ситуацию, в которой вам нужно изменить IP-адрес контроллера домена, поскольку в этом случае существуют другие последствия, помимо настроек DNS.