OSITC.006: Windows Users, Groups, and Permissions

Elementary Overview

Windows access control answers a simple operational question: who is allowed to do what? A technician needs to distinguish user identity, group membership, administrator elevation, file permissions, ownership, and user rights instead of treating every “Access denied” message as the same problem.

This lesson follows OSITC.005: Windows Services Fundamentals. Services often run under specific accounts, inherit permissions from those identities, and fail when the account cannot read a file, bind a resource, access a share, or perform a required local right.

The same access-control evidence also appears in OSITC.004: Windows Event Viewer Fundamentals, where failed logons, privilege use, and object-access events can help explain why a task did or did not succeed.

Authentication And Authorization Are Different

Authentication proves an identity. Authorization determines what that identity may access after it has signed in.

Microsoft’s Access Control Overview describes Windows access control through permissions, ownership, inheritance, user rights, and auditing. A user can authenticate successfully and still be denied access to a file, service, registry key, printer, or administrative operation.

Local Accounts Are Security Principals On One Device

A local Windows account is defined by the local computer itself. Microsoft’s Local Accounts documentation explains that local accounts have rights and permissions on that device and are represented internally by security identifiers.

Useful management tools include Settings, Computer Management, Local Users and Groups where available, PowerShell, and command-line utilities. In managed business environments, accounts may instead come from Active Directory or Microsoft Entra-backed sign-in models, but the local operating system still evaluates security tokens, groups, privileges, and ACLs when authorizing access.

Standard User And Administrator Are Not The Same Thing

A standard user should be able to perform ordinary work without receiving unrestricted control over the computer. An account in the local Administrators group has broader rights, but Windows does not simply run every process from that account at full administrative privilege all the time.

Microsoft recommends limiting membership in the Administrators group because administrator rights increase the impact of mistakes and malicious software. This is the practical meaning of least privilege: provide the minimum access required for the task.

User Account Control Separates Normal Work From Elevation

User Account Control, or UAC, is the Windows mechanism that prompts when an operation requires administrator-level permission. Microsoft’s UAC overview explains that applications normally run with standard permissions and can request elevated rights when required.

An administrator account can therefore have two practical security contexts: its normal user token and an elevated administrator token. Approving a UAC prompt allows the selected process to run with higher privilege; it does not permanently elevate every process in the session.

MDTechVideos — walkthrough of Windows UAC settings. This lesson follows Microsoft’s security guidance and does not recommend disabling UAC as a routine troubleshooting shortcut.

Administrator Protection Pushes Privilege Separation Further

Newer Windows development has continued moving toward stronger separation between ordinary work and administrative actions. Windows Insider builds have tested Administrator Protection, which creates a more isolated just-in-time elevation model rather than treating an administrator session as broadly privileged.

The social post below is a Windows Insider community example showing the feature under test. Treat it as implementation context rather than a substitute for Microsoft documentation because Insider behavior can change before broad release.

To try out the feature yourself, enable these IDs:45172197 (ShadowAdmin)51406324 (AdminlessConsumerConfig)The taskmgr changes for administrator protection can be enabled with additional IDs: 46471475, 56508991
— phantomofearth 🌳 (@phantomofearth.bsky.social) 2025-06-28T16:44:35.171Z

Windows Insider community example — Administrator Protection testing in Windows 11 Insider builds.

Groups Simplify Permission Management

Permissions should usually be assigned to groups rather than individually to every user. Microsoft’s access-control guidance recommends group-based assignment because users can inherit access by group membership and administrators can change one membership instead of editing many objects.

Common local groups include Administrators, Users, Remote Desktop Users, Backup Operators, and other built-in groups. Membership matters because the user’s access token contains group SIDs that Windows compares with permissions on protected objects.

SIDs Identify Security Principals

A Security Identifier, or SID, uniquely identifies a Windows security principal such as a user or group. Display names can change; the SID is what Windows uses internally to associate permissions with that principal.

That is why a deleted user can sometimes leave an ACL entry that displays as a raw SID instead of a friendly name. The permission still references the old identifier even though Windows can no longer resolve it to an existing account.

Use whoami To Inspect The Current Security Context

The whoami command can show the current user, groups, privileges, and SID information. A strong technician checks the actual token instead of assuming which identity the process is using.

whoami
whoami /user
whoami /groups
whoami /priv
whoami /all

Microsoft’s whoami documentation describes these switches. When troubleshooting a service, scheduled task, remote session, or elevated terminal, compare the actual identity and group memberships before changing permissions.

NTFS Permissions Are Stored In ACLs

Files and folders on NTFS can carry an Access Control List. The discretionary portion, or DACL, contains access-control entries that allow or deny rights to specific users or groups.

Common simplified NTFS permissions include:

Full control — broad control, including changing permissions.
Modify — read, write, execute, and delete without all permission-management rights.
Read & execute — read files and execute permitted programs.
Read — view file or folder data where applicable.
Write — create or change data where permitted.

Advanced permissions break these into more granular rights. Do not assume the simplified checkbox view tells the entire story when inheritance, ownership, explicit deny entries, or multiple groups are involved.

Eli the Computer Guy — foundational Windows file and NTFS permission concepts, including users, groups, shares, inheritance, and effective access.

Inheritance Explains Many Permission Surprises

A child file or folder can inherit permissions from its parent container. This makes large directory trees manageable, but it also creates one of the most common technician mistakes: editing a child object without realizing the permission is inherited from above.

Before changing an ACL, identify which entries are explicit and which are inherited. If the design is wrong at the parent, fixing one child may only create an exception that becomes difficult to maintain.

Ownership Is Not The Same As Permission

The owner of an object has special authority over its permissions, but ownership does not mean every possible data operation is automatically allowed in every context. Administrators can sometimes take ownership to recover control of an object, but that action changes security state and should be documented.

Do not take ownership as the first response to every Access Denied message. First determine why access was denied and whether the current ACL is intentional.

Use icacls To Inspect And Manage ACLs

Microsoft’s icacls documentation identifies icacls as the current command-line utility for displaying and modifying file and folder DACLs. The older cacls utility is deprecated.

icacls "C:\Data"
icacls "C:\Data\Report.txt"
icacls "C:\Data" /verify

For a lab folder, a technician may also inspect inheritance or grant a controlled permission after confirming the intended account:

icacls "C:\Lab" /grant LabUser:(RX)
icacls "C:\Lab" /inheritancelevel:e

These are examples, not commands to run blindly against production paths. Before modifying permissions, capture the existing ACL, confirm the intended security model, and understand whether subfolders should inherit the change.

Explicit Deny Requires Care

An explicit Deny entry can override an Allow that would otherwise be obtained through another group. Deny entries are useful in some designs, but they can make troubleshooting more difficult because a user may appear to belong to an allowed group and still be denied.

Prefer clean group design and targeted Allow permissions when possible. Use Deny intentionally, not as a quick repair for confusing permissions.

Share Permissions And NTFS Permissions Are Separate Layers

When a folder is accessed over a Windows file share, share permissions and NTFS permissions can both affect access. A user who has broad NTFS rights but restrictive share rights may still be blocked over the network.

Always ask whether the user is accessing the path locally, through a UNC path such as \\SERVER\Share, through an application, or through a service account. The access path changes which control layers apply.

User Rights Are Different From Object Permissions

Windows user rights authorize system-level actions such as signing in locally, signing in through Remote Desktop, backing up files, or shutting down the system. These are different from permissions on files and folders.

This distinction matters during troubleshooting. A user may have Full Control on a folder but still lack the user right needed to log on through a specific method or perform a protected operating-system action.

Effective Access Comes From Multiple Inputs

A user’s effective access can result from direct permissions, several group memberships, inherited entries, explicit entries, deny entries, ownership, user rights, UAC elevation state, and whether the resource is local or remote.

That is why “just add Full Control” is poor troubleshooting. It may hide the real cause, create excessive privilege, and make the system harder to secure later.

Troubleshoot Access Denied In A Fixed Order

Identify the exact resource and operation that failed.
Identify the exact user or service account performing the operation.
Use whoami /all or equivalent evidence to confirm the current security context.
Check relevant group memberships.
Determine whether UAC elevation is required.
Inspect the object’s owner and ACL.
Separate explicit entries from inherited entries.
Look for deny entries and conflicting group membership.
If the resource is remote, inspect share permissions as well as NTFS permissions.
Check whether a required user right or service logon right is missing.
Review Event Viewer when auditing or logon failures provide useful evidence.
Change only the permission that the approved access model requires.
Retest using the original user and original access path.
Document the final change.

Technician Pattern Recognition

User can open a folder but cannot save: inspect Modify/Write permissions rather than assuming complete access failure.
Administrator still receives Access Denied: check whether the process is elevated, whether the ACL contains a deny, and whether ownership or another protected control applies.
Local access works but network share fails: inspect share permissions, network identity, and remote-access policy in addition to NTFS.
Permission change on parent unexpectedly affects many folders: inspect inheritance scope before changing anything else.
User appears twice in effective access through different groups: evaluate all group SIDs and any deny entries.
Service starts manually as administrator but fails at boot: inspect the service account’s file permissions, user rights, dependencies, and environment rather than granting administrator rights to the service.
ACL shows an unresolved SID: determine whether the referenced account was deleted or is temporarily unavailable before removing the entry.

Exercises

Create a lab standard user and explain why it should not automatically be added to Administrators.
Run whoami /user, whoami /groups, and whoami /priv in a lab and explain the difference between the outputs.
Use icacls to display the ACL on a test folder. Identify inherited versus explicit entries.
Describe what happens if a user receives Allow through one group and an applicable explicit Deny through another entry.
Explain why taking ownership should not be the first troubleshooting step.
Design a group-based permission model for a shared Finance folder where Finance staff can modify files and other employees have no access.
Describe how you would troubleshoot a service that can read its configuration file when started interactively but cannot read it when running under its configured service account.

Knowledge Check + Answers

What is authentication? Proving an identity.
What is authorization? Determining what an authenticated identity is allowed to access or perform.
What is a SID? A Security Identifier that uniquely identifies a Windows security principal.
What does UAC do? It separates normal execution from administrator-level elevation and prompts when higher privilege is requested.
What is a DACL? The portion of an access-control list that contains allow and deny entries controlling access to an object.
What does inheritance do? It allows child objects to receive access-control entries from a parent container.
Why use groups for permissions? Group-based assignment scales better and is easier to manage than changing every user individually.
What Windows command replaces the deprecated cacls utility? icacls.
Are user rights and file permissions the same? No. User rights authorize system-level actions; file permissions control access to objects.
Why can an administrator account still receive Access Denied? The process may not be elevated, the ACL may contain a deny, ownership may matter, or another security control may apply.

Prior Lessons And Primary References

Elementary Conclusion

Windows permissions make sense when you separate identity from access. First establish who the process is running as. Then inspect its groups, elevation state, object permissions, inheritance, ownership, share permissions, and required user rights. Tools such as whoami, icacls, Event Viewer, Computer Management, and the Windows security UI let a technician replace guesswork with evidence. The goal is not to make every Access Denied message disappear by granting administrator rights. The goal is to give the correct identity exactly the access it needs and no more.

BitcoinVersus.Tech

BitcoinVersus.Tech publishes open technical education across Windows, Linux, networking, data centers, electrical systems, programming, semiconductors, robotics, fiber optics, and firmware.

Editor’s Note

Permissions, group policy, domain membership, administrator protection, service identities, share access, auditing, and UAC behavior vary by Windows edition, management environment, and security policy. Follow current Microsoft documentation and approved organizational access-control procedures before changing production permissions.

BitcoinVersus.tech is not a financial advisor. Content is provided for informational purposes.