The Local Security Model: Who Can Do What

What is it?

Windows decides every 'is this allowed?' with a simple model. Each process runs with an access token — a badge that says which account it is and which groups that account belongs to (for example, Administrators or just Users). Each protected resource (a file, a registry key, a service) carries permissions saying which accounts or groups may do what. When a process tries an action, Windows compares the token against the resource's permissions and allows or denies it. Administrators can change the system; standard users can use it but not reconfigure it.

Why it matters

This one model explains every access decision on a Windows machine, and it is the reason least privilege works: if a user (and so every process they run) carries only a standard-user token, a mistake or a malicious program is confined to what a standard user can do. Understanding tokens and group membership is the basis of both administration and security on Windows.

Where you see it

In the User Account Control (UAC) prompt (which asks for elevation to an administrator token), in 'access denied' errors, in the Administrators vs Users groups, and in the permissions on any file, folder, key or service.

What normal looks like

Day-to-day work done under a standard-user token; administrative changes made deliberately, with an explicit elevation (a UAC prompt) to an administrator token only when needed. Most accounts are members of Users, not Administrators.

What suspicious looks like

For security: everyday accounts that are permanent members of Administrators, processes running with an administrator token that have no reason to, or elevation happening without a corresponding deliberate action. Broad, always-on privilege is the risk the model exists to limit.

How analysts investigate

By asking, for any action: what token did the process carry (which account, in which groups), and what did the resource permit? An 'access denied' is the model working; an unexpected success means the token had more privilege than it should — which points at group membership or an unnecessary elevation.

Common beginner mistakes

Running everyday work as an administrator 'to avoid prompts'. Then every process — including anything malicious that slips in — inherits an administrator token and can change the whole system. Standard-user by default is the entire point.
Thinking permissions are about the person at the keyboard. Windows checks the token the PROCESS carries — which is why a standard user's processes cannot make admin changes even though the same person could, after elevating, in an admin context.

At Aldar, a.hakim can open documents, run the browser and use business apps all day — but if they try to install a system-wide program or change a protected setting, Windows stops them with a prompt or an 'access denied'. That is not arbitrary: it is the local security model doing exactly its job. Every action a.hakim's programs attempt is checked against what a.hakim's account is allowed to do. Understanding how that check works turns 'Windows won't let me' from a mystery into something you can reason about.

How Windows decides what is allowed

A process carries an access token (account + group memberships). Each resource has permissions. Windows compares the two for every action — allow or deny.

   THE ACCESS DECISION

   Process (started by a.hakim)                Resource: C:\Windows\System32\drivers\etc\hosts
   +-----------------------------+            +-------------------------------------------+
   | ACCESS TOKEN                |            | PERMISSIONS                               |
   |  Account: ALDAR\a.hakim     |            |  Administrators : read + write            |
   |  Groups : Users            |  --check-> |  Users          : read only               |
   +-----------------------------+            +-------------------------------------------+
   Wants to WRITE the file.  Token is in 'Users' -> Users may only READ -> DENIED.
   (After a UAC elevation to an Administrators token, the same write would be ALLOWED.)

Windows matches the process's token (account + groups) against the resource's permissions. A standard-user token writing an admin-only file is denied; elevating to an administrator token changes the answer.

Two ideas make this work. First, privilege travels with the process, not the person: when a.hakim logs in, Windows builds an access token from their account and its group memberships, and every process they start carries a copy of that token. So what a program may do is decided by the token it holds. Second, elevation is deliberate and temporary: because a.hakim works under a standard-user token, doing something administrative requires explicitly obtaining an administrator token — that is what the UAC prompt is. This is why least privilege is powerful: if the default token is standard-user, then a mistake, a bad download, or a malicious macro runs with only standard-user power and cannot silently reconfigure the machine. Broad power is opt-in, per action, not always-on.

Why the same action succeeds for one account and fails for another

On WS-041, a script tries to write a new service configuration (a machine-wide change). Run by a.hakim it fails with 'access denied'; run by the help-desk account t.admin it succeeds. Both are real people at Aldar. Explain the difference using the model.

Identify the token each process carried.
The script run by a.hakim carried a.hakim's token: account ALDAR\a.hakim, group membership Users (a standard user). The script run by t.admin carried a token whose groups include Administrators. Same script, same machine, same target — the only difference is the token, because privilege travels with the process that runs it.
Compare each token to what the resource permits.
Writing a service configuration is a machine-wide change, which Windows permits only to Administrators. a.hakim's token is in Users, not Administrators, so the check fails → access denied. That denial is not a bug; it is the model correctly protecting a system-level resource from a standard user. t.admin's token is in Administrators, so the same check passes → the write succeeds.
Draw the operational and security lesson.
Operationally: to make the change under a.hakim, they'd need to run the script elevated (with an administrator token), via UAC — not have their everyday account permanently made an admin. Security-wise: the fact that a.hakim's normal token CAN'T make this change is exactly the protection you want — if a.hakim were a standing administrator, any malware running as a.hakim could reconfigure services too. Decision: keep a.hakim standard, elevate deliberately for admin tasks. The 'access denied' was the system working as designed.

Quick check

When a process tries to do something, what does Windows actually check to allow or deny it?

A quick self-check — it doesn't affect your XP or progress.

Quick check

Why is doing everyday work under a standard-user account (not an administrator) a strong security practice?

A quick self-check — it doesn't affect your XP or progress.

An Aldar administrator suggests making every employee's daily account a permanent member of the Administrators group 'so they never get blocked by prompts.' Using the token model, explain what this would do to the blast radius of a malicious email attachment one employee opens.~5m

If the daily account is an administrator, what token do the processes it launches — including a malicious attachment — carry?
If every daily account is a permanent administrator, then every process it starts — including a malicious attachment the employee opens — inherits an administrator token. So the malware runs with full machine-wide power immediately: it can install services, change protected settings, and reconfigure the system, with no elevation prompt to slow it down. Keeping daily accounts standard-user confines that same attachment to standard-user power, dramatically shrinking the blast radius. Convenience here trades away the exact protection the model provides.