We have a current setup that works using Ansible v2.0.0 in which we specify ansible_ssh_user in inventory exactly as follows.
ansible_ssh_user: user@realm
When running playbooks we use kinit to get a kerberos ticket using real credentials (myrealname@myrealdomain.com) and everything works.
That is ansible uses the kerberos ticket for myrealname@myrealdomain.com and we can successfully connect to Windows servers.
However, behavior in Ansible 2.1 and 2.2 is different. When using the newer versions, Ansible tries to connect with the fake user@realm username, ignoring our kerberos ticket and hence failing to connect.
changing ansible_ssh_user to ansible_user makes no difference
What does work is setting ansible_user to myrealname@myrealdomain.com in the inventory. However, this is problematic as we have several users and don’t want to have to constantly change our inventory depending on which user is actually running playbooks.
Am I missing something or did something change in regards to behavior? Is there some way to get the old behavior?
Pre-2.1, Ansible only supported the “default” Kerberos principal, so folks needing more than one Kerberos principal at a time (eg, multiple principals in parallel or the ability to switch principals mid-run) were hosed. With 2.1 and later (and some associated fixes to pykerberos and requests_kerberos), we actually use ansible_user (when specified) to look up the right user. If it’s not specified, we revert to the default principal behavior that 2.0 and previous used.
Why are you specifying a nonsensical value for ansible_user instead of just leaving it blank?
If you need to set it back to null at the host level for some reason, you can do that in YAML (eg host_vars) with the ~ character as the value, or by using !!null. I don’t believe those work in .ini inventory, though. I’d strongly suggest you just not set it to a garbage value, though.
Thank you. The reason we used a bogus user@realm value in our inventory was because it “worked” and allowed us to run playbooks as the authenticated user rather than relying on a set value in inventory or requiring operators to enter it at the command line. Leaving it blank in our 2.0 install caused the following error:
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: TypeError: argument of type ‘NoneType’ is not iterable
We did find that specifying the transport as kerberos and leaving the ansible_user variable undefined provides the same functionality in the newer builds. Although we will need to change our inventory, this will only be problematic until we get everyone updated to 2.2.
The behavior you describe for newer builds makes sense.