Subscribe via Email

Subscribe via RSS


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Using Get-ACL to view and modify Access Control Lists (part 1)

The Get-ACL cmdlet can be used to view and modify Access Control Lists in PowerShell. It works with any object you have a PSProvider for – be it files, folders, registry keys, Active Directory objects, and so on.

Viewing and setting the Owner

To find the owner of an object there are couple of ways. The easy way is to use the Owner property:

But there’s a GetOwner() method too. This takes as input the type of output you want. The input must be of class System.Security.Principal.IdentityReference. There are two such class: System.Security.Principal.NTAccount gives you the user account while System.Security.Principal.SecurityIdentifier gives you the SID. These two classes are worth remembering when you want to convert between a user account and SID or vice versa.

You can set the owner too using the SetOwner() method.

Simply doing a SetOwner() won’t do the trick though because what Get-Acl returns is an ACL object and so all we are really doing is setting the ownership info in that object but not applying it back to the file or folder whose ACL it is.

The correct way would be thus:

Setting the owner – gotchas

For reasons I don’t know, the following doesn’t work:

It could be because of this:

When you set the owner directly, the object is empty. It could be because the SetOwner method doesn’t return anything so $acl is assigned nothing. But when you set $acl to the ACL and then set its owner, it works.

Another gotcha is that Set-Acl cannot be set to give ownership to another user. It can only be used to take ownership. Have a look at this:

I couldn’t find much but this Hey, Scripting Guy! post briefly mentions the following:

… although you can take ownership of a file using Windows PowerShell, we don’t believe that you can give ownership of a file to someone else. To transfer ownership to another user you’ll need to use the Windows Resource Kit utility Subinacl.exe.

Yet another gotcha is that built-in groups like “Users” and “Administrators” need to be referred to differently:

I discovered this looking at this page of well known SIDs, finding the SID of the built-in “Users” group, and translating it via PowerShell:

SID: S-1-5-32-545
Name: Users
Description: A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group. When a computer joins a domain, the Domain Users group is added to the Users group on the computer.

In fact, the error Exception calling "SetOwner" with "1" argument(s): "Some or all identity references could not be translated." is a good way of checking if a user account exists.

More later!