Содержание
- Руководство по устранению неполадок с проверкой подлинности Kerberos
- Контрольный список для устранения неполадок
- Распространенные проблемы и решения
- Проблемы с делегированием Kerberos
- Наиболее распространенные способы устранения неполадок с делегированием Kerberos
- Единый вход не работает и запрашивает проверку подлинности один раз.
- Методы устранения неполадок
- Проблемы с обнаружением контроллера домена проверки подлинности
- Не удается получить доступ к ресурсу, настроенном с помощью интегрированной проверка подлинности Windows с ошибкой 1355
- Основные причины проблемы
- Действия по устранению неполадок
- Сценарий тестирования анализа журналов
- Среда и конфигурация
- Поток проверки подлинности
- Анализ сетевого монитора рабочего процесса
- Проверьте событие безопасности успешного выполнения 4624 в IISServer.contoso.com
- Устранение неполадок с рабочим процессом проверки подлинности
Руководство по устранению неполадок с проверкой подлинности Kerberos
В этом руководстве представлены основные понятия, используемые при устранении неполадок с проверкой подлинности Kerberos.
Контрольный список для устранения неполадок
Ошибка, связанная с Kerberos, является симптомом сбоя другой службы. Протокол Kerberos использует множество служб, которые должны быть доступны и правильно функционировать для проверки подлинности.
Чтобы определить, возникает ли проблема с проверкой подлинности Kerberos, проверьте системный журнал событий на наличие ошибок из любых служб (таких как Kerberos, kdc, LsaSrv или Netlogon) на клиенте, целевом сервере или контроллере домена, которые обеспечивают проверку подлинности. Если такие ошибки существуют, могут возникнуть ошибки, связанные с протоколом Kerberos.
Аудит сбоев в журнале событий безопасности целевого сервера может показать, что протокол Kerberos использовался при сбое входа.
Перед проверкой протокола Kerberos убедитесь, что следующие службы или условия работают правильно:
- Сетевая инфраструктура работает должным образом, и все компьютеры и службы могут взаимодействовать.
- Контроллер домена доступен. Команду (например, nltest /dsgetdc:contoso.com /force /kdc ) можно выполнить nltest /dsgetdc: /force /kdc на клиентском или целевом сервере.
- Система доменных имен (DNS) настроена должным образом и разрешает имена узлов и службы соответствующим образом.
- Часы синхронизируются по всему домену.
- Устанавливаются все критические обновления и обновления для системы безопасности для Windows Server.
- Обновляется все программное обеспечение, в том числе программное обеспечение, не Майкрософт.
- Компьютер перезагружается, если вы используете серверную операционную систему.
- Доступны необходимые службы и сервер. Для правильной работы протокола проверки подлинности Kerberos требуется работающий контроллер домена, инфраструктура DNS и сеть. Убедитесь, что вы можете получить доступ к этим ресурсам, прежде чем приступать к устранению неполадок с протоколом Kerberos.
Если вы изучили все эти условия и по-прежнему возникают проблемы с проверкой подлинности или ошибки Kerberos, необходимо найти решение. Проблемы могут быть вызваны настройкой протокола Kerberos или настройкой других технологий, работающих с протоколом Kerberos.
Распространенные проблемы и решения
Проблемы с делегированием Kerberos
В типичном сценарии олицетворяющая учетная запись будет учетной записью службы, назначенной веб-приложению, или учетной записью компьютера веб-сервера. Олицетворенной учетной записью будет учетная запись пользователя, требующая доступа к ресурсам через веб-приложение.
Существует три типа делегирования с помощью Kerberos:
Полное делегирование (неограниченное делегирование)
Следует максимально избегать полного делегирования. Пользователь (интерфейсный пользователь и внутренний пользователь) может находиться в разных доменах, а также в разных лесах.
Ограниченное делегирование (только Kerberos и переход на протокол)
Пользователь может быть из любого домена или леса, но интерфейсные и серверные службы должны работать в одном домене.
Ограниченное делегирование на основе ресурсов (RBCD)
Пользователь может быть из любого домена, а интерфейсные и серверные ресурсы — из любого домена или леса.
Наиболее распространенные способы устранения неполадок с делегированием Kerberos
- Отсутствует или дублируется имя субъекта-службы
- Сбои разрешения имен или неправильные ответы (неправильные IP-адреса, указанные для сервера)
- Большие билеты Kerberos (MaxTokenSize) и среда настроены неправильно
- Порты блокируются брандмауэрами или маршрутизаторами
- Учетная запись службы не имеет соответствующих привилегий (назначение прав пользователя)
- Интерфейсные или внутренние службы не в одном домене и настройка ограниченного делегирования
Дополнительные сведения см. в разделе:
Единый вход не работает и запрашивает проверку подлинности один раз.
Рассмотрим следующие сценарии.
- Клиентское и серверное приложение, например сервер Майкрософт Edge и IIS. Для сервера IIS настроена проверка подлинности Windows (согласование).
- Клиентское и серверное приложение, например SMB-клиент и сервер SMB. По умолчанию сервер SMB настраивается с помощью интерфейса поставщика поддержки безопасности (SSPI).
Пользователь открывает Майкрософт Edge и просматривает внутренний веб-сайт http://webserver.contoso.com . Веб-сайт настроен с помощью negotiate, и этот веб-сайт запрашивает проверку подлинности. После того как пользователь вручную введет имя пользователя и пароль, он получит проверку подлинности, и веб-сайт работает должным образом.
Этот сценарий является примером клиента и сервера. Метод устранения неполадок одинаков для любого клиента и сервера, настроенного с помощью интегрированной проверка подлинности Windows.
Встроенная проверка подлинности Windows нарушается на уровне пользователя или компьютера.
Методы устранения неполадок
Проверьте конфигурацию клиента на наличие встроенного параметра проверки подлинности, который можно включить на уровне приложения или компьютера. Например, все приложения на основе HTTP будут искать, чтобы сайт был в доверенной зоне при попытке выполнить встроенную проверку подлинности.
Откройте inetcpl.cpl (свойства браузера), которые используются всеми приложениями на основе HTTP для конфигураций Internet Explorer, и проверьте, настроен ли веб-сайт в качестве локальной интрасети.
Приложения также имеют конфигурацию для выполнения интегрированных проверка подлинности Windows.
Майкрософт Edge или Internet Explorer имеет параметр Включить встроенную проверку подлинности Windows.
Проверьте конфигурацию приложения, и клиентский компьютер может получить билет Kerberos для заданного имени субъекта-службы (SPN). В этом примере имя субъекта-службы имеет значение http/webserver.contoso.com .
Сообщение об успешном выполнении, когда вы можете найти имя субъекта-службы:
Сообщение об ошибке, если не удается найти имя субъекта-службы:
Определите и добавьте соответствующие имена субъектов-служб в соответствующие учетные записи пользователя, службы или компьютера.
Если вы определили, что имена субъектов-служб можно получить, можно проверить, зарегистрированы ли они в правильной учетной записи с помощью следующей команды:
Проблемы с обнаружением контроллера домена проверки подлинности
Серверам приложений, настроенным со встроенной проверка подлинности Windows, требуются контроллеры домена (DCs) для проверки подлинности пользователя или компьютера и службы.
Невозможность связаться с контроллером домена во время процесса проверки подлинности приводит к ошибке 1355:
Указанный домен либо не существует, либо не удалось связаться
Не удается получить доступ к ресурсу, настроенном с помощью интегрированной проверка подлинности Windows с ошибкой 1355
Сообщения об ошибках могут отличаться с точки зрения приложения, но смысл ошибки заключается в том, что клиенту или серверу не удается обнаружить контроллер домена.
Ниже приведены примеры таких сообщений об ошибках:
При попытке присоединиться к домену Contoso произошла следующая ошибка:
Указанный домен либо не существует, либо с ним не удалось связаться.
Не удалось найти контроллер домена для contoso.com домена
Не удалось связаться с контроллером домена 1355
Основные причины проблемы
Неправильная настройка DNS на клиенте
Вы можете выполнить ipconfig /all команду и просмотреть список DNS-серверов.
Неправильная настройка DNS на контроллерах домена в доверенном домене или лесе
Сетевые порты заблокированы между клиентом и контроллерами домена
Порты обнаружения контроллера домена: UDP 389 (UDP LDAP) и UDP 53 (DNS)
Действия по устранению неполадок
- Выполните команду , nslookup чтобы определить все ошибки в настройке DNS.
- Откройте необходимые порты между клиентом и контроллером домена. Дополнительные сведения см. в статье Настройка брандмауэра для доменов и доверия Active Directory.
Сценарий тестирования анализа журналов
Среда и конфигурация
Client1.contoso.com (компьютер Windows 11) присоединяется к домену Contoso.com .
Пользователь принадлежит и Contoso.com входит на клиентский компьютер.
Параметры браузера на клиентском компьютере
Все веб-сайты являются частью локальной зоны интрасети.
IISServer.contoso.com (Windows Server 2019) присоединяется к домену Contoso.com .
Конфигурация проверки подлинности
Проверка подлинности Windowsвключена.
Поставщики проверки подлинности: согласование
Включенные поставщики задаются следующим образом:
Поток проверки подлинности
- Пользователь John входит в Client1.contoso.com , открывает браузер Майкрософт Edge и подключается к IISServer.contoso.com .
- Клиентский компьютер выполнит следующие действия (шаг 1 на схеме выше):
- Сопоставитель DNS кэширует IISServer.contoso.com данные, чтобы проверить, кэшируется ли эта информация.
- Сопоставитель DNS проверяет файл HOSTS на наличие любого сопоставления, расположенного IISServer.contoso.com в папке C:WindowsSystem32driversetcHosts.
- Отправьте DNS-запрос на предпочтительный DNS-сервер (настроенный в параметрах IP-конфигурации), который также является контроллером домена в среде.
- Служба DNS, запущенная на контроллере домена, будет искать настроенные зоны, разрешать запись узла A и отвечать IP-адресом IISServer.contoso.com (шаг 2 на схеме выше).
- Клиентский компьютер выполнит трехстороннее подтверждение TCP через TCP-порт 80 к IISServer.contoso.com .
- Клиентский компьютер отправит анонимный HTTP-запрос по адресу IISServer.contoso.com .
- Сервер IIS, прослушивающий порт 80, получит запрос от Client1.contoso.com , изучит конфигурацию проверки подлинности серверов IIS и отправит ответ на запрос HTTP 401 на клиентский компьютер с конфигурацией проверки подлинности Согласование (шаг 3 на схеме выше).
- Процесс Майкрософт Edge, на котором выполняется Client1.contoso.com , будет знать, что сервер IIS настроен с помощью Negotiate, и проверит, является ли веб-сайт частью локальной зоны интрасети. Если веб-сайт находится в зоне локальной интрасети, процесс Майкрософт Edge вызовет LSASS.exe, чтобы получить билет Kerberos с именем HTTPIISServer.contoso.com субъекта-службы (шаг 5 на схеме выше).
- Контроллер домена (служба KDC) получит запрос от Client1.contoso.com , выполнит поиск в своей базе данных имени субъекта-службы HTTPIISServer.contoso.com и найдите IISServer.contoso.com настроенное с помощью этого имени субъекта-службы.
- Контроллер домена ответит ответом TGS с билетом для сервера IIS (шаг 6 на схеме выше).
- Процесс Майкрософт Edge на клиентском компьютере отправит запрос протокола приложений Kerberos (AP) на веб-сервер IIS с билетом Kerberos TGS, выданным контроллером домена.
- Процесс IIS вызовет LSASS.exe на веб-сервере для расшифровки билета и создания маркера с членством в группе SessionID и Users для авторизации.
- Процесс IIS получит дескриптор от LSASS.exe к маркеру, чтобы принять решения об авторизации и позволит пользователю подключиться с ответом AP.
Анализ сетевого монитора рабочего процесса
Для выполнения указанных ниже действий необходимо быть пользователем локальной группы администраторов.
Установите Майкрософт монитор сети на клиентском компьютере ( Client1.contoso.com ).
Выполните следующую команду в окне командной строки с повышенными привилегиями (cmd.exe):
Запустите монитор сети.
Откройте Майкрософт браузере Edge и введите http://iisserver.contoso.com .
Анализ трассировки сети:
DNS-запрос к контроллеру домена для записи узла A: IISServer.contoso.com .
Ответ DNS от службы DNS на контроллере домена.
Процесс Майкрософт Edge при Client1.contoso.com подключении к веб-серверу IISServer.contoso.com IIS (анонимное подключение).
Сервер IIS отвечает с http-ответом 401: Согласование и NTLM (настройка выполняется на сервере IIS).
Запрос Kerberos от Client1.contoso.com отправляется к контроллеру DCA.contoso.com домена с имям субъекта-службы: HTTP/iisserver.contoso.com .
Контроллер DCA.contoso.com домена отвечает запросом Kerberos, который содержит ответ TGS с билетом Kerberos.
Теперь процесс Client1.contoso.com Майкрософт Edge переходит на сервер IIS с запросом AP Kerberos.
Сервер IIS возвращает ответ о том, что проверка подлинности завершена.
Выполните команду , klist tickets чтобы проверить билет Kerberos в выходных данных команды в Client1.contoso.com .
Проверьте событие с идентификатором 4624 на сервере IIS, где отображается Success аудит:
По умолчанию Success аудиты или Failure включены во всех операционных системах сервера Windows. Вы можете проверить, включен ли аудит, с помощью следующей команды.
Если аудит не включен, включите аудит. Просмотрите категорию входа в список ниже. Как вы можете заметить, подкатегория входа включена с Success and Failure помощью .
Если вы не видите вход с Success and Failure помощью , выполните команду , чтобы включить его:
Проверьте событие безопасности успешного выполнения 4624 в IISServer.contoso.com
Просмотрите следующие поля:
- Logon type : 3 (сетевой вход)
- Security ID в New Logon поле: ContosoJohn
- Source Network Address : IP-адрес клиентского компьютера.
- Logon Process и Authentication Package : Kerberos
Устранение неполадок с рабочим процессом проверки подлинности
Используйте один из следующих методов для устранения проблемы.
Проверьте, можно ли разрешить имя веб-сервера IIS ( IISServer.contoso.com ) из Client1.contoso.com .
Проверьте, отвечает ли DNS-сервер на правильный IP-адрес сервера IIS с помощью следующего командлета:
Проверьте, открыты ли сетевые порты между клиентским компьютером и веб-сервером IIS ( IISServer.contoso.com ) с помощью следующего командлета:
Убедитесь, что вы получаете билет Kerberos от контроллера домена.
Откройте обычную командную строку (не командную строку администратора) в контексте пользователя, пытающегося получить доступ к веб-сайту.
Выполните команду klist purge .
klist get http/iisserver.contoso.com Выполните команду следующим образом:
Вы увидите, что вы получите билет Kerberos для имени http/IISServer.contoso.com субъекта-службы в столбце Cached Ticket (2) .
Проверьте, запущена ли веб-служба IIS на сервере IIS, используя учетные данные по умолчанию.
Откройте обычный запрос PowerShell (не администратор PowerShell Prompt) в контексте пользователя, пытающегося получить доступ к веб-сайту.
Просмотрите журнал событий безопасности на сервере IIS:
- Журнал событий успешного выполнения 4624
- Журнал событий ошибок 4625
Процесс изоляции. Вы можете использовать приведенные ниже действия по устранению неполадок, чтобы проверить, могут ли другие службы на сервере IIS обработать проверку подлинности Kerberos.
Сервер IIS должен работать под управлением серверной версии Windows.
На сервере IIS должен быть открыт порт для таких служб, как SMB (порт 445).
Создайте новую общую папку или предоставьте пользователю John разрешения на чтение в одной из папок (например, Software$), к которой уже предоставлен общий доступ на компьютере.
Источник
Table of Contents
- Locate manageability status errors
- Troubleshoot manageability status errors
- Additional resources
This topic is Part II of the Server Manager Troubleshooting Guide.
- Windows Server 2012 — Server Manager Troubleshooting Guide, Part I: Overview
- Windows Server 2012 — Server Manager Troubleshooting Guide, Part
III: Common Events and Errors in Server Manager
In Server Manager in Windows Server® 2012, manageability is defined as the readiness or ability of a remote computer to be managed by using Server Manager. The following factors are measured as part of evaluating the manageability of a remote computer.
- Whether the computer can communicate with Server Manager, and transmit data about the computer’s operational state, and installed roles and features.
- Whether the computer is running the right software, or software is configured in a way that allows Server Manager to query and update the computer.
- Whether the user of Server Manager has adequate user rights to query the computer or make changes to its configuration.
Locate manageability status errors
Manageability status is displayed in the following locations in the Server Manager console.
- On the Server Manager dashboard, the Manageability row in role and server group thumbnails displays alerts (red-highlighted numbers) if there are manageability problems with servers associated with those roles or groups, and a custom filter
created in the Manageability Detail View dialog box is not suppressing those alerts. - The Manageability Detail View dialog box, opened from the
Manageability row in thumbnails on the dashboard, displays the manageability status errors that are the source of alerts. - In the Servers tile on any role or server group home page (including the page for the
All Servers group) the Manageability column displays manageability status.
Troubleshoot manageability status errors
The following table can help you interpret the brief manageability status messages, and resolve problems that are preventing you from managing remote servers by using Server Manager. Many manageability status errors have underlying error messages that are
generated by Windows Remote Management (WinRM); these can be the result of security or authentication problems (such as attempting to manage a remote server in an untrusted domain, for example; or attempting to manage a server by using credentials that are
not recognized as those of an administrator on the remote server), or configuration problems (missing Windows PowerShell, remote management not enabled on the target server, etc.).
Note: In Server Manager practical terms, Negotiate authentication means that Server Manager falls back to NTLM authentication (1) if you attempt to use Server Manager to manage a server that is in an untrusted domain, or
that is in a workgroup, and (2) you provide explicit credentials to manage the target server. If you are using Server Manager to manage servers on which you must authenticate by using
Negotiate authentication, you cannot disable NTLM in your server environment.
In this context, the client is defined as the computer from which you are managing by using Server Manager; this computer can be a server that is running Windows Server 2012, or a computer that is running Windows 8 with
Remote Server Administration Tools installed.
To use the table, match the manageability status for a managed server with an underlying source WinRM or provider message displayed in the
Task Details dialog box, opened from the Notifications area in Server Manager. Find the row in the table where the combination of manageability status message and underlying error message match what is displayed in your Server
Manager console. Read the Possible Causes and Suggested Resolutions column in the matching row to find resolution steps that might help, or causes that are easy to eliminate (such as typographical errors in account credentials).
Manageability Status Message | Issue Category | Underlying Source Message from WinRM or Providers (shown in Task Details pane) |
Possible Causes and Suggested Resolutions | Severity Level |
---|---|---|---|---|
Kerberos security error |
Client-side authentication error: KerbUnknownSecurityError |
Error <computer name> : Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode |
Client and target server are in the same domain; the target server is added to Server Manager, but later, the target server’s domain is changed to a trusted but different domain. Try removing the target server from the Server |
Error |
Kerberos target resolution error |
Client-side authentication error: KerbResolutionError |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error occurred while |
Client is in a domain, and the target server is in a workgroup (using the NetBIOS name of the server): A Kerberos error occurs if explicit credentials are not specified for managing the target server, because the Kerberos ticket |
Error |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error occurred while Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter. |
Client is in Domain1 and the target server is in an untrusted Domain2. A Kerberos error occurs because the Kerberos TGS cannot find the target server. Explicit credentials must be used to manage the target server. Right-click |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error occurred while Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter. |
Client is in a domain and the target server is in the same domain, but the domain name provided for the target server is incorrect or misspelled. |
Error |
||
Kerberos authentication error |
Client-side authentication error: Kerb0x80090311Error |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode |
Client is in a domain, but the domain controller for the client computer is not accessible. Try adding the target server to the client computer’s trusted host list. For information about how to add a managed server to the trusted |
Error |
Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode 0x80090311 occurred |
Client is in a domain, and the target server is in the same domain (using the NetBIOS name or FQDN, and explicit but local-only administrator credentials for the target, or other non-domain credentials): A Kerberos error occurs |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode |
Client is in a domain and the target server is in a workgroup (using the NetBIOS name of the server): User has specified explicit credentials. An error occurs if the user has not added the server to the trusted host list of the |
Error |
||
Client-side authentication error: Kerb0x8009030eError |
Error : Refresh failed with the following error (WSMAN): The metadata failed to be retrieved from the server, due to the following error: WinRM cannot process the request. The following error with errorcode 0x8009030e occurred |
Client is in a domain: Attempting to connect to a remote server by using implicit credentials that are the local administrator’s credentials on the client. Instead, use domain credentials that are recognized by the domain of |
Error |
|
WinRM Default authentication error |
Client-side authentication error: DefaultAuthReqsError |
Error <computer IP address>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. Default authentication |
Client and target server are both in the same domain. The target server was added to Server Manager by using the IP address of the server, such as by using the |
Error |
Client is in a domain and the target server is in a workgroup. The target server was added to Server Manager by using its IP address. An authentication error occurs because if a client is in a domain, and attempting to connect |
Error |
|||
WinRM Negotiate authentication error |
Client-side authentication error: NegoAuthReqsError |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. If the authentication |
Client is in a workgroup, and the target server is in a workgroup (using the NetBIOS name of the server): The network can resolve the name of the server. An authentication error occurs because the target server has not been added |
Error |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. If the authentication |
Client computer is in a workgroup, and the target server is also in a workgroup (using the IP address of the server): An authentication error occurs because the target server has not been added to the trusted host list of the |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. If the authentication |
Client computer is in a workgroup, and the target server is in a domain (using the NetBIOS name of the server): User’s network can resolve the name of the server. An authentication error occurs because the target server has not |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request. If the authentication |
Client is in a workgroup and the target server is in a domain (using the IP address of the server): An authentication error occurs because the target server has not been added to the trusted host list of the client computer to |
Error |
||
Target name resolution error |
Name resolution error |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request because the server name Error <computer name>: Refresh failed with the following error: The RPC server is unavailable. |
Client is in a workgroup, and the target server is in a workgroup (using the NetBIOS name of the server): A name resolution error occurs if the DNS server that is used by the client cannot resolve the target server name. This |
Error |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WinRM client cannot process the request because the server name Error <computer name>: Refresh failed with the following error: The RPC server is unavailable. |
Client is in a workgroup and the target server is in a domain (using the NetBIOS name of the server): A name resolution error occurs if the DNS server that is used by the client cannot resolve the target server name. Add the |
Error |
||
Name resolution error: SpecialCasedError |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: WS-Management could not connect to the specified destination: (<computer |
The target server name includes an unsupported character or string, such as |
Error |
|
Error — Cannot manage the operating system of the target computer |
Non-Windows target computer error |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The client cannot connect to the destination specified in the request. Error <computer name>: Refresh failed with the following error: The RPC server is unavailable. |
The target computer is not running a Windows-based operating system. You cannot use Server Manager to manage this computer. |
Error |
Target computer not accessible |
Network connection-related errors |
Configuration Refresh failed with the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that |
The network connecting the client and server is offline, or there is a problem with the target server’s connection to the network. Try verifying that Windows Firewall exceptions have been enabled on the target server for Windows The |
Error |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter. |
The target computer is offline; either it is turned off, or not responding because of other hardware or software failures. |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify Error <computer name>: Refresh failed with the following error: The RPC server is unavailable. |
Client computer is in a domain and the target server is in a workgroup (using the NetBIOS name of the server): User has specified explicit credentials for the target server, and added the target server to the trusted host list |
Error |
||
Error <computer IP address>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Error <computer IP address>: Refresh failed with the following error: The RPC server is unavailable. |
Client is in a domain, and the target server is in a workgroup (using the IP address of the server): User has specified explicit credentials for the target server, and added the target server to the trusted host list of the client. |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify Error <computer name>: Refresh failed with the following error: The RPC server is unavailable. |
The client is in a workgroup, and the target server is in a workgroup (using the NetBIOS name of the server): The user’s network can resolve the name of the server, and the user has added the target server to the trusted host |
Error |
||
Error <computer IP address>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Error <computer IP address>: Refresh failed with the following error: The RPC server is unavailable. |
The client is in a workgroup, and the target server is in a workgroup (using the IP address of the target server): The user has added the server to the trusted host list of the client. However, a subnet timeout error occurs if |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter. |
WinRM 3.0, WinRM 2.0, and DCOM are unavailable or not enabled on the target. On a server that is running Windows Server 2012, the user might have disabled both WinRM 3.0 or DCOM. On a server that is running an older Windows Server |
Error |
||
The metadata failed to be retrieved from the server, due to the following error: WS-Management cannot process the request. The operation failed because of an HTTP error. The HTTP error (50) is: The request is not supported. |
User is attempting to connect to the target server by using an IPv4 address, but on the client computer, only IPv6, not IPv4, is enabled. Either connect to the target server by using its IPv6 address, or change settings on the |
Error |
||
Online — Verify WinRM 3.0 service is installed, running, and required firewall ports are open |
Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Windows Remote Management (WinRM) cannot complete the operation. Verify that the specified |
WinRM 2.0 and 3.0 are either not available or not enabled, but DCOM is enabled on the target server. Note: This error can occur on a server that is running an older Windows Server operating system (Windows Server 2008 R2 or Windows Server 2008) where the |
Error |
|
Network connection related errors: WinRM 2.0 and DCOM |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WS-Management service cannot process the request. The resource |
WinRM 3.0 is not available or enabled, but WinRM 2.0 and DCOM are both enabled on the target server. This can occur on servers that are running older Windows Server operating systems (Windows Server 2008 R2 or Windows Server |
Error |
|
Network connection related errors: WinRM 2.0 |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: The WS-Management service cannot process the request. The resource Error <computer name>: Refresh failed with the following error: Call was canceled by the message filter. |
WinRM 3.0 and DCOM are either not available or not enabled, but WinRM 2.0 is enabled on the target server. Note: A user might have enabled WinRM 2.0, but not DCOM, on a target server that is running an older Windows Server operating system, and not yet installed the |
Error |
|
Online — Access denied |
Access denied error |
Error <computer IP address>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
Client is in a domain and the target server is in a workgroup (using the IP address of the server): The user has provided explicit credentials and added the server to the trusted host list of the client. However, an “access denied” |
Error |
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
Client is in a workgroup and the target server is in a workgroup (using the NetBIOS name of the server): The user’s network can resolve the name of the server, the user has added the target server to the trusted hosts list on |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
Client is in a workgroup and the target server is in a workgroup (using the IP address of the server): The user has added the server to the trusted hosts list of the client, and removed subnet restrictions on the server. However, |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
Client is in a workgroup and the target server is in a domain (using the NetBIOS name of the server): The user’s network can resolve the name of the server, and the user has added the server to the trusted hosts list of the client. |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
The client is in a workgroup, and the target server is in a domain (using the IP address of the server): The user has added the server to the trusted hosts list on the client. However, an “access denied” error can occur if the |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
The user is attempting to manage the remote server with a credential that has only standard user (not a member of the Administrators group) access rights on the target server, and the user has not enabled standard user remote |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
An incorrect or misspelled user name was provided to log on to the target server. |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
The correct user name for the account used to manage the target server was provided, but the password was incorrect. |
Error |
||
MessageID: 1326. Message: The metadata failed to be retrieved from the server, due to the following error: The user name or password is incorrect. |
The correct user name for the account used to manage the target server was provided, but the password was incorrect. |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
Client is in a domain, and the server is in a workgroup (using the NetBIOS name of the server): The user has specified explicit credentials, added the target server to the trusted hosts list of the client, and removed the subnet |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
Both the client and the target server are in workgroups (using the NetBIOS name of the server): The user’s network can resolve the name of the server, the user has added the server to the trusted hosts list of the client, the |
Error |
||
Error <computer name>: Configuration refresh failed with the following error: The metadata failed to be retrieved from the server, due to the following error: Access is denied. |
Both the client and target server are in workgroups (using the IP address of the server): User has added the server to the trusted host list of the client, and removed the subnet restrictions on the server. The user attempts |
Error |
||
Online – Cannot manage a client-based operating system |
Server Manager WMI providers are not available on the target computer |
Message: The metadata failed to be retrieved from the server, due to the following error: The WS-Management service cannot process the request. The CIM namespace root/microsoft/windows/servermanager is not valid. |
This is typical of Windows 8, on which Server Manager providers are not available and DCOM is not enabled by default. You cannot manage this computer by using Server Manager. |
Error |
Inventory discovery-based errors |
None |
Server Manager inventory collection finds that the target computer is running a Windows client-based operating system. You cannot manage this computer by using Server Manager, so you must contact them. h |
Error |
|
Online — Server Manager WMI providers not loading on the target server |
Server Manager WMI provider cannot load error |
Error <computer name>: Configuration refresh failed with the following error: HRESULT = 0x80041013 |
The Server Manager provider is available, but cannot load. This error can occur when WMI namespace access rights do not grant access to the user, and is most commonly seen when standard users (those who are not members of the |
Error |
Online – Cannot manage operating systems older than Windows Server 2003 |
Inventory discovery-based errors |
None |
Server Manager inventory collection finds that the target computer is running a release of Windows Server that is older than Windows Server 2003. You cannot manage this computer by using Server Manager. |
Error |
Online – Limited data – Windows Server 2003 |
Inventory discovery-based errors |
None |
Server Manager inventory collection finds that the target computer is running Windows Server 2003. |
Informational |
Online – Restart pending |
Inventory discovery-based errors |
None |
Server Manager inventory collection finds that the target server requires a restart. Restart the target server. |
Informational |
Online – Windows PowerShell not installed |
Inventory discovery-based errors |
None |
Server Manager inventory collection finds that Windows PowerShell is not installed on the target server. On a target server that is running Windows Server 2012, run the following cmdlet on the computer that is running Server |
Informational |
Online – Performance counters not started |
Inventory discovery-based errors |
None |
Server Manager inventory collection finds that performance counter data collection is turned off on the target server. |
Informational |
Online — Cannot get event data |
Data retrieval errors |
Any errors from the Server Manager provider that are related to event data retrieval. This error can also occur if specific roles and features have been installed, but not yet configured. The following underlying error messages are examples of known cases where a role, role service, or feature requires post-installation
The following underlying error message can occur for Active Directory Federation Services when the only role services that are installed are web agents. Configuring the installed role services does not resolve the error.
|
Server Manager cannot get event data from the target server. The user might not have access rights to the target server event log, or event log files might not contain valid data. For some roles and features (Hyper-V, Print and Document Services, AD LDS), this error can occur after installation, but before required post-installation configuration has been completed. The error is resolved after post-installation |
Error |
Online — Cannot get service data |
Any errors from the Server Manager provider that are related to service data retrieval |
Server Manager cannot get services data from the target server. The user might not have access rights to service data on the target server, or service data files might not contain valid data. To grant service data access rights |
Error |
|
Online — Cannot get BPA results |
Any errors from the Server Manager provider related to BPA result retrieval (excluding Windows PowerShell not enabled errors which are covered by other manageability status messages) |
Server Manager cannot get Best Practices Analyzer result data from the target server. The user might not have access rights to BPA data on the target server, or BPA result data might not be readable. Standard users cannot get |
Error |
|
Online — Cannot get performance counter data |
Any errors from the Server Manager provider related to performance data retrieval (excluding performance counters off errors, which are covered by other manageability status messages) |
Server Manager cannot get performance counter data from the target server. The user might not have access rights to performance data on the target server, or the data might not be readable. To grant performance data access rights |
Error |
|
Online — Cannot get role and feature data |
Any errors from the Server Manager provider related to role and feature data retrieval |
Server Manager cannot get role and feature inventory data from the target server. The user might not have access rights to role and feature data on the target server, or the data might not be readable. To grant role and feature |
Error |
|
Online — Data retrieval failures occurred |
(If two or more types of data cannot be retrieved)
This error can also occur if specific roles and features have been installed, but not yet configured. The following underlying error messages are examples of known cases where a role, role service, or feature requires post-installation
The following underlying error message can occur for Active Directory Federation Services when the only role services that are installed are web agents. Configuring the installed role services does not resolve the error.
|
Server Manager cannot get a combination of data types: events, BPA results, performance counters, or services. This can be caused by insufficient user access rights, data that is not valid, or WinRM time-outs. To grant event, performance, role and feature inventory, and service data access rights to standard (non-Administrator) users, administrators should run the For some roles and features (Hyper-V™, Print and Document Services, AD LDS), this error can occur after installation, but before required post-installation configuration has been completed. The error is resolved after post-installation |
Error |
|
An unknown error occurred |
Unknown errors |
None |
If the error persists, |
Error |
Additional resources
- Server Manager Troubleshooting Guide, Part I: Overview
- Add Servers to Server Manager
- Managing Downlevel Windows-based Servers from Server Manager in Windows Server 2012
- Enable-ServerManagerStandardUserRemoting
Posted by Mitchell Benjamin 2020-06-25T23:06:30Z
Hello I am experiencing an issue where I receive the attached error when attempting to manage my servers from my hypervisor. I can get this working my promoting the hypervisor to domain controller however I do not want to. How can I authenticate this without promoting to DC? Thank you from Mitchell
2 Replies
-
What happens if you right click and do manage as and set a different user account?
-
lock
This topic has been locked by an administrator and is no longer open for commenting.
To continue this discussion, please ask a new question.
Read these next…
Snap! — No-Password Logins, Solar Powered Water Filter, Glitch in the Matrix?
Spiceworks Originals
Your daily dose of tech news, in brief.
Welcome to the Snap!
Flashback: February 9, 1996: Introduction of the Bandai Pippin (Read more HERE.)
Bonus Flashback: February 9, 1990: Galileo Probe does a Venus Flyby (Read more HERE.)
You nee…
Roku TV being used as Wallboard Issues
Hardware
Helping someone out at their shop. They have 4 large Roku screens and 2 laptops with dual HDMI ports for video. They are viewing static website business dashboards and PowerPoint. At first all 4 screens connected to wireless, worked for a while but with a…
Charging for SSO
Security
We have SSO set up with around 5 or 6 solution providers via our M365. Not one of them charges for this, they just sent us the documentation.I identified another online service in use by one of our departments which would benefit from using SSO for staff …
Spark! Pro series — 9th February 2023
Spiceworks Originals
Today in History: America meets the Beatles on “The Ed Sullivan Show”
At approximately 8:12 p.m. Eastern time, Sunday, February 9, 1964, The Ed Sullivan Show returned from a commercial (for Anacin pain reliever), and there was Ed Sullivan standing …
Green Brand Rep Wrap-Up: January 2023
Spiceworks Originals
Source Opens a new window Opens a new windowHi, y’all — Chad here. A while back, we used to feature the top posts from our brand reps (aka “Green Gals/Guys/et. al.) in a weekly or monthly wrap-up post. I can’t specifically recall which, as that was ap…
Содержание
- Ошибка: сбой проверки подлинности Kerberos
- Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:
- Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам
- Симптомы
- Причина
- Решение
- Вычисление максимального размера маркера
- Известные проблемы, влияющие на MaxTokenSize
- Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене
- Симптомы
- Причина
- Типы шифрования Kerberos
- Проверка подлинности NTLM
- Решение
- Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4
- Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256
- Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4
- Дополнительная информация
- Ошибка проверки подлинности kerberos windows server 2019
- Идентификация и доступ в Active Directory
- Протокол аутентификации kerberos
- Детальная проверка kerberos от начала логирования
- Ошибка проверки подлинности kerberos windows server 2019
- Спрашивающий
- Общие обсуждения
- Все ответы
Ошибка: сбой проверки подлинности Kerberos
В ходе удаленной отладки может возникнуть следующее сообщение об ошибке:
Эта ошибка возникает, когда монитор удаленной отладки Visual Studio выполняется от имени учетной записи локальной системы (LocalSystem) или учетной записи сетевой службы (NetworkService). Работая под одной из этих учетных записей, удаленный отладчик должен установить соединение с аутентификацией на основе Kerberos, чтобы иметь возможность возвращать данные главному компьютеру отладчика Visual Studio.
Проверка подлинности Kerberos невозможна при следующих условиях:
Удаленный компьютер или ведущий компьютер с отладчиком включен в рабочую группу, а не в домен.
Служба Kerberos на контроллере домена была отключена.
Если аутентификация на основе Kerberos недоступна, следует сменить учетную запись, от имени которой выполняется монитор удаленной отладки Visual Studio. Инструкции см. в статье Ошибка: службе удаленного отладчика Visual Studio не удается подключиться к этому компьютеру.
Если оба компьютера входят в один и тот же домен, но это сообщение возникает снова, проверьте, что служба DNS на целевом компьютере правильно определяет имя главного компьютера. Выполните описанные ниже действия.
Для проверки того, что DNS на целевом компьютере правильно распознает имя главного компьютера:
На целевом компьютере войдите в меню Пуск и выберите в меню Стандартные пункт Командная строка.
В окне командной строки введите:
В первой строке ответа ping будет выведено полное имя компьютера и IP-адрес, возвращаемый службой DNS для указанного компьютера.
Источник
Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит к многим группам
Эта статья поможет вам решить проблемы с ошибкой проверки подлинности Kerberos, когда пользователь принадлежит к многим группам.
Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 327825
Симптомы
Дополнительные сведения о контексте ошибки см. в ссылке HTTP 400 Bad Request (Запросзагона слишком долго) ответов на запросы HTTP.
В аналогичных условиях Windows проверки подлинности NTLM работает, как и ожидалось. Проблема проверки подлинности Kerberos может возникнуть только при анализе Windows поведения. Однако в таких сценариях Windows не удастся обновить параметры групповой политики.
Такое поведение происходит в любой из поддерживаемых в настоящее время Windows версиях. Сведения о поддерживаемых версиях Windows см. в Windows.
Причина
Пользователь не может проверить подлинность, так как билет, который создает Kerberos для представления пользователя, недостаточно велик, чтобы содержать все члены группы пользователя.
В рамках службы проверки подлинности ExchangeWindows создает маркер для представления пользователя для целей авторизации. Этот маркер (также называемый контекстом авторизации) включает идентификаторы безопасности (SID) пользователя и siD-коды всех групп, к которой принадлежит пользователь. Он также включает все SID-данные, хранимые в атрибуте учетной sIDHistory записи пользователя. Kerberos хранит этот маркер в структуре данных сертификата атрибута привилегий (PAC) в билете Kerberos Ticket-Getting (TGT). Начиная с Windows Server 2012, Kerberos также сохраняет маркер в структуре данных Active Directory Claims (Dynamic Access Control) в билете Kerberos. Если пользователь является членом большого количества групп, и если существует много утверждений для пользователя или используемого устройства, эти поля могут занимать много пробелов в билете.
Маркер имеет фиксированный максимальный размер MaxTokenSize (). Транспортные протоколы, такие как удаленный вызов процедуры (RPC) и HTTP, зависят от значения при выделении буферов MaxTokenSize для операций проверки подлинности. MaxTokenSize имеет следующее значение по умолчанию в зависимости от версии Windows, которая создает маркер:
Как правило, если пользователь принадлежит к более чем 120 универсальным группам, значение по умолчанию не создает достаточно большого буфера для MaxTokenSize удержания информации. Пользователь не может проверить подлинность и может получить сообщение из памяти. Кроме того, Windows не сможет применить параметры групповой политики для пользователя.
Другие факторы также влияют на максимальное число групп. Например, УАИ для глобальных и локальных доменных групп имеют меньшие требования к пространству. Windows Server 2012 и более поздние версии добавляют сведения о претензиях в билет Kerberos, а также сжимаются SID-данные ресурсов. Обе функции изменяют требования к пространству.
Решение
Чтобы устранить эту проблему, обновим реестр на каждом компьютере, который участвует в процессе проверки подлинности Kerberos, включая клиентские компьютеры. Рекомендуется обновить все системы на Windows, особенно если пользователям необходимо войти в несколько доменов или лесов.
Внесение неправильных изменений в реестр может привести к возникновению серьезных проблем. Перед его изменением необходимо создать реестр длявосстановления в случае возникновения проблем.
На каждом из этих компьютеров установите запись реестра для MaxTokenSize большего значения. Эту запись можно найти в HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaKerberosParameters подкайке. Компьютеры должны перезапустить после внести это изменение.
Дополнительные сведения об определении нового значения см. в разделе Вычисление максимального размера маркера MaxTokenSize в этой статье.
Например, рассмотрим пользователя, используюшего веб-приложение, которое опирается на SQL Server клиента. В рамках процесса проверки подлинности клиент SQL Server передает маркер пользователя в SQL Server базу данных. В этом случае необходимо настроить запись реестра на каждом MaxTokenSize из следующих компьютеров:
В Windows Server 2012 (и более поздних версиях) Windows можно войти в журнал события (Event ID 31), если размер маркера преодолеет определенный порог. Чтобы включить такое поведение, необходимо настроить параметр групповой политики Конфигурация компьютераАдминистративные шаблоныSystemKDCWarning для больших билетов Kerberos.
Вычисление максимального размера маркера
TokenSize = 1200 + 40d + 8s
Для Windows Server 2012 (и более поздних версий) эта формула определяет свои компоненты следующим образом:
Windows Сервер 2008 R2 и более ранние версии используют ту же формулу. Тем не менее, в этих версиях число членов группы домена и локальной группы является частью значения d, а не значения s.
Если у вас есть значение 0x0000FFFF (64K), вы можете быть в состоянии буферить примерно MaxTokenSize 1600 D-класса SID или примерно 8000 S-class SIDs. Однако на значение, которое можно безопасно использовать, влияет ряд других факторов, в том числе MaxTokenSize следующие:
Если вы используете доверенные учетные записи делегирования, каждый SID требует в два раза больше места.
Если у вас несколько трастов, настройте эти траста для фильтрации siD-систем. Эта конфигурация снижает влияние размера билета Kerberos.
Если вы используете Windows Server 2012 или более поздний вариант, на требования к пространству SID также влияют следующие факторы:
В 2019 г. Корпорация Майкрософт отправила обновления в Windows, которые изменили конфигурацию неподготовленного делегирования для Kerberos на отключенную. Дополнительные сведения см. в статью Updates to TGT delegation across incoming trusts in Windows Server.
Так как сжатие SID ресурсов широко используется и неконтентированное делегированное число неограниченно, 48000 или больше должны стать достаточными для MaxTokenSize всех сценариев.
Известные проблемы, влияющие на MaxTokenSize
Для большинства реализаций должно быть достаточно значения в MaxTokenSize 48 000 bytes. Это значение по умолчанию в Windows Server 2012 и более поздних версиях. Однако, если вы решите использовать большее значение, просмотрите известные проблемы в этом разделе.
Ограничение размера в 1010 групповых SID для маркера доступа к LSA
Эта проблема аналогична тому, что пользователь, у которого слишком много членов группы, не может проверить подлинность, но расчеты и условия, которые регулируют проблему, отличаются. Например, пользователь может столкнуться с этой проблемой при использовании проверки подлинности Kerberos или Windows проверки подлинности NTLM. Дополнительные сведения см. в статью Ведение журнала учетной записи пользователя, в которую входит более 1010групп, на компьютере на Windows сервере.
Известная проблема при использовании значений MaxTokenSize более 48 000
Для смягчения вектора атаки на службу internet Information Server (IIS) использует ограниченный размер буфера http-запроса в 64 КБ. Билет Kerberos, который является частью http-запроса, закодирован как Base64 (6 битов, расширенный до 8 битов). Таким образом, билет Kerberos использует 133 процента от первоначального размера. Поэтому, если максимальный размер буфера в IIS составляет 64 КБ, билет Kerberos может использовать 48 000 битов.
Если задать запись реестра значению, которое превышает 48000 bytes, и буферное пространство используется для siDs, может возникнуть ошибка MaxTokenSize IIS. Однако если вы установите запись реестра до 48 000 бит и используете пространство для SID-файлов и утверждений, возникает ошибка MaxTokenSize Kerberos.
Известные проблемы при использовании значений MaxTokenSize больше 65 535
Мы также определили, что протокол IKE IPSEC не позволяет BLOB-адресу безопасности быть больше 66 536 битов, и он также не будет иметь значения, когда задавалось большее MaxTokenSize значение.
Источник
Ошибка «Неподтверченный etype» при доступе к ресурсу в надежном домене
Применяется к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер КБ: 4492348
Симптомы
Компьютер в детском домене леса Службы домена Active Directory (AD DS) не может получить доступ к службе, которая находится в другом домене в одном лесу. При запуске сетевого следа на сообщениях на клиентском компьютере и с клиентского компьютера этот след содержит следующие сообщения Kerberos:
На контроллере домена детского домена viewer событий записи следующую запись события 14:
Причина
Эта проблема возникает при настройке домена ребенка (или только клиента) следующим образом:
Типы шифрования Kerberos
Шифрование RC4 считается менее безопасным, чем более новые типы шифрования, AES128-CTS-HMAC-SHA1-96 и AES256-CTS-HMAC-SHA1-96. Руководства по безопасности, такие как руководство по технической реализации Windows 10 безопасности, предоставляют инструкции по повышению безопасности компьютера, настроив его на использование только шифрования AES128 и/или AES256 (см. типы шифрования Kerberos, чтобы предотвратить использование наборов шифрования DES и RC4).
Такой клиент может продолжать подключаться к службам в собственном домене, которые используют шифрование AES128 или AES256. Однако другие факторы могут помешать клиенту подключиться к аналогичным службам в другом доверяемом домене, даже если эти службы также используют шифрование AES128 или AES256.
На очень высоком уровне контроллер домена (DC) отвечает за управление запросами доступа в собственном домене. В рамках процесса проверки подлинности Kerberos dc проверяет, что клиент и служба могут использовать один и тот же тип шифрования Kerberos. Однако, когда клиент запрашивает доступ к службе в другом доверяемом домене, dc клиента должен «передать» клиенту dc в домен службы. Когда dc создает билет на передачу, вместо сравнения типов шифрования клиента и службы, он сравнивает типы шифрования клиента и доверия.
Проблема возникает из-за конфигурации самого доверия. В Active Directory объект домена имеет связанные доверенные объекты домена (TDOs), которые представляют каждый домен, которому он доверяет. Атрибуты TDO описывают отношения доверия, включая типы шифрования Kerberos, поддерживаемые доверием. Связь по умолчанию между детским доменом и родительским доменом — это двунаружное транзитное доверие, которое поддерживает тип шифрования RC4. Оба родительского и детского домена имеют TDOs, которые описывают эту связь, в том числе тип шифрования.
Проверка подлинности NTLM
После сбоя проверки подлинности Kerberos клиент пытается вернуться к проверке подлинности NTLM. Однако если проверка подлинности NTLM отключена, у клиента нет других альтернатив. Поэтому попытка подключения сбой.
Решение
Чтобы устранить эту проблему, используйте один из следующих методов:
Выбор зависит от ваших потребностей в безопасности и необходимости свести к минимуму нарушения или поддерживать обратную совместимость.
Метод 1. Настройка доверия для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4
Этот метод добавляет новые типы шифрования в конфигурацию доверия и не требует изменений для клиента или службы. В этом методе для настройки доверия используется средство командной ksetup строки.
Чтобы настроить тип доверия шифрования Kerberos, откройте окно командной подсказки на домене DC в доверенного домена и введите следующую команду:
В этой команде представлено полностью квалифицированное доменное имя (FQDN) доверяемого домена.
В примере, в котором находится корневой домен (где находится служба) и это детский домен (где находится клиент), откройте окно командной подсказки на dc и введите следующую contoso.com child.contoso.com contoso.com команду:
После завершения этой команды dc может успешно создать переходный билет, который клиент может использовать для child.contoso.com достижения contoso.com dc.
Так как связь между двумя доменами является двунастройным транзитным доверием, настройте другую сторону доверия, открыв окно Командная подсказка на dc и введите child.contoso.com следующую команду:
Дополнительные сведения о средстве ksetup см. в ksetup.
Метод 2. Настройка клиента для поддержки шифрования RC4 в дополнение к шифрованию AES128 и AES256
Этот метод предполагает изменение конфигурации клиента, а не доверия. Вы можете изменить конфигурацию одного клиента или с помощью групповой политики изменить конфигурацию нескольких клиентов в домене. Однако главный недостаток этого изменения конфигурации заключается в том, что если вы отключили шифрование RC4 для повышения безопасности, откат этого изменения может оказаться невозможен.
Полные инструкции по изменению типов шифрования, которые могут использовать клиенты, см. в Windows Конфигурации для поддерживаемого типа шифрования Kerberos.
Метод 3. Настройка доверия для поддержки шифрования AES128 и AES 256 вместо шифрования RC4
Этот метод напоминает метод 1 в том, что вы настраивает атрибуты доверия.
В случае Windows лесных трастов обе стороны доверия поддерживают AES. Поэтому все запросы на билеты в трастах используют AES. Однако сторонний клиент Kerberos, который проверяет билет на реферал, может уведомить вас о том, что в билете используется тип шифрования, который клиент не поддерживает. Чтобы позволить такому клиенту и далее проверять билет, обнови его в поддержку AES.
При использовании этого метода настройте доверие с помощью оснастки Active Directory Domains and Trusts MMC. Чтобы использовать этот метод, выполните следующие действия:
В доменах Active Directory и Trusts перейдите к надежному объекту домена (в contoso.com примере). Щелкните правой кнопкой мыши объект, выберите свойства и выберите трасты.
В поле Домены, которые доверяют этому домену (входящие трасты), выберите доверчивый домен (в child.domain.com примере).
Выберите свойства, выберите другой домен поддерживает шифрование Kerberos AES, а затем выберите ОК.
Чтобы проверить конфигурацию доверия, выберите Проверка в диалоговом окне доверчивый домен.
В случае доверия в одну сторону доверенный домен перечисляет доверчивый домен как входящий, а доверчивый домен — как исходящую.
Если связь является двустойким доверием, каждый домен перечисляет другой домен как входящий, так и исходящую. В этой конфигурации убедитесь, что проверьте конфигурацию домена в доменах, которые доверяют этому домену (входящие трасты) и доменам, доверенным этим доменом (исходящая трастов). В обоих случаях необходимо выбрать почтовый ящик.
На вкладке Trusts нажмите кнопку ОК.
Перейдите к объекту домена для доверяемой области ( child.contoso.com ).
Дополнительная информация
Дополнительные сведения о TDOs см. в следующих статьях:
Дополнительные сведения о типах шифрования Kerberos см. в следующих статьях:
Источник
Ошибка проверки подлинности kerberos windows server 2019
Добрый день уважаемые читатели, не так давно у меня на работе была задача по настройке групп доступности SQL на Windows кластере, там клиентам сделали красивый веб-инструментарий, все замечательно, теперь клиент ждет следующего развития ситуации, а именно настройка и внедрение механизма Single Sign-On (SSO) или по русски единая точка аутентификация, мы с вами уже с ней знакомились при настройке Vmware vCenter Server. Данный механизм работает на протоколе шифрования kerberos, о котором мы и поговорим. Мы рассмотрим как происходит проверка подлинности kerberos в Active Directory, так как понимание принципов работы, поможет вам в реализации единой точки аутентификации.
Идентификация и доступ в Active Directory
Доменные службы Active Directory (Active Directory Domain Services, AD DS ) обеспечивают идентификацию и доступ (Identity and Access, IDA ) для корпоративных сетей. Давайте посмотрим каким требованиям и критериям должна соответствовать структура IDA:
Протокол аутентификации kerberos
Именно за счет провайдеров Security Support Provider (SSP) сделан механизм аутентификации. Операционная система Windows уже имеет встроенные модули, но никто не мешает программистам, взять и написать свой и подключить его к SSPI
Протокол аутентификации kerberos пришел на смену устаревшему и уже с точки зрения не безопасному, протоколу NTLM, он был основным до Windows 2000. Протокол Kerberos всегда используется в построении механизмов Single Sign-On. В его основе лежит такой принцип, что если двум участникам известен некий ключ и у них есть возможность подтвердить это, то они смогут однозначно идентифицировать друг друга.
Междоменный ключ (inter-realm key). Этот ключ обеспечивает междоменную аутентификацию и используется для обеспечения доверительных отношений в среде Aсtive Directory.
Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей). TGT шифруется при помощи ключа, общего для служб KDC, то есть клиент не может прочитать информацию из своего билета. Этот билет используется клиентом для получения других билетов.
Сам Ticket-Granting Service состоит из двух вещей, первая это копия сессионного ключа и информация о клиенте. Все эти данные зашифрованы ключом, общим между сервисом к которому идет обращение и KDC. Это означает, что пользователь не сможет посмотреть эти данные, а вот служба или сервер к которому идет обращение да.
Еще очень важным моментом, является тот фактор, что служба KDC, должна точно знать к какому именно сервису идет обращение и каким ключом шифрования производить обработку. Для этого есть такой механизм, как Service Principal Names, по сути это уникальный идентификатор службы, который будет прописан в вашей базе Active Directory. Из требований к нему, он должен быть уникален в рамках леса. Каждая служба, которая будет использовать Kerberos, должна иметь зарегистрированный SPN. Без правильно настроенного идентификатора протокол для этой службы или сервера работать не будет.
Сам SPN будет хранится в атрибуте Service-Principal-Name, у той учетной записи к которой он привязан и под которым стартует служба. Таким образом, SPN связывает воедино все части процесса. Клиент знает, к какой службе он хочет получить доступ. И при запросе ключа он строит строку SPN, к примеру, при помощи функции DsMakeSpn. Сервер KDC, получив эти данные, может найти учетную запись, под которой стартует эта служба, и, используя ключ этой учетной записи из Active Directory, создать билет доступа к службе и зашифровать его этим ключом.
Как производится настройка SPN мною уже была описана в одной из статей.
Детальная проверка kerberos от начала логирования
Давайте еще в картинках я расскажу более детально как происходит проверка подлинности kerberos, от момента ввода пароля пользователем. И так:
Источник
Ошибка проверки подлинности kerberos windows server 2019
Этот форум закрыт. Спасибо за участие!
Спрашивающий
Общие обсуждения
Имеется хост-система Windows 10 и установленная на VMware Windows Server 2008 r2 Core. Серверной версии присвоен ip-адрес. С помощью Диспетчера серверов Windows 10 пытаюсь подключиться по ip для удаленного управления, но выдается «Ошибка проверки подлинности Kerberos». Какие действия предпринять?
Все ответы
Сразу оговорюсь, что в делах администрирования я совсем новичок.
Расхождения во времени нет, везде стоит правильное. winrm включен на Windows Server. Какие логи нужно посмотреть? Спасибо.
В RSAT ведь и входит Диспетчер серверов, насколько я понимаю? Проблема была изначально, у меня просто появилась задача подключиться к серверу через этот диспетчер.
Через Управление компьютером > Подключиться к другому компьютеру возникает «Ошибка (5). Отказано в доступе».
Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?
Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?
Эти команды необходимо выполнить на DC а не на рядовом сервере, зайдите на DC локально и выполните и выложите вывод команд
Я не волшебник, я только учусь MCP, MCTS, CCNA. Если Вам помог чей-либо ответ, пожалуйста, не забывайте жать на кнопку «Предложить как ответ» или «Проголосовать за полезное сообщение». Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции работодателя. Вся информация предоставляется как есть без каких-либо гарантий. Блог IT Инженера, Twitter.
Хм, команды dcdiag и repadmin /showrepl не проходят на сервере. Видимо, нужно что-то доустанавливать?
Эти команды необходимо выполнить на DC а не на рядовом сервере, зайдите на DC локально и выполните и выложите вывод команд
У вас dc виртуальный или физический сервер?
Тогда будем пытаться делать вывод из имеющейся информации. Из того, что приведено, подозрительны две вещи:
Они должны быть зарегистрированы на MY-PC
Источник
Receiving an error ‘Hyper-V failed to authenticate using Kerberos authentication’ when taking replication? We can help you fix it.
Hyper-V is a virtualization tool from Microsoft. We can create Virtual Machine on x86-64 systems.
At Bobcares, we often receive requests to fix errors related to Hyper-V as a part of our Server Management Services.
Today, let’s analyze the cause of this error and see how our Support Engineers fix it for our customers.
Explore more about Microsoft Kerberos
The Kerberos protocol defines how clients interact with a network authentication service.
It works on tickets to allow nodes communicate over a non-secure network. Also, it helps to prove their identity to one another securely.
Kerberos is one of the fastest authentication method and the commonly used one.
The Kerberos authentication protocol provides a mechanism for mutual authentication.
Causes for “Hyper-V failed to authenticate using Kerberos authentication”
The error appears when trying to enable Hyper-V replica. The common reason is the Kerberos authentication might not be configured properly.
Another reason is the required attributes not being added. The attributes need to be present in both the source and destination server. To resolve the error our Support Engineers add the required attributes.
The sample error looks like:
How we fix “Hyper-V failed to authenticate using Kerberos authentication”
Recently we had a customer who was facing a problem when enabling replication. Now let’s discuss how our Support Engineers fix the error and help the customer.
Configuring the Hyper-V Server’s Service Principal Name Attributes
We open Active Directory Users and Computers and spot the virtual server host.
Then, right-click on the virtual server host and click on properties. Now, properties windows appear and click on the attribute editor tab.
Now click on the ServicePrincipalName(SPN) attribute and then click on the edit button.
We analyze the entries and we add the required entry. If the entries are present and are incorrect then we correct it accordingly.
We enter each attribute value with its corresponding server’s NetBIOS name as well as its FQDN.
Common missing attributes are:
Microsoft Virtual Console Service/ SOURCESERVER
Microsoft Virtual Console Service/ SOURCESERVER.DOMAIN.LOCAL
Microsoft Virtual System Migration Service/ SOURCESERVER
Microsoft Virtual System Migration Service/ SOURCESERVER.DOMAIN.LOCAL
Hyper-V Replica Service/SOURCESERVER
Hyper-V Replica Service/ SOURCESERVER.DOMAIN.LOCAL
We make sure the entries are present in both the source and destination servers.
After that, We enable the replication.
[Need any further assistance with Hyper-V? – We’ll help you with it]
Conclusion
In short, we’ve discussed the causes of the error ‘Hyper-V failed to authenticate using Kerberos authentication’. Also, we’ve discussed how our Support Engineers resolve the error for enabling replication.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;