Never had this error before, and also Google could not help me so far.
When I create a new virtualenv and install pip modules, I get the mentioned error when I try to manage Windows hosts with Ansible.
I’m on debian 8.9.
Steps to reproduce:
`
cd ~
virtualenv venv_ansible
. venv_ansible/bin/activate
Are you able to try port 5986 and see if that works. Potentially port 5985 is failing because the encryption process is creating a bad request causing the 400 but it would be good to know if your setup works with HTTPS where WinRM encryption isn’t happening.
Just wondering if this is a transient error? I have occasionally had problems when the windows host is applying windows updates or running ngen to recompile dotnet code following installation of an upgrade to dotnet framework.
On a related note: maybe try just tweaking the existing setup to use ansible_winrm_message_encryption=never on your Windows host(s) in the inventory or via -e to prove if it’s related to the new message encryption support. You’ve clearly been running unencrypted in the past- we’ll leave the discussion of that being a good idea for another thread but disabling message encryption that way should put you back to exactly the way it was working before.
Yes, this means the message encryption done with Kerberos is failing for whatever reason and producing a malformed message. This encryption support was added in pywinrm 0.3.0 and it would be great to find out what may been happening to cause it to fail as it is quite important to use it when running over http.
To help with us replicating the issue are you able to share with us as much information on the hosts as possible like;
The version of Windows you are using
Run ‘krb5-config --version’ on the Ansible controller and let us know the version
What OS the Ansible controller is on
A copy of ‘/etc/krb5.conf’ on the Ansible controller (feel free to blank out the hostname)
The output of ‘klist -v’ when run on the Ansible controller after connecting to the host. This tells us what type of encryption is being uses for the principal
(venv_ansible)[userid@ansiblehost ~/ansible_test]$ ansible -m win_ping -i hosts windows -vvvvvv
ansible 2.4.3.0
config file = None
configured module search path = [u’/home/userid/.ansible/plugins/modules’, u’/usr/share/ansible/plugins/modules’]
ansible python module location = /home/userid/venv_ansible/local/lib/python2.7/site-packages/ansible
executable location = /home/userid/venv_ansible/bin/ansible
python version = 2.7.9 (default, Jun 29 2016, 13:08:31) [GCC 4.9.2]
No config file found; using defaults
setting up inventory plugins
Parsed /home/userid/ansible_test/hosts inventory source with ini plugin
Loading callback plugin minimal of type stdout, v2.0 from /home/userid/venv_ansible/local/lib/python2.7/site-packages/ansible/plugins/callback/minimal.pyc
META: ran handlers
Using module file /home/userid/venv_ansible/local/lib/python2.7/site-packages/ansible/modules/windows/win_ping.ps1
Using module file /home/userid/venv_ansible/local/lib/python2.7/site-packages/ansible/modules/windows/win_ping.ps1
<server2016.domain.local> ESTABLISH WINRM CONNECTION FOR USER: userid@DOMAIN.LOCAL on PORT 5985 TO server2016.domain.local
checking if winrm_host server2016.domain.local is an IPv6 address
<server2012r2.domain.local> ESTABLISH WINRM CONNECTION FOR USER: userid@DOMAIN.LOCAL on PORT 5985 TO server2012r2.domain.local
<server2016.domain.local> WINRM CONNECT: transport=kerberos endpoint=http://server2016.domain.local:5985/wsman
checking if winrm_host server2012r2.domain.local is an IPv6 address
<server2012r2.domain.local> WINRM CONNECT: transport=kerberos endpoint=http://server2012r2.domain.local:5985/wsman
<server2016.domain.local> WINRM CONNECTION ERROR: Bad HTTP response returned from server. Code 400
Traceback (most recent call last):
File “/home/userid/venv_ansible/local/lib/python2.7/site-packages/ansible/plugins/connection/winrm.py”, line 240, in _winrm_connect
self.shell_id = protocol.open_shell(codepage=65001) # UTF-8
File “/home/userid/venv_ansible/local/lib/python2.7/site-packages/winrm/protocol.py”, line 157, in open_shell
res = self.send_message(xmltodict.unparse(req))
File “/home/userid/venv_ansible/local/lib/python2.7/site-packages/winrm/protocol.py”, line 242, in send_message
raise ex
WinRMTransportError: Bad HTTP response returned from server. Code 400
server2016.domain.local | UNREACHABLE! => {
“changed”: false,
“msg”: “kerberos: Bad HTTP response returned from server. Code 400”,
“unreachable”: true
}
<server2012r2.domain.local> WINRM CONNECTION ERROR: Bad HTTP response returned from server. Code 400
Traceback (most recent call last):
File “/home/userid/venv_ansible/local/lib/python2.7/site-packages/ansible/plugins/connection/winrm.py”, line 240, in _winrm_connect
self.shell_id = protocol.open_shell(codepage=65001) # UTF-8
File “/home/userid/venv_ansible/local/lib/python2.7/site-packages/winrm/protocol.py”, line 157, in open_shell
res = self.send_message(xmltodict.unparse(req))
File “/home/userid/venv_ansible/local/lib/python2.7/site-packages/winrm/protocol.py”, line 242, in send_message
raise ex
WinRMTransportError: Bad HTTP response returned from server. Code 400
server2012r2.domain.local | UNREACHABLE! => {
“changed”: false,
“msg”: “kerberos: Bad HTTP response returned from server. Code 400”,
“unreachable”: true
}
Without testing it I believe there may be an issue with the RC4 encryption that is being used. Will have to try it out but that is a pretty old protocol and believed to be broken. While we should still look at fixing it, you should look at adding in one of the AES types on your krb5.conf file http://web.mit.edu/kerberos/krb5-1.12/doc/admin/enctypes.html. I believe you need a dc on Server 2008 or newer.
Yep, the non-default encryption setting is almost certainly the issue. Can you file a bug on https://github.com/02strich/pykerberos? No promises that we’ll get to it, but I have a couple ideas as to what might be causing it. I think the fix could be pretty simple (there’s a code path in there that never got tested because the default AES encryption settings never hit it).
Hi,
I had a similar issue and you guys were spot on.
Removing these lines solved my problem:
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
but disabling message encryption that way should put you back to exactly the way it was working before.