Назад | Перейти на главную страницу

Как включить согласованную аутентификацию для WinRM

Я отключил согласование аутентификации для службы winrm на моем сервере, выполнив:

winrm put winrm/config/service/Auth @{Negotiate="false"}

И теперь я могу выполнять любые операции с WinRM. Я получаю сообщение об ошибке:

    Message = The WinRM client cannot process the request. The WinRM client trie
d to use Negotiate authentication mechanism, but the destination computer (local
host:47001) returned an 'access denied' error. Change the configuration to allow
 Negotiate authentication mechanism to be used or specify one of the authenticat
ion mechanisms supported by the server. To use Kerberos, specify the local compu
ter name as the remote destination. Also verify that the client computer and the
 destination computer are joined to a domain. To use Basic, specify the local co
mputer name as the remote destination, specify Basic authentication and provide
user name and password. Possible authentication mechanisms reported by server:

Я понимаю ошибку, но проблема в том, что единственный способ, который я нашел в Интернете для включения аутентификации Negotiate, - это выполнить:

winrm put winrm/config/service/Auth @{Negotiate="true"}

Что, конечно, дает ошибку выше. Есть ли другой способ включить аутентификацию Negotiate?

Использовать групповую политику:

Компьютер> Политики> Административные шаблоны> Компоненты Windows> Удаленное управление Windows> Служба WinRM:
Disallow Negotiate Authentication: отключено.

Отредактируйте раздел реестра HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ WSMAN \ Client.

Установите auth_kerberos и auth_negotiate на 1.

Перезапустите службу.

Как предложено в этот ответ, но Сервис, а не Клиент:

  1. Отредактируйте ключ реестра HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service.

  2. Устанавливать auth_kerberos и auth_negotiate к 1.

  3. Перезапустите службу удаленного управления Windows (WS-Management).

На нашей машине server 2012 / exchange 2010 у нас была эта ошибка при попытке использовать программу резервного копирования AVG.

Я обнаружил удаление обоих maxenvelopesize и trusted_hosts под этим ключом сделали трюк

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client]
"maxEnvelopeSize"=dword:000007d0
"trusted_hosts"="*"

Один сервер у меня работал, а другой нет. Не смог найти проблему. Наконец я разобрался.

На отправляющем сервере: установите локальную политику Computer Configuration \ Administrative Templates \ System \ Credentials Delegation \ Allow Delegating Fresh Credentials. Там установите WSMAN * в Добавить серверы в список (также установите флажок Concatenate OS по умолчанию)

На принимающем сервере (создайте файл .reg со следующим :):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client] 
"auth_credssp"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service]
"auth_credssp"=dword:00000001

работает для меня

Обратите внимание, что если компьютер (сервер) является членом домена или сам является контроллером домена (в моем случае Windows Server 2019), групповая политика может применяться из групповой политики домена.
Поэтому я предлагаю (в этих случаях) использовать приведенную ниже команду и проверить значение политики «Запретить согласование аутентификации».

C:\Temp\gpresult /h rep.htm

Его можно применить из «Политики контроллеров домена по умолчанию» !!