Hi again Jordan,
Those solutions absolutely did work for me, and have solved an issue 
elsewhere i was having as well, so thanks again.

I do have a question about the module further.
Namely,
how the heck do I force this to assign domain groups?

fatal: [HOST.DOMAIN.net]: FAILED! => {
    "changed": false,
    "msg": "account_name [email protected] is not a valid account, 
cannot get SID: Exception calling \"Translate\" with \"1\" argument(s): 
\"Some or all identity references could not be translated.\""
}

I know the groups exists, it was created in the play right before it, both 
models, domain\group and group@domain dont translate.

On Friday, April 3, 2020 at 4:52:15 PM UTC-4, Jordan Borean wrote:
>
> Sorry I misread what you said and thought you meant you didn't think 
> become mattered here but I see your problem. You've set the become vars as 
> a module option to win_acl, the directives should be on the same 
> indentation as win_acl itself. Unfortunately not all Windows modules 
> currently validate that the options you've specified are actually 
> supported, they are just silently ignored but hopefully over time more of 
> them use the newer framework that does do that validation. In short your 
> task should look like
>
> - name: Define RW permissions on new share.
>   win_acl:
>     path: "{{ prd_shr_path }}"
>     rights: Modify
>     type: allow
>     user: 'DOMAIN\{{ h_dl_prefix }}{{ u_name }}{{ suffix_RW }}'
>     inherit: containerinherit, objectinherit
>   become: yes
>   become_method: runas
>   vars:
>     ansible_become_user: '{{ ansible_user }}'
>     ansible_become_pass: '{{ ansible_password }}'
>
> I've made a slight tweak to specify the user and password in the vars 
> section. My reasons for this are
>
>    - You need to specify the password or else you will have the same 
>    problem as WinRM where you become the user but with no password available, 
>    there is no task directive for 'become_pass' and it needs to be set in a 
>    variable
>    - Setting a var has a higher precedence than a task directive, so if 
>    you've set 'become_user: some user' on your task but have set 
>    'ansible_become_user: other user' in your host/group vars for that host, 
>    'other user' is used. Setting it on the vars section of a task is pretty 
>    high up there on variable precedence with only a few things being higher 
>    (vars specified by -e is one of them)
>    - I've also said to just become the connection user using the existing 
>    connection variables. This makes things host agnostic and just ensures 
> that 
>    the process runs as the same connection user but has it's credentials 
>    available for delegation
>    
>

-- 
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/ca43258d-c157-4bd0-a2c0-a2982c1fb963%40googlegroups.com.

Reply via email to