Knife-windows bootstrap failing with WinRMAuthorizationError using ssl and domain authentication

Chef Infra (archive)
1

I know there are a number of previous posts with issues similar to this but haven't been able to find an identical one with a solution that works for me.
I'm trying to run a 'knife bootstrap windows winrm' command from a windows workstation using ssl and domain authentication to bootstrap a windows node and am getting this error:

ERROR: Failed to authenticate to myhost as mydomain\myusername Response: WinRM::WinRMAuthorizationError Hint: Make sure to profix domain usernames with the correct domain name. Hint: Local user names should be prefixed with computer name or IP address.

Here's the bootstrap command I'm trying:

knife bootstrap windows winrm --winrm-transport ssl *myhost* --winrm-user 'mydomain\myusername' --winrm-password 'mypassword' --winrm-ssl-verify-mode verify_none

The remote machine is configured with a https winrm listener created using the command:
new-item -address * -force -path wsman:\localhost\listener -port 5986 -hostname myhost -transport https -certificatethumbprint mythumbprint

The certificate thumbprint comes from a self-signed certificate created using the knife windows cert generate command.

Basic authentication is disabled from a GPO:

I have also tried using the -f pemfile option for the bootstrap command using the .pem file for the same certificate, but without success.

I have been referencing this extremely helpful resource from Matt Wrock.
I tried using the New-SelfSignedCertificateEx tool suggested there to create a certificate with the IsCA flag set to $true (with the intention of using that cert for the https listener) but the tool doesn't create a certificate for me...

A bootstrap without ssl (using sspinegotiate and the winrm-s patch) does work, but I want to use ssl.

Workstation:
Windows 7 (Powershell 4)
winrm (1.3.4)
winrm-s (0.3.1)
knife-windows (1.1.1)

Target Node:
Windows 2008 R2 Ent

(Note the workstation is in a different domain to the node)

Would appreciate any guidance anyone has.
Thanks in advance,
Martin

2

Hey Martin,

Couple of things to try -

Have you restarted the WinRM service after creating the new listener?
Is the firewall open for port 5896?
Are you able to create a PowerShell remoting session over SSL to the node from the workstation?

I’ve also experienced winrm being left in an odd state after GPO controls were put in place, but nothing I could ever consistently reproduce.

Steve

3

The fact that you are getting a WinRM::WinRMAuthorizationError means you are getting a 401 from the winrm endpoint so that likely eliminates any problems with SSL/certificate setup. You are successfully getting through to the winrm service and just failing to authenticate.

Your command looks correct and if you are able to authenticate using SSPI then the credentials must be correct as well.

For the sake of sanity and because I don’t personally use domains much these days, I created a dummy controller and joined another machine to that domain. Then ran:

knife winrm -m 192.168.137.98 ipconfig --winrm-transport ssl --winrm-user 'kitchen\vagrant' --winrm-password 'vagrant' --winrm-ssl-verify-mode verify_none

This worked. The only key diffrence I can think of is that my workstation is windows 10. You might also see if you can create a normal remote powershell session with the same user making sure to specify -UseSSL.

4

Thanks for the suggestions guys… still no luck unfortunately.

I hadn’t restarted the WinRM service, but doing so hasn’t helped. The firewall is open.

Running this command to open a remote PowerShell session does work:

$session = New-PSSession -ComputerName hostname -Port 5986 -Credential 'domain\username' -UseSSL

5

And just to confirm, that yes it is a 401 status code that is being caught resulting in the WinRM::WinRMAuthorizationError error.

Tried passing the credentials in the format of username@domain also (as well as domain/username) but to no avail.

6

This issue was resolved by upgrading the WinRm gem to 1.7.0 which includes this fix for nodes where CbtHardeningLevel is set to Strict (in my case via a GPO as can be seen in the winrm output in my initial post).
Thanks Matt for resolving!