PowerShell Problem Solver: Identify Folders with Blocked Inheritance Using PowerShell

I’ll be the first to admit that working with file and folder permissions makes my head hurt. It’s one of the most complicated tasks in Windows that IT pros frequently want to automate. A common task is to identify folders that have been configured to block inheritance. Using inheritance generally makes like easier when it comes to NTFS permissions. A folder that’s blocking inheritance is often the exception to the rule and an indication that someone has done something they probably shouldn’t have. Although there are scenarios when you may be expecting blocked inheritance, any folder that’s not configured is the exception. This is most often the case with user home folders. 

Using PowerShell ACL cmdlets

I have some local test folders that I’ll use for my demonstration. It is very important that you test everything in this article in a non-production environment, especially if you’re going to change folder permissions. The PowerShell ACL cmdlets can be a little tricky to use. Although I’m running commands locally, you should be able to take the same techniques and commands and wrap them in Invoke-Command so that you can execute them in a PowerShell remoting session. I wouldn’t recommend trying to get or set the ACL of \file02c$sharedfoo over the wire because there’s no reason to pass that type of SMB traffic. Instead use remoting so that everything is secure and goes over a single port.
It should also go without saying, but I will say this anyways that you need to run the commands with an account that has enough permissions to read the access control list on a given folder. Typically an account with local administrator privileges is sufficient.
Let’s begin by looking at the ACL of a folder that has had inheritance disabled.

​get-acl C:workdemo3 | select *

The property that’s of interest is AreAccessRulesProtected.

AreAccessRulesProtected is a boolean property. If the value is true, then inheritance has been disabled. I’m going to check this property for all top-level folders using PowerShell inheritance techniques.

​dir c:work -Directory | get-acl |
Select @{Name="Path";Expression={Convert-Path $_.Path}},AreAccessRulesProtected |
Format-table -AutoSize

I have two top-level folders, which is generally what people test. If you need to drill down, then you can by using –Recurse with the DIR command. By the way, I’m defining a custom property for the path because the Get-ACL cmdlet has a path property, but it looks like this: Microsoft.PowerShell.CoreFileSystem::C:workdemo3, and I prefer to have more user-friendly paths.

Because the AreAccessRulesProtected property is a boolean, you don’t need to use the –eq operator, so it’s a simple matter to filter out folders that have blocked Powershell inheritance.

​dir c:work -Directory -recurse | get-acl |
Where {$_.AreAccessRulesProtected} |
Select @{Name="Path";Expression={Convert-Path $_.Path}},AreAccessRulesProtected |
format-table -AutoSize

These are the folders under C:Work that have inheritance disabled.

If I want to find folders that have inheritance enabled, then I can use the –NOT operator in my filter.

Let’s say you want to re-enable inheritance once you’ve identified folders with blocked inheritance. The following outlines a simple way to do so.
First, we need the access control list for a folder.

​$acl = get-acl c:workdemo2

To modify, we can use the SetAccessRuleProtection() method, which takes a few parameters.

​$acl.SetAccessRuleProtection.OverloadDefinitions

The parameter values are both boolean. The second parameter indicates if you want to save existing rules, and I generally do.

​$acl.SetAccessRuleProtection($False,$True)

All I’ve done is set the property on the ACL object. It hasn’t been applied to the folder. To accomplish that, I need to use Set-ACL.

​set-acl -Path c:workdemo2 -AclObject $acl

Rechecking inheritance, I can see that this folder is now back to normal. At least for my purposes.

To make life easier, I have a function called Set-Inheritance.

#requires -version 3.0
Function Set-Inheritance {
[cmdletbinding(SupportsShouldProcess)]
Param(
[Parameter(Position=0,Mandatory,HelpMessage="Enter the file or folder path",
ValueFromPipeline=$True,ValueFromPipelineByPropertyName)]
[ValidateNotNullOrEmpty()]
[Alias("PSPath")]
[string]$Path,
[switch]$NoInherit,
[switch]$NoPreserve,
[switch]$Passthru
)
BEGIN {
    Write-Verbose  "Starting $($MyInvocation.Mycommand)"
} #begin
PROCESS {
    Try {
        $fitem = Get-Item -path $(Convert-Path $Path) -ErrorAction Stop
    }
    Catch {
        Write-Warning "Failed to get $path"
        Write-Warning $_.exception.message
        #bail out
        Return
    }
    if ($fitem) {
    Write-Verbose ("Resetting inheritance on {0}" -f $fitem.fullname)
    $aclProperties = Get-Acl $fItem
    Write-Verbose ($aclProperties | Select * | out-string)
    if ($noinherit) {
        Write-Verbose "Setting inheritance to NoInherit"
    	if ($nopreserve) {
    		#remove inherited access rules
            Write-Verbose "Removing existing rules"
     		$aclProperties.SetAccessRuleProtection($true,$false)
     	}
     	else {
     		#preserve inherited access rules
     		$aclProperties.SetAccessRuleProtection($true,$true)
     	}
    }
    else {
     	#the second parameter is required but actually ignored
        #in this scenario
     	$aclProperties.SetAccessRuleProtection($false,$false)
    }
    Write-Verbose "Setting the new ACL"
    #hashtable of parameters to splat to Set-ACL
    $setParams = @{
        Path = $fitem
        AclObject = $aclProperties
        Passthru = $Passthru
    }
    Set-Acl @setparams
    } #if $fitem
} #process
END {
    Write-Verbose  "Ending $($MyInvocation.Mycommand)"
} #end
} #end function
Set-Alias -name sin -value Set-Inheritance

With this function, I can easily reset inheritance with a one-line command:

​dir c:work -Directory -recurse | get-acl | Where {$_.AreAccessRulesProtected} | set-inheritance -whatif

If I intentionally want to disable or block inheritance, I can do that as well.

​Set-Inheritance C:workdemo1 -NoInherit

Be careful about using the –NoPreserve parameter with my function. If you use it all existing permissions will be wiped out, and you’ll need to repopulate access control from scratch. As I mention at the beginning, you must carefully test these steps in a non-production environment. Personally, I like being able to use PowerShell to identify folders blocked inheritance. Unless I’m faced with a lot of folders, I’m just as happy resetting permissions manually. I’ve provided a PowerShell tool you can use, but just because you can doesn’t always mean you should.

FAQs

What is the default PowerShell inheritance behavior for newly created folders in Windows?

By default, when creating new folders in Windows, PowerShell inheritance automatically applies the parent folder’s permissions to the new folder. This PowerShell inheritance mechanism ensures consistent security across your directory structure without manual configuration.

How can PowerShell inheritance affect Group Policy Objects (GPOs) in Active Directory?

PowerShell inheritance in Active Directory allows GPO settings to flow down through organizational units (OUs), with child OUs inheriting settings from parent OUs. Administrators can use PowerShell to manage and modify these inheritance settings across the AD structure.

What are the security implications of modifying PowerShell inheritance on network shares?

Modifying PowerShell inheritance on network shares can impact security by potentially creating permission gaps or unauthorized access points. It’s crucial to understand that breaking inheritance without proper planning can lead to security vulnerabilities and access control issues.

How does PowerShell inheritance interact with cross-domain resources?

When dealing with cross-domain resources, PowerShell inheritance follows trust relationships between domains. Administrators need to ensure proper domain trust configurations and understand how inheritance flows across domain boundaries to maintain security.

What are the best practices for managing PowerShell inheritance in large enterprise environments?

Enterprise-level PowerShell inheritance management should include regular auditing, documentation of inheritance exceptions, implementation of change control processes, and use of automated scripts to monitor and maintain consistent inheritance patterns across the organization.