Ошибка разрешения имени целевого компьютера server 2016

Обновлено 30.07.2021

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выполним теперь обновление групповой политики с помощью данной команды

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

Из скрина выше видно что прилетели 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

Добрый день уважаемые читатели и гости блога, сегодня продолжаем изучать доменные технологии, предоставляемые компанией Microsoft и рассмотрим вот такую ошибку ввода компьютера в домен Active Directory «Не удалось изменить DNS-имя основного контроллера домена на «» для этого компьютера. Будет использоваться прежнее имя: contoso.com. Убедитесь, что имя «» является допустимым для текущего домена. Ошибка: При изменении имени узла DNS для объекта невозможно синхронизировать значения имени субъекта службы», ниже рассмотрим всю ситуацию подробно.

Описание проблемы с вводом в домен

По идее присоединение компьютера к Active Directory это простое действие, но как оказалось даже оно может принести сложности. У меня была старая виртуальная машина на Hyper-V, поступила задача ее переустановить для тестовых служб. По идее старая учетная запись этого компьютера лежала в нужно OU и к ней применялись нужные политики доступа, логично, что я воспользовался механизмом переустановки учетной записи, доступный через правый клик по ней. Это является правильной практикой, которую советует сама Microsoft

После выполнения данной процедуры, можно спокойно присоединять, вашу виртуальную машину с тем же именем, и она попадет в базе Active Directory именно в ту OU, где лежала предшественница. Все вроде круто, но в момент ввода в домен, выскочила ошибка:

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

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

Причины ошибки «Не удалось изменить DNS-имя основного контроллера домена»

Рассмотрим причины, по которым ваш компьютер не может пройти аутентификацию на DC и не содержится в его базе.

Чистим старые хвосты в Active Directory

Сразу хочу отметить, что данный способ у меня отработал сразу. Я полностью удалил учетную запись компьютера, с которым были проблемы. После чего снова добавил нужный сервер в домен, и он уже не выдавал ошибку «Не удалось изменить DNS-имя основного контроллера домена на «» для этого компьютера». Учетная запись появилась в привычном контейнере «Computers»

Убедитесь, что включен NetBIOS через TCP/IP

Нажмите WIN+R и введите ncpa.cpl, у вас откроется окно «Панель управленияВсе элементы панели управленияСетевые подключения». Выберите ваш сетевой интерфейс, который смотрит в туже сеть, что и DC его аутентифицирующий. Перейдите в свойства сетевого интерфейса, выберите «Протокол Интернета версии 4 (TCP/IPv4)», далее кнопка «Дополнительно». На вкладке WINS, вам необходимо выбрать пункт «Включить NetBIOS» через TCP/IPv4 и сохранить настройки.

Так же на вкладке DNS, вы можете прописать дополнительные DNS суффиксы (полное имя домена), нажмите ок.

В принципе этого достаточно, чтобы избавится от ошибки «»Не удалось изменить DNS-имя основного контроллера домена на «» для этого компьютера. Будет использоваться прежнее имя: contoso.com. Убедитесь, что имя «» является допустимым для текущего домена. Ошибка: При изменении имени узла DNS для объекта невозможно синхронизировать значения имени субъекта службы»»

Если вам не помогли манипуляции, то ставьте варшарк и смотрите трафик и доступность портов, не блокирует ли у вас то-то.

Источник

помогите подключиться WIN7 к домену. с win7 на server2003

Сеть как настроена? ДНС сервера прописаны в ДХЦП? Главным ДНС сервером укажите КД и все будет норм, для полного функционала лучше поднять функциональный уровень до 2008 R2 после подъема самого КД на W2k8 R2, до кучи гляньте как настроен сам ДНС, какие клиенты имеют право апдейтить записи если стоит параметр SECURE ONLY, forwarders настроены?
IP DC и cmd—> ipconfig /all скрин скинуть можете?
Да и поддержка ОС Вашего КД закончилась еще в ИЮЛЕ месяце сего года.

Безымянный.bmp 422,65К 124 скачиваний srever

Server 2003 Sp2.. windows 7 maximalnaya.. C:WINDOWSsysvolsysvoldz.localpolices scripts

Прикрепленные изображения

DanCooper
Присоединение W7 к домену возможно только на версиях Professional и выше.. вы случаем не Хому пытаетесь в домен впихнуть?

Peace Data
у него Максимальная версия

DanCooper
на Windows 7 нужно указать DNS сервер 192.168.0.101 (это IP адрес вашего Windows 2003 сервера) и потом уже пробовать.

DanCooper
на Windows 7 нужно указать DNS сервер 192.168.0.101 (это IP адрес вашего Windows 2003 сервера) и потом уже пробовать.

DNS сервер ставил и 192.168.0.101 и 127.0.0.1 и 212.112.96.1 не помогло

неверно указан DNS сервер статически или DHCP выдает неправильные DNS настройки

Посмотрел еще раз внимательно конфы, что замечено:
на сервере..
DNS сервер 127.0.0.1
Подразумевается что DNS сервер для AD поднят на Server?
Если так.. то
Workstation DNS сервер 192.168.0.1 кривой. должен быть 192.168.0.101 (Адрес сервера) а не шлюза.
Потому как контроллер домена держит свою базу DNS имен, а шлюз 192.168.0.1 выполняет роль DNS маскарадинга перенаправляя все запросы на DNS провайдера, но никак не на DNS AD

В случае если для AD не поднят DNS на сервере (что есть криво, и кажись невозможно при включении роли AD) но все же. То в IPконфиге сервера, DNS должен быть тогда тоже 192.168.0.1 а не локалхост.

на сервере..
DNS сервер 127.0.0.1
Подразумевается что DNS сервер для AD поднят на Server?

скрин Безымянный.bmp это скрин от 2003 сервера, который является AD. Этот сервер по имени SRDZ01 имеет IP адрес 192.168.0.101 и шлюз 192.168.0.1(скорее всего выход в Интернет) и DNS 127.0.0.1(т.е. указывает на себя, значит должен быть поднят DNS). Т.е. если этот сервер на самом деле является AD для сети, то все компьютеры в сети в качестве Primary DNS сервера должны указывать на 192.168.0.101, чтобы они имели представление об магической AD

на другом скрине приведены сетевые настройки Windows 7. Это компьютер по имени PCDZ03-kana имеет IP адрес 192.168.0.90 и шлюз 192.168.0.1(скорее всего выход в Интернет) и DNS 192.168.0.1(т.е. шлюз является DNS сервером, а шлюз про AD в курсе?). Данный компьютер не в курсе об AD в которую его пихают(автор даже имя не упоминал, но если верить по указанным путям можно сделать вывод что это dz.local, но не факт!).

да и я вообще сомневаюсь в настройках 2003 сервера и AD, так как если он является AD, то в сетевых настройках Primary DNS Suffix, DNS Suffix Search List и т.д. содержали бы упоминания об AD dz.local(или иное имя AD)

в итоге имеем: неправильные/заблуждающийся входные данные, кривые настройки/руки, афтар бесследно исчез, которому я пожелаю удачи в решении проблемы после столько разных рекомендаций

Источник

Устранение ошибок, которые возникают при Windows компьютеров на основе Windows домена

В этой статье описано несколько распространенных сообщений об ошибках, которые могут возникать при подступах к клиентских компьютерах, Windows в домен. В этой статье также содержится предложение по устранению неполадок для этих ошибок.

Применяется к: Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4341920

Где найти файл Netsetup.log

Windows в файле %windir% отламывание Netsetup.log.

Сетевые сообщения об ошибках и разрешениях

Ошибка 1

Попытка разрешить DNS-имя dc в присоединяемом домене не удалась. Убедитесь, что этот клиент настроен для достижения DNS-сервера, который может разрешать имена DNS в целевом домене.

Решение

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

Ошибка 2

Попытка устранить имя DNS контроллера домена в присоединяемом домене не удалась. Убедитесь, что этот клиент настроен для достижения DNS-сервера, который может разрешать имена DNS в целевом домене.

Решение

При введите доменное имя, убедитесь, что вы введите имя DNS, а не имя NetBIOS.

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

Ошибка 3

Была предпринята попытка операции при несущестовом сетевом подключении.

Решение

При введите доменное имя, убедитесь, что вы введите имя DNS, а не имя NetBIOS. Кроме того, перезапустите компьютер, прежде чем пытаться присоединиться к компьютеру в домен.

Ошибка 4

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

Решение

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

При введите доменное имя, убедитесь, что вы введите имя DNS, а не имя NetBIOS.

Ошибка 5

Решение

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

При введите доменное имя, убедитесь, что вы введите имя DNS, а не имя NetBIOS.

Кроме того, можно обновить драйвер сетевого адаптер.

Ошибка 6

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

Решение

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

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

При введите доменное имя, убедитесь, что вы введите имя DNS, а не имя NetBIOS.

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

Ошибка 7

Формат указанного имени сети недействителен.

Решение

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

При введите доменное имя, убедитесь, что вы введите имя DNS, а не имя NetBIOS. Убедитесь, что для сетевого адаптера клиентского компьютера установлены самые последние драйверы. Проверка подключения между подключенным клиентом и целевой dc над требуемой портами и протоколами. Отключите функцию разгрузки труб TCP и разгрузку IP.

Ошибка 8

Служба каталогов исчерпала пул относительных идентификаторов.

Решение

Убедитесь, что контроллер постоянного тока, в котором размещен мастер операций по относительному ID (RID), является сетевым и функциональным. Дополнительные сведения см. в документе Event ID 16650:в сервере Windows идентификатор учетной записи не удалось инициализировать.

Вы можете использовать netdom query fsmo команду, чтобы определить, какая роль dc имеет главную роль RID.

Убедитесь, что Active Directory реплицируется между всеми DCs. Для обнаружения ошибок можно использовать следующую команду:

Ошибка 9

Вызов удаленной процедуры не удался и не выполняется.

Решение

Убедитесь, что для сетевого адаптера клиентского компьютера установлены самые последние драйверы. Проверка подключения между подключенным клиентом и целевой dc над требуемой портами и протоколами. Отключите функцию разгрузки труб TCP и разгрузку IP.

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

Ошибка 10

Изменение имени DNS основного домена этого компьютера на «» не удалось. Имя останется «.». Указанный сервер не может выполнять операцию.

Решение

Сообщения об ошибках проверки подлинности и разрешения

Ошибка 1

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

Решение

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

Чтобы присоединить компьютер к домену, учетной записи пользователя необходимо предоставить разрешение на создание объектов компьютера в Active Directory.

По умолчанию пользователь, не управляющий, может присоединиться к домену Active Directory не более 10 компьютеров.

Ошибка 2

Ошибка logon. Имя целевой учетной записи неверно.

Решение

Убедитесь, что контроллеры домена (DCs) зарегистрированы с помощью правильных IP-адресов на DNS-сервере и правильно ли зарегистрированы их имена главных служб (SPNs) в учетных записях Active Directory.

Ошибка 3

Ошибка logon: пользователю не был предоставлен запрашиваемого типа логотипа на этом компьютере.

Решение

Убедитесь, что у вас есть разрешения на добавление компьютеров в домен. Чтобы присоединиться к компьютеру в домене, учетной записи пользователя необходимо предоставить разрешение на создание объекта компьютера в Active Directory.

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

Ошибка 4

Ошибка logon: неизвестное имя пользователя или плохой пароль.

Решение

Убедитесь, что вы используете правильное имя пользователя и сочетание паролей существующей учетной записи пользователя Active Directory, когда вам будут предложены учетные данные для добавления компьютера в домен.

Ошибка 5

Сопоставление между именами учетных записей и ИД безопасности не было сделано.

Решение

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

Ошибка 6

Недостаточное хранилище доступно для выполнения этой операции.

Решение

Эта ошибка может возникнуть, когда размер маркера Kerberos превышает максимальный размер по умолчанию. В этой ситуации необходимо увеличить размер маркера Kerberos компьютера, который вы пытаетесь присоединиться к домену. Дополнительные сведения см. в следующих статьях Базы знаний:
935744 сообщение об ошибке «Недостаточное хранилище для выполнения этой операции» при использовании контроллера домена для пользования компьютером в домене
327825 проверки подлинности Kerberos, когда пользователь принадлежит к многим группам

Ошибка 7

Учетная запись не разрешена для входа с этой станции.

Решение

Эта проблема связана с несоответствием параметров подписи SMB между клиентского компьютера и dc, который в настоящее время связаться для операции пользования доменом присоединиться. Просмотрите следующую документацию для дальнейшего изучения текущих и рекомендуемых значений в вашей среде:
281648 ошибки: учетная запись не разрешена для входа с этой станции 823659 проблемы с клиентом, службой и программой могут возникнуть при изменении параметров безопасности и назначений прав пользователей

Ошибка 8

Учетная запись, указанная для этой службы, отличается от учетной записи, указанной для других служб, работающих в том же процессе.

Решение

Убедитесь, что в dc, через который вы пытаетесь присоединиться к домену, запущена Windows time.

Источник

Windows 7 или Windows домена Server 2008 R2 отображает ошибку (изменение имени DNS основного домена этого компьютера на «» не удалось. )

В этой статье предоставляется решение ошибки, которая возникает при использовании домена присоединиться к пользовательскому интерфейсу (пользовательскому интерфейсу) для пользования компьютером группы Windows 7 или Windows Server 2008 R2 в домен Active Directory, указав целевое доменное имя DNS.

Применяется к: Windows 7 Пакет обновления 1, Windows Server 2012 R2
Исходный номер КБ: 2018583

Симптомы

Использование пользовательского интерфейса для пользования интерфейсом Windows 7 или Windows Server 2008 R2 в домен Active Directory, указав целевое доменное имя DNS, сбой с ошибкой на экране:

Указанный сервер не может выполнить необходимую операцию.

The NETSETUP. ЖУРНАЛ на присоединяемом компьютере содержит следующий текст:

NetpSetDnsHostNameAndSpn: NetpLdapBind не удалось: 0x3a

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

Расширенные ошибки, которые делают «Изменение имени основной DNS. «. к ошибке, не связанной с этим КБ, относятся:

Причина

Когда компьютер присоединяется к домену, он пытается зарегистрировать основное имя службы, чтобы убедиться, что суффикс DNS разрешен в целевом домене. Домен присоединяется к пользовательскому интерфейсу, запрашивает сведения из базы данных политики местного органа безопасности (LSA) для коротких (NetBIOS) и длинных (DNS) имен целевого домена.

Ошибка, описанная в разделе Симптомы, возникает из-за того, что функция в пользовательском интерфейсе LDAP неправильно выполняет привязку LDAP к контроллеру домена в целевом домене с его коротким именем, которое не выполняется в одном из следующих условий:

Решение

Несмотря на появление ошибки на экране, описанной в разделе Symptoms, операция оккупирования домена завершается, о чем свидетельствует состояние в NETSETUP. LOG.

Успех NetpCompleteOfflineDomainJoin: запрос на перезагрузку :0x0
NetpDoDomainJoin: состояние: 0x0

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

Убедитесь, что NetBIOS через TCP/IP включен.

Проверка подключения к сети с конечным подключением через порт UDP 137 по сетевому пути, соединяющему клиента и помощника DC, обслуживающий операцию подключения.

Если ошибка произошла только в среде IPv6 или требуется исправление для устранения ошибки, откройте инцидент поддержки с службой поддержки и службой поддержки Майкрософт, запросив исправление после RTM для Windows 7/Windows Server 2008 R2.

Добавьте Суффикс DNS домена в свойства TCP/IP.

Источник

Невозможно выбрать роль DNS Server при добавлении контроллера домена в существующий домен Active Directory

В этой статье помогают устранить проблему, из-за которой при продвижении контроллера реплики сервера Windows Server 2008 или Windows Server 2008 R2 отключили или отключили серый цвет в мастере установки Active Directory.

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 2002584

Симптомы

При продвижении контроллера домена реплики Windows Server 2008 или Windows Server 2008 R2 параметр автоматической установки роли DNS Server отключен или отключен в мастере установки Active Directory (DCPROMO).

Текст в дополнительном информационном поле гласит:

DNS нельзя установить на этом контроллере домена, так как в этом домене не установленА DNS.

Снимок экрана этого условия показан ниже:

Файл %windir%debugdcpromoui.log на продвигаемом контроллере домена реплики показывает следующее:

Ввод SLD doesDomainHostDns
dcpromoui A74. A78 046C Dns_DoesDomainHostDns тестирование доменного имени SLD
dcpromoui A74. Запрос A78 046D SOA возвращен 9003, чтобы домен не принимал DNS
dcpromoui A74. A78 046E Dns_DoesDomainHostDns возвращает ложные
dcpromoui A74. A78 046F HRESULT = 0x00000000
dcpromoui A74. A78 0470 Домен не имеет DNS.

Причина

Дефект кода не позволяет включить почтовый ящик DNS Server при продвижении контроллеров реплики домена в существующие домены с однометными именами DNS, например «contoso», а не с полностью квалифицированным DNS-именем типа «» или contoso.com corp.contoso.com «». Это условие существует даже при установке Microsoft DNS на контроллере домена и размещены зоны для целевого домена, интегрированные в Active Directory.

Дополнительные сведения о доменах одной метки можно получить на следующем веб-сайте Майкрософт:

DCPromo проверяет, находится ли зона DNS для целевого леса Active Directory в Active Directory. Если зона DNS для целевого домена не устанавливается на существующий контроллер домена в целевом лесу, DCPROMO не позволяет пользователю устанавливать DNS во время продвижения реплики.

Цель этого поведения состоит в том, чтобы не допустить создания администраторами дублирующих копий зон DNS с различными областями репликации (то есть зон на основе файлов в Microsoft или сторонних DNS-серверах и интегрированных DNS-зонах Active Directory на контроллерах домена на недавно созданном контроллере домена).

Решение

Во-первых, продолжайте продвижение и установите роль DNS Server после ее продвижения.

Во-вторых, конфигурации DNS-клиента и сервера на продвигаемом контроллере домена реплики было достаточно для обнаружения контроллера домена-помощника в целевом домене, но DCPROMO установила, что зона DNS для домена не была интегрирована в Active Directory.

Определите, на каких DNS-серверах будет расположена зона для домена Active Directory и какие области репликации будут использовать эти зоны (Microsoft DNS и сторонние DNS, раздел приложений в лесу, раздел приложений для всей области домена, основной файл и так далее.)

Не позволяйте невозможности автоматической установки роли DNS Server во время DCPROMO блокировать продвижение контроллеров реплики Windows Server 2008 в домене. Диспетчер серверов может использоваться для установки роли Microsoft DNS Server на существующие контроллеры домена, а также компьютеры, функционируют как компьютеры членов или workgroup. Зоны DNS и их записи можно реплицировать или скопировать между DNS-серверами.

К определенным обходным решениям относятся следующие:

Если зоны DNS существуют на DNS-серверах за пределами домена, рассмотрите возможность переноса зон в существующий контроллер домена в домене, в котором размещена роль DNS Server.

Если данные зоны должны быть перемещены, настройте сервер Microsoft DNS для хранения вторичной копии зоны, затем преобразуйте эту зону в основную на основе файлов, а затем перенастройку зоны для интеграции Active Directory по мере необходимости. Этот шаг можно игнорировать, если вы не заинтересованы в сохранении данных зоны DNS.

Настройте новый контроллер домена реплики, продвигаемый, чтобы указать исключительно на DNS-серверы, на которые размещены интегрированные копии зоны Active Directory.

Используйте следующую команду, чтобы заставить Windows 2000, Windows XP, Windows Server 2003, Windows Vista и Windows Server 2008 для динамической регистрации записей host A или AAAA:

Используйте следующую команду для принудительного Windows 2000, Windows Server 2003 и контроллеров домена Windows Server 2008 для динамической регистрации записей SRV

Перезапустите DCPROMO на контроллере домена реплики.

Источник