Аутентификация Hyper-V-Manager не удается в Windows 11 и Windows Server 2022.

Вопрос или проблема

У меня есть два работающих VM-хоста на основе Hyper-V Server 2019. К этим хостам можно получить доступ, используя Hyper-V-Manager и vmconnect.exe на Windows 10 и Windows Server 2012R2. Однако на более новых версиях Windows (Windows 11 и Windows 2022) ни Hyper-V-Manager, ни vmconnect.exe не могут подключиться. Обе программы показывают одинаковую ошибку:

Операция на компьютере ‘DEP-VMHOST01’ не выполнена: WinRM не может обработать запрос. Произошла следующая ошибка при использовании аутентификации Kerberos: Невозможно найти компьютер DEP-VMHOST01.local. Убедитесь, что компьютер существует в сети и что указанное имя написано правильно.

(Оригинальная ошибка на немецком, это перевод на английский) Оригинальная ошибка на немецком:
Fehler beim Vorgang auf Computer ‘DEP-VMHOST01’: Die Anforderung kann von WinRM nicht verarbeitet werden. Der folgende Fehler ist bei Verwendung der Kerberos-Authentifizierung aufgetreten: Der Domputer ‘DEP-VMHOST.local’ konnte nicht gefunden werden. Stellen Sie sicher, dass der Computer im Netzwerk vorhanden ist und dass der angegebene Namen richtig geschrieben ist.

Соединение тестировалось с использованием Hyper-V-Manager и vmconnect.exe с помощью следующей команды:
vmconnect.exe DEP-VMHOST01 linux01
[linux01 – это работающая виртуальная машина на хосте]

Меня смущает DEP-VMHOST01.local, я ожидал здесь: DEP-VMHOST01.example.com или [email protected] (Имя компьютера с доменом позади)

Используемый домен Windows структурирован следующим образом:
Имя компьютера в ActiveDirectory и на VM-хосте: <Аббревиатура отдела>-<Имя>
DNS-Имя: <Имя>.<Аббревиатура отдела>.example.com
Например, имя компьютера: DEP-VMHOST01, DNS: vmhost.dep.example.com

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

Аутентификация Kerberos и winrm работают (без повторного ввода пароля) и были протестированы с помощью следующих команд:

Enter-PSSession DEP-VMHOST01 -Authentication Kerberos
Открывает удаленную power shell без

winrs -r:DEP-VMHOST01 powershell Get-VM
Перечисляет удаленно работающие виртуальные машины

Доступ к VM-хосту с использованием других инструментов из Microsoft Management Console также возможен (проверено с помощью надстройки Computer Management).

Скопировать рабочий vmconnect.exe на Windows Server 2022 не удается, так как приложение вылетает при запуске (жалуясь на отсутствие файла в журнале событий Windows). Приложение vmconnect из C:\Program Files\Hyper-V\6.3 (или 6.2) на Windows Server 2022 жалуется на то, что оно совместимо только с Hyper-версиями новее Windows Server 2012. Запуск приложений из C:\Program Files\Hyper-V\6.2 на Windows Server 2012 работает.

Кто-нибудь знает, как параметры Kerberos задаются в приложениях управления Hyper-V?

Ответ или решение

Аутентификация через Hyper-V-Manager не выполняется на Windows 11 и Windows Server 2022
При проблемах с аутентификацией Hyper-V Manager на Windows 11 и Windows Server 2022 в среде, где Hyper-V Server 2019 работает корректно с более старыми версиями Windows, такими как Windows 10 и Windows Server 2012R2, ключевую роль играют следующие аспекты: настройки Kerberos, имя компьютера (имя хоста), доменная структура и настройки WinRM (Windows Remote Management).

Теория:
Основная проблема заключается в ошибке аутентификации Kerberos, которая возникает, когда Hyper-V Manager и vmconnect.exe не могут найти хост DEP-VMHOST01 через DNS. В контексте Kerberos аутентификация требует, чтобы имя принципала сервиса (SPN) было точно сопоставлено с именем хоста, используемым в запросе. Если Kerberos не может разрешить имя компьютера корректно, это может привести к сбоям в аутентификации.

Ошибка, которую вы наблюдаете, указывает на проблему в разрешении имени или настройке DNS. Такое поведение характерно для случаев, когда используется растровое доменное имя ".local", но ожидалось доменное имя ".example.com". Еще один аспект, который стоит проверить — это наличие правильных записей DNS и корректно настроенных SPNs в Active Directory.

Пример:
Ваши команды PowerShell и winrs для проверки аутентификации работают, что указывает на то, что базовая способность системы использовать Kerberos функционирует правильно, но проблема может возникать из-за несовпадения в настройках DNS или конфигурации SPN. В частности, название DEP-VMHOST01.local не распознается, в то время как vmhost.dep.example.com является ожидаемой DNS-записью.

Применение:

Проверка конфигурации DNS и сети:
- Убедитесь, что DNS-серверы настроены правильно и все соответствующие записи (A и PTR) присутствуют для DEP-VMHOST01.
- Проверьте возможность разрешения через команду nslookup или ping с обеих сторон (клиента и сервера) для DEP-VMHOST01 и vmhost.dep.example.com.
Проверка SPN в Active Directory:
- Убедитесь, что SPN настроен для всех необходимых служб, включая HOST/DEP-VMHOST01 и HOST/vmhost.dep.example.com.
- Используйте setspn -L DEP-VMHOST01 для проверки списка зарегистрированных SPN данного хоста.
Конфигурация WinRM:
- Проверьте конфигурацию WinRM на хосте с использованием команды winrm get winrm/config и удостоверьтесь, что разрешены необходимые для Kerberos Get действия.
- Убедитесь, что порт 5985 (для HTTP) и 5986 (для HTTPS) открыт для удаленного управления.
Сравните версии и совместимость:
- Изучите версии vmconnect.exe и обратите внимание на совместимость с хостами Hyper-V Server 2019. На машинах с Windows Server 2022 может возникнуть несовместимость с более старыми версиями программного обеспечения.
Рассмотрение исправлений и обновлений:
- Проверьте наличие соответствующих исправлений или обновлений для OS, так как известные ошибки могут быть исправлены в более поздних патчах Windows 11 или Server 2022.
Временные метки и автоматически настроенные параметры:
- Время и дата на всех системах должны быть синхронизированы для корректного функционирования Kerberos. Проверьте настройки времени и конфигурацию сервера времени, используемого в вашей сети.

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