First of all thanks for the detailed explanation and thoughts :) in our situation we want to allow user to login to the control machine with their windows credentials to be able to run ansible playbooks. yet we want the actual work of ansible to be done under a specific user within the active directory. that is the "deployment" user for that environment.
in any case i just did another run with only '@' in the "ansible_ssh_user" variable. works the same. the bottom line is that ansible can be told to use kerberos with the '@' char, yet it assumes that the user supplied is the user holding a kerberos ticket. it does not validate this nor allow to use a different user but the user which has an available ticket. BTW, how do i open a bug ticket? On Thursday, August 20, 2015 at 11:09:40 AM UTC+3, J Hawkesworth wrote: > > It is definitely surprising but not sure if necessarily its a bug in > ansible. > > Bear with me, I'll try and explain why: > > If you regard kerberos tickets (that let you access your windows domain > machines) as being analogous to ssh keys (that let you access your linux > machines) then ansible is at least consistent in that in both cases it is > up to you to acquire the necessary thing (kerberos ticket, ssh key) and is > not something that ansible manages (unless you make your playbooks do so). > > In your case you have (inadvertently) acquired a kerberos ticket by > logging in to your controller. That ticket is potentially a powerful thing > as (unlike an ssh key) it may give you access to any host belonging to that > domain. When ansible attempts to connect it finds you have a ticket for > the domain and so it uses it. > This is pretty much exactly what you would expect if (lets pretend for a > minute) your ansible controller was a windows machine. If you'd logged > into host A as user1@DOMAIN and tried to pick up a file on a share from > host B then windows would be using user1@DOMAIN credentials to see if you > have permission to access the share on host B. > > Thinking about your scenario in the same way you are logging in to your > controller as user1@DOMAIN but then asking ansible to access your windows > domain hosts as user2@DOMAIN. > > I'm not saying what you are doing is wrong but I think Ansible should be > flexible enough to cope with other scenarios as well. > > For instance I value the ability to connect to more than one domain from > my ansible controller, so for me logging in to the controller as a user on > a particular domain isn't a goal. > > I get round the need to acquire kerberos tickets before I start connecting > to anything by using a custom ansible callback plugin (findable on this > list or ansible-devel I think if you are interested). The callback plugin > has its limitations though (main one being not working with the ansible > command, only ansible-playbook), and it would probably be a lot simpler to > wrap up calls to ansible and ansible-playbook in a shell script that calls > kinit before you start. > > So yes it is surprising but when you think about the way the individual > pieces involved work its really just a consequence of putting together > technologies that weren't designed to work together. > > I'm curious to know if you just put > ansible_ssh_user: @DOMAIN > or even > ansible_ssh_user: @ > in your vars whether the behaviour would be any different from what you > are getting now. > > That could actually be quite a nice way of reflecting that it is using > whatever tickets are available, rather than what is specified. > > By all means raise a bug report - I think we should at the minimum > document how it behaves in your scenario. I'm just not sure ansible should > be forced to acquire the kerberos ticket - what do others think? > > Jon > > On Wednesday, August 19, 2015 at 12:46:37 PM UTC+1, Amir Luzon wrote: >> >> yes it does, thank you. >> >> does this not seem like a bug? >> >> On Wednesday, August 19, 2015 at 2:40:53 PM UTC+3, J Hawkesworth wrote: >>> >>> I think this is because when you logged into the machine, as part of the >>> login process a kerberos ticket has been cached for the user you logged in >>> as. >>> >>> When ansible runs, the winrm connection plugin determines that you want >>> to connect via kerberos (there is a bit of guessing going on here, from >>> memory it is assumed you want to connect using kerberos based on having an >>> @ in the ansible_ssh_user and having the python kerberos library loaded. >>> >>> The actual authorisation is then handled by the kerberos library and >>> since you have a kerberos ticket (as a result of logging in), I suspect it >>> is using that. >>> >>> If you can I suggest you install krb5-workstation and then log in as >>> whichever user, then try running klist to see what tickets are cached for >>> your user. >>> >>> if you want to manually create a ticket for the other user, you can do >>> that like this: >>> >>> kinit [email protected] >>> >>> (note domain name must be in upper case). >>> >>> Does that clarify things at all? >>> >>> >>> >>> >>> >>> On Wednesday, August 19, 2015 at 11:38:26 AM UTC+1, Amir Luzon wrote: >>>> >>>> LDAP user is a user in the active directory. >>>> >>>> "and ansible is then attempting to use your kerberos credentials to >>>> talk to your windows machines." - but we configured the "ansible_ssh_user| >>>> to a specific user and it is not using that user but the user logged in to >>>> the control machine...why is that? >>>> >>>> The control machine is: Linux version 2.6.32-504.16.2.el6.x86_64 ( >>>> [email protected]) (gcc version 4.4.7 20120313 (Red Hat >>>> 4.4.7-11) (GCC) ) >>>> >>>> On Wednesday, August 19, 2015 at 12:56:53 PM UTC+3, J Hawkesworth wrote: >>>>> >>>>> Not hit this- I'm not sure what you mean by 'LDAP (windows) users' but >>>>> if you are logging in to your ansible controller using a windows domain >>>>> user, and password then chances are you are using kerberos and ansible is >>>>> then attempting to use your kerberos credentials to talk to your windows >>>>> machines. >>>>> >>>>> You don't mention which OS you are running your ansible controller on >>>>> but if you have krb5-workstation (yum package) or apt-get equivalent >>>>> installed, you can run the command >>>>> >>>>> klist >>>>> >>>>> which will show any kerberos credentials you have. I suspect ansible >>>>> is using these. >>>>> >>>>> If I'm right then I think your options are >>>>> >>>>> a/ use a local user on your windows machines (change >>>>> ansible_ssh_user=some_local_user not a user@domain) >>>>> >>>>> b/ log in to your ansible controller as a domain user with suitable >>>>> privileges for whatever it is you need to do on your windows machines and >>>>> change your >>>>> ansible_ssh_user=domain_user_you_logged_in_to_ansible_as@DOMAIN ) >>>>> >>>>> Hope the above helps >>>>> >>>>> Jon >>>>> >>>>> On Wednesday, August 19, 2015 at 9:19:46 AM UTC+1, Amir Luzon wrote: >>>>>> >>>>>> hi guys, >>>>>> >>>>>> our control machine is configured so that we can login to the machine >>>>>> with our LDAP (windows) users. from there we run ansible playbooks. >>>>>> >>>>>> here are some of the configurations we use: >>>>>> >>>>>> [windows:vars] >>>>>> ansible_ssh_user=[DeployUser]@[OurDomain] >>>>>> ansible_ssh_pass=password >>>>>> ansible_connection=winrm >>>>>> >>>>>> the [DeployUser] is not the same as the LDAP user to login to the >>>>>> ansible control machine. >>>>>> >>>>>> yet when running powershell modules on a windows machine we noticed >>>>>> that Ansible will use the LDAP user used to login to control machine and >>>>>> not the user configured in the hosts file on ansible_ssh_user. >>>>>> >>>>>> from what i understand ansible should use the ansible_ssh_user on >>>>>> windows machine to do whatever but for us it uses the LDAP user??? >>>>>> >>>>>> anyone encounter this issue? please help! >>>>>> >>>>>> >>>>>> thanks in advance >>>>>> >>>>> -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c63905a6-7a3d-497c-b953-6573160a41f1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
