I've taken to just brute-force running the same playbook over and over again until the issue goes away. I still suspect GPO or replication or time... or something
However - one clue - When the kerberos error happens, I see this generated in the log files: Log Name: System Source: Microsoft-Windows-WinRM Date: 3/1/2020 6:16:34 PM Event ID: 10154 Task Category: None Level: Warning Keywords: Classic User: N/A Computer: hostname.internal.domain Description: The WinRM service failed to create the following SPNs: WSMAN/hostname.internal.domain; WSMAN/hostname. Additional Data The error received was 1355: %%1355. User Action The SPNs can be created by an administrator using setspn.exe utility. On Sunday, March 1, 2020 at 2:58:06 PM UTC-8, Dave York wrote: > > Second Run (from failure) gets further (?!?!) > > [image: ansible-krb3.png] > > > > > On Sunday, March 1, 2020 at 2:57:18 PM UTC-8, Dave York wrote: >> >> First run looks the same: >> >> [image: ansible-krb2.png] >> >> >> >> >> >> >> >> >> On Sunday, March 1, 2020 at 2:38:29 PM UTC-8, Dave York wrote: >>> >>> Thanks again for the help on this. >>> >>> I double verified the machine credential is a domain admin, and verified >>> that time is in-sync between the ansible tower host and the domain. >>> >>> I'll try setting ansible_winrm_transport: kerberos and >>> ansible_winrm_message_encryption: always and see what happens >>> >>> On Sunday, March 1, 2020 at 2:31:12 PM UTC-8, Jordan Borean wrote: >>>> >>>> The fact that you were able to get a Kerberos ticket showed that your >>>> host is set up to get the tickets correctly. Some things you should check >>>> >>>> - The domain account is a local admin, non admins can technically >>>> connect through WinRM but not by default. In any case Ansible is very >>>> limited with what it can do when connecting as a non-admin account so >>>> it's >>>> not something we usually document >>>> - The time is synced between your Ansible controller and the >>>> Windows server >>>> - You aren't using message encryption. This should be done >>>> automatically but some older libraries that Ansible uses may not have >>>> it >>>> available. To check set 'ansible_winrm_message_encryption: always' just >>>> to >>>> double check message encryption is available and works >>>> >>>> >>>> Also you should set `ansible_winrm_transport: kerberos' to stop the >>>> fallback to Basic auth. Unfortunately this is also another backwards >>>> compatibility issue which we can't take away but isn't something that is >>>> really optimal. >>>> >>> -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/542fd015-2e39-44b6-bbd8-d5a93ff4fa2c%40googlegroups.com.
