I'm experiencing a similar conundrum. Unfortunately kdestroy -A and kinit with my deploy user's password still does not resolve the issue. Looks like I have to stick with the local credential authentication approach until I can pass different domain creds other than my own.
On Thursday, August 20, 2015 at 6:17:32 AM UTC-5, J Hawkesworth wrote: > > Ok so in your case running kinit deployment@YOURDOMAIN beforehand would be > a work around. > > Just curious if you put > > ansible_ssh_user: @SOMEOTHERDOMAIN > > (where SOMEOTHERDOMAIN is not the domain you logged in as, does it still > behave in the same way. > > Also, I think others might be interested in setting things up like you, > where your ansible controller is effectively partcipating in the domain. If > you have any instructions on how to set that up for your platform please > can you share (I'm trying to add more detail around windows set up at the > moment). > > Some instructions on how to raise bug reports here: > http://docs.ansible.com/ansible/community.html#i-d-like-to-report-a-bug > > the winrm connection plugin is part of the core language - make sure you > use the issue template as well. > > All the best > > Jon > > On Thursday, August 20, 2015 at 9:23:16 AM UTC+1, Amir Luzon wrote: >> >> 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/930d65bf-7a07-4429-9cb6-2e24fd71efd7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
