"Error: Unencrypted communication not supported" with 0.8.0 and winrm

[rlaveycal]

I've just upgraded from 0.6.0 to 0.8.0 and now I get

ERROR: RuntimeError: Error: Unencrypted communication not supported. Please check winrm configuration winrm/config/service AllowUnencrypted flag.

when trying to bootstrap. The command

knife winrm myserver.me.com dir -m -x user -P pass

gives the same error. Uninstalling 0.8.0 fixes the problem.

The error seems to be coming from the winrm-s gem's sspi.rb class (decrypt_payload).

The 2 machines are Windows 2012 R2 and not on a domain. The client machine has Client/AllowUnencrypted set to true and service/AllowUnencrypted set to false. The target machine has service/AllowUnencrypted set to true.

[adamedx]

@muktaa, can you take a look? Presumably this only happens if we run from Windows.

[adamedx]

@rlaveycal, can you let us know the value of wsman:\localhost\service\auth\negotiate on the remote system? If it's not set to $true, I would expect this error to occur.

[rlaveycal]

winrm get winrm/config/service/auth on the remote system returns

Auth
    Basic = true
    Kerberos = true
    Negotiate = true
    Certificate = false
    CredSSP = false
    CbtHardeningLevel = Relaxed

and winrm get winrm/config/client/auth on the client returns

Auth
    Basic = true
    Digest = true
    Kerberos = true
    Negotiate = true
    Certificate = true
    CredSSP = false

[adamedx]

I also see the failure even when negotiate is set to $true. A workaround is to set $allowunencrypted to $false. The fix should probably be to behave the same as the Windows winrm client in this situation, which is influenced by policy set on the client system.

[carpnick]

It took me adding "AllowUnencrypted = false" to both the client (Windows) and the server side to get this to function.

It was in a weird state that was doing shell_open but then just blocked:

DEBUG: :session => :init
DEBUG: :relay_to_servers => echo . & echo Response received.
DEBUG: :relayed => 10.68.161.108
DEBUG: 10.68.161.108 => :run_command
DEBUG: 10.68.161.108[A92917B5-F5DD-4734-9218-A516DDA75A4E] => :shell_open
..DEBUG: Adding 10.68.161.108

[muktaa]

@carpnick , @adamedx -
The local winrm config does not affect the winrm connection.
AllowUnencrypted=false should be set on the winrm service of the remote machine. On the remote machine, the setting of winrm client's AllowUnencrypted does not affect the connection.

In brief, the following should be set on the remote machine:
winrm set winrm/config/service @{AllowUnencrypted="false"}

@carpnick - Please check and let me know if it works otherwise for you.

[carpnick]

@muktaa
Must have gotten stuck changing too many variables at once. When connecting to the system from a windows box with the client config of the following the winrm connection still works:
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = true
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = true
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts = *

[rlaveycal]

Yep, I can confirm that setting the remote machine's service/allowunencrypted to false works.

[gryte]

I just ran into this scenario in the new Windows curriculum[1] at learn.getchef.com when attempting to bootstrap the cloudshare Windows node from my personal Windows workstation. Ensuring that the cloudshare Windows node was set to false resolved the issue for me as well.

[1]https://learn.getchef.com/windows/bootstrap-your-node/

[adamedx]

@muktaa, it seems like people are still getting confused by this. I think we can do something clever here and rely on the name format.

[muktaa]

Working on getting a fix for this issue.

On Mon, Oct 13, 2014 at 9:01 AM, Adam Edwards notifications@github.com
wrote:

@muktaa https://github.com/muktaa, it seems like people are still
getting confused by this. I think we can do something clever here and rely
on the name format.

—
Reply to this email directly or view it on GitHub
#108 (comment)
.

[adamedx]

Thank you Mukta.

[btm]

A lot of our documentation says you must/may set AllowUnencrypted to True on winrm/config/service on the server.

https://docs.getchef.com/plugin_knife_windows.html
https://github.com/opscode/knife-windows/blob/master/README.md#nodes

My 2008R2 Server:

PS C:\Users\Administrator> winrm get winrm/config/service
Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 1500
    EnumerationTimeoutms = 240000
    MaxConnections = 300
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = true
    Auth
        Basic = true
        Kerberos = true
        Negotiate = true
        Certificate = false
        CredSSP = false
        CbtHardeningLevel = Relaxed
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = false
    EnableCompatibilityHttpsListener = false
    CertificateThumbprint
    AllowRemoteAccess = true

My Windows 8.1 Client:

PS C:\> knife winrm name:vm_server_2008R2 'dir' -x Administrator -P 'my_password' -a ipaddress
ERROR: RuntimeError: Error: Unencrypted communication not supported. Please check winrm configuration winrm/config/service AllowUnencrypted flag.

Setting winrm set winrm/config/service @{AllowUnencrypted="false"} on the server makes it work again under knife-windows 0.8.0. This works with knife-windows 0.6.0, so I'd consider it a bug.

[btm]

It looks like we currently, and in #109, are only using negotiate when we see a domain in the username, but winrm defaults to using negotiate when not in a domain and defaults to using kerberos when in a domain. It seems like we're making a confusing set of choices in here and #109. we should

1. Add at least a debug message whenever we make a choice, e.g. Chef::Log.debug("Switching from plaintext to negotiate authentication because we're on Windows")
2. allow the user to override our choice of using negotiate instead of basic auth when they're on windows.
3. We are conflating SSL with authentication and should separate them. Perhaps a new authentication flag, transport could be plaintext or ssl. if we see ssl, we should change the port to 5986 unless they've passed a port.

http://msdn.microsoft.com/en-us/library/aa384295(v=vs.85).aspx

Kerberos is the default method of authentication when the client is in a domain and the remote destination string is not one of the following: localhost, 127.0.0.1, or [::1].
Negotiate is the default method when the client is not in a domain.
Negotiate is the default method when the client is in domain, but the remote destination string is one of the following: localhost, 127.0.0.1, or [::1].