Обновлено 30.07.2021
Всем привет сегодня разберем как решается ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно в Windows Server 2012 R2. Симптомы у данного сообщения, не обрабатываются групповые политики и не правильно могут разрешаться имена.
Вот как более детально выглядит ошибка при обработке групповой политики. Событие с кодом ID 1054: Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно.
Ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена
Проверка разрешения имен
Первым делом нужно проверить может ли наш сервер правильно разрешать внутренние доменные имена. Для этого воспользуемся утилитой nslookup. Выберите любое доменное имя сервера или лучше контроллера домена. Открываем командную строку и пишем
dc1 это мой контроллер домена. Как видите у меня локальные DNS имена разрешал, внешний DNS сервер, так как на сервере стоит два сетевых интерфейса и один со внешним ip адресом.
выполнение nslookup
причину мы выяснили, из за чего выскакивает ошибка.
Приоритетность контроллеров домена
Давайте теперь посмотрим, какой из контроллеров домена является для вашего сервера самым авторитетным, ранее я уже рассказывал как определить какой domain controller вас авторизовал, но нам нужен авторитет в вашем домене и возможность обращение к нему по LDAP. Делается это командой
nltest /dnsgetdc:ваше имя домена
Я вижу что у меня это dc2, его ip адрес мне и понадобится.
Ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена
Так же нужно проверить доступность DC по протоколу RPC, с помощью команды
nltest /dsgetdc:ваше имя домена
доступность DC по протоколу RPC
В данном случае проблем я не обнаружил. Пилим дальше.
Настройка DNS на внешнем сетевом интерфейсе
Так как мы выяснили ip адрес контроллера домена, что нас авторизовывал, его мы и пропишем в качестве DNS сервера на внешнем сетевом интерфейсе. В свойствах ipv4 прописываем его как основной DNS сервер. Напомню, что для разрешения внешних имен у вас должна быть настроена рекурсия на ДНС сервере.
настройка dns сервера
Теперь снова выполним команду nslookup и видим, что теперь внутренние имена разрешаются внутренним DNS сервером.
выполнение nslookup
Выполним теперь обновление групповой политики с помощью данной команды
Видим, что все обновилось корректно и проблема при обработке групповой политики, об этом сообщает событие с кодом ID 1502. Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно в Windows Server 2012 R2 ушла.
обновление GP
Из скрина выше видно что прилетели 24 политики. На этом все. Материал сайта pyatilistnik.org
Зарегистрирован: 28.08.2019
Пользователь #: 171,955
Сообщения: 77
Зарегистрирован: 28.03.2007
Пользователь #: 53,638
Сообщения: 4774
Зарегистрирован: 28.03.2007
Пользователь #: 53,638
Сообщения: 4774
Источник
Устранение сбоев Kerberos в Internet Explorer
Эта статья помогает изолировать и устранить причины различных ошибок при доступе к веб-сайтам, настроенным для использования проверки подлинности Kerberos в Internet Explorer. Количество потенциальных проблем почти такое же большое, как и количество доступных средств для их решения.
Распространенный симптом при сбое Kerberos
Вы пытаетесь получить доступ к веб-сайту, на котором Windows была настроена интегрированная проверка подлинности, и вы ожидаете использовать протокол проверки подлинности Kerberos. В этой ситуации браузер немедленно запросит учетные данные:
Хотя вы вводите допустимые имя пользователя и пароль, вам снова будет предложено (всего три запроса). Затем показан экран, на который указывается, что доступ к нужному ресурсу запрещен. На экране отображается код состояния HTTP 401, похожий на следующую ошибку:
Не разрешено
ОШИБКА HTTP 401. Запрашиваемой ресурс требует проверки подлинности пользователей.
На сервере Microsoft IIS (IIS) журналы веб-сайтов содержат запросы, которые заканчиваются кодом состояния 401.2, например следующим журналом:
Или на экране отображается код состояния 401.1, например следующий журнал:
Определите, используется ли Kerberos
При устранении неполадок с проверкой подлинности Kerberos рекомендуется упростить настройку до минимума. То есть один клиент, один сервер и один сайт IIS, работающий в порту по умолчанию. Кроме того, можно выполнять некоторые основные действия по устранению неполадок. Например, используйте тестовую страницу для проверки используемого метода проверки подлинности. Если вы используете ASP.NET, вы можете создать ASP.NET тестовую страницу проверки подлинности.
Если вы используете классический ASP, вы можете использовать следующую страницу Testkerb.asp:
Вы также можете использовать следующие средства, чтобы определить, используется ли Kerberos:
Дополнительные сведения о том, как можно сгенерить такие следы, см. в статью отслеживание на стороне клиента.
Когда используется Kerberos, запрос, отправленный клиентом, является большим (более 2000 битов), так как загон включает билет HTTP_AUTHORIZATION Kerberos. Следующий запрос — страница, на основе Windows kerberos для проверки подлинности входящих пользователей. Размер запроса GET составляет более 4000 bytes.
Если используется рукопожатие NTLM, запрос будет значительно меньше. В следующем захвате клиента показан запрос на проверку подлинности NTLM. Запрос GET гораздо меньше (менее 1400 bytes).
После определения сбоя проверки подлинности Kerberos проверьте каждый из следующих элементов в заданного порядке.
Проверка сбоя проверки подлинности Kerberos
В следующих разделах описываются вещи, которые можно использовать для проверки сбоя проверки подлинности Kerberos.
Клиент и сервер в одном домене
Использование Kerberos требует домена, так как билет Kerberos доставляется контроллером домена (DC). Кроме того, возможны дополнительные сценарии, в которых:
Эти возможные сценарии обсуждаются в разделе Почему не удается делегирования Kerberos между двумя моими лесами, хотя он использовался для работы в разделе этой статьи.
Настроен ли IIS для использования интегрированной проверки подлинности
Включена ли интегрированная проверка подлинности в Internet Explorer
Используется ли URL-адрес, используемый для разрешения в зону безопасности, для которой можно отправить учетные данные
Всегда запустите эту проверку для следующих сайтов:
Вы можете проверить, в какой зоне браузер решает включить сайт. Для этого откройте меню File internet Explorer и выберите Свойства. В окне Properties будет отображаться зона, в которой браузер решил включить веб-сайт, на который вы просматриваете.
Вы можете проверить, позволяет ли зона, в которую включен сайт, автоматический логотип. Для этого откройте меню internet options internet Explorer и выберите вкладку Security. После выбора нужной зоны выберите кнопку Настраиваемый уровень для отображения параметров и убедитесь, что выбран автоматический логотип. (Как правило, эта функция включена по умолчанию для зон Интрасети и доверенных сайтов).
Даже при такой конфигурации не часто (так как для клиента требуется доступ к DC), Kerberos можно использовать для URL-адреса в интернет-зоне. В этом случае, если параметры по умолчанию не будут изменены, браузер всегда будет подсказок пользователю для учетных данных. Делегация Kerberos не будет работать в зоне Интернета. Это потому, что Internet Explorer позволяет делегирования Kerberos только для URL-адресов в зонах Интрасети и Доверенные сайты.
Настроен ли сервер IIS для отправки www-authenticate: заготавка переговоров
Если IIS не отправляет этот заголовок, используйте консоль IIS Manager для настройки заголовка Negotiate через свойство конфигурации NTAuthenticationProviders. Дополнительные сведения см. в Windows поставщиков проверки подлинности.
Доступ к консоли можно получить с помощью параметра Providers Windows проверки подлинности в диспетчере IIS.
По умолчанию свойство NTAuthenticationProviders не установлено. Это приводит к отправке iiS как заглавных Windows NT, так и lan-менеджеров (NTLM).
Установлен ли клиент и сервер на одном компьютере
По умолчанию Kerberos не включен в этой конфигурации. Чтобы изменить это поведение, необходимо установить ключ DisableLoopBackCheck реестра. Дополнительные сведения см. в 926642.
Может ли клиент получить билет Kerberos
Вы можете использовать средство Kerberos List (KLIST), чтобы убедиться, что клиентский компьютер может получить билет Kerberos для данного имени основного имени службы. В этом примере основное имя службы (SPN) — http/web-server.
KLIST является родным Windows с Windows Server 2008 для серверных операционных систем и Windows 7 Пакет обновления 1 для клиентских операционных систем.
При сбое запроса на билет Kerberos проверка подлинности Kerberos не используется. Может произойти откат NTLM, так как запрашиваемая SPN неизвестна dc. Если dc недостижим, не происходит откат NTLM.
Чтобы объявить SPN, см. следующую статью:
Использование spNs при настройкевеб-приложений, которые находятся на службы IIS.
Использует ли веб-сервер порт по умолчанию (80)
По умолчанию Internet Explorer не включает сведения о номере порта в SPN, который используется для запроса билета Kerberos. Это может быть проблемой, если вы используете IIS для пользования несколькими сайтами в разных портах и удостоверениях. В этой конфигурации проверка подлинности Kerberos может работать только для определенных сайтов, даже если все spNs были правильно объявлены в Active Directory. Чтобы устранить эту проблему, необходимо установить FEATURE_INCLUDE_PORT_IN_SPN_KB908209 значение реестра. (Сведения о том, как объявить ключ, см. в разделе Ключи функций Internet Explorer.) Этот параметр заставляет Internet Explorer включить номер порта в SPN, который используется для запроса билета Kerberos.
Использует ли Internet Explorer ожидаемый SPN
Если к веб-сайту можно получить доступ с помощью псевдонима (CNAME), internet Explorer сначала использует DNS-разрешение для разрешения имени псевдонима на имя компьютера (ANAME). Затем имя компьютера используется для создания SPN и запроса билета Kerberos. Даже если URL-адрес, который вошел в адресной панели Internet Explorer, internet Explorer запрашивает http://MYWEBSITE SPN для HTTP/MYSERVER, если MYWEBSITE является псевдонимом (CNAME) MYSERVER (ANAME). Это поведение можно изменить с помощью FEATURE_USE_CNAME_FOR_SPN_KB911149 ключа реестра. (См. ключи функции Internet Explorer для получения сведений о том, как объявить ключ.)
Трассировка сетевого монитора — это хороший метод проверки SPN, связанного с билетом Kerberos, как в следующем примере:
Соответствует ли удостоверение пула приложений учетной записи, связанной с SPN
Когда билет Kerberos отправляется из Internet Explorer на сервер IIS, он шифруется с помощью закрытого ключа. Закрытый ключ — это хаш пароля, используемого для учетной записи пользователя, связанной с SPN. Таким образом, расшифровать билет может только приложение, которое работает под этой учетной записью.
Ниже приводится сводка алгоритма проверки подлинности Kerberos:
Internet Explorer определяет SPN с помощью URL-адреса, вступив в адресную планку.
SpN передается через API интерфейса поставщика службы поддержки безопасности (SSPI) (InitializeSecurityContext) в системный компонент, отвечающий за безопасность Windows безопасности (процесс службы подсистем местного органа безопасности (LSASS). На данном этапе можно увидеть, что код Internet Explorer не реализует код для построения билета Kerberos. Internet Explorer вызывает только API SSPI.
LSASS использует СНО, переданный для запроса билета Kerberos в DC. Если dc может обслуживать запрос (известный SPN), он создает билет Kerberos. Затем он шифрует билет с помощью ключа, построенного из хаши пароля учетной записи пользователя для учетной записи, связанной с SPN. Затем LSASS отправляет билет клиенту. Что касается Internet Explorer, то билет является непрозрачной blob.
Internet Explorer инкапсулирует билет Kerberos, предоставленный LSASS в загонке, а затем отправляет его на Authorization: Negotiate сервер IIS.
IIS обрабатывает запрос и передает его в правильный пул приложений с помощью указанного загона хоста.
Пул приложений пытается расшифровать билет с помощью API SSPI/LSASS и следуя следующим условиям:
Если билет можно расшифровать, проверка подлинности Kerberos будет успешной. Доступны все службы, связанные с билетом (вымысление, делегирование, если позволяет билет и так далее).
Если расшифровать билет нельзя, возвращается ошибка Kerberos (KRB_AP_ERR_MODIFIED). Эта ошибка является общей ошибкой, которая указывает, что билет был изменен каким-либо образом во время его транспортировки. Так что расшифровать билет не получается. Эта ошибка также регистрируется в журналах Windows событий.
Если вы явно не объявляете SPN, проверка подлинности Kerberos работает только в соответствии с одним из следующих удостоверений пула приложений:
Но эти удостоверения не рекомендуется, так как они являются угрозой безопасности. В этом случае билет Kerberos создается с помощью spN по умолчанию, созданного в Active Directory при добавлении в домен компьютера (в этом случае запущенного сервера IIS). Этот SPN по умолчанию связан с учетной записью компьютера. В соответствии с IIS учетная запись компьютера сопопосается с сетевой службой или объектом ApplicationPoolIdentity.
Если в пуле приложений необходимо использовать удостоверение, помимо перечисленных удостоверений, объявите SPN (с помощью SETSPN). Затем связать его с учетной записью, используемой для удостоверения пула приложений. Обычной ошибкой является создание аналогичных СНО, которые имеют различные учетные записи. Например,
Эта конфигурация не сработает, так как нет детерминистского способа узнать, будет ли зашифрован билет Kerberos для SPN http/mywebsite с помощью пароля UserAppPool1 или UserAppPool2. Эта конфигурация обычно создает KRB_AP_ERR_MODIFIED ошибок. Чтобы определить, есть ли вы в этом плохом сценарии повторяемой СНО, используйте средства, задокументированные в следующей статье:
Начиная с Windows Server 2008, вы также можете использовать обновленную версию SETSPN для Windows, которая позволяет обнаруживать дублирующиеся spNs с помощью команды при объявлении нового SPN для целевой учетной setspn –X записи. Дополнительные сведения см. в setspn.
Кроме того, рекомендуется просмотреть следующие статьи:
Не удается ли проверка подлинности Kerberos в версиях IIS 7 и более поздних версий, даже если она работает в IIS 6
Проверка подлинности режима ядра — это функция, представленная в IIS 7. Он предоставляет следующие преимущества:
Если spN объявлен для определенной учетной записи пользователя (также используемой в качестве удостоверения пула приложений), проверка подлинности режима ядра не может расшифровать билет Kerberos, так как она использует учетную запись машины. Эта проблема типична для сценариев веб-фермы. В этом сценарии обычно объявляется spN для (виртуального) имени хост-имени NLB. Чтобы предотвратить эту проблему, используйте один из следующих методов:
Почему не удается делегирование, хотя проверка подлинности Kerberos работает
В этом сценарии проверьте следующие элементы:
Зона Internet Explorer, используемая для URL-адреса. Делегирования Kerberos разрешено только для зон Интрасети и доверенных сайтов. (Другими словами, Internet Explorer задает флаг при вызове ISC_REQ_DELEGATE InitializeSecurityContext только в том случае, если определяемая зона — это интрасеть или доверенные сайты.)
Учетная запись пользователя пула приложений IIS, на который размещен ваш сайт, должна иметь флажок Доверенный для делегирования в Active Directory.
В случае сбоя делегирования рассмотрите возможность использования диспетчера конфигурации Kerberos для IIS. Этот инструмент позволяет диагностировать и исправлять конфигурации IIS для проверки подлинности Kerberos и связанных СНО в целевых учетных записях. Дополнительные сведения см. в README.md. Вы можете скачать средство отсюда.
Почему я получаю плохую производительность при использовании проверки подлинности Kerberos
Kerberos — это протокол проверки подлинности на основе запросов в более старых версиях Windows Server, таких как Windows Server 2008 SP2 и Windows Server 2008 R2. Это означает, что клиент должен отправить билет Kerberos (который может быть довольно большой blob) с каждым запросом, который сделан на сервер. Это противоречит методам проверки подлинности, которые используют NTLM. По умолчанию NTLM основан на сеансах. Это означает, что браузер будет проверить подлинность только одного запроса, когда откроет подключение TCP к серверу. Каждый последующий запрос на одно и то же подключение TCP больше не требует проверки подлинности для того, чтобы запрос был принят. В более новых версиях IIS с Windows R2 начиная с 2012 года Kerberos также основан на сеансах. Только первый запрос на новое подключение TCP должен быть аутентификацией на сервере. Последующие запросы не должны включать билет Kerberos.
Это поведение можно изменить с помощью свойства authPersistNonNTLM, если вы работаете в версиях IIS 7 и более поздних версий. Если свойство настроено на верное, Kerberos станет сеансом на основе. В противном случае он будет основан на запросе. Это будет иметь более плохую производительность, так как каждый раз необходимо включать больший объем данных для отправки на сервер. Дополнительные сведения см. в рублях Запрос на основе сеанса проверки подлинности Kerberos (или параметр AuthPersistNonNTLM).
Почему не удается делегирования Kerberos между двумя лесами, хотя раньше он работал
Рассмотрим следующий сценарий.
В этом сценарии делегирования Kerberos может перестать работать, даже если раньше она работала, и вы не вносили изменений ни в леса, ни в домены. Проверка подлинности Kerberos по-прежнему работает в этом сценарии. Не удается только делегирования.
Эта проблема может возникнуть из-за обновлений Windows Server, выпущенных Корпорацией Майкрософт в марте 2019 г. и июле 2019 г. Эти обновления отключили неподготовленную делегирование Kerberos (возможность делегирования маркера Kerberos из приложения в службу back-end) через границы леса для всех новых и существующих трастов. Дополнительные сведения см. в статью Updates to TGT delegation across incoming trusts in Windows Server.
Клавиши функций Internet Explorer
Эти клавиши являются ключами реестра, которые включат или выключают некоторые функции браузера. Ключи расположены в следующих расположениях реестра:
Клавиши функций должны создаваться в одном из этих местоположений в зависимости от того, хотите ли вы включить или отключить эту функцию:
Источник
Adblock
detector
Обновлено 2023 января: остановите эти сообщения об ошибках и устраните распространенные проблемы с помощью этого инструмента. Получить сейчас в эту ссылку
- Скачайте и установите программного обеспечения.
- Он просканирует ваш компьютер на наличие проблем.
- Затем инструмент исправить проблемы которые были найдены.
Все мы знаем, что механизм групповой политики периодически обновляет всю архитектуру групповой политики каждые 90 минут. Таким образом, когда мы настраиваем параметр GPO, нам приходится ждать, пока этот параметр будет применен к клиентам. Кроме того, клиентам может потребоваться выйти из системы и снова войти в систему, чтобы настройка вступила в силу.
Если нам нужно обновить архитектуру GPO сразу после применения параметра, мы используем команду gpupdate /force. Использование параметра /force немедленно обновит объекты групповой политики как на уровне пользователя, так и на уровне компьютера. Кроме того, изменение относится не только к новым или измененным объектам групповой политики, но и к более старым объектам групповой политики.
Однако иногда запуск команды gpupdate /force не приводит к обновлению механизма GPO. Недавно мы столкнулись с этой проблемой на нашем сервере Windows. Следующее сообщение было показано, когда мы решили обновить механизм GPO:
Не удалось успешно обновить ИТ-политику. Были обнаружены следующие ошибки:
Ошибка обработки групповой политики из-за отсутствия сетевого подключения к контроллеру домена. Это может быть временное состояние. Сообщение об успешном завершении создается, когда компьютер подключен к контроллеру домена и групповая политика успешно обрабатывается. Если вы не видите сообщение об успешном завершении в течение нескольких часов, обратитесь к администратору.
Что вызывает сообщение «Обработка групповой политики не удалась из-за отсутствия сетевого подключения к контроллеру домена»
Эта проблема может быть временной и может быть вызвана одной или несколькими из следующих причин:
- разрешение имен/сетевое соединение с текущим контроллером домена;
- Задержка службы репликации файлов (файл, созданный на другом контроллере домена, не был реплицирован на текущий контроллер домена);
- Клиент распределенной файловой системы (DFS) отключен.
Эта ошибка может возникать не только при запуске gpupdate /force вручную, но и после запуска инструментов DCDIAG или в средстве просмотра событий при входе пользователя в систему. В некоторых случаях при возникновении этой ошибки вы не можете открыть общие сетевые ресурсы или ресурсы домена DFS с помощью сообщение об ошибке «Сетевой путь не найден».
Чтобы устранить ошибку «Ошибка обработки групповой политики из-за отсутствия сетевого подключения к контроллеру домена», выполните следующие действия.
Обновлено: январь 2023 г.
Этот инструмент настоятельно рекомендуется, чтобы помочь вам исправить вашу ошибку. Кроме того, этот инструмент обеспечивает защиту от потери файлов, вредоносных программ и аппаратных сбоев, а также оптимизирует работу вашего устройства для достижения максимальной производительности. Если у вас уже есть проблема с компьютером, это программное обеспечение может помочь вам решить ее и предотвратить повторение других проблем:
- Шаг 1: Установите инструмент восстановления и оптимизации ПК. (Виндовс 10, 8, 7, ХР, Виста).
- Шаг 2: Нажмите Начать сканирование чтобы определить, какие проблемы вы испытываете с вашим компьютером.
- Шаг 3: Нажмите Починить всечтобы решить все проблемы.
Откройте локальную политику безопасности
- Первое, что нужно сделать в этой ситуации — открыть локальную политику безопасности.
- Для этого нажмите Windows + R, чтобы открыть диалоговое окно «Выполнить».
- Затем скопируйте и вставьте файл secpol.MSC и нажмите Enter.
Это должно открыть окно политики безопасности, и вы можете продолжить оттуда.
Назначение разрешений пользователям
- Следующим шагом является открытие назначения прав пользователя в только что открывшемся окне.
- Для этого перейдите в «Настройки безопасности» и выберите «Локальные политики».
- Ниже этого нажмите «Назначить права пользователя».
- Наконец, вы должны дважды щелкнуть Доступ к этому компьютеру из сети.
Эта функция определяет, какому пользователю разрешен доступ к сети с другого компьютера.
Добавить нового пользователя или группу
- Наконец, вам нужно добавить нового пользователя или группу, чтобы все снова заработало правильно.
- В окне, которое появляется после того, как вы дважды щелкните Доступ к этому компьютеру из сети, мы ожидаем, что вы нажмете Добавить пользователя или группу.
- Внесите необходимые изменения, затем нажмите OK и продолжите.
ОДОБРЕННЫЙ: Чтобы исправить ошибки Windows, нажмите здесь.
Часто задаваемые вопросы
Чтобы устранить ошибку «Ошибка обработки групповой политики из-за отсутствия сетевого подключения к контроллеру домена», которая может возникнуть при запуске gpupdate /force, необходимо выполнить следующие действия: Откройте локальную политику безопасности. Изменить назначение прав пользователя. Добавьте нового пользователя или группу.
Если параметры политики не применяются к клиенту, проверьте раздел GPO. Если вы настраиваете параметр в разделе «Конфигурация компьютера», ваша групповая политика должна быть связана с OU с объектами-компьютерами. То же самое верно, если вы настраиваете параметр в разделе «Конфигурация пользователя».
В окне командной строки введите gpupdate /force и нажмите Enter на клавиатуре. Строка «Обновление политики» должна появиться в окне командной строки ниже того места, где вы только что набрали. После завершения обновления вам будет предложено выйти из системы или перезагрузить компьютер.
- Щелкните правой кнопкой мыши выбранное подразделение и выберите «Обновление групповой политики».
- В диалоговом окне «Принудительное обновление групповой политики» нажмите «Да».
- Это эквивалентно запуску GPUpdate.exe /force из командной строки.
Сообщение Просмотров: 127
Добрый день. Примерно раз в неделю выскакивает ошибка:
Ошибка при обработке групповой политики. Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно. Источник GroupPolicy, код 1054.
Практически сразу за ней :
Компьютер не может установить безопасный сеанс связи с контроллером домена DOMAIN по следующей причине:
Сервер RPC недоступен. Источник NETLOGON, код 5719
На сервере крутится SQL 2008, сервер терминалов и сервер 1С v8.
Сразу после ошибки, на сервер теминалов не возможно зайти. Подключение клиентов 1С, так же не возможно. По данным ошибка нашел ответ от майкрософт — обновить систему. Поставил все обновления, проблема осталась. Решается
временно перезагрузкой сервера. Других ошибок в системе нет.
- Remove From My Forums
GPUpdate fails: Event ID: 1054 — Windows could not obtain the name of a domain controller
-
Question
-
In troubleshooting another issue (windows updates failing to download with code 8024402c, unsure if related), I noticed that gpupdate fails to execute on my machine. This is a Win7 x86 client on a domain with three 2008/2008R2 DCs.
GPUpdate /force reports:
Updating Policy... User policy could not be updated successfully. The following errors were encountered: The processing of Group Policy failed. Windows could not obtain the name of a domain controller. This could be caused by a name resolution failure. Verify your Domain Name System (DNS) is configured and working correctly. Computer policy could not be updated successfully. The following errors were encountered: The processing of Group Policy failed. Windows could not obtain the name of a domain controller. This could be caused by a name resolution failure. Verify your Domain Name System (DNS) is configured and working correctly. To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access informati on about Group Policy results.
Event Logs Show:
Log Name: System Source: GroupPolicy: Event ID: 1054 Level: Error User: System OpCode: (1) The processing of Group Policy failed. Windows could not obtain the name of a domain controller. This could be caused by a name resolution failure. Verify your Domain Name System (DNS) is configured and working correctly. Details: - EventData SupportInfo1 1 SupportInfo2 1903 ProcessingMode 0 ProcessingTimeInMilliseconds 1123 ErrorCode 58 ErrorDescription The specified server cannot perform the requested operation.
Client is configured with three DNS servers. Each return all three DCs, and the correct IP addresses, when queried for _ldap._tcp.dc._msdcs.domainname.
Checking the event logs, this seems to have been happening consistently for the last month or so. There is an occassional group policy application success in the event logs, but 99% are failures. I don’t see any other relevant errors in
the event logs.DCDiag is fine.
GPResult shows GPOs being applied.
How can I figure out why GPUpdate can’t find a DC? Does the error detail «The Specified server cannot perform the requestion operation.» suggest that the issue isn’t actually finding a DC, but something else failing?
-
Edited by
Friday, October 19, 2012 6:04 PM
-
Edited by
Answers
-
Hello,
As I see, you may have have DNS issues to locate DCs.
If this is the case, I would recommend proceeding like that:
- Make sure that each DC has only one IP address in use and ONLY one NIC card enabled (Other NICs should be disabled)
- Make sure that public DNS servers are configured as DNS forwarders and not in IP settings of DCs
- Choose a healthy DC / DNS server and make each DC point to it as primary DNS server
- Make each DC / DNS server point to its private IP address as secondary DNS server
- Make sure that needed ports for AD replication are opened:
http://technet.microsoft.com/en-us/library/bb727063.aspx - Check your DNS zones and remove manually all obsolete / unused DNS records for DCs
Once done, run ipconfig /registerdns and restart netlogon on each DC you have.
On the client computer, run ipconfig /flushdns and check again.
This
posting is provided «AS IS» with no warranties or guarantees , and confers no rights.Microsoft Student Partner 2010 / 2011
Microsoft Certified Professional
Microsoft Certified Systems Administrator: Security
Microsoft Certified Systems Engineer: Security
Microsoft Certified Technology Specialist: Windows Server 2008 Active
Directory, Configuration
Microsoft Certified Technology Specialist: Windows Server 2008 Network
Infrastructure, Configuration
Microsoft Certified Technology Specialist: Windows Server 2008 Applications
Infrastructure, Configuration
Microsoft
Certified Technology Specialist: Windows 7, Configuring
Microsoft
Certified Technology Specialist: Designing and Providing Volume Licensing Solutions to Large Organizations
Microsoft Certified IT Professional: Enterprise Administrator
Microsoft Certified IT Professional: Server Administrator
Microsoft Certified Trainer-
Marked as answer by
Andy Qi
Monday, October 29, 2012 6:43 AM
-
-
Marked as answer by
Andy Qi
Monday, October 29, 2012 6:43 AM
-
Marked as answer by
Вот как более детально выглядит ошибка при обработке групповой политики. Событие с кодом ID 1054: Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно.
Проверка разрешения имен
dc1 это мой контроллер домена. Как видите у меня локальные DNS имена разрешал, внешний DNS сервер, так как на сервере стоит два сетевых интерфейса и один со внешним ip адресом.
причину мы выяснили, из за чего выскакивает ошибка.
Давайте теперь посмотрим, какой из контроллеров домена является для вашего сервера самым авторитетным, ранее я уже рассказывал как определить какой domain controller вас авторизовал, но нам нужен авторитет в вашем домене и возможность обращение к нему по LDAP. Делается это командой
Я вижу что у меня это dc2, его ip адрес мне и понадобится.
Так же нужно проверить доступность DC по протоколу RPC, с помощью команды
В данном случае проблем я не обнаружил. Пилим дальше.
Так как мы выяснили ip адрес контроллера домена, что нас авторизовывал, его мы и пропишем в качестве DNS сервера на внешнем сетевом интерфейсе. В свойствах ipv4 прописываем его как основной DNS сервер. Напомню, что для разрешения внешних имен у вас должна быть настроена рекурсия на ДНС сервере.
Теперь снова выполним команду nslookup и видим, что теперь внутренние имена разрешаются внутренним DNS сервером.
Выполним теперь обновление групповой политики с помощью данной команды
Видим, что все обновилось корректно и проблема при обработке групповой политики, об этом сообщает событие с кодом ID 1502. Windows не удалось получить имя контроллера домена. Возможная причина: ошибка разрешения имен. Проверьте, что служба DNS настроена и работает правильно в Windows Server 2012 R2 ушла.
Из скрина выше видно что прилетели 24 политики. На этом все. Материал сайта pyatilistnik.org