SMB working-user vs failing-user access comparison

Good For

• one user can open an SMB share while another cannot

• nested AD group troubleshooting

• Kerberos and cached-credential comparison

• share versus NTFS permission conflicts

• avoiding direct-user ACL shortcuts

How to Use It

1. Confirm UserA and UserB are testing the same UNC path from comparable client/network context and record the exact failing error.

2. Capture the identity actually presented in each session with whoami, including SID and token groups; do not assume current AD membership equals the current logon token.

3. Compare direct and nested AD group membership and whether the expected access group is present in each user's token.

4. Capture Kerberos ticket context with the read-only klist command plus cached credential targets for both sessions and look for different CIFS tickets, alternate credentials, stale sessions, or name/IP variants.

5. Capture SMB share permissions and NTFS ACLs on the file server, including ownership and inheritance protection.

6. Trace relevant allow/deny entries through nested groups and inheritance and identify the first authorization difference between the working and failing paths.

7. Use approved effective-access calculation only as corroborating evidence; do not substitute it for token and ACL comparison.

8. Repair the group-based permission or token model rather than granting the failing user directly, then retest both users.

Execution Modes

• local
• remote-single-host

Inputs and Outputs

Inputs

• working user
• failing user
• UNC share path
• file server
• expected access group
• directory read access

Outputs

• verbose-console
• operator-notes

Command Starter

whoami /user
whoami /groups

Get-SmbShareAccess -Name '<SHARE_NAME>'
Get-Acl -Path '<SHARE_PATH>' | Format-List Owner,AccessToString,AreAccessRulesProtected
Get-ADPrincipalGroupMembership -Identity '<USER_SAMACCOUNTNAME>' | Select-Object Name,DistinguishedName | Sort-Object Name

Validation

• The working and failing sessions identify the actual user SID and current token groups.

• Relevant nested groups, Kerberos/cached-credential context, SMB share ACL, NTFS ACL, and inheritance are captured.

• The first authorization delta between UserA and UserB is explicitly named.

• No direct-user ACE is added merely to make the incident disappear.

• Both the repaired user and the known-good user are retested.

Reporting

• Record a two-column UserA/UserB comparison for identity, token groups, CIFS ticket context, and ACL path.

• State the first differing authorization condition and the evidence supporting it.

• Attach before/after results to the ticket or access review.

Safety Notes

• This workflow is read-only until a separately approved remediation step.

• Do not add the failing user directly to share or NTFS permissions as a shortcut.

• Do not purge Kerberos tickets or cached credentials until their existing state is captured and the action is justified.