{"id":2021,"date":"2014-12-22T13:29:05","date_gmt":"2014-12-22T09:29:05","guid":{"rendered":"https:\/\/rakhesh.com\/?p=2021"},"modified":"2014-12-22T13:29:34","modified_gmt":"2014-12-22T09:29:34","slug":"setting-file-acls-via-powershell","status":"publish","type":"post","link":"https:\/\/rakhesh.com\/windows\/setting-file-acls-via-powershell\/","title":{"rendered":"Setting file ACLs via PowerShell"},"content":{"rendered":"

Yesterday I ran WireShark at work with my admin account and saved the results to a file. Later I moved that file (as my admin account) to the desktop of my regular account so I could email it to someone. But as you know moving has the effect that the original permissions are retained<\/a> so even though the file was now in my regular Desktop I as a regular user couldn’t access it.<\/p>\n

Running Explorer as an administrator doesn’t help either. Because of UAC when I right click Explorer and do “Run as administrator” it still runs as me but in an elevated context. This is an Explorer specific quirk<\/a>. So unless I were to logout and login as my admin account, there seemed to be no way of changing the file ACLs to give my regular account permissions.<\/p>\n

But of course there are ways. PowerShell was my first choice (coz I knew it had a Set-ACL<\/code> cmdlet) but I wasn’t sure how to assign permissions using PowerShell. A quick web search got me to this blog post<\/a> that summarizes what needs to be done. Up shot of the matter is you do something along these lines:<\/p>\n

$acl = Get-Acl \\path\\to\\file\r\n$permission = \"domain\\user\",\"FullControl\",\"Allow\"\r\n$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission\r\n$acl.SetAccessRule($accessRule)\r\n$acl | Set-Acl \\path\\to\\file<\/pre>\n
What you do here is that first you store the current ACLs of the file into a variable. Then you create a new ACE object with the permissions you want. Add that to the previous variable and assign the new ACL to the file.<\/p>\n
While the above is useful, it would be good if I could just copy the ACLs from a file with ACEs I like to the file I want to modify. Something like this: <\/p>\n
get-acl \\path\\to\\file\\with\\permissions\\you\\like | set-acl \\path\\to\\file<\/pre>\n
This doesn’t work though. <\/p>\n
If I run this in a PowerShell session under my regular account it fails (obviously):<\/p>\n
Set-Acl : Attempted to perform an unauthorized operation.<\/pre>\n
But if I run this under my admin account, then too it fails (though for not an obvious reason): <\/p>\n
Set-Acl : The security identifier is not allowed to be the owner of this object.<\/pre>\n
This is because by default Set-ACL<\/code> also tries to set the owner ACE, and since the owner is different from the user account under which Set-ACL<\/code> is running it gives an error. In Windows you can’t assign someone else as an owner unless you have a  privilege for doing that (the SeRestorePrivilege<\/code> privilege, see this MSDN<\/a> page). All you can do is grant someone a Take Ownership permission and then they<\/em> have to take ownership. (See this forum post<\/a> for more info. Another forum post<\/a> gives a workaround. Also, this blog post<\/a> from Lee Holmes is useful in the context of the second forum post). <\/p>\n
So a simple copy-paste is out of the question …<\/p>\n
I still might be able to fix this easily though. Remember the reason the file (in my case) has a different set of permissions is because its ACEs are protected from inheritance. If I had copied the file over instead of moving, then permissions won’t be protected and inheritance would have kicked in. But since I moved the file here its permissions are protected. I can confirm this via Get-ACL<\/code> too:<\/p>\n
(Get-Acl \\path\\to\\file).AreAccessRulesProtected<\/pre>\n
So all I need to do here is remove protection. That can be done via the SetAccessRuleProtection<\/code> method<\/a>. This takes two parameters – the first determines whether protection is enabled ($true<\/code>) or not ($false<\/code>). The second is ignored if protection is disabled; but if protection is enabled then it determines whether the inherited rules are kept ($true<\/code>) or discarded ($false<\/code>) . Thus, in my case, all I need to do is the following:<\/p>\n
$acl = Get-Acl \\path\\to\\file\r\n$acl.SetAccessRuleProtection($false,$false)\r\n$acl | Set-Acl \\path\\to\\file<\/pre>\n
After this the file has both the original ACEs as well as the ones inherited from my home folder (notice the last three rules in the list below):<\/p>\n
(Get-Acl .\\admin.txt).Access | ft IdentityReference,IsInherited -AutoSize\r\n\r\nIdentityReference       IsInherited\r\n-----------------       -----------\r\nNT AUTHORITY\\SYSTEM           False\r\nBUILTIN\\Administrators        False\r\nDOMAIN\\admin                  False\r\nNT AUTHORITY\\SYSTEM            True\r\nBUILTIN\\Administrators         True\r\nDOMAIN\\user                    True<\/pre>\n
Now I can just copy the ACLs from another file – with PowerShell running under my account – as I had tried earlier. This is optional, I did it so the permissions are consistent with others. <\/p>\n
get-acl \\path\\to\\file\\with\\permissions\\you\\like | set-acl \\path\\to\\file<\/pre>\n
While  on Set-ACL<\/code> the following snippet too might be useful: <\/p>\n
$acl = Get-Acl \\path\\to\\file\r\nforeach ($a in (Get-Acl \\path\\to\\file\\with\\permissions\\you\\like).Access) { $acl.SetAccessRule($a) }\r\n$acl | Set-Acl \\path\\to\\file<\/pre>\n
This takes the ACLs from an existing file and adds<\/em> these to the file I want.  Again, this only works if you already have permissions on the file – in case above, I could do this after I have turned off protection. <\/p>\n
While on PowerShell and ACLs its worth pointing to this<\/a> Tip post. That’s where I first learnt about PowerShell and ACLs though I admit I have forgotten most of what I learnt from lack of use.  This blog post<\/a> which I came across today is a good read too. I came across it while searching for how to enable inheritance. <\/p>\n
Apart from PowerShell there are other commands which can set\/ get ACLs. One of these is ICACLS<\/a>, which is present in Windows Vista\/ Server 2003 SP2 and upwards. <\/p>\n
Interestingly ICACLS seems to be able to set the owner to another account even though PowerShell fails. Not sure why that succeeds …<\/p>\n
icacls \\path\\to\\file \/setowner \"DOMAIN\\User\"<\/pre>\n
ICACLS can also easily reset the ACLs with inherited ones (i.e. like the PowerShell above it disables protection but also replaces the non-inherited entries with inherited ones). <\/p>\n
icacls \\path\\to\\file \/reset<\/pre>\n
This is a good post<\/a> on using ICACLS. Apart from resetting and changing owners, you can also use ICACL to add\/ remove ACEs, find files belonging to a particular user, and even substitute an ACE username\/ SID with another. You can even save all ACEs of files in a folder and then restore them. <\/p>\n
Lastly, if you are an administrator and want to take ownership of a file or directory, the takeown<\/code> command<\/a> is useful. It is not as useful as ICACLS which lets you assign someone else as the owner, but is useful if you are an admin and want take ownership. <\/p>\n","protected":false},"excerpt":{"rendered":"
Yesterday I ran WireShark at work with my admin account and saved the results to a file. Later I moved that file (as my admin account) to the desktop of my regular account so I could email it to someone. But as you know moving has the effect that the original permissions are retained so … Continue reading Setting file ACLs via PowerShell<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[85],"tags":[415,414,140,413,227,289,412],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/2021"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=2021"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/2021\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=2021"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=2021"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=2021"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}