"Kerberos-based authentication was failed. Code 401" - but I've already acquired a valid ticket

Archives Ansible Project
, ,
1

Hi,

I’m struggling with 401 authentication error. I’ve got Windows Server 2012 R2 and Ubuntu 14.04 machine (with Ansible v2.0.0.2). I’m trying to authenticate as test user (who belongs to Domain Admins group). This is my inventory_windows.yml file:

[windows]
10.91.96.60 ansible_user=test@MYCLOUD.LOCAL ansible_port=5986 ansible_connection=winrm

And the way I execute Ansible:

ansible windows -i inventory_windows.yml -m win_ping -vvvvvv

Using /etc/ansible/ansible.cfg as config file
Loaded callback minimal of type stdout, v2.0
<10.91.96.60> ESTABLISH WINRM CONNECTION FOR USER: test@MYCLOUD.LOCAL on PORT 5986 TO 10.91.96.60
<10.91.96.60> WINRM CONNECT: transport=kerberos endpoint=https://10.91.96.60:5986/wsman
<10.91.96.60> WINRM CONNECTION ERROR: the username/password specified for this server was incorrect
Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/ansible/plugins/connection/winrm.py”, line 138, in _winrm_connect
protocol.send_message(‘’)
File “/usr/local/lib/python2.7/dist-packages/winrm/protocol.py”, line 193, in send_message
return self.transport.send_message(message)
File “/usr/local/lib/python2.7/dist-packages/winrm/transport.py”, line 301, in send_message
raise WinRMTransportError(‘kerberos’, error_message)
WinRMTransportError: 500 WinRMTransport. Kerberos-based authentication was failed. Code 401

I know that I should acquire a ticket first. Here’s how I do this:

kinit test@MYCLOUD.LOCAL
Password for test@MYCLOUD.LOCAL:

klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: test@MYCLOUD.LOCAL

Valid starting Expires Service principal
03/04/2016 16:29:19 03/05/2016 02:29:19 krbtgt/MYCLOUD.LOCAL@MYCLOUD.LOCAL
renew until 03/05/2016 16:29:20

I thought that if I acquired a ticket, than there should be no authentication errors, but apparently I’m wrong.

Note that I’ve already (as described here: troubleshooting-kerberos-connections):

  1. Synchronized the time between Linux and Windows machine.
  2. Verified that my forward and reverse DNS lookups are working fine. nslookup 10.91.96.60 returns the correct FQDN:
    nslookup 10.91.96.60
    Server: 10.91.97.101
    Address: 10.91.97.101#53

60.96.91.10.in-addr.arpa name = winhost.mycloud.local.

  1. Enabled AllowUnencrypted option on Windows machine and tried with ansible_winrm_scheme=http.

One of the things I’m not sure is this:
“Ensure that the Ansible controller has a properly configured computer account in the domain.”

Could someone explain this? I’ve created ‘azure’ computer account in AD (‘azure’ is the hostname of my Ubuntu machine). Is this enough?

Any help would be much appreciated!

2

I’d recommend using the hostname, rather than the ip address of the windows machine you want to connect to in your inventory. Kerberos/Active Directory seems to be intended to work with host and domain names.

I would also check that ping yourhost and ping yourhost.mycloud.local return the correct ip for the host (this is what I meant by dns working ‘both ways’).

Also I’d suggest trying without setting ansible_winrm_scheme=http - if only because I have it working without this, although I believe it should work either way.

One last thought, have you run the https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1 script on the remote host?

You can check if kerberos support is on if you run

winrm get winrm/config

and look for keberos under Serivce → Auth

Hope this helps,

Jon

3

Thank you very much for your help. I have already done everything you suggested - I tried to use hostnames instead of IPs, checked ‘both way’ DNS configuration, used HTTP instead of HTTPS, verified that Kerberos and HTTP are enabled. The Powershell scripts was executed on the remote host as well. Unfortunately nothing helped. I have provisioned another Active Directory VM and created new domain - this time it worked as expected. It’s just a pity I don’t know what was wrong in my previous configuration. Thank you anyway!