Windows проверить разрешение имен

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

Вот как более детально выглядит ошибка при обработке групповой политики. Событие с кодом 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 ушла.

Использвание команды Nslookup для проверки DNS серверов и записей доменов

Nslookup (name server lookup) это утилита командной строки, которую можно использовать для диагностики службы DNS, проверки DNS записей и серверов и обнаружения проблем, связанных с разрешением имен в системе DNS. Утилита nslookup изначально разработана в составе пакета BIND и в дальнейшем портирована на Windows. На данный момент утилита Nslookup входит в состав всех поддерживаемых версий Windows.

Утилита Nslookup умеет отправлять запросы на DNS сервер, который указан в настройках вашего сетевого подключения. Этот адрес считается DNS севером по умолчанию (default server). Пользователь может указать адрес любого другого доступного DNS сервера, в результате чего все следующие DNS запросы будут выполнятся уже на нем.

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

Вы можете использовать утилиту nslookup в интерактивном или не-интерактивном режиме.

Чтобы выполнить DNS запрос с помощью nslookup в неинтерактивном режиме, откройте командную строку и выполните команду:

В данном примере мы запросили IP адрес сервера vmblog.ru. Утилита nslookup обратилась к DNS серверу (указан в строке Server) и он вернул, что этому имени соответствует IP адрес 37.252.2.22.

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

Если же вы получит ответ вида:

Server: dns1.someserver.com
Address: хх.хх.хх.хх
*** dns1.contoso.com can’t find vmblog.ru: Non-existent domain

Это означает, что для данного имени не найдено записей в DNS зоне.

В том случае, если ваш DNS сервер недоступен или не отвечает, вы получите ошибки DNS request timed out.

В этом случае проверьте, указан ли у вас правильный адрес DNS сервера и нет ли проблем с сетевым подключением у провайдера.

Строка Non-authoritative answer (Не заслуживающий доверия ответ)означает, что DNS сервер, который выполнил запрос не является владельцем зоны vmblog.ru (в его базе нет записей об этом домене), а для выполнения разрешения имени использовался рекурсивный запрос к другому DNS серверу.

Можно обратиться к авторитетному серверу, указав его адрес непосредственно в параметрах утилиты nslookup. Например, чтобы выполнить разрешение имени на DNS сервере, который содержит данный домен (authoritative server), используйте команду:
nslookup vmblog.ru ns1.vmblog.ru
При запуске nslookup без параметров, утилита переходит в интерактивный режим. В этом режиме вы можете выполнять различные команды. Полный список доступных внутренних команд утилиты nslookup можно вывести, набрав знак вопроса.

Для завершения работы с nslookup наберите команду exit и нажмите Enter.

Чтобы найти DNS сервера, которые отвечают за конкретный домен (authoritative servers), выполните команды:

Вы можете выполнить и обратное преобразование (получить DNS имя по IP адресу), для этого просто наберите IP адрес в интерактивной строке nslookup и нажмите Enter.

Вы можете задать тип DNS записей, которые должна вернуть утилита nslookup. Например, чтобы перечислить все почтовые сервера, заданные для определенного домена, выполните команду:

nslookup -type=mx gosuslugi.ru

Не заслуживающий доверия ответ:
gosuslugi.ru MX preference = 20, mail exchanger = mx68.gosuslugi.ru
gosuslugi.ru MX preference = 10, mail exchanger = mx.gosuslugi.ru
mx68.gosuslugi.ru internet address = 109.207.8.100
mx.gosuslugi.ru internet address = 109.207.1.100

Как вы видите, у данного домене 2 MX записи с приоритетами 10 и 20 (Чем меньше число, тем выше приоритет адреса). Если запись MX не отображается, скорее всего они просто не настроены для данного домена.

Чтобы вывести все DNS записи в доменной зоне, выполните команду:

nslookup -type=any gosuslugi.ru

gosuslugi.ru nameserver = ns2.gosuslugi.ru
gosuslugi.ru nameserver = ns8-l2.nic.ru
gosuslugi.ru nameserver = ns1.gosuslugi.ru
gosuslugi.ru nameserver = ns4-l2.nic.ru
gosuslugi.ru MX preference = 10, mail exchanger = mx.gosuslugi.ru
gosuslugi.ru MX preference = 20, mail exchanger = mx68.gosuslugi.ru
ns2.gosuslugi.ru internet address = 213.59.255.175
ns8-l2.nic.ru internet address = 91.217.21.1
ns1.gosuslugi.ru internet address = 109.207.2.218
ns4-l2.nic.ru internet address = 91.217.20.1
mx.gosuslugi.ru internet address = 109.207.1.100
mx68.gosuslugi.ru internet address = 109.207.8.100

Использование опции отладки (debug) позволяет получить дополнительную информацию, содержащуюся в заголовках запросов клиента и ответов сервера (время жизни, флаги, типы записей и т.п.):

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

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

Как уже было сказано, комплексную проверку доступности служб AD можно осуществить с помощью утилиты dcdiag. Но поскольку она устанавливается дополнительно, то в оперативных случаях следует быть готовым выполнить простейшие проверки стандартными средствами операционной системы. Обычно достаточно проконтролировать возможность разрешения имен с помощью типовых утилит. Необходимо проверить достижимость контроллера домена по его краткому (без доменного суффикса) и полному имени, а также разрешение адресов служб AD. Соответствующая структура DNS создается автоматически, и обычно достаточно проконтролировать ее наличие в оснастке управления сервером DNS. Если такая возможность отсутствует, то нужно вручную, с помощью команды nslookup, выполнить попытку разрешения имен, перечисленных в табл. 11.6. Для разрешения имен служб (записи типа SRV) в nslookup предварительно следует выполнить команду set type=all или set type=srv. Обратите также внимание, что в операции разрешения имени сервера глобального каталога указывается имя леса, а не домена. Обычно в малых организациях эти имена совпадают.

Таблица 11.6. Перечень имен, проверяемых в процессе теста

Имя	Тип записи	Чему соответствует
_\dap._tcp.dc._msdcs.	SRV	Контроллер домена
_ldap._tcp.pdc._msdcs.	SRV	Эмулятор первичного контроллера
_ldap._tcp.gc._msdcs.	SRV	Сервер глобального каталога
_kerberos._tcp.dc._msdcs.	SRV	Расположение службы KDC

Обратите внимание на весьма простую операцию, удачное выполнение которой зависит от правильности настройки системы, разрешения имен и от функционирования контроллера домена. Попробуйте открыть следующий сетевой ресурс: \\ \SYSVOL. Если попытка неудачна, то либо в организации неверно настроено разрешение имен, либо контроллер домена неработоспособен.

Порядок разрешения имен узла Microsoft TCP/IP

Аннотация

В данной статье рассматриваются различные методы имя узла для разрешения адреса IP используется клиентами Microsoft Windows. Последовательность методов отличается от последовательность, используемая для разрешения имен NetBIOS в IP-адреса.

Дополнительная информация

В сети, использующей протокол TCP/IP необходимо преобразовать имена ресурсов в IP-адреса для подключения к этим ресурсам. Клиенты Microsoft Windows будет следовать последовательность методов при попытке разрешения имени в адрес, Остановка поиска, если он успешно соответствует имени в IP-адрес. Существуют две последовательности main используется почти во всех случаях: при разрешении NetBIOS и имя узла разрешение. Клиентам, подключающимся к ресурсам на серверах Майкрософт, обычно через диспетчер файлов или сетевом окружении наиболее часто использовать разрешение имен NetBIOS. За дополнительной информацией обратитесь к следующей статье базы знаний Майкрософт:

119493 NetBIOS через WINS и разрешения имен TCP/IP

Разрешение имен узлов разрешения имен TCP/IP ресурсов, которые не подключаются через интерфейс NetBIOS. Наиболее распространенным примером этого является веб-обозревателях, например Microsoft Internet Explorer. Другие примеры приложений Интернета, Ping, FTP и Telnet. Многие современные базы данных и почтового приложения, которые подключаются с помощью Winsock, реализация Microsoft Windows сокеты TCP/IP также использовать разрешение имен узлов. Примерами таких приложений являются Outlook и Exchange.When устранения проблем с разрешением имен, очень важно для сужения ли разрешение приложения NetBIOS-имя или имя узла. Примечание: В контексте этой статьи термин «клиент» не ссылается обязательно на рабочей станции. Windows NT server будет иметь роль клиента при его требуется доступ к ресурсам, требующим разрешения имен узлов. Разрешение имен узлов обычно использует следующую последовательность:

Клиент проверяет, если запрашиваемое имя собственного.

Клиент затем производит поиск в локальном файле Hosts, список IP-адреса и имена, хранящиеся на локальном компьютере. Примечание: местоположение файла Hosts зависит от операционной системы: Windows NT %Systemroot%\System32\Drivers\Etc Windows 95 \ Windows for Workgroups \ Windows 3.1 \ MS-Client 3.0 \Net Lan Manager 2.2c Client \Net Где % Systemroot % — папка, в которой установлена Windows NT, — это диск, на котором установлена операционная система, а ссылается на загрузочный диск или диск C. Пример файла hosts Hosts.sam, устанавливается вместе с протоколом TCP/IP, показывая в необходимый формат.

Серверы имен (DNS) домена запрашиваются.

Если имя по-прежнему не устранена, последовательность разрешение имен NetBIOS используется в качестве резервной копии. Этот порядок можно изменить, настроив тип узла NetBIOS клиента.

Клиент Windows попробуйте каждый из этих методов, пока он успешно разрешает имя или исчерпывает эти методы. Windows NT, Windows 95 или Windows для рабочих групп клиентов, использующих Microsoft TCP/IP 3.11b, выполните следующее. LAN Manager 2.2c или клиентов Microsoft 3.0 клиент не будет использовать разрешение имен NetBIOS как резервной копии. Дополнительные сведения можно найти в следующих статьях базы знаний Майкрософт:

169141 разрешение NetBIOS и имя узла для клиента MS и LM 2.2 cПри разрешении имен клиента будет пропускать методы, для которых не настроен. Например если отсутствует файл hosts на компьютере, затем он будет пропустить шаг #2 и повторите запрос к DNS-серверу. Если нет IP-адреса сервера DNS введены в конфигурации TCP/IP клиента, клиент будет перейдите к следующему шагу в последовательности после DNS. Метод для изменения порядка разрешения имени узла, отличается для различных операционных систем и версий. Эти определения приводятся в наборы ресурсов для определенных операционных систем, а также в Base.For знаний Майкрософт Дополнительные сведения, можно найти в следующих статьях базы знаний Майкрософт:

171567 Windows NT 4.0 ServiceProvider приоритета значения не применяется

Как изменить порядок разрешения имен в Windows 95 и Windows NT 139270

119372 Установка порядок поиска разрешение имен для TCP/IP-32

Устранение неполадок

Проблема: Не удается разрешить имя узла клиента. Устранение неполадок действия: Если клиент не может разрешить имя узла, а затем лучше всего проверить узла должны использовать разрешение имен последовательности, перечисленных выше, клиент. Если имя не существует в какие-либо ресурсы, используемые клиентом, необходимо решить для какой ресурс для его добавления. Если имя существует в один из ресурсов, например DNS-сервер или сервер Windows Internet Name Service (WINS), клиент не разрешает имя правильно сосредоточить свое внимание на устранение конкретного ресурса. Кроме того убедитесь, что клиент пытается разрешить имя узла, а не имя NetBIOS. Многие приложения имеют несколько методов, которые они могут использовать для разрешения имен, это особенно верно, почта и базы данных приложений. Приложение может быть настроено для подключения к ресурсам с помощью NetBIOS. В зависимости от конфигурации клиента клиент может обойти разрешения имен узлов. Там будет необходимо либо изменить тип подключения для сокетов TCP/IP или устранения неполадок как проблема NetBIOS. Проблема: Клиент разрешает имя очень медленно или не может разрешить имя и долго не сообщает об ошибке. Действия по устранению неполадок: DNS-серверов в конфигурации TCP/IP клиента, но сервер не доступен для клиента обычно в результате. Так как протокол TCP/IP предполагает сети с низкой надежностью, клиент повторной попытки соединения до оставления попытка запроса на DNS-сервере. Затем клиент попытается опросить второго сервера DNS, если она настроена и использовать то же время к сбою. Только после этого будет клиент шаги для разрешения NetBIOS-имен как описано выше. Существует три способа подход этой проблемы.

Если имя узла правильно введена в хост-файле, будет разрешена прежде чем клиент предпринимает попытку запроса DNS. Это решение работает также в том случае, если DNS-серверы временно недоступны и есть небольшое количество имена узлов, которые должны быть разрешены. Настройка вручную файлы Hosts для многочисленных клиентов может быть чрезмерно высокой. –ИЛИ-

Если доступных DNS-серверов, но неверные адреса DNS-серверов в конфигурации TCP/IP для клиентов, затем исправление этих адресов позволит клиентам немедленно связаться с DNS-серверами. Даже если DNS-сервер сообщает о том, что он не может разрешить имя, это будет происходить намного быстрее, чем если клиент не может достичь DNS-сервера на всех. –ИЛИ-

Если DNS-серверы настроены на клиенте, но эти серверы окончательно недоступны, то удалите IP-адреса DNS-серверов из конфигурации клиента. Клиент затем будет выполнять поиск DNS без задержки. –ИЛИ-

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

Дополнительные сведения о TCP/IP и разрешения имен, можно найти в следующем техническом документе анонимный FTP-сервера корпорации Майкрософт: