Build a Read-Only SMB and NTFS Permission Evidence Report with PowerShell

Expected Outcome

A report shows the share and filesystem authorization layers for selected paths, identifies inherited/direct ACEs and ownership, and links identities to group evidence so a reviewer can investigate effective access safely.

Assumptions

• Read access to the selected SMB server/share configuration and NTFS ACLs

• An explicit small share/path scope

• Directory read permissions if resolving AD users/groups and nested membership

• An approved-access source if the goal is to compare actual ACLs with intended policy

Bill of Materials

• PowerShell ISE or Visual Studio Code with PowerShell extension

• Access to the file server

• CSV file handling capabilities

Build Steps

1. Inventory the SMB share layer

   Use Get-SmbShare and Get-SmbShareAccess for the selected shares to record share path, principals, access type, and rights. Do not change share permissions during discovery.

2. Collect NTFS ACL and inheritance evidence

   Use Get-Acl on the selected root and representative subpaths to record owner, IsProtected/inheritance state, principal, Allow/Deny, rights, inheritance flags, propagation flags, and whether each ACE is inherited.

3. Resolve identities and groups separately

   For relevant domain principals, resolve SID/name and direct/nested group membership using directory read operations. Preserve unresolved SIDs and lookup failures rather than discarding them.

4. Keep effective-access conclusions bounded

   Present share ACL, NTFS ACL, group/token evidence, and inheritance as separate layers. Do not claim the report alone proves UserX can access a file unless the user/token and both authorization layers are actually evaluated.

5. Seed one controlled permission difference

   In a disposable test folder/share, create an approved temporary group-based difference, run the collector, and confirm the expected ACE/inheritance/group evidence appears. Remove the test difference afterward.

6. Hand user-specific failures to the comparison workflow

   For a real case where one user works and another fails, use the SMB working-user vs failing-user access comparison workflow rather than adding a direct-user ACE.

Validation

• Share ACL and NTFS ACL are both present for each selected share/path

• Owner and inheritance protection/state are visible

• Domain identities are represented by stable identity/SID evidence where possible

• A seeded test ACE is detected and then disappears after cleanup

• The report does not auto-change ACLs

• The report does not equate raw ACL enumeration with proven effective user access

Troubleshooting

• Permission denied while collecting: record Unknown/AccessDenied and use an authorized read context rather than taking ownership

• Unresolved SID: preserve the SID and investigate directory/object lifecycle separately

• Unexpected access: compare the actual user token, nested groups, share ACL, NTFS ACL, cached credentials, and Kerberos context

Cleanup or Rollback

• Remove only the disposable test ACE/group created for validation

• Retain the evidence report if it is part of an access review

• Do not reset inheritance or ownership as cleanup unless the lab deliberately changed it

Next Improvements

• Schedule regular audits to maintain file share security.

• Implement a monitoring system for real-time permission changes.

• Consider automating the audit process with scheduled PowerShell scripts.