Disabled Account Permissions

When employees leave your organization, their Active Directory accounts are typically disabled as part of the offboarding process. However, disabling an account doesn't remove the user's file system permissions. Those permissions remain in place indefinitely, creating security risks, compliance concerns, and cluttered access control lists.

This guide explains why disabled account permissions matter, how to find them across your file servers, and the best practices for cleaning them up as part of a comprehensive offboarding process.

Why Disabled Account Permissions Matter

Security Implications

While a disabled account can't be used to log in directly, the permissions present risks:

• Account re-enablement - If an attacker or insider re-enables the account, all original access is restored
• Permission inheritance - The disabled user's permissions may affect how inheritance works
• Attack surface mapping - Accumulated permissions reveal what data former employees could access
• Insider threat history - Understanding past access is crucial for investigating data breaches

Compliance Requirements

Multiple regulatory frameworks require timely access revocation:

• SOX - Section 404 requires access controls and timely revocation
• HIPAA - Requires workforce member access termination procedures
• PCI-DSS - Requirement 8.1.3 mandates immediate revocation for terminated users
• ISO 27001 - A.9.2.6 requires removal of access rights upon termination
• NIST 800-53 - AC-2 requires disabling accounts and reviewing access

Audit Risk: Auditors specifically look for permissions belonging to disabled or terminated users. Finding these is often an automatic finding in compliance audits.

Operational Cleanliness

Beyond security and compliance, stale permissions create practical problems:

• Cluttered ACLs - Access control lists become harder to read and manage
• Troubleshooting complexity - More entries mean more potential permission conflicts
• Performance impact - Extremely large ACLs can affect access check performance
• Inheritance confusion - Old permissions may unexpectedly affect new users

The Offboarding Gap

Most organizations have offboarding checklists that include disabling the AD account, but few include comprehensive permission removal:

What Typically Happens

1. HR notifies IT of employee departure
2. IT disables the Active Directory account
3. Email access is revoked
4. VPN/remote access is disabled
5. File permissions are forgotten

Why Permissions Are Overlooked

• No visibility - IT doesn't know where the user has permissions
• Time pressure - Offboarding happens quickly, permission audit takes time
• Distributed data - User may have access across multiple file servers
• Group memberships - Removing group access is different from direct permissions

The solution: Integrate a Permissions Reporter scan into your offboarding process to identify all file access for departing employees before or immediately after account disablement.

Finding Disabled Account Permissions

Permissions Reporter can identify permissions belonging to disabled Active Directory accounts across your entire file system. Here's how:

Step 1: Ensure AD Integration is Enabled

Permissions Reporter queries Active Directory to determine account status. Verify that:

• The application is running with appropriate AD read permissions
• Domain connectivity is available
• Group expansion is enabled to resolve nested memberships

Step 2: Run a Permissions Scan

1. Create a new project or open an existing one
2. Add the file server paths you want to audit
3. Run the permissions scan
4. Wait for the scan to complete

Step 3: Apply the Disabled Accounts 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 "Permissions referencing disabled accounts" from the quick filter menu
5. Click Apply to filter the results

How it works: Permissions Reporter checks each permission's associated account against Active Directory. Accounts with the "Account Disabled" flag set are identified and can be filtered.

Step 4: Review and Export Results

The filtered results show:

• The disabled account name
• The folder or file path
• The permission type (Allow/Deny)
• The access rights granted
• Whether the permission is inherited or explicit

Export the results for remediation planning and compliance documentation.

Remediation Approaches

Individual User Cleanup (Offboarding)

For individual departures, filter to the specific user and remove their permissions:

# PowerShell: Remove a specific disabled user's permissions
$disabledUser = "DOMAIN\jsmith"
$paths = @("\\FileServer\Shared", "\\FileServer\Department")

foreach ($path in $paths) {
    Get-ChildItem -Path $path -Recurse -Directory | ForEach-Object {
        $acl = Get-Acl $_.FullName
        $rulesToRemove = $acl.Access | Where-Object {
            $_.IdentityReference.Value -eq $disabledUser
        }
        foreach ($rule in $rulesToRemove) {
            $acl.RemoveAccessRule($rule)
        }
        if ($rulesToRemove) {
            Set-Acl $_.FullName $acl
            Write-Host "Removed permissions from: $($_.FullName)"
        }
    }
}

Bulk Cleanup (Periodic Maintenance)

For periodic cleanup of all disabled account permissions:

1. Export the list from Permissions Reporter
2. Verify with HR that listed accounts are truly terminated
3. Document current state for audit trail
4. Remove permissions systematically
5. Verify removal with a follow-up scan

Best practice: Perform bulk cleanup quarterly, but integrate individual cleanup into your standard offboarding checklist for immediate action on departures.

Handle File Ownership

Before removing permissions, address file ownership:

• Identify owned files - Use the Owner Report to find files owned by the disabled user
• Transfer ownership - Assign to the user's manager or department head
• Archive if needed - Move personal files to an archive location
• Then remove permissions - After ownership is transferred

Building a Better Offboarding Process

Recommended Workflow

1. Before last day: Run Permissions Reporter filtered to the departing user to document their current access
2. On last day: Disable the AD account (standard procedure)
3. Within 24 hours: Transfer file ownership to manager
4. Within 7 days: Remove explicit permissions from file systems
5. Within 30 days: Remove from security groups (if not done immediately)
6. Document: Export before/after reports as evidence

Automation Opportunities

Use Permissions Reporter's automation features to support offboarding:

• Scheduled scans - Weekly scans to catch missed departures
• Email reports - Automatic notification of disabled account permissions
• Command-line integration - Trigger scans from HR system workflows
• XML export - Feed data into security orchestration tools

Special Considerations

Service Accounts

Be careful with accounts that appear disabled but serve a purpose:

• Some service accounts are disabled for interactive logon but used for scheduled tasks
• Legacy application accounts may have unusual configurations
• Verify with application owners before removing permissions

Accounts on Leave

Employees on extended leave may have disabled accounts:

• Maternity/paternity leave
• Medical leave
• Sabbaticals

Coordinate with HR to distinguish between temporary disablement and permanent termination.

Litigation Hold

If a departed employee is involved in litigation:

• Do not remove permissions without legal approval
• Document current access as part of discovery
• Permissions Reporter exports may be required as evidence

Related Resources

• Finding Orphaned SIDs and Deleted Accounts
• Principals Report - View permissions by user
• File Owner Report - Find files owned by specific users
• Advanced Filtering - Create custom filters
• NTFS Security & Compliance FAQ