Winrm не удается выполнить операцию windows admin center

Столкнулся с нетривиальным поведением всех служб удалённого управления внутри домена. Однажды без видимых причин Windows Admic Center потерял доступ ко всем удалённым машинам в домене и начал сыпать ошибкой:

Сбой подключения к удаленному серверу name.domainname. Сообщение об ошибке: WinRM не удается выполнить операцию Убедитесь, что имя компьютера указано правильно, компьютер доступен по сети, а в брандмауэре задано исключение для службы WinRM, которое разрешает доступ к этому компьютеру. По умолчанию исключение брандмауэра для WinRM для общедоступных профилей ограничивает доступ к удаленным компьютерам в той же локальной подсети. Подробности см. в разделе справки «about_Remote_Troubleshooting».

При этом, при попытке пробросить удалённый Powershell в некоторые машины проброс проходит, в иные сыпет ошибками, типа:

Enter-PSSession : Сбой подключения к удаленному серверу name.domainname. Сообщение об ошибке: Access is
denied. Подробности см. в разделе справки "about_Remote_Troubleshooting".
строка:1 знак:1
+ Enter-PSSession name.domainname
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (name.domainname:String) [Enter-PSSession], PSRemotingTr
   ansportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

Доходит до абсурда: есть два полностью идентичных по железу сервера, введённых в эксплуатацию одновременно, имеют на борту одну и ту же редакцию Windows Server Core установленную с одного и того же источника, воткнуты в соседние порты свитча, один доступен, второй нет.

Для того, чтобы избежать неверной настройки на хостах, в систему была закинута групповая политика, созданная по подобию этой: https://support.auvik.com/hc/en-us/articles/204424… с парой нюансов (не слушается ipv6, отложенный запуск службы WinRM вместо сиюминутного).

Правила были раскатаны по gpupate /force. Проверка winrm listener отдаёт вполне живые параметры:

winrm e winrm/config/listener
Listener [Source="GPO"]
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, %все другие локальные айпишники%

Можно было бы грешить на файрволлы, но я пробовал открывать всё, безуспешно:

Get-NetFirewallRule -DisplayName "Windows Remote Management*"


Name                          : WINRM-HTTP-In-TCP
DisplayName                   : Windows Remote Management (HTTP-In)
Description                   : Inbound rule for Windows Remote Management via WS-Management. [TCP 5985]
DisplayGroup                  : Windows Remote Management
Group                         : @FirewallAPI.dll,-30267
Enabled                       : True
Profile                       : Domain, Private
Platform                      : {}
Direction                     : Inbound
Action                        : Allow
EdgeTraversalPolicy           : Block
LooseSourceMapping            : False
LocalOnlyMapping              : False
Owner                         :
PrimaryStatus                 : OK
Status                        : The rule was parsed successfully from the store. (65536)
EnforcementStatus             : NotApplicable
PolicyStoreSource             : PersistentStore
PolicyStoreSourceType         : Local
RemoteDynamicKeywordAddresses : {}

Name                          : WINRM-HTTP-Compat-In-TCP
DisplayName                   : Windows Remote Management - Compatibility Mode (HTTP-In)
Description                   : Compatibility mode inbound rule for Windows Remote Management via WS-Management. [TCP 80]
DisplayGroup                  : Windows Remote Management (Compatibility)
Group                         : @FirewallAPI.dll,-30252
Enabled                       : False
Profile                       : Any
Platform                      : {}
Direction                     : Inbound
Action                        : Allow
EdgeTraversalPolicy           : Block
LooseSourceMapping            : False
LocalOnlyMapping              : False
Owner                         :
PrimaryStatus                 : OK
Status                        : The rule was parsed successfully from the store. (65536)
EnforcementStatus             : NotApplicable
PolicyStoreSource             : PersistentStore
PolicyStoreSourceType         : Local
RemoteDynamicKeywordAddresses : {}

Name                          : WINRM-HTTP-In-TCP-PUBLIC
DisplayName                   : Windows Remote Management (HTTP-In)
Description                   : Inbound rule for Windows Remote Management via WS-Management. [TCP 5985]
DisplayGroup                  : Windows Remote Management
Group                         : @FirewallAPI.dll,-30267
Enabled                       : True
Profile                       : Public
Platform                      : {}
Direction                     : Inbound
Action                        : Allow
EdgeTraversalPolicy           : Block
LooseSourceMapping            : False
LocalOnlyMapping              : False
Owner                         :
PrimaryStatus                 : OK
Status                        : The rule was parsed successfully from the store. (65536)
EnforcementStatus             : NotApplicable
PolicyStoreSource             : PersistentStore
PolicyStoreSourceType         : Local
RemoteDynamicKeywordAddresses : {}

Интернет пестрит идеями сделать winrm quickconnect на удалённых машинах, что не играет никакой роли, так как применена групповая политика, или обязательно либо разрешать прослушку ipv6 адресов, либо полностью их отключать на удалённой сетевой карте (пробовал оба варианта, безуспешно).

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

Единственным рабочим костылём оказывается установка Google Chrome на Windows Server Core и управление сервером из локального браузера, но это просто дичь, которую не хочется делать локальным стандартом.

ЧЯДНТ? Я уже извелся весь.

При настройке WinRM на серверах в домене Active Directory столкнулся со странной проблемой. После того как служба WinRM была настроена и включена на сервере, к ней разрешено удалённое подключение через Windows PowerShell Remoting, при попытке удаленного подключения к данному серверу с помощью команды
Enter-PSSession msk-dp01
в консоли PowerShell появляется следующая ошибка WinRM:

Картинка с сайта: winitpro.ru

В английской версии Windows ошибка выглядит так:

Картинка с сайта: winitpro.ru

При этом на сервере порты WinRm (5985/HTTP, 5986/HTTPS) отвечают и принимают соединения. Проверить доступность TCP портов WinRM можно с помощью утилиты PortQryV2 или командлета PowerShell Test-NetConnection:

TNC msk-dp01 –port 5985

Картинка с сайта: winitpro.ru

Как оказалось, проблема оказалась связана с большим размером токена Kerberos у пользователя, за счет того, что пользователь состоит в слишком большом количестве доменных групп. Ошибка возникает при превышении размера токена 16 Кб (см статью MaxTokenSize — размер токена Kerberos). В нашей ситуации происходит все тоже самое, сервер WinRm сбрасывает запрос от клиента, т.к. размер заголовка пакета аутентификации превышает 16 Кб. В статье по ссылке мы упоминали, что по-умолчанию в IIS используется размер HTTP заголовка не более 16 Кб, и в случае проблем с HTTP аутентификацией из за большого токена пользователя, его нужно увеличить до 64 Кб

Чтобы исправить проблему, нужно уменьшить размер токена (уменьшить количество групп безопасности, в которых состоит пользователь), а если это невозможно, тогда в редакторе реестра на сервере нужно изменить значение следующих DWORD параметров реестра в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters

• MaxFieldLength увеличить до 0000ffff (65535)
• MaxRequestBytes увеличить до 0000ffff (65535)

Картинка с сайта: winitpro.ru

Осталось перезагрузить сервер и проверить подключение WinRm через Enter-PSSession с клиента.