Broken Inheritance in NTFS Permissions

NTFS permission inheritance is one of Windows' most powerful features for managing file access at scale. When configured correctly, permissions set at a parent folder automatically flow to all children, making access management simple and consistent. But when inheritance is broken - intentionally or accidentally - it creates management complexity and can lead to security gaps.

This guide explains how permission inheritance works, why it sometimes gets broken, and how to identify all folders with disabled inheritance across your file system.

Understanding Permission Inheritance

How Inheritance Works

When you create a folder, it automatically inherits permissions from its parent:

• Parent has "Sales Group - Modify" - Child folders get the same permission
• Inherited permissions show "(i)" prefix - Indicates the permission comes from above
• Changes propagate automatically - Update the parent, children follow
• No manual management needed - Set once at the root, apply everywhere

Best practice model: Set permissions at the share root, let inheritance do the work, and only break inheritance where you need different access. This is the recommended NTFS permission model.

When Inheritance Breaks

Inheritance can be disabled (broken) by:

• Intentional configuration - Administrator disables inheritance for security reasons
• Application installation - Some software disables inheritance during setup
• User actions - End users modifying permissions without understanding inheritance
• Migration artifacts - Permissions from legacy systems may not inherit correctly
• Troubleshooting attempts - Quick fixes that become permanent

The Impact of Broken Inheritance

When inheritance is disabled, the folder becomes an isolated security boundary:

• No automatic permission updates - Parent changes don't affect this folder
• Manual management required - Must update permissions individually
• Inconsistent access - Users may have access to parent but not this subfolder
• Harder troubleshooting - Access issues become more complex to diagnose

Common Scenarios Requiring Broken Inheritance

Legitimate Use Cases

Some situations genuinely require disabling inheritance:

• Confidential subfolders - An HR folder within a department share that only HR should access
• Restricted project data - Project folders requiring limited team access
• Compliance requirements - Regulatory mandates for specific access controls
• Application requirements - Software requiring specific permission configurations

Problematic Patterns

Watch for these warning signs of inheritance misuse:

• Too many breaks - More than 10-15% of folders with broken inheritance suggests overuse
• Deep nesting - Inheritance breaks several levels deep indicate structural issues
• No documentation - No one knows why inheritance was disabled
• Accumulation over time - Number of breaks keeps growing without review

Red flag: If you can't explain why inheritance is disabled on a folder, it's likely unnecessary and should be re-evaluated.

Finding Folders with Broken Inheritance

Permissions Reporter can quickly identify all folders where inheritance has been disabled, helping you assess and manage your inheritance strategy.

Step 1: Run a Permissions Scan

1. Launch Permissions Reporter
2. Create a new project or open existing
3. Add the folder paths to analyze
4. Run the permissions scan

Step 2: Apply the Broken Inheritance Filter

1. After the scan completes, click the Filter dropdown in the main toolbar
2. Select Edit Post-Scan Filter to open the filter editor
3. In the filter editor toolbar, click the Quick button
4. Select "Folders not inheriting permissions" from the quick filter menu
5. Click Apply to filter the results

What the filter finds: This preset identifies folders where the "Include inheritable permissions from this object's parent" option is unchecked - meaning the folder does not receive permissions from its parent.

Step 3: Review the Inheritance Map

The filtered view provides:

• Folder path - Where inheritance is disabled
• Current permissions - What explicit permissions exist
• Depth in tree - How deep the break occurs
• Child folder count - How many folders are affected downstream

Step 4: Export for Analysis

Export findings to plan your inheritance strategy:

1. Click Export
2. Choose your format (Excel recommended for analysis)
3. Add columns for: Reason, Owner, Remediation Decision
4. Review each break with folder owners

Remediation Strategies

Assess Before Changing

Before modifying inheritance, understand the current state:

1. Document current permissions - Export before making changes
2. Identify the reason - Ask folder owners why inheritance is disabled
3. Evaluate impact - What would change if inheritance were re-enabled?
4. Test in non-production - If possible, test changes first

Re-Enable Inheritance

For folders that don't need isolated permissions:

# PowerShell: Re-enable inheritance
$path = "D:\Shares\Department\SubFolder"

$acl = Get-Acl $path

# Enable inheritance, preserve existing explicit permissions
$acl.SetAccessRuleProtection($false, $true)

Set-Acl $path $acl

Write-Host "Inheritance re-enabled on: $path"

Best practice: Use the second parameter ($true) to preserve existing explicit permissions. This prevents accidental access loss while restoring inheritance.

Re-Enable and Clean Up

After re-enabling inheritance, clean up redundant explicit permissions:

# Re-enable inheritance and remove redundant explicit rules
$path = "D:\Shares\Department\SubFolder"

$acl = Get-Acl $path
$acl.SetAccessRuleProtection($false, $true)
Set-Acl $path $acl

# Reload ACL to see inherited permissions
$acl = Get-Acl $path

# Find explicit rules that duplicate inherited rules
$inherited = $acl.Access | Where-Object { $_.IsInherited -eq $true }
$explicit = $acl.Access | Where-Object { $_.IsInherited -eq $false }

foreach ($exp in $explicit) {
    $duplicate = $inherited | Where-Object {
        $_.IdentityReference -eq $exp.IdentityReference -and
        $_.FileSystemRights -eq $exp.FileSystemRights -and
        $_.AccessControlType -eq $exp.AccessControlType
    }
    if ($duplicate) {
        $acl.RemoveAccessRule($exp)
        Write-Host "Removed redundant: $($exp.IdentityReference)"
    }
}

Set-Acl $path $acl

Document Legitimate Breaks

For inheritance breaks that are genuinely needed, document them:

• Why inheritance is disabled - Business/security reason
• Who approved it - Data owner, security team
• When it was configured - Date and context
• Review schedule - When to re-evaluate the need

Building an Inheritance Strategy

Design Principles

Follow these principles for a maintainable permission structure:

• Minimize breaks - Use inheritance as the default; break only when necessary
• Break at appropriate levels - Higher-level breaks affect fewer individual folders
• Document all breaks - Maintain a registry of intentional inheritance disabling
• Audit regularly - Review breaks quarterly to remove unnecessary ones

Folder Structure Recommendations

Design your folder structure to minimize inheritance breaks:

\\FileServer\Shares\
    ├── Finance\              [Inheritance break - Finance access only]
    │   ├── Reports\          [Inherits from Finance]
    │   ├── Budgets\          [Inherits from Finance]
    │   └── Confidential\     [Inheritance break - CFO only]
    │
    ├── HR\                   [Inheritance break - HR access only]
    │   ├── Policies\         [Inherits from HR]
    │   └── Personnel\        [Inheritance break - HR Managers only]
    │
    └── Public\               [Inheritance break - All users read]
        └── Templates\        [Inherits from Public]

In this model, inheritance breaks occur at logical security boundaries, not scattered throughout the structure.

Ongoing Monitoring

Maintain your inheritance strategy with regular auditing:

• Schedule monthly scans with Permissions Reporter
• Compare reports to detect new inheritance breaks
• Investigate unexpected breaks immediately
• Maintain your documentation of legitimate breaks

Related Resources

• NTFS Permissions Overview
• NTFS Permissions Best Practices
• NTFS Permissions Troubleshooting FAQ
• Advanced Filtering
• Folder Security Metrics