Таблица политики разрешения имен повреждена разрешение dns будет выполняться с ошибкой

Обновлено: 04.07.2024

Исходные данные:
Клиент Windows 8 Pro (без обновлений), IP статический.
Windows Server 2016 (в режиме 2008R) - Active Directory, DNS сервер - в домене клиенты Windows 7 PRO.

Проблема:
При попытке подключения Windows 8 Pro к домену появилась ошибка - нет доступа к сетевой папке.

В журнале системы:
Таблица политики разрешения имен повреждена. Разрешение DNS будет выполняться с ошибкой до устранения этой неполадки. Для получения дополнительных сведений ознакомьтесь с таблицей политики для правила .
Компьютер OPO4 попытался присоединится к домену ws, но произошел сбой. Код ошибки 1231.

Оказывается на этом компьютере не работает доступ к сетевым папкам. Во вкладке "сеть" можно выбрать любой ПК, ввести логин и пароль и сразу получить ошибку доступа к сетевой папке (второй раз ввести не даёт, запускается мастер устранения неполадок, который ничего не находит).

Что примечательно - сетевые диски работают без проблем (именно поэтому до ввода в домен, эту ошибку не замечал).
Nslookup разрешает имена ПК в DNS.

Конфигурация антивируса и других программ аналогична компьютерам с Windows 7 Pro (у которых такой проблемы нет).
Брандмауэр отключен, обновления отключены, антивирус выключал, галочка "Клиент для сетей Microsoft" в настройках адаптера стоит.

Давно подумываю переставить на 8.1 или на 7ку. Но просто интересно, что может быть.
Заранее спасибо.

__________________
Помощь в написании контрольных, курсовых и дипломных работ здесь

Служба доступа к сетевым папкам и принтерам
Здравствуйте! Подскажите пожалуйста, как называется служба, которая обеспечивает доступ к сетевым.

Настройка доступа к сетевым папкам в Windows 7 Professional SP1
Есть ПК с Windows 7 Professional в роли сервера, на нём есть учётная запись Admin и разшарена папка.

Организация доступа к сетевым папкам с разных компьютеров без домена
Всем доброго дня! Что имеем: 1) локальную сеть на Виндоус 10 + Убунту 16.04 2) сетевые ресурсы.

Проблемы доступа к сетевым папкам пропадают учетные данные и доступ только по ip
Здравствуйте. Есть локальная сеть с контролером домена. в сети компьютеры с виндовс 7 и 10. На.

Вот как более детально выглядит ошибка при обработке групповой политики. Событие с кодом ID 1054: Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно.

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

Проверка разрешения имен

Первым делом нужно проверить может ли наш сервер правильно разрешать внутренние доменные имена. Для этого воспользуемся утилитой nslookup. Выберите любое доменное имя сервера или лучше контроллера домена. Открываем командную строку и пишем

dc1 это мой контроллер домена. Как видите у меня локальные DNS имена разрешал, внешний DNS сервер, так как на сервере стоит два сетевых интерфейса и один со внешним ip адресом.

причину мы выяснили, из за чего выскакивает ошибка.

Приоритетность контроллеров домена

Давайте теперь посмотрим, какой из контроллеров домена является для вашего сервера самым авторитетным, ранее я уже рассказывал как определить какой domain controller вас авторизовал, но нам нужен авторитет в вашем домене и возможность обращение к нему по LDAP. Делается это командой

Я вижу что у меня это dc2, его ip адрес мне и понадобится.

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

Так же нужно проверить доступность DC по протоколу RPC, с помощью команды

доступность DC по протоколу RPC

В данном случае проблем я не обнаружил. Пилим дальше.

Настройка DNS на внешнем сетевом интерфейсе

Так как мы выяснили ip адрес контроллера домена, что нас авторизовывал, его мы и пропишем в качестве DNS сервера на внешнем сетевом интерфейсе. В свойствах ipv4 прописываем его как основной DNS сервер. Напомню, что для разрешения внешних имен у вас должна быть настроена рекурсия на ДНС сервере.

настройка dns сервера

Теперь снова выполним команду nslookup и видим, что теперь внутренние имена разрешаются внутренним DNS сервером.

Видим, что все обновилось корректно и проблема при обработке групповой политики, об этом сообщает событие с кодом ID 1502. Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно в Windows Server 2012 R2 ушла.

В очередном «конспекте админа» остановимся на еще одной фундаментальной вещи – механизме разрешения имен в IP-сетях. Кстати, знаете почему в доменной сети nslookup на все запросы может отвечать одним адресом? И это при том, что сайты исправно открываются. Если задумались – добро пожаловать под кат. .

Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:

регистрация и проверка сетевых имен;

установление и разрыв соединений;

связь с гарантированной доставкой информации;

связь с негарантированной доставкой информации;

В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.

Небольшая памятка о сути широковещательных запросов.

Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.

Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255

Естественно, постоянно рассылать широковещательные запросы не эффективно, поэтому существует кэш NetBIOS – временная таблица соответствий имен и IP-адреса. Таблица находится в оперативной памяти, по умолчанию количество записей ограничено шестнадцатью, а срок жизни каждой – десять минут. Посмотреть его содержимое можно с помощью команды nbtstat -c, а очистить – nbtstat -R.

Пример работы кэша для разрешения имени узла «хр».

Что происходило при этом с точки зрения сниффера.

В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.

В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.

В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.

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

если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;

Наглядная схема прохождения запроса DNS.

Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.

Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.

DNS переключается на TCP с тем же 53 портом для переноса DNS-зоны и для запросов размером более 512 байт. Последнее встречается довольно редко, но на собеседованиях потенциальные работодатели любят задавать вопрос про порт DNS с хитрым прищуром.

Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.

В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.

На скриншоте видно, что сразу после чистки кэша в него добавляется содержимое файла hosts, и иллюстрировано наличие в кэше неудачных попыток распознавания имени.

При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.

Настройка политики разрешения имен через GPO.

При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.

Операционная система Windows пытается разрешить имена в следующем порядке:

проверяет, не совпадает ли имя с локальным именем хоста;

смотрит в кэш DNS распознавателя;

если в кэше соответствие не найдено, идет запрос к серверу DNS;

если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;

если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;

Для удобства проиллюстрирую алгоритм блок-схемой:

Алгоритм разрешения имен в Windows.

Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.

Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.

Отдельного упоминания заслуживают доменные сети – в них запрос с коротким именем отработает чуть по-другому.

Для того чтоб при работе не нужно было вводить FQDN, система автоматически добавляет часть имени домена к хосту при различных операциях – будь то регистрация в DNS или получение IP адреса по имени. Сначала добавляется имя домена целиком, потом следующая часть до точки.

При попытке запуска команды ping servername система проделает следующее:

Настройка добавления суффиксов DNS через групповые политики.

Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.

Суффиксы DNS и их порядок в выводе ipconfig /all.

Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:

Это поведение иногда приводит в замешательство начинающих системных администраторов.

При диагностике стоит помнить, что утилита nslookup работает напрямую с сервером DNS, в отличие от обычного распознавателя имен. Если вывести компьютер из домена и расположить его в другой подсети, nslookup будет показывать, что всё в порядке, но без настройки суффиксов DNS система не сможет обращаться к серверам по коротким именам.

Отсюда частые вопросы – почему ping не работает, а nslookup работает.

В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.

Если же нет возможности запустить сниффер, рекомендую сравнить вывод ping и nslookup, очистить кэши, проверить работу с другим сервером DNS.

Кстати, если вспомните любопытные DNS-курьезы из собственной практики – поделитесь в комментариях.

Узел «Конфигурация Windows» в основном предназначен для обеспечения безопасности компьютера и учетной записи, для которой применяются данные политики. В конфигурации Windows вы можете найти несколько узлов:

Этот узел предоставляет возможность управлением расширением таблицы политик разрешения имен (NRTP), которая хранит параметры конфигурации для безопасности DNS (DNSSEC). Политика разрешения имен - это объект групповой политики, в котором указаны сведения о политике, которые отображаются в NRTP. Это расширение стоит настраивать только в том случае, если ваш компьютер входит в состав домена Active Directory. Эта политика расположена только в узле «Конфигурация компьютера».

При создании правила вам следует обратить внимание на следующие моменты:

Правила можно создавать для следующих частей пространства DNS:

* Суффикс - это зона пространства имен DNS, к которой применяется данное правило. Суффикс является частью полного доменного имени;
* Префикс - это первая часть полного доменного имени, к которому применяется правило;
* Полное доменное имя - состоит из узла и имени домена, включая домен верхнего уровня;
* Подсеть (IPv4) - это адрес подсети в формате IPv4 для зоны, к которой в случае обратного просмотра будет применено правило;
* Подсеть (IPv6) - это адрес подсети в формате IPv6 для зоны, к которой в случае обратного просмотра будет применено правило;
* Любой - применяется для всех найденных пространств имен DNS.

В поле «Центр сертификации» вы можете указать ЦС, который используется для создания цифровых подписей. Можно вводить ЦС вручную или выбрать нужный, воспользовавшись кнопкой «Обзор».

На вкладке «DNSSEC» вы можете включить DNSSEC для создаваемого правила и указать принудительную проверку конфигурации для безопасности DNS, а также выбрать тип шифрования, который будет использоваться для данного правила. Доступные значения: «Без шифрования (только целостность)», «Тройной DES (3DES)», «Advanced Encryption Standard (AES)» с длиной ключа 128, 192 или 256 бит, или AES с длиной ключа 192 и 256 бит.

На вкладке «Параметры DNS для прямого доступа» вы можете указать серверы, которые клиент DNS будет использовать при соответствии указанного имени; прокси-сервер, который будет использоваться для подключения к Интернету; и можете указать тип шифрования для использования IPSec при взаимодействии между клиентом и сервером DNS.

Если вы нажмете на кнопку «Дополнительные параметры глобальной политики», то сможете настроить параметры роуминга, параметры ошибки запроса и разрешения запроса.

После того как все параметры будут указаны, нажмите на кнопку «Создать». После чего созданное правило отобразится в таблице политик разрешения имен. Изменения политики не будут сохранены, пока вы не нажмете на кнопку «Применить».

Читайте также: