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}}’
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
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
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.
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
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
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
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 GDHFStoastRW@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.
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.
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.
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
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.
