win_chocolatey using unc path in source

Archives Ansible Project
1

Hi cheers,

I’m not able to use a share or unc path in the source parameter of win_chocolatey module
The same is running if you use choco directly with cinst -y myPack --source “\myserver\myshare”

I’ve opened an issue on github (https://github.com/ansible/ansible/issues/49871)

they allready answer that it was supported… but i’ve never seen examples running fine.

I don’t know what is wrong as i use a user which have the rights to access the share.

  • name: deploy LogPoint
    win_chocolatey:
    name: myPack
    source: \myserver\myshare
    state: latest

can anyone experienced the same thing ? I’ve also seen a post here on which there were doubts about the support of this solution…

2

Hi

The source parameter can be used to specify a file path to some package, we even used to use that functionality in the integration tests for the module. The ‘source’ module option is used with the ‘–source’ argument as shown by https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/windows/win_chocolatey.ps1#L166-L169 so it has the same rules and supports the same features as the command line.

What you are most likely coming across is the double hop/credential delegation issue as Ansible runs the task through WinRM. When using WinRM (or other network logons), the user’s credentials are typically not accessible to the running process so it cannot then authenticate with different servers like a file share. In this case it will try and access the share as an anonymous user which results in either an access is denied or file not found error. Compared to when you run it locally, the process has access to the user’s credentials and can authenticate as that user for downstream server implicitly.

Microsoft have a detailed guide on this here https://blogs.technet.microsoft.com/ashleymcglone/2016/08/30/powershell-remoting-kerberos-double-hop-solved-securely/. Ansible has also documented this issue such as https://docs.ansible.com/ansible/latest/user_guide/windows_winrm.html#limitations and https://docs.ansible.com/ansible/latest/user_guide/windows_faq.html#why-can-i-run-a-command-locally-that-does-not-work-under-ansible.

So to get this task working you have a few options available to you;

  • If in a domain environment, use ‘ansible_winrm_transport: kerbros’ and ‘ansible_winrm_kerberos_delegation: True’ to enable Kerberos auth with credential delegation
  • A special Kerb ticket is sent to the server which can use that ticket for further authentication
  • You can configure this to be constrained to only work for certain downstream servers in AD if you wish
  • This is the most secure option as no credential is actually sent to the server but a special kerb ticket but it still has some limitations where become is more suited towards the task
  • Use ‘ansible_winrm_transport: credssp’ after enabling CredSSP auth on your Windows host
  • This works the same as Kerberos but works for local account but this is unconstrained delegation- Use become[1] on the Ansible task
  • As well as running it in a process that has access to the user’s credentials it also changes the logon type from network to interactive
  • This can solve other issues when it comes to installing certain programs or hotfixes
    Using become is probably the easiest and it’s quite simple to do;

`

  • name: deploy LogPoint
    win_chocolatey:
    name: myPack
    source: \myserver\myshare
    state: latest
    become: True
    become_method: runas
    vars:
    ansible_become_user: ‘{{ ansible_user }}’
    ansible_become_pass: ‘{{ ansible_password }}’

`

What that task will do is run under become and set the become user to the current Ansible connection user with it’s password. Give that a try and see how you go.

Thanks

Jordan

[1] - https://docs.ansible.com/ansible/latest/user_guide/become.html#become-and-windows