NTFSSecurity Tutorial 2 – Managing NTFS Inheritance and Using Privileges


Summary

In my previous post, NTFSSecurity Tutorial 1 – Getting, adding and removing permissions, I talked about NTFS inheritance. Inheritance is a fundamental feature of NTFS to keep permissions consistent and easy to manage.

However, there are some scenarios where you want to disable inheritance on folders or find out where it has been disabled. This post explains how this can be achieved by using the NTFSSecurity module.

Installation

You can download NTFSSecurity on the TechNet Script Gallery: https://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85. Please unblock the file before extracting it. More information about installing PowerShell modules can be found here: Hey, Scripting Guy! How Can I Install Windows PowerShell Modules on Multiple Users' Computers?

Managing NTFS Inheritance

Determine Inheritance Settings

To determine if a file or folder inherits from its parent, use the Get-NTFSAccessInheritance cmdlet (there is also a Get-NTFSAuditInheritance cmdlet). There are two ways to specify the file or folder: You can use the Path parameter or pipe the file or folder object to Get-NTFSAccessInheritance:

Get-NTFSAccessInheritance -Path C:\Windows

Get-Item C:\Windows | Get-Inheritance

The output might looks like this:


 
You can easily get the information for a bunch of items by using the built-in Get-ChildItem cmdlet, and then pipe all the items to Get-NTFSAccessInheritance:

Get-ChildItem c:\ | Get-NTFSAccessInheritance

 

Enabling Inheritance

The cmdlet for enabling the inheritance on an object is similar to reading the inheritance information:

Enable-NTFSAccessInheritance -Path .\Data

By default, the cmdlet does not return any output unless you use the PassThru switch.

The cmdlet provides one additional switch parameter: RemoveExplicitAccessRules. When specified, all explicitly assigned access control entries (ACEs) will be removed after enabling the inheritance. This is like setting the folder back to default permissions.


 
The previous output shows that there were only explicitly assigned ACEs in the Data folder. These were removed after enabling the inheritance and there are only inherited ACEs remaining.

Note: The RemoveExplicitAccessRules switch should be used with care. Using this switch by accident can cause users to not be able to access their resources.

A common use case for Enable-NTFSAccessInheritance

If users can alter the ACL of files or folders, they might remove relevant ACEs. The result is that the administrators are no longer able to access the data. Another reason why an administrator cannot access data is that someone has disabled the inheritance and deleted all inherited ACEs.

First you need to use the recursive method provided by Get-ChildItem to get all files and folders and filter out the items where inheritance is enabled.The remaining items are piped to Enable-NTFSAccessInheritance, which informs about items where inheritance is enabled with the PassThru switch.

Get-ChildItem -Recurse | Get-NTFSAccessInheritance | Where-Object { -not $_.InheritanceEnabled } | Enable-NTFSAccessInheritance -PassThru
 


 
Disabling Inheritance

In NTFSSecurity, you also need to disable inheritance. When enabling inheritance you have to determine what to do with explicit ACES (usually you keep them). When disabling inheritance, the inherited ACEs can be converted into explicit ones or they can be removed. This is controlled by the RemoveInheritedAccessRules switch.

In the following example, the inheritance for the folder GPO is enabled. The folder is inheriting four ACEs from the parent (drive D). After disabling inheritance, the ACEs still exist as explicit ACEs.


 
Note: When using the RemoveInheritedAccessRules switch, you need to make sure that the access is guaranteed after disabling the inheritance. If an item does not have explicit ACEs assigned and you remove all inherited ACEs, nobody will be able to access the file. However, an administrator can always use the back-up privilege or take ownership to get access again.

Using privileges

Note: There was a big change in Windows 8 and Windows Server 2012 regarding how privileges can be used. The features described in this section work only on Windows 8.1, Windows 8, Windows Server 2012 R2, and Windows Server 2012.

Sometimes permissions are hosed and access is denied, even if you are the mighty administrator. In this case, you cannot even read the existing ACL. Of course, the administrator can always take the ownership of an object, but this erases the existing ACL of the object. This is bad because you cannot determine by the ACL the people who need to have access.

Windows has a very handy concept of privileges. A privilege represents the right of an account, such as a user or group account, to perform various system-related operations on the local computer, such as shutting down the system, loading device drivers, or changing the system time. Privileges differ from access rights in two ways:

  • Privileges control access to system resources and system-related tasks, whereas access rights control access to securable objects.
  • A system administrator assigns privileges to user and group accounts, whereas the system grants or denies access to a securable object based on the access rights granted in the ACEs in the object's DACL.

When dealing with files and folders, three privileges are worth looking at:

  • Back up files and directories:

This user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system. By default, Administrators and Backup Operators can make use of this privilege.

  • Restore files and directories:

This security setting determines which users can bypass file, directory, registry, and other persistent objects permissions when restoring backed up files and directories, and it determines which users can set valid security principals as the owner of an object.

Specifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system:

    • Traverse Folder/Execute File
    • Write

By default Administrators and Backup Operators have this privilege assigned.

  • Take ownership of files or other objects:

This security setting determines which users can take ownership of any securable object in the system, including Active Directory objects, files and folders, printers, registry keys, processes, and threads. By default, this privilege is assigned to Administrators.

For a list of privileges, refer to Privileges in the TechNet Library.

To create the situation described previously, you can use the following command sequence:

Set-NTFSOwner .\Data -Account 'NT AUTHORITY\SYSTEM'

Disable-NTFSAccessInheritance .\Data -RemoveInheritedAccessRules

The first command assigns the ownership of the Data folder to the SYSTEM account, and the second command disables the inheritance. Now only the SYSTEM account can access the item.


 

Windows Explorer is not helpful either:
 

Enabling privileges

The NTFSSecurity module provides the Enable-Privileges cmdlet. This cmdlet enables the privileges Backup, Restore, and Security (if you have them). You can get a list of available privileges by using Get-Privilege.

Running Get-Privilege in a non-elevated Windows PowerShell console should return something like this:


 

 The privileges Backup, Restore, and Security are missing. If you run the same command in an elevated Windows PowerShell console, the list gets much longer:
  

All these privileges are disabled by default. Having them enabled all the time would be quite dangerous and would increase ones scope of action too much. However in some scenarios, it is required to make use of privileges, for example, when doing backup jobs, data migrations, or permission cleanups.

To enable the privileges, call Enable-Privileges. You will get a warning message that informs you about the enabled privileges.

Note: If you call the cmdlet in a non-elevated Windows PowerShell console, and hence, you do not hold the proper privileges, the following error message returns: “Enable-Privileges: Could not enable requested privileges. Cmdlets of NTFSSecurity will only work on resources you have access to.”

After calling Enable-Privileges, you can check the state of the privileges by using Get-Privileges.

Using Enabled Privileges

Enabling the privileges is pretty much all you need to do. The process that has enabled them uses them automatically.

After removing the permissions from the Data folder, there is no way to access it or display the owner or ACL. However, after enabling the privileges, Windows bypasses the ACL and grants you full access (thanks to the Backup and Restore privilege).


 
Get-NTFSAccess does not return any data because there is no ACE in the ACL. Remember that all ACEs have been removed by disabling the inheritance.

Now you can take the ownership and enable inheritance again:

Set-NTFSOwner -Path .\Data -Account BUILTIN\Administrators

Enable-NTFSInheritance -Path .\Data

  

Now the access is how it should be again.

Disabling privileges

If you no longer need the privileges, it is strongly recommended to disable them. Use the command Disable-Privileges for this.

After calling Disable-Privileges, you can check the state of the privileges by using Get-Privileges.


Comments (22)

  1. Bernard says:

    New location to download the NTFS Security module
    https://github.com/raandree/NTFSSecurity

  2. Derek says:

    I have a bit of an outlier issue, but am curious if you can provide any insight.

    I’m trying to use the NTFSSecurity module with Quest One ActiveRoles, and appear to be stuck on the error of

    At line: 51 char:74. Cannot bind parameter ‘Account’. Cannot convert value “groupname” to type “Security2.IdentityReference2”. Error: “Some or all identity references could not be translated.”

    I’m using the latest available version of the plug-in (4.2.3)

    Based on comments I’ve seen here and elsewhere, it has something to do with the quotes.

    When I turn on debugging for the script, I only get proper resolution of the group (I use a variable), with either double quotes, or no quotes. Single quotes don’t resolve.

    For example, here is the line item

    Add-NTFSAccess -Path \\server\share\$username -Account domain\prefix-share-$username-rw -AccessRights AppendData, CreateDirectories, CreateFiles, ExecuteFile, ListDirectory, ReadAttributes, ReadData, ReadExtendedAttributes, ReadPermissions, WriteAttributes, WriteExtendedAttributes -AppliesTo ThisFolderSubfoldersAndFiles -PassThru

    Even the error message properly displays the fact it’s translating the “Account” correctly. Any suggestions?

    1. Derek says:

      Disregard – figured this out. I had to add a pause before this line as a previous line creates the group. It just wasn’t “ready”. Hope that helps someone in the future!

  3. Notourious says:

    Raimund,

    first of all that you for share such a useful articles.

    I need a help using your scripts. I’m trying to write a script where I can I can move my IIS folder structure to a new drive. That I was able to achieve. However, now I’ve to change the folder permissions. Using your script I managed to change the Drive permission… like:

    D: Admininstrators -> Full Controll | System -> Full Control | Local Users -> Read and Execure

    How do I do to make all child objects to inherits same permission?

    By making the changes from UI there is a option “Replace permission entries on all child obhects with entries shown here that applu to child objects” which I believe your script does not have.

    Could you help me out to find out how can I achieve it?

    Cheers

  4. Charles Palmer says:

    I am having a problem with the latest version of the module. I have followed the guidance in the articles on here as well as the help for the module but I am still having the issue. I am working on a 2012R2 server with the latest version of the module. When I am using Add-NTFSAccess to add permissions for an account. I am not getting any failures and everything seems to be working fine until I try to access the share/folder with an account that is not an Administrator account.
    Specifically, I create a folder named Home in the root of my drive. Drive has permissions set to inherit Administrators, System and a few additional groups that I add with the script (FA-FullControl, FA-Change, FA-Read). I have not tested whether or not those group permissions work or not. But inside of Home, I then create a folder named Username. Folder creates and then I use Add-NTFSAccess to grant domain\username access to the folder Username. Again, I get no errors or failures. Everything looks good.
    I log into a computer as Username (which is not in the Administrators group) and try to access \\servername\username share and I get an access denied error message. I actually tried to open a call to Microsoft about this after banging my head against it for a few days to no avail. I showed them my script and they said they don’t support Powershell and wanted me to create the folder share and assign the permissions through the GUI. Doing that, it works fine. If I go into the GUI and just propagate the permissions onto subfolders, it “fixes” the permissions and it works. If I was only doing a few folders, I would just move on. I am trying to do hundreds of folders. I am wondering if anyone else has experience anything similar to this problem and came up with a workaround for it that I might use. I would really hate to have to resort to icacls or one of the old methods I used to use before Powershell to make this work. I did not have this problem early on in my testing of this script (the project got back burnered for about a year) but I can’t say I definitively tested with anything other than my admin accounts at that time.
    Any information would be greatly appreciated.
    Here is a representative line of how I used the command:
    Add-NTFSAccess -Path $DrivePath -Account ($Domain+’\FA-FullControl’) -AccessType Allow -AccessRights FullControl
    And, again, the command runs successfully just something isn’t quite right in the permissions.

    1. Sorry, I have seen this too late. Do you still have the issue?

      And of course does Microsoft support PowerShell. However Microsoft does not support modules provided by the community. Can you reproduce the behavior also when using .net classes and not this module?

  5. LRobeo says:

    Hi, I know this post is old, but I don’t seem to have the “Get-NTFSAccessInheritance” module in my NTFSSecuity 4.2.3 module. Has the name been changed in newer versions? I do have GetNTFSAccess and GetNTFSInheritance, though. Which should I use?

    1. Get-NTFSInheritance returns the access and audit inheritance. I have combined the functionality of both old cmdlets into one.

  6. Jerry Burney says:

    Hey I am having problem with Enable-NTFSAuditInheritance. I run the command on a folder but when I check it nothing has changed.
    Enable-NTFSAuditInheritance -path \\server\folder but nothing shows up in the Auditing tab in explorer. The folder above has the audit set for sub-folders and files. I can do it manually through explorer just fine. Any ideas?

  7. Ivaylo Kralev says:

    Hello,
    i receive an error when i try set ownership from variable:
    in my script:

    Getting the owner of folder:

    Get-Item $TargetFolder | get-NTFSOwner | select owner | convertTo-csv | select -skip 2 | Out-File own.txt

    Setting the owner from own.txt:

    Set-NTFSOwner $TargetFolder -Account $owner

    but when i set the ownership i get the following error:

    Set-NTFSOwner : Cannot bind parameter ‘Account’. Cannot convert value “”NT AUTHORITY\SYSTEM”” to type
    “Security2.IdentityReference2”. Error: “Some or all identity references could not be translated.”

    Can you advise please?

    Regards Ivo!

    1. It looks like that you have too many quotes in the CSV file. If the principal cannot be resolved, ”NT AUTHORITY\SYSTEM” should be in one set of quotes. Can you check the file please and try to either fix the export or remove the double double quotes?

      1. Ivaylo Kralev says:

        Thanks for you input Raimund,
        in file, username is with one quote

    2. Ivaylo Kralev says:

      Hi,
      i have removed the quotes from exported file

      Get-Content “.\own.txt” | % {$_ -replace ‘”‘, “”} | out-file -FilePath own1.txt -Force
      $owner= get-content “.\own1.txt”
      Set-NTFSOwner $TargetFolder -Account $owner

      1. Ivaylo Kralev says:

        and it works :)

  8. WillT says:

    You mentioned in the future you’ll write a tutorial on Get-ChildItem2. Is there any tutorial or example usage you can provide? Many thanks, you code is fantastic and it helps SO many people.

  9. Luke B says:

    While everything seems to work just as described, I cannot actually access files in my directory from a remote machine. I am using Windows 7.

    1. Luke, can you be more specific about the problem. Accessing remote files works in my case:

      Get-ChildItem2 \\kerbdc2\c$

    2. Or are you trying to access remote resources from a remote session? Then your issue is this: http://tfl09.blogspot.de/2013/02/powershell-remoting-double-hop-problem.html

  10. Jerry says:

    I can’t seem to use wildcards in the get-childitem2

    1. Right, unfortunately I have not implemented using wildcards yet. I am working on it…

  11. Keith says:

    Did you ever write a follow up for getting effective permissions?

Skip to main content