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.