Closed tolecnal closed 3 years ago
I created a MCVE playbook for the win_acl
behavior:
---
- hosts: all
gather_facts: yes
vars:
dir: '{{ ansible_env.USERPROFILE }}\delme'
tasks:
- win_file:
path: "{{ dir }}"
state: directory
- win_acl:
path: '{{ dir }}'
user: '{{ ansible_env.USERNAME }}'
rights: FullControl
type: allow
state: present
inherit: ContainerInherit, ObjectInherit
propagation: None
I had the same issue on a DC in my environment.
While the bug might exist in win_acl
there's a simple workaround this role can use. It will now just pass along the SID directly rather than getting the name and translating that.
Today I ran into an issue when deploying this role to some domains I wanted to deploy this to.
I was able to deploy the role with success to all normal servers in the domains, however I ran into a problem when deploying it to their associated Domain Controllers. The issue that arose was in the task set correct permissions on .ssh directory where it failed with the following error:
failed: [dc01.dev.local] (item=svcAccountName) => {"ansible_loop_var": "item", "changed": false, "item": "svcAccountName", "msg": "account_name svcAccountName is not a valid account, cannot get SID: Exception calling \"Translate\" with \"1\" argument(s): \"Some or all identity references could not be translated.\""}
For some reason win_acl is not able to use the samAccountName/account name on Domain Controllers, as it's not able to translate the SID.
By changing the "offending" with_items to the following:
{{ ansible_env.USERDOMAIN }}\{{ pri_openssh_ssh_current_user.stdout_lines[0]}}'
I was able to make it work - I also tested this on a none domain joined server to see if it also worked with none domain members as well, which it did. The prerequisite here is that one would need to enable gather_facts to get the required variable content.
The question is if this should be fixed in the role itself, or if this is an issue with win_acl.