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

knife winrm: Local account auth fails over SSL transport on systems joined to a domain #176

Closed
adamedx opened this issue Feb 8, 2015 · 8 comments

Comments

@adamedx
Copy link

adamedx commented Feb 8, 2015

If a system is joined to a domain, communication over an SSL listener on a remote system fails with a 401 error if credentials local to the remote system (i.e. non-domain credentials) are used, even when those credentials are part of the local administrators group and may be used to successfully communicate over ssl with the winrs tool in Windows or the Enter-PSSession command in PowerShell.

However, if domain credentials are used for that same system, authentication succeeds and the commands are executed.

Here's an example from master with verbose failure logging:
bundle exec knife winrm -f /Users/myuser/downloads/winrmcert.pem -m mysystem.myorg.org -t ssl ipconfig -x 'administrator' -P 'xxxxx' -p 5986

WARNING: No knife configuration file found

WARNING: --winrm-authentication-protocol option is not specified. Switching to Negotiate authentication

DEBUG: Adding mysystem.myorg.com

DEBUG: Trying WinRM communication with negotiate authentication and :ssl transport

DEBUG: WinRM::WinRMWebService options: {:user=>"administrator", :pass=>"xxxxxxx", :basic_auth_only=>false, :disable_sspi=>true, :no_ssl_peer_verification=>false, :ca_trust_path=>"/Users/myuser/downloads/winrmcert.pem"}

DEBUG: Endpoint: https://mysystem.myorg.com:5986/wsman

DEBUG: Transport: ssl

DEBUG: ipconfig

ERROR: Failed to authenticate to ["mysystem.myorg.org"] as administrator

Response: Bad HTTP response returned from server (401).

Hint: Please check winrm configuration 'winrm get winrm/config/service' AllowUnencrypted flag on remote server.

/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/winrm-1.2.0/lib/winrm/http/transport.rb:48:in `send_request': Bad HTTP response returned from server (401). (WinRM::WinRMHTTPTransportError)
@docwhat
Copy link

docwhat commented Feb 9, 2015

I think the user has to be .\Administrator to use the local user when hooked up to a domain... or MachineName\Administrator. Only if you aren't hooked up to a domain, then just Adminstrator works.

@adamedx
Copy link
Author

adamedx commented Feb 9, 2015

Yes, my expectation @docwhat is that the ".\administrator" and "machine\administrator" formats should work, but both seem to fail on release 0.8.2 and on the master branch.

@docwhat
Copy link

docwhat commented Feb 9, 2015

Hmm. Is AllowUnencrypted set to false? Because if you use SSL I think it has to be that way.

@adamedx
Copy link
Author

adamedx commented Feb 10, 2015

Yes, it's set to false. Note that the scenario should work because it works with the winrs tool -- it does not work with knife-windows, and only in the case that the system is domain-joined and the account is local. If you use a domain account, it will work, or you can use a local account, but only if the system is removed from the domain.

@carpnick
Copy link
Contributor

Something related. Been awhile since I tested this, but this also is related to multi-domain single forest support.

I joined a machine to domain foo, and tried to authenticate with bar\username. They are the same forest with domain trust. I noticed in the windows event log though, that winrm was sending across the machine domain instead of my user supplied domain. I haven't gotten back to testing this use case, but figured I would throw in another use case.

@adamedx
Copy link
Author

adamedx commented Aug 8, 2015

I've confirmed this is still an issue with knife-windows 1.0.0.rc.1 and later, even with the latest winrm gem.

@btm
Copy link
Contributor

btm commented Aug 8, 2016

@mwrock I feel like you know why this is...

@mwrock
Copy link
Member

mwrock commented Aug 8, 2016

Yes @btm, I'm pretty certain this has been fixed since we implemented negotiate auth in the winrm gem. Unless the user specified that basic auth should be forced, the SSL transport now defaults to use NTLM authentication which should now function as expected with domain joined nodes.

I'll close this but anyone please reopen if you find this still not working with the latest winrm gem (currently 1.8.1).

@mwrock mwrock closed this as completed Aug 8, 2016
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