win_acl and remote fileshares

[Jesse Lyon]

win_acl and remote fileshares

https://docs.ansible.com/ansible/latest/modules/win_acl_module.html#win-acl-module

Using the WIN_ACL module, is it possible to manage file system permissions on a remote UNC path?

Making the assumption that it is, so long as your user has permissions to do that operation I'm having consistent issues with Access is denied errors while trying to perform the following.

    prd_svm_fix: '\\{{prd_vserver}}.domain.net'
    prd_shr_path: '{{prd_svm_fix}}\{{vol_junction}}\{{obj_name}}'




##PERMISSIONS NONSENSE
  - 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
      become_user: "SA_AN...@DOMAIN.NET"

I'm made the attempt to not "Become" the service account listed, or do it natively through the user I'm connecting to my windows host as, but I'm having a hell of a time finding out precisely where I'm being waived off with this error.

The full traceback is:
Access is denied
At line:106 char:11
+ If (-Not (Test-Path -LiteralPath $path)) {
+           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (\\NAS.DOMAIN.net\Apps\toast:String) [Test-Path], UnauthorizedAccessException
    + FullyQualifiedErrorId : ItemExistsUnauthorizedAccessError,Microsoft.PowerShell.Commands.TestPathCommand


ScriptStackTrace:
at <ScriptBlock>, <No file>: line 106


System.UnauthorizedAccessException: Access is denied ---> System.ComponentModel.Win32Exception: Access is denied
   --- End of inner exception stack trace ---
   at Microsoft.PowerShell.Commands.FileSystemProvider.ItemExists(String path, ErrorRecord& error)
fatal: [system.DOMAIN.net]: FAILED! => {
    "changed": false,
    "msg": "Unhandled exception while executing module: Access is denied"

the UNC path I'm trying to change is not a windows file server, but instead a NetApp hosting the shares, this step is imediately after the vol/share is create and the ACL's are flapping in the breeze wide open "Everyone: Full Control" so I don't imagine it a filesystem "access is denied" issue.

Any help/thoughts would be appreciated.

Thanks!

Jess

[Jordan Borean]

This is because of the double hop problem, without the users credentials the WinRM service cannot authenticate to those fileshares as that user so it appears to be an anonymous user which does not have access. The only way around this is to use become on the task or connect with an authentication option that support credential delegation like CredSSP or Kerberos with delegation enabled.

[Jesse Lyon]

Hey Jordan,

How's that different than what I'm doing here?

      become: yes
      become_method: runas
      become_user: "SA_AN...@DOMAIN.NET"

Should I be using a different method?

[J Hawkesworth]

I had trouble writing to files on a NetApp device via a windows host over winrm.  In the end it transpired the netapp device was not actually a 'domain peer' - it wasn't taking part in the domain and was just set up to allow 'Everyone' access to a share.

That was fixed by upgrading to a newer NetApp device and I believe getting the netapp setup properly to take part in the domain.

I don't recall having to set acl on the files on the NetApp though, so maybe I had a different issue.

Hope this helps,

Jon

[Jordan Borean]

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
  

[Jesse Lyon]

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 GDHFSt...@DOMAIN.NET 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.

[Jordan Borean]

Is the host actually joined to the domain the groups reside in, if you have multiple domain controllers it may not have replicated to whatever that host is talking to when finding the groups.

[Jess L]

The filer/svm is a member of the domain.

Domain groups had replicated (these groups are my test guys and have existed for weeks actually)

The filer is not a member of the groups, that'd be a bit backwards versus what we're trying to accomplish.

On Mon, Apr 6, 2020, 11:49 PM Jordan Borean <jbor...@gmail.com> wrote:

Is the host actually joined to the domain the groups reside in, if you have multiple domain controllers it may not have replicated to whatever that host is talking to when finding the groups.

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/feXbjO2LLEE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/ba6f6242-30ab-49bf-b48c-cf1eb235c943%40googlegroups.com.

[Jesse Lyon]

Current permissions on file path

I've got 1500+ volumes off of this current filer that are all using NTFS permissions from this same domain as well without issue.

I can assign them through set-acl through powershell just using a different path as the ACL fomatter through get-acl and assigning it as a variable  without any fits.

[Jordan Borean]

There's not much more I can really say, Windows ACLs are based on SIDs so it needs to be able to translate a human readable name to the actual SID. If the module is complaining that it's unable to to translate an identity that's just what Windows is returning as it's unable to translate the name to an actual SID. You shouldn't need become or credential delegation enabled for this as the host will talk to the DC to translate the names under it's own account. The only thing I would suggest is to try translating it yourself through a win_shell task and see if it errors out

- win_shell: |
    $account = [System.Security.Principal.NTAccount]'gr...@REALM.COM'
    $account.Translate([System.Security.Principal.SecurityIdentifier])

If that works then I'm not sure why the win_acl task is failing, you could try the Netlogon form 'DOMAIN\group' but the UPN should work just fine here. If the win_shell task fails then there's a problem with your host setup.

Thanks

Jordan