Managing NTFS permissions with PowerShell

• Author
• Recent Posts

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

• Install Ansible on Windows - Thu, Jul 20 2023
• Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
• Azure Virtual Desktop: Getting started - Fri, Apr 14 2023

Unfortunately, even the Windows PowerShell v5 April 2015 preview contains only two cmdlets related to access control lists (ACLs), and they are pretty weak:

• Get-ACL
• Set-ACL

In today’s exercise, we’ll use Raimund Andrée’s File System Security PowerShell module to simplify NTFS permissions management. By using Windows PowerShell remoting and Raimund’s module, you can automate what is otherwise tedious, time-consuming manual work.

Begin by downloading Raimund’s module from the TechNet Script Center and unpacking the ZIP file to a folder named NTFSSecurity in your env:$PSModulePath location. By default, your PowerShell module path is:

C:\ProgrHam Files\WindowsPowerShell\Modules

Here’s a picture from my Windows 8.1 administrative workstation:

Make sure your PowerShell modules are stored in the proper location.

You’ll note that Raimund’s NTFSSecurity project is quite a bit more complex than other custom modules you might have seen, including several dynamic link libraries (DLLs) and such. More to the point, Raimund leverages the AlphaFS library to give him easier access to the .NET Framework’s NTFS access features.

The final preliminary ingredient we need here is a folder and some files to play with. I created a folder named dox in the root of drive C: and populated the folder with a subfolder and a bunch of dummy files. Look here:

We need some files to play with.

Okay—no more File Explorer. From now on, everything we do will be from an elevated Windows PowerShell console session, with a bit of Out-GridView thrown in for good measure. Let’s begin!

Viewing NTFS permissions

First, let’s verify that PowerShell module auto-loading properly recognizes our new NTFSSecurity module. Use Get-Command to auto-import the NTFSSecurity module and enumerate its commands:

Get-Command –Module NTFSSecurity

On an NTFS volume, folders and files each contain a discretionary access control list (DACL) that, in turn, consists of one or more access control entries (ACEs). These ACEs define the group, user, and computer accounts that are explicitly granted or denied access to those files and folders.

Let’s start by enumerating the NTFS ACEs for C:\dox and output the results in a grid view:

Get-NTFSAccess –Path 'C:\Dox' | Out-GridView –Title 'C:\Dox Permissions'

This is a view of the ACEs of a directory.

We can do the same thing for individual files:

Get-NTFSAccess -Path 'C:\dox\cbt.png' | Select-Object –Property Account, AccessRights
Account                                            AccessRights
-------                                            ------------
BUILTIN\Administrators                              FullControl
NT AUTHORITY\SYSTEM                                 FullControl
BUILTIN\Users                       ReadAndExecute, Synchronize
NT AUTHORITY\Authenticated Users            Modify, Synchronize

To list permissions for all folder contents recursively, we can combine Get-ChildItem, Get-NTFSAccess, and the PowerShell pipeline:

Get-ChildItem –Path 'C:\dox' –Recurse | Get-NTFSAccess

Modifying NTFS permissions

Let’s say that we need to grant members of the Marketing group and a user named jrose read-only permissions to all contents of the dox folder. Notice that the Add-NTFSAccess cmdlet accepts a comma-separated list of security IDs (SIDs) or account names:

Add-NTFSAccess –Path 'C:\dox' –Account 'win81box\Marketing', 'win81box\jrose' –AccessRights Read

We can add the –AppliesTo ThisFolderOnly parameter and value set if we need to block NTFS permissions inheritance on the folder contents. In fact, take a look at the following Windows PowerShell ISE screenshot; I want to show you the enumeration contents for both –AccessRights and –AppliesTo:

The PowerShell ISE makes it easier to visualize enumerations.

Now we’ll verify that the C:\dox ACL took our update:

Get-NTFSAccess -Path 'C:\dox' | Where-Object -FilterScript { $_.AccessRights -eq 'Read' } | Format-Table -AutoSize      Path: C:\dox (Inheritance enabled)
Account            Access Rights Applies to                   Type  IsInherited
-------            ------------- ----------                   ----  -----------
WIN81BOX\Marketing Read          ThisFolderSubfoldersAndFiles Allow False
WIN81BOX\jrose     Read          ThisFolderSubfoldersAndFiles Allow False

Determining effective permissions

Were you as happy as I was when the Microsoft Windows Server product team gave us effective permissions in Windows Server 2008 R2? What’s even better is that we can use Raimund’s NTFSSecurity module to tap into that time-saving functionality.

As an example, imagine that we need to see jrose’s effective permissions on the file c:\dox\HTML\about.html. Let’s use Get-EffectiveAccess to get ’er done!

Get-Item -Path 'C:\dox\HTML\about.html' | Get-EffectiveAccess -Account 'win81box\jrose' | Format-List
Name               : about.html
FullName           : C:\dox\HTML\about.html
InheritanceEnabled : False
InheritedFrom      :
AccessControlType  : Allow
AccessRights       : Modify, Synchronize
Account            : WIN81BOX\jrose
InheritanceFlags   : None
IsInherited        : False
PropagationFlags   : None

Now don’t freak out. You probably wonder, “Why does jrose have Modify permission when we set Read at the parent folder level?” Remember that the original ACL contained a Modify permissions entry for Authenticated Users; NTFS permissions are cumulative. Thus, to resolve this issue, we’ll need to either modify or remove Authenticated Users or add Deny permissions to jrose (that’s not considered best practice because it can produce troubleshooting problems farther down the road).

Also, the Format-List output I gave you introduces other questions, such as “Why is the Inherited From property blank?” The answer to this question is that the NTFSSecurity module is an open-source community project. As such, you’re bound to find some bugs and other inconsistent behavior. The good news is that you are free to fork the project and make these adjustments yourself!

Removing NTFS permissions

To finish up, let’s remove those two new entries from our c:\dox ACL:

Remove-NTFSAccess -Path 'C:\dox' -Account win81box\marketing, win81box\jrose -AccessRights Read -PassThru

The –PassThru switch parameter is useful when you want to see the results of your pipeline when such output is normally suppressed.