User
The person
The user account should identify the employee. Avoid sprinkling one-off permissions directly onto the user unless there is a documented reason.
Everyday IT · Groups & Permissions
Give access without creating a mess.
This is the authorization side of the identity boundary: group-based access, NTFS and share permission layers, Effective Access, inherited ACLs, token refresh, and access-denied troubleshooting.User → Group → Access
The permission model to remember
When access is role-based, onboarding, offboarding, and troubleshooting all become easier.
Group
The role or access set
A security group represents something useful: Accounting Share Read/Write, HR Folder Access, VPN Users, or Printer Floor 2.
Access
The resource
The group is granted access to the folder, application, SharePoint site, printer, or other resource. Add and remove users at the group level.
If you cannot explain why a user has access, the permission design is already getting too complicated.
Security groups vs distribution lists
These are not interchangeable even when their names look similar.
Security group
Used to authorize access
Security groups can be used for permissions and, depending on configuration, may also be mail-enabled. Think access first.
Distribution list
Used to distribute email
Distribution lists are primarily mail-routing objects. Membership on a distribution list does not automatically grant file, SharePoint, application, or Windows access.
Common mistake
Similar name, different job
Do not assume a group called Accounting gives file access just because it receives accounting email. Check the group type and where it is actually used.
Adding access the safe way
Match the employee's role and verify what the group actually grants.
01
Find a comparable employee
Look at a known-good user with the same role. Use their group membership as evidence, not as an automatic copy list.
02
Identify the group purpose
Before adding the user, understand whether the group grants a folder, printer, VPN, application, SharePoint, mailbox, or privileged resource.
03
Add only what belongs to the role
Skip temporary project groups, administrative groups, legacy access, and anything you cannot explain.
04
Verify from the user's side
Test the resource the user actually needs. Do not stop at “the group membership looks right.”
NTFS vs share permissions, simplified
Windows file access commonly has two permission layers.
Share permission
Controls access through the network share
Share permissions apply when users reach the folder over the network. They are one gate.
NTFS permission
Controls file-system access
NTFS permissions apply to folders and files themselves. They usually provide the more detailed access model.
Effective result
The user gets the most restrictive combination
A generous share permission does not override restrictive NTFS permissions, and vice versa. Check both when troubleshooting network access.
Quick “Access Denied” logic
Do not start changing ACLs until you know which layer is failing.
Question 1
Does everyone fail or one user?
If everyone fails, suspect the resource, server, share, network path, or a broad permission change. If one user fails, compare that user's membership and effective access.
Question 2
Can the user reach the path?
If the path cannot be reached at all, solve connectivity, DNS, VPN, or server availability before permissions.
Question 3
Is the right group present?
Compare with a working peer and verify the user is in the correct role-based group. Remember that tokens and sessions may need refresh after membership changes.
Question 4
Is there an explicit deny or unusual inheritance?
Denies, broken inheritance, nested groups, and old direct ACL entries can complicate the result. Escalate before redesigning permissions on a production share.
Prove access before changing the design
Membership and effective access are related, but they are not the same test.
Effective Access
Test an approved and unapproved user
Use Windows Effective Access or another approved method to verify what the user actually receives from direct, inherited, and group-based permissions.
Token refresh
New group membership may not be visible yet
A user may need to sign out and back in, reconnect a session, or otherwise refresh the Windows access token before a new security-group membership is evaluated.
Mapped drives
A missing drive is not automatically a permission problem
First determine what the drive is supposed to map to and whether the direct path works. Troubleshoot mapped drives and file access
Inheritance
Preserve a known-good access path
If inheritance must change, add the approved access first, record the current ACL, and verify both allowed and denied users afterward.
What not to do casually
Permissions are easy to loosen and harder to untangle later.
Avoid
Giving Full Control to fix a ticket
Broad permissions can hide the actual problem while creating unnecessary risk.
Avoid
Direct user permissions everywhere
They make offboarding and audits harder and lead to permission sprawl.
Avoid
Changing inheritance on a large folder tree
This can affect thousands of objects. Understand the current design and impact before changing inheritance.
Avoid
Using privileged groups as shortcuts
Administrative membership should never be the answer to an ordinary access request.
Next Test
Let the result determine the next guide.
UNC path works
Access still fails or differs by action
Prove the identity, then test the SMB share and NTFS layers separately instead of changing both ACLs together. Find the failing permission layer
Group changed
Access is still denied
Refresh the user's token, prove the path, and check effective access before changing another group or ACL. Test access after a group change
Inheritance
The folder boundary must change
Preserve a known-good access path and a rollback record before changing inherited permissions. Restrict inheritance safely
Risk unclear
The change is broader than the ticket
Define the blast radius, approval, verification, and recovery path before acting. Plan the change and rollback
Authentication or authorization?
If the user cannot prove identity, start with sign-in. If the user can sign in but cannot reach the resource, stay with groups and permissions.
Authentication
The sign-in itself is failing
Directory source
Confirm the user and group structure
Routine access changes should be understandable and repeatable.
When permission sprawl, inherited access, privileged groups, or ACL redesign makes the path difficult to explain or risky to change, consider an independent permissions review.