icacls command with the /remove flag and the specific Security Identifier (SID) instead of the username. This approach bypasses the need for Active Directory resolution, allowing you to clean up orphaned access control entries directly through the command line or PowerShell on Windows systems.
Understanding Orphaned Permissions
When a user account is deleted from a domain or local machine, the files they owned or had access to retain the original Access Control Entry (ACE). The operating system cannot resolve the username because the account no longer exists in the directory service. Consequently, standard graphical tools often display the SID as a string of numbers and letters, or simply fail to load the permission dialog because the identity is unresolvable.
This situation creates "orphaned" permissions that clutter your security settings and can complicate auditing processes. While you might see warnings about inaccessible accounts when browsing properties, the underlying issue is that the ACL (Access Control List) still references an invalid principal. Removing these entries requires addressing the unique identifier rather than the human-readable name.
Identifying the Problematic SID
The first step is to identify the exact Security Identifier associated with the deleted user. You can view this information using the icacls tool from the command prompt. Navigate to the affected directory and run the following command to list all permissions:
icacls "C:\Path\To\Folder" /T /QLook for entries that resemble S-1-5-21-... followed by a long numeric string. These are the SIDs of the deleted users. If you have many files, the output will be extensive, so it helps to filter the results. You can use PowerShell to extract only the lines containing the specific SID pattern if you know part of the identifier. Alternatively, check the Event Viewer under Security logs for events related to denied access, which may sometimes provide context, though direct inspection of the ACL is more reliable.
Removing Permissions via Command Line
Once you have identified the SID, you can use the icacls command to remove the ACE. The syntax requires specifying the target path, the /remove parameter, and the SID itself. It is crucial to use the full SID string without any prefixes like DOMAIN\ since the domain reference is invalid for a deleted account.
icacls "C:\Path\To\Folder" /T /remove S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXIn this command, /T ensures that the operation applies recursively to all subdirectories and files within the specified folder. The /remove flag tells icacls to delete the matching ACE entirely. If you do not use /T, only the top-level folder's permissions will be updated, leaving the rest of the structure with the orphaned entries. Always test this on a non-critical folder first to ensure the syntax works correctly for your environment.
PowerShell Alternative
For administrators who prefer scripting or need to handle multiple folders, PowerShell offers a robust alternative using the Get-Acl and Set-Acl cmdlets. However, manipulating ACLs programmatically requires loading the existing ACL, removing the specific access rule, and then applying the modified ACL back to the object. This method is more verbose but provides greater control over error handling and logging.
You can retrieve the ACL for a file, iterate through the access rules, find the one matching the orphaned SID, remove it from the collection, and then save the changes. This approach is particularly useful when you need to audit the changes before committing them or when dealing with complex inheritance scenarios that icacls might handle differently. For more details on managing permissions across different environments, consider reviewing our guide on NTFS Permissions on Multi-OS Volumes.
Verifying the Cleanup
After executing the removal command, verify that the orphaned permissions have been successfully deleted. Run the icacls command again on the same directory and confirm that the SID no longer appears in the output. If the entry persists, it is possible that the file has additional hardlinks or that the change was not applied recursively due to permission errors on specific subfolders.
If you encounter issues where files appear locked or inaccessible during the cleanup process, it may be due to other services holding handles to those files. In such cases, refer to resources on resolving folder in use errors to ensure that no background processes are interfering with the permission modification. Successful removal should result in clean ACLs that only contain active, resolvable user accounts and groups.
Frequently Asked Questions
Why does the GUI show a long number string instead of a name?
The graphical interface displays the raw Security Identifier (SID) because it cannot resolve the username to a known account in Active Directory or the local SAM database. This happens automatically when the linked user object is deleted, leaving the permission entry orphaned. You must use the SID string to manage these permissions effectively.
Can I remove orphaned permissions using the Properties dialog?
While you can open the Security tab in the Properties dialog, editing these entries is often difficult or impossible because the UI expects a resolvable identity. Attempting to edit the field may result in errors or require manual SID entry, which is prone to typos. Using the command line is the recommended and more reliable method for bulk removal.
What happens if I remove the wrong SID?
Removing an incorrect SID will revoke access for the corresponding user or group, potentially causing legitimate users to lose permissions to critical files. Always double-check the SID against your records or event logs before executing the remove command. It is advisable to take a backup of the ACL using icacls /save before making widespread changes.
Does this fix apply to shared network folders?
Yes, the icacls command modifies the underlying NTFS permissions, which are separate from Share permissions. Removing an orphaned NTFS entry will clean up the security descriptor regardless of whether the folder is shared. However, you should also check Share permissions to ensure there are no conflicting access rules at the network level.
How do I restore permissions after accidental deletion?
If you accidentally remove valid permissions, you can restore them from a backup created with icacls /save. Use the icacls /restore command with the backup file to revert the ACLs to their previous state. Without a backup, you may need to manually re-add the correct users or reset permissions to inherit from the parent directory.