All works on port 5986, but fails on 5985

180 views
Skip to first unread message

Alexander Fichel

unread,
May 24, 2016, 5:54:27 AM5/24/16
to Ansible Project
What is the point of running the ConfigureRemotingForAnsible.ps1 script if I already have a listener on my windows:

Type            Keys                                Name
----            ----                                ----
Container       {Transport=HTTP, Address=*}         Listener_1084132640

Since script adds a HTTPS listener, I wanted to try and run Ansible playbook using non https port (5985)

I am using ansible 2.0.2.0

This works on port 5986 assuming I run the ConfigureRemotingForAnsible.ps1 script

ansible_user: my_us...@DOMAIN.COM
ansible_port: 5986
ansible_connection: winrm
ansible_winrm_server_cert_validation: ignore

But if I change to:

ansible_user: my_us...@DOMAIN.COM
ansible_port: 5985
ansible_connection: winrm

I get error:

WinRMTransportError: 500 WinRMTransport. Kerberos-based authentication was failed. Code 500
n2-3wbn-udin41.na.msds.rhi.com | FAILED! => {
    "failed": true,
    "msg": "failed to exec cmd PowerShell -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -EncodedCommand U.................................

Does this mean my windows servers are not configured to be authenticated over HTTP?


Trond Hindenes

unread,
May 24, 2016, 6:22:00 AM5/24/16
to Ansible Project
The Default WinRM (5985) listener uses Kerberos both for authentication and encryption (so commands aren't sent in clear-text), it has a hard requirement on encryption (can be turned off, but not recommended). PyWinRM is not (at this time at least) able to do Kerberos-based encryption (as opposed to authentication), which is why we use ssl-based encryption instead (on port 5986).

This lets is do what we need securely, while not tearing holes in Windows' default WinRM security.
Reply all
Reply to author
Forward
0 new messages