Winrm не удается обработать запрос при проверке подлинности kerberos возникла следующая ошибка

I have two forests with a transitive on-way trust between them: PROD -> TEST (test trusts PROD). I had previously had kerberos authentication working with winrm from PROD to machines in TEST. I have verified the trust is healthy, I also verified users
in TEST can use WINRM with kerberos just fine. Users from PROD cannot connect via kerberos to machines in TEST with winrm.

I have verified the service has registered the appropriate SPNs. I ran dcdiag against all my PROD and TEST domain controllers and didn’t find anything that would prevent kerberos from happening. I even tried disabling the firewall entirely on my TEST dcs
but that didn’t gain me anything.

I’ve enabled kerberos logging but only see the expected errors such as it couldn’t find a PROD SPN for the machine, which it shouldn’t from what I understand, it should go to the TEST domain and find the SPN from there.

I’m really out of next steps before I call PSS and hope someone here has run into this and could provide me some next steps.

PowerShell Error:

Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found.  
 Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
 After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
 Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (:) [], PSRemotingTransportException
    + FullyQualifiedErrorId : PSSessionStateBroken

winrs Error:

Winrs error:
WinRM cannot process the request. The following error occured while using Kerberos authentication: The network path was not found.  
 Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the two domains.
 After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
 Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config.

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

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

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

TNC msk-dp01 –port 5985

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

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

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

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

PS C:Windowssystem32> Enter-PSSession -ComputerName serv1

Enter-PSSession : Сбой подключения к удаленному серверу serv1. Сообщение об ошибке: Клиенту WinRM не удается обработать запрос. Если применяемая схема проверки подлинности отличается от Kerberos или компьютер клиента не входит в домен, необходимо использовать транспорт HTTPS или добавить компьютер назначения к значениям параметра конфигурации TrustedHosts. Чтобы настроить TrustedHosts, используйте winrm.cmd. Обратите внимание, что в списке TrustedHosts могут находиться компьютеры, не прошедшие проверку подлинности. Чтобы получить дополнительные сведения об этом, выполните следующую команду: winrm help config. Подробности см. в разделе справки «about_Remote_Troubleshooting».

строка:1 знак:1

+ Enter-PSSession -ComputerName serv1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (serv1:String) [Enter-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : CreateRemoteRunspaceFailed