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

Зарегистрирован: 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

Ошибка пользовательского интерфейса	Символическая строка ошибки	Ошибка hex #	Десятичной ошибки #
Указанный сервер не может выполнять операцию	ERROR_BAD_NET_RESP	0x3a	58

Случаи, когда ошибка «Изменение имени 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 на контроллере домена реплики.

Источник

Общие

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

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

Windows Server 20162019 Evaluation Edition: сброс триала, обновление до Standart/Datacenter

Версия для оценки Windows Server 2016 Evaluation Edition доступна для скачивания с официального сайта Microsoft. Версия имеет полный функционал и нормально работает в течении триального периода (180 дней).Беда заключается в том, что по истечении триального периода сервер пишет в логи:

Процесс C:Windowssystem32wlmswlms.exe () инициировал действие «Завершить работу» для компьютера от имени пользователя NT AUTHORITYСИСТЕМА по причине: Другое (Запланированное)
Код причины: 0x80000000
Тип выключения: Завершить работу
Комментарий: Истек срок действия лицензии для этой установки Windows. Компьютер завершает работу.

Такая ситуация имеет два варианта решения: Вариант 1 (не правильный) — сбросить триальный период. Вариант 2 (правильный) — обновить до нормальной версии и активировать через KMS-сервер или с помощью MAK/Retail ключа.

Вариант 1. Сброс триала.

Запускаем Powershell и вводим команду:

Дожидаемся сообщения «Command completed successfully» и перезагружаем сервер.

Вариант 2. Upgrade до Standard/Datacenter.

Проверяем что стоит Evaluation Edition.

Должно быть: Current Edition ServerStandardEval.

Смотрим список доступных версий

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

Для версии Standard:

Для версии Datacenter:

Далее можно активировать операционку через KMS-сервер либо MAK/Retail ключом.

Для преобразования Windows Server 2019 EVAL в полноценную версию нужно использовать GVLK (KMS) ключи для Windows Server 2019. В остальном процедура аналогичная.

Конвертировать Windows Server 2019 Evaluation в Windows Server 2019 Standard:

dism /online /set-edition:ServerStandard /productkey: N69G4-B89J2-4G8F4-WWYCC-J464C /accepteula

Конвертировать Windows Server 2019 Evaluation в Windows Server 2019 Datacenter:

dism /online /set-edition:ServerDatacenter /productkey:WMDGN-G9PQG-XVVXX-R3X43-63DFG /accepteula

Причины ошибок HTTP 500

Как мы уже упоминали выше, сообщения о внутренних ошибках сервера не указывают какой-то конкретной проблемы.

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

Более конкретная информация о причине конкретной ошибки HTTP 500 часто предоставляется, когда она возникает на сервере с использованием программного обеспечения Microsoft IIS. Ищите числа после 500, как в HTTP Error 500.19 – Internal Server Error, это означает, что данные конфигурации недействительны.

Список часто встречающихся ошибок и способ их устранения.

1. В удаленном подключении отказано, так как не удалось распознать указанную комбинацию имени пользователя и пароля или выбранный протокол проверки подлинности не разрешен на сервере удаленного доступа. (Неверный логин или пароль).

Возможные причины появления ошибки и способы её устранения:
1) Неправильно введен логин или пароль.
• Проверьте, правильно ли вы написали логин/пароль. Обратите внимание, что все написанные в пароле знаки необходимо вводить. Также соблюдайте верхний и нижний регистр при написании пароля.
• Проверьте, верно ли введен адрес VPN сервера в настройках
Требуется пересоздать vpn-подключение, если перенабор логинапароля не помог.

2) Логин уже авторизован на сервере.
Пробуйте подключиться через 5-10 минут. Если подключиться не получилось, обращайтесь в отдел поддержки пользователей.
! Ни в коем случае, не сообщайте никому свои реквизиты для подключения.

2. Удаленное подключение не установлено, так как не удалось разрешить имя сервера удаленного доступа. (Нет линка).

Возможные причины появления ошибки и способы её устранения:
1) Проверьте, включена ли сетевая карта на Вашем ПК.
Если состояния подключения по локальной сети отключено – включите двойным кликом левой кнопки мыши.

2) Подключение по локальной сети (Еthernet) зачеркнуто красным крестом и снизу подписано «Сетевой кабель не подключен».
Проверьте, подключен ли сетевой кабель к компьютеру, если нет, то его требуется переподключить. Если подключиться не получилось, обращайтесь в отдел поддержки пользователей.

3. Не удалось установить связь по сети между компьютером и VPN-сервером, так как удаленный сервер не отвечает. Возможная причина: одно из сетевых устройств между компьютером и удаленным сервером не настроено для разрешения VPN-подключений. Чтобы определить, какое устройство вызывает эту проблему, обратитесь к администратору или поставщику услуг. (Неверный адрес сервера).

Возможные причины появления ошибки и способы её устранения:
Проверьте настройки VPN.
Запустите значок с рабочего стола «K-Telecom» и в открывшемся окне нажмите правой кнопкой мышки по подключению. Выберете «Просмотр свойств подключения». Перейдите во вкладку «Общие», имя сервера должно быть 172.16.0.1 или L2.

4. Сетевая папка недоступна. За информацией о разрешении проблем в сети обратитесь к справочной системе Windows. (Не получен ip по dhcp).

Возможные причины появления ошибки и способы её устранения:
1) Проверьте, получает ли сетевая карта адрес сети.
Откройте: Панель управления – Сеть и интернет – Центр управления сетями и общим доступом – Изменение параметров адаптера. Нажмите правой кнопкой мыши по значку «Ethernet » и выберете «Состояние». Если ip адрес начинается на 169.254.xxx.xxx, то обращайтесь в отдел поддержки пользователей.

2) Блокирование антивирусной программой.
Убедитесь, что фаервол или антивирус со встроенным фаерволом не блокируют соединение.

5. Удаленное подключение не установлено, так как не удалось разрешить имя сервера удаленного доступа. (Нет связи до DNS серверов, DNS прописан вручную, отсутствует ip адрес по dhcp).

Возможные причины появления ошибки и способы её устранения:
1) Неправильные настройки локальной сети.
Проверьте настройки подключения по локальной сети. Инструкция по настройке локальной сети здесь.

2) Проверьте получает ли сетевая карта адрес сети.
Откройте: Панель управления – Сеть и интернет – Центр управления сетями и общим доступом – Изменение параметров адаптера. Нажмите правой кнопкой мыши по значку «Еthernet) » и выберете «Состояние». Если ip адрес начинается на 169.254.xxx.xxx, то обращайтесь в отдел поддержки пользователей.

3) Блокирование антивирусной программой.
Убедитесь, что фаервол или антивирус со встроенным фаерволом не блокируют соединение.

Настройка сети на Windows Server 2019

На сервере обычно используется статический IP адрес. Но, по умолчанию, после установки системы сетевые интерфейсы пытаются получить IP адреса по dhcp. Сейчас я покажу как установить статический IP адрес на сетевой интерфейс вашего Windows сервера:

В меню “Пуск” переходим в “Параметры“:

В настоящее время программисты из Microsoft пытаются перенести все элементы управления из старой “Панели управления” в новую панель под названием “Параметры Windows“. Дальше в открывшемся окне выбираем “Сеть и Интернет“:

В следующим окне с лева выбираем “Ethernet“, а справа “Настройка параметров адаптера“:

Кликаем правой кнопкой мыши по адаптеру и выбираем пункт меню “Свойства“:

Дальше выделяем компонент “IP версии 4 (TCP/IP)“. Дополнительно, ещё я отключаю “IP версии 6 (TCP/IPv4)“:

В следующем окне переключаемся на “Использовать следующий IP-адрес” и вводим необходимый адрес, не забываем указать маску, шлюз и адрес DNS сервера:

После чего остаётся нажать кнопку “ОК” и закрыть оставшиеся окна.

Настройка сети на Windows Server 2019 является важной операцией. Без настроенной сети вы не сможете ни обновить ни активировать ваш сервер

Зарегистрирован: 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

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

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

Источник