Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Many rspec tests fail on Windows 2008 R2 with 401 #29

Closed
timops opened this issue Jul 25, 2012 · 26 comments
Closed

Many rspec tests fail on Windows 2008 R2 with 401 #29

timops opened this issue Jul 25, 2012 · 26 comments

Comments

@timops
Copy link

timops commented Jul 25, 2012

Example output from one:

  1. Test remote WQL features via WinRM should run a CMD command string
    Failure/Error: output = @winrm.run_cmd('ipconfig /all')
    WinRM::WinRMHTTPTransportError:
    Bad HTTP response returned from server (401).

    /Users/timgreen/Desktop/WinRM/lib/winrm/http/transport.rb:48:in `send_request'

    /Users/timgreen/Desktop/WinRM/lib/winrm/winrm_service.rb:368:in`send_message'

    /Users/timgreen/Desktop/WinRM/lib/winrm/winrm_service.rb:113:in `open_shell'

    /Users/timgreen/Desktop/WinRM/lib/winrm/winrm_service.rb:239:in`run_cmd'

    ./spec/cmd_spec.rb:11:in `block (2 levels) in <top (required)>'

@pmorton
Copy link
Contributor

pmorton commented Jul 25, 2012

401 is unauthorized which usually indicates bad credentials. To get
the test suite working, create a config.yml and rerun tests. Example
is checked in

https://github.com/zenchild/WinRM/blob/master/test/config-example.yml

Does that solve your problem?

P

On Jul 25, 2012, at 11:50 AM, timops
[email protected]
wrote:

Example output from one:

  1. Test remote WQL features via WinRM should run a CMD command string
    Failure/Error: output = @winrm.run_cmd('ipconfig /all')
    WinRM::WinRMHTTPTransportError:
    Bad HTTP response returned from server (401).

    /Users/timgreen/Desktop/WinRM/lib/winrm/http/transport.rb:48:in `send_request'

    /Users/timgreen/Desktop/WinRM/lib/winrm/winrm_service.rb:368:in`send_message'

    /Users/timgreen/Desktop/WinRM/lib/winrm/winrm_service.rb:113:in `open_shell'

    /Users/timgreen/Desktop/WinRM/lib/winrm/winrm_service.rb:239:in`run_cmd'

    ./spec/cmd_spec.rb:11:in `block (2 levels) in <top (required)>'


Reply to this email directly or view it on GitHub:
https://github.com/zenchild/WinRM/issues/29

@timops
Copy link
Author

timops commented Jul 25, 2012

Paul,

I was able to configure the config.yml without any issues. Username and password is not an issue, as it has been tested with 'winrm'

The issue was brought to my attention from here:

http://tickets.opscode.com/browse/KNIFE_WINDOWS-25

I wouldn't be surprised if this is only an issue for Windows 2008 R2. Have you successfully tested on this platform?

@pmorton
Copy link
Contributor

pmorton commented Jul 25, 2012

Tim - the reports prior to your (on the ops code bug) seemed to
implicate domain authentication. In your example can you confirm that
you are trying to authenticate a local account on that server?

On Jul 25, 2012, at 12:27 PM, timops
[email protected]
wrote:

Paul,

I was able to configure the config.yml without any issues. Username and password is not an issue, as it has been tested with 'winrm'

The issue was brought to my attention from here:

http://tickets.opscode.com/browse/KNIFE_WINDOWS-25

I wouldn't be surprised if this is only an issue for Windows 2008 R2. Have you successfully tested on this platform?


Reply to this email directly or view it on GitHub:
https://github.com/zenchild/WinRM/issues/29#issuecomment-7259274

@timops
Copy link
Author

timops commented Jul 25, 2012

Paul,

I have only tried local myself, but I suspect the same thing will happen if I promote this to a Domain Controller and test again with an AD account. I'm basing this assumption on the other user's issue from the Opscode ticket. I'm happy to do a dcpromo right now on my server and re-test the same set of commands if you'd like. I did notice that Microsoft deprecated some endpoints when they released 2008R2, although I'm not sure if this is the issue.

@pmorton
Copy link
Contributor

pmorton commented Jul 25, 2012

Tim - I am not able to repro this issue. I have a vagrant VM with Windows 2008 R2. My config.yml is as follows:

auth_type: plaintext
endpoint: "http://localhost:5985/wsman"
options:
  user: vagrant
  pass: vagrant

What is the output of your winrm config?

Here is mine:

C:\Users\vagrant>winrm get winrm/config/service
Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 15
    EnumerationTimeoutms = 60000
    MaxConnections = 25
    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

Is there any way that you can share an instance with me that I can use to Repro?

Paul

@timops
Copy link
Author

timops commented Jul 25, 2012

Paul,

I just changed my settings to mirror what you have above, still isn't working for me. I'm working in a public cloud environment so I can provide you with a login. Maybe you could give me an email address I can send these to?

@timops
Copy link
Author

timops commented Jul 25, 2012

Paul,

It looks like changing the winrm/service setting to match yours did in fact work. The problem inputs (for me) were:

Basic = false
AllowUnencrypted = false

Thanks so much for your help! BTW, didn't realize you were on the Chef mailing lists already, otherwise I would have gave you the appropriate shout-out. Sorry about that =)

@peterloron
Copy link

Hello. I'm running into this exact issue. Even with setting WinRM to allow unencrypted and basic auth, I still get a 401. Are there some sort of logs or wireshark caps I can send to help investigate this? Thanks.

@pmorton
Copy link
Contributor

pmorton commented Aug 17, 2012

Can you post the output of the following command from the client that you
are connecting to?

winrm get winrm/config

On Aug 16, 2012, at 11:41 AM, Peter Loron [email protected] wrote:

Hello. I'm running into this exact issue. Even with setting WinRM to allow
unencrypted and basic auth, I still get a 401. Are there some sort of logs
or wireshark caps I can send to help investigate this? Thanks.


Reply to this email directly or view it on
GitHubhttps://github.com/zenchild/WinRM/issues/29#issuecomment-7794781.

@peterloron
Copy link

Output below. I have also posted info on my situation to a ticket for knife-windows, which relies on this gem:

http://tickets.opscode.com/browse/KNIFE_WINDOWS-25

In short...I can use the native winrs command (authenticating with a domain account) and it works. Trying the same thing using the winrm gem (or knife) yields a 401 error.

I'm happy to work with the dev(s) to investigate the issue. I can run custom builds, debug, etc. Thanks.

Config
MaxEnvelopeSizekb = 150
MaxTimeoutms = 60000
MaxBatchItems = 32000
MaxProviderRequests = 4294967295
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = false
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts
Service
RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
MaxConcurrentOperations = 4294967295
MaxConcurrentOperationsPerUser = 15
EnumerationTimeoutms = 60000
MaxConnections = 25
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
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 180000
MaxConcurrentUsers = 5
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 15
MaxMemoryPerShellMB = 150
MaxShellsPerUser = 5

@pmorton
Copy link
Contributor

pmorton commented Aug 17, 2012

The issue is that either you need to setup you client to allow unencrypted
traffic. The knife plugin uses the http port by default.

P

On Aug 17, 2012, at 9:40 AM, Peter Loron [email protected] wrote:

Output below. I have also posted info on my situation to a ticket for
knife-windows, which relies on this gem:

http://tickets.opscode.com/browse/KNIFE_WINDOWS-25

In short...I can use the native winrs command (authenticating with a domain
account) and it works. Trying the same thing using the winrm gem (or knife)
yields a 401 error.

I'm happy to work with the dev(s) to investigate the issue. I can run
custom builds, debug, etc. Thanks.

Config
MaxEnvelopeSizekb = 150
MaxTimeoutms = 60000
MaxBatchItems = 32000
MaxProviderRequests = 4294967295
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = false
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts
Service
RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
MaxConcurrentOperations = 4294967295
MaxConcurrentOperationsPerUser = 15
EnumerationTimeoutms = 60000
MaxConnections = 25
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
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 180000
MaxConcurrentUsers = 5
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 15
MaxMemoryPerShellMB = 150
MaxShellsPerUser = 5


Reply to this email directly or view it on
GitHubhttps://github.com/zenchild/WinRM/issues/29#issuecomment-7828092.

@peterloron
Copy link

Changed the setting. No difference in results. Note that is is not something that will work for us in prod...traffic needs to be encrypted.

@pmorton
Copy link
Contributor

pmorton commented Aug 17, 2012

The GEM support WinRM over SSL. At the moment, I am not sure that the folks over at opscode are supporting the https endpoint. Are you using a local account or a windows domain account? What is the format of your username?

@peterloron
Copy link

It is a domain account. Both the client and server are in the domain. I've tried:

username
Domain\username
Domain\username

On Aug 17, 2012, at 11:26, Paul Morton [email protected] wrote:

The GEM support WinRM over SSL. At the moment, I am not sure that the folks over at opscode are supporting the https endpoint. Are you using a local account or a windows domain account? What is the format of your username?


Reply to this email directly or view it on GitHub.

@pmorton
Copy link
Contributor

pmorton commented Aug 17, 2012

Can you send me a copy of the knife output and a packet capture of the
event (Wireshark)?

[email protected]

Paul

On Fri, Aug 17, 2012 at 12:18 PM, Peter Loron [email protected]:

It is a domain account. Both the client and server are in the domain. I've
tried:

username
Domain\username
Domain\username

On Aug 17, 2012, at 11:26, Paul Morton [email protected] wrote:

The GEM support WinRM over SSL. At the moment, I am not sure that the
folks over at opscode are supporting the https endpoint. Are you using a
local account or a windows domain account? What is the format of your
username?


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com/zenchild/WinRM/issues/29#issuecomment-7832353.

@pmorton
Copy link
Contributor

pmorton commented Aug 23, 2012

@peterloron I have not forgotten about this, I have been wildly busy and will give it a gander shortly.

@pmorton
Copy link
Contributor

pmorton commented Aug 23, 2012

Peter - In looking at the packet capture it seems to have selected basic authentication. Basic authentication does not support domain authentication, and hence authorization will fail.

Authorization: Basic ZG9jdXNpZ25ocVxccGV0ZXIubG9yb246QWdvODpjdXJzdA==

What is the knife command-line that you are using? Feel free to omit your username and password.

@peterloron
Copy link

knife winrm 'valid.machine.name' 'ipconfig' -VV -m -x _*_* -P "*****"

I have tried using quotes around the user name as well as using a single or double backslash between the domain and username. I have tried setting both ends to allow and disallow Basic auth. No difference. Always a 401.

@plentz
Copy link

plentz commented Nov 16, 2012

I was getting the same error and this is what I did to make it work

winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}

Another thing that may help: I wasn't able to connect as Administrator. I needed to create a new user(in my case I created 'remoteadmin' with admin privileges)

@peterloron
Copy link

Unfortunately, I need to run with domain authentication and encryption so turning them off is not a solution for me.

-Pete

On Nov 16, 2012, at 8:23 AM, Diego Plentz [email protected] wrote:

I was getting the same error and this is what I did to make it work

winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}

Reply to this email directly or view it on GitHub.

@plentz
Copy link

plentz commented Nov 16, 2012

@peterloron you tried to create an user other then Administrator?

@pmorton
Copy link
Contributor

pmorton commented Mar 22, 2013

Here is the good news... I have tracked down the bug that requires BASIC auth everywhere. I will have a new version soon with support for NTLM which will address most of these setup issues.

@plentz
Copy link

plentz commented Mar 22, 2013

@pmorton awesome!

@peterloron
Copy link

Fantastic!

On Mar 22, 2013, at 3:36 PM, Paul Morton [email protected] wrote:

Here is the good news... I have tracked down the bug that requires BASIC auth everywhere. I will have a new version soon with support for NTLM which will address most of these setup issues.


Reply to this email directly or view it on GitHub.

@pmorton
Copy link
Contributor

pmorton commented Mar 22, 2013

I am going to close this and leave open the Milestone item #37

@pmorton pmorton closed this as completed Mar 22, 2013
@bendizen
Copy link

If running from powershell these have to be single quoted:

winrm set winrm/config/client/auth '@{Basic="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'

Otherwise you'll get: Error: Invalid use of command line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants