Find orphaned SIDs and Everyone permissions on Windows file servers

What this is about: orphaned SIDs, broad groups, hidden exceptions

Windows does not store names in the access lists of folders but security identifiers (SIDs). Every account and group gets its own SID when it is created, and Windows never issues the same SID again – not even to a new account with the same name. When an account is deleted, its entries remain in the NTFS permissions. Windows can no longer find a name for them and shows Account Unknown followed by the SID, for example S-1-5-21-…-1107: an orphaned SID. Not every SID without a name is orphaned, though – see Not every SID without a name is orphaned.

Broad groups are groups that contain practically everyone. Their SIDs are fixed or end in a fixed number:

• Everyone: S-1-1-0 – all users
• Authenticated Users: S-1-5-11 – all authenticated users and computers, including those from trusted domains
• Domain Users: S-1-5-21-…-513 – every user account in the domain; new accounts are added automatically
• BUILTIN\Users: S-1-5-32-545 – after installation it contains just Authenticated Users

If one of these groups can write or modify, or has full control, practically every signed-in person can create, change or delete files there – and so can any malware running under their account. Two more patterns make a review hard: inheritance broken deep in the folder tree – such exceptions are invisible from above – and rights given directly to individual people instead of groups. Microsoft recommends granting access through groups, so that a move to another department only changes a group membership.

Typical occasions: a file server that has grown over the years is to be cleaned up or migrated, or an access review is due – internally or ahead of an audit, for example under ISO/IEC 27001.

Not every SID without a name is orphaned

Unknown at first only means that Windows has not found a name for this SID right now. There are reasons for that where the account still exists, or is not a user account at all:

• Capability SIDs (S-1-15-3-…)

  Since Windows 8 and Windows Server 2012, capabilities let Windows components and apps access resources, and each capability has its own SID. By design these SIDs have no friendly name. Microsoft explicitly advises against deleting them from file system or registry permissions: features may no longer work correctly, and they cannot be added back through the user interface. Known ones are listed under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities.

• Domain controller not reachable

  If a network time-out prevents the name lookup, the SID also appears without a name – although the account exists.

• Accounts from other domains

  SIDs that the own domain does not recognise are looked up in trusted domains. If the trust is broken or the other domain cannot be reached, no name comes back.

• Migrated accounts

  An account that moves to another domain gets a new SID; the old one can be kept in the account’s SID history and then still grants access. Windows can look up such old SIDs in every domain of the forest and then shows the migrated account’s name; if the responsible domain cannot be reached, no name comes back. So before deleting a SID from a former domain, check whether a migrated account still carries it – otherwise you take rights away from it.

• Logon sessions

  SIDs of a logon session (S-1-5-5-…) never have an account name.

Genuinely orphaned SIDs usually grant nobody access any more, because Windows never reuses a SID. They are still a finding: nobody can tell any longer whom the right was once given to. Deleting entries that only look orphaned is the bigger risk. A first clue is the domain part – everything before the last number of a SID such as S-1-5-21-…-1107. Signed in with a domain account, whoami /user shows your own SID: if its domain part matches that of the unknown entry, the entry comes from your domain.

In Explorer: Security and Effective Access

For a single folder, the built-in tools are enough. Properties › Security shows the NTFS permissions, and Advanced lists the entries one by one. The Effective Access tab works out what a selected person or group may do with this folder; rights granted to Everyone and Authenticated Users are included. Orphaned SIDs appear there as a SID without a name – whether such a SID really is orphaned is covered in Not every SID without a name is orphaned.

The limits: Explorer shows one folder – and, for effective access, one person – at a time. Share permissions sit separately under Sharing › Advanced Sharing. There is no list across the whole folder tree, no export and no comparison with the last check. Fine for spot checks, not for a file server with thousands of folders.

icacls: search a whole folder tree for a SID

icacls displays and changes access lists from the command prompt; icacls D:\Data\Project shows the list of a single folder. To search a whole tree there is /findsid, which finds every file and folder whose access list explicitly mentions the given SID. A SID in numeric form needs a leading *:

• icacls D:\Data\* /findsid *S-1-1-0 /t /c – every file and folder under D:\Data whose access list contains Everyone
• icacls D:\Data\* /findsid *S-1-5-11 /t /c – the same for Authenticated Users
• icacls D:\Data\* /findsid *S-1-5-21-…-1107 /t /c – where a particular orphaned SID is still listed
• icacls D:\Data\* /verify /t /c – access lists that are not canonical

/t includes all subfolders, and /c carries on after errors such as access denied while still showing them. Canonical means explicit denies before explicit allows, followed by the inherited entries – in a different order, Windows may grant something other than the entries seem to promise.

The limits: /findsid tells you where a SID appears, not which right it has there; whether Everyone can only read or also write is shown by the list of that one folder. icacls cannot search for orphaned SIDs in general, only for a SID you already know. It knows nothing about group memberships or share permissions, and on large shares the search can take a long time.

PowerShell: every entry as a list for Excel

A short PowerShell script produces a complete list you can filter in Excel. An example for Windows PowerShell 5.1 that writes every entry of every subfolder of D:\Data as a row in a CSV file:

Get-ChildItem -LiteralPath D:\Data -Directory -Recurse | ForEach-Object { $p = $_.FullName; (Get-Acl -LiteralPath $p).Access | Select-Object @{Name="Path";Expression={$p}}, IdentityReference, FileSystemRights, AccessControlType, IsInherited } | Export-Csv D:\Reports\permissions.csv -NoTypeInformation -Encoding UTF8 -UseCulture

-Encoding UTF8 keeps accented characters in paths and names intact – Windows PowerShell 5.1 otherwise writes ASCII – and -UseCulture separates the columns with the list separator of the regional settings. In Excel, filter IdentityReference for the broad groups and FileSystemRights for values such as FullControl, Modify or Write. Entries that show S-1-5-21-… instead of a name are candidates for orphaned SIDs; IsInherited separates explicit entries from inherited ones. Check the starting folder itself with (Get-Acl -LiteralPath D:\Data).Access.

Broken inheritance shows up in the AreAccessRulesProtected property: it is True when a folder does not take over rights from its parent. This lists all such folders: Get-ChildItem -LiteralPath D:\Data -Directory -Recurse | Where-Object { (Get-Acl -LiteralPath $_.FullName).AreAccessRulesProtected } | Select-Object FullName. The permissions of a share are read by Get-SmbShareAccess -Name Data -CimSession FS01 – usually with administrator rights on the server.

Where scripts stop: Get-Acl returns entries, not effective permissions. Windows checks the entries in order until a deny or a sufficient allow applies; who belongs through nested groups, what deny entries take away and how share and NTFS permissions combine is not worked out by the script. Folders the scanning account cannot read end up as error messages in the console rather than as rows in the list. Paths longer than 260 characters only work in programs prepared for them. And every run starts from scratch: the comparison with last time and evidence to sign off are up to you.

Share and NTFS permissions: Everyone with Full Control on the share

A file server has two independent sets of permissions: those of the share and the NTFS permissions of the folders. Over the network, the more restrictive of the two applies. For anyone working on the server locally or through Remote Desktop, only the NTFS permissions count.

Everyone with Full Control on the share is therefore not a mistake in itself. Microsoft describes this approach explicitly: some administrators always set the share to Full Control for Everyone and control access through NTFS alone. Then, however, the NTFS permissions have to be right – Everyone with write access in NTFS is the real finding. Conversely, a strict share can limit generous NTFS permissions: if you only check NTFS, you see more access than is possible over the network.

Cleaning up: back up first, then change with care

Finding is one thing, changing another – a change can take away access that is still needed. A careful sequence:

• Back up: icacls D:\Data\* /save D:\Backup\acl-data.txt /t /c saves the access lists of all files and folders under D:\Data – not the folder D:\Data itself. icacls D:\Data\ /restore D:\Backup\acl-data.txt writes them back – overwriting any later changes as well.
• Clarify: is the SID really orphaned – or a capability SID, an account from another domain, a migrated account? Leave the permissions of Windows system folders alone.
• Change at the source: inherited entries come from a parent folder and are removed where they are set explicitly – in Explorer, or with icacls D:\Data\Project /remove *S-1-5-21-…-1107, which removes all entries for this SID from the folder’s access list.
• Replace broad groups: instead of Everyone or Domain Users, grant access to a group that contains exactly the people responsible.
• Check: review again afterwards and compare with the state before.

Important: /remove, /restore and changes in Explorer take effect immediately. Try commands that change permissions in a test environment or on a copy first, and change production shares only with a backup and in an agreed time window. A permissions report such as Zutritt changes nothing itself – it provides the findings beforehand and the comparison afterwards.

Zutritt: orphaned SIDs and broad groups in a permissions report

Zutritt is our permissions report for Windows file shares. It reads the share and NTFS permissions of a share, a whole server or local folders, resolves groups down to individual people and computes effective permissions like Windows – with the stored order of the entries, deny entries, inheritance, and share and NTFS combined. 15 rules report what this guide is looking for, each with an explanation and a recommendation:

• Orphaned SID (ZT04)

  Entries, owners and share permissions whose account no longer exists – but only when the responsible account database was reachable and does not know the SID. Otherwise the result is Unknown. Capability SIDs, app packages, service SIDs and logon sessions are never treated as orphaned.

• Broad group can write or read (ZT01, ZT02)

  Everyone, Authenticated Users, Domain Users and similar groups with write access (high) or read access (medium) – reported on the folder where the entry is set, with the right that remains after deny entries.

• Hidden exceptions and moved folders (ZT06, ZT14)

  Inheritance broken deep in the tree – from level 3 below the scanned target, adjustable – and folders that carried their old inherited rights along when they were moved.

• People, disabled accounts, full control (ZT03, ZT12, ZT05)

  Rights given directly to a person instead of a group, rights of disabled accounts and full control for accounts and groups without an administrator role.

• Who can get in here, and shares open to everyone (ZT08)

  The folder view “who can get in here” shows every person with their effective right over share and NTFS. Everyone or Authenticated Users with at least Change on the share is reported as information only.

• Excel, PDF and comparison

  A filterable Excel workbook with every entry, a PDF with a sign-off block and the comparison with the last run: new and resolved findings, and who can now access more or less. Anything that could not be read appears as a finding in the report instead of silently missing.

Zutritt only reads: it changes no permissions, files or accounts and needs no server, agent or service. When in doubt, it shows more access rather than less. A command line with exit codes serves scheduled runs.

Honestly: Zutritt is a pre-release (0.1.2) and not code-signed yet – SmartScreen may warn. It runs on Windows 10 version 1809 or later and Windows 11 (x64). It resolves Active Directory only for the scanning PC’s own domain; groups from trusted domains are named but not expanded, and the resolution has so far been tested against a simulated directory only, not yet in a real domain. Share permissions can only be read with administrator rights on the server; otherwise Zutritt works from NTFS alone. Zutritt does not monitor continuously but runs on demand or as a scheduled task. Zutritt is free of charge under the MIT licence. The download follows with the public release.

Our product

Zutritt – Share and NTFS permissions report

Share and NTFS permissions down to each person, 15 rules from orphaned SIDs to Everyone can write, Excel and PDF to sign off – read-only, for Windows 10 and 11.

Status: Coming soon · Coming soon

More about Zutritt Comparison with other permission reports

The options compared

Over the network, the more restrictive of share and NTFS permission applies. “By hand” means possible, but with your own effort, such as comparing two exports. Zutritt resolves Active Directory only for the scanning PC’s own domain and has so far been tested against a simulated directory only.

Which option fits when?

• One folder, one question

  Explorer: Security, Advanced and Effective Access.

• Where is Everyone – or a particular SID – listed?

  icacls … /findsid … /t /c across the whole tree, then check the right in the individual folder.

• Every entry as a list to filter

  A PowerShell script with Get-Acl and Export-Csv – or a permissions report that delivers the list ready-made.

• A recurring access review with evidence

  A permissions report with effective permissions, a comparison with the last run and a PDF to sign off, such as Zutritt.

• The SID starts with S-1-15-3

  A Windows capability SID: do not remove it.

• Cleaning up

  First icacls … /save, then clarify each finding and change it at the source – a report changes nothing itself.