Comment activer l'authentification de négociation pour winrm

J'ai désactivé l'authentification de négociation pour le service winrm sur mon serveur en exécutant:

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

Et maintenant, je peux effectuer n'importe quelle opération avec winrm. Je reçois l'erreur:

    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:

Je comprends l'erreur, mais le problème est que le seul moyen que je trouve sur le Web pour activer l'authentification de négociation est d'exécuter:

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

Ce qui bien sûr donne l'erreur ci-dessus. Existe-t-il un autre moyen d'activer l'authentification de négociation?

Utiliser la stratégie de groupe:

Ordinateur> Stratégies> Modèles d'administration> Composants Windows> Gestion à distance Windows> Service WinRM:
interdire l'authentification de négociation: désactivé.

Modifiez la clé de registre HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ WSMAN \ Client.

Définissez auth_kerberos et auth_negotiate sur 1.

Redémarrez le service.

Comme suggéré dans cette réponse , mais le service, pas le client:

1. Modifiez la clé de registre HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service.

2. Réglez auth_kerberoset auth_negotiatesur 1 .

3. Redémarrez le service Windows Remote Management (WS-Management).

Sur notre serveur 2012 / Exchange 2010, nous avons rencontré cette erreur lors de la tentative d'utilisation du logiciel de sauvegarde AVG.

J'ai trouvé que retirer les deux maxenvelopesizeet trusted_hostssous cette clé a fait l'affaire

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

J'avais un serveur qui fonctionnait, mais pas un autre. Je n'ai pas pu trouver le problème. Enfin, je l'ai compris.

Sur le serveur d'envoi: définissez la stratégie locale Configuration ordinateur \ Modèles d'administration \ Système \ Délégation d'informations d'identification \ Autoriser la délégation de nouvelles informations d'identification. Là, définissez WSMAN * dans Ajouter des serveurs à la liste (cochez également la case Concaténer les paramètres par défaut du système d'exploitation)

Sur le serveur de réception (créez un fichier .reg avec les éléments suivants :):

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

travaille pour moi

Veuillez noter que si l'ordinateur (serveur) est membre d'un domaine ou lui-même est un contrôleur de domaine (dans mon cas, Windows Server 2019), la stratégie de groupe peut être appliquée à partir de la stratégie de groupe du domaine.
Je suggère donc (dans ces cas) d'utiliser la commande ci-dessous et de vérifier la valeur gagnante de la stratégie "Interdire la négociation d'authentification".

C:\Temp\gpresult /h rep.htm

Il peut être appliqué à partir de la "Politique des contrôleurs de domaine par défaut" !!