Lesson 2: Windows Security, Permissions, and Identity

A user signs into Windows successfully and still gets Access Denied on a folder.

Is the password wrong?

No.

Authentication already succeeded.

The failure is higher in the access-control path.

Windows security becomes easier when you separate these decisions:

who are you?
   ↓
what groups or roles apply?
   ↓
what does policy allow?
   ↓
what permissions apply to this resource?
   ↓
what process privilege is required?

One successful step does not imply the next one.

Visual reference

See the system before you troubleshoot it

reference sheetSecurity Controls and Evidence

System process animation

Authentication comes before authorization

Follow an identity claim through verification, access policy, resource use, and audit evidence.

RestartPreviousPlay sequenceNext

1. 1Identity claimA user or service names its identity.
2. 2CredentialA secret, key, certificate, or factor supports the claim.
3. 3AuthenticationThe system verifies claim and credential.
4. 4AuthorizationPolicy decides allowed actions.
5. 5ResourceThe approved action reaches the object or service.
6. 6Audit evidenceThe system records who did what and when.

Technician question: What proves identity without proving permission?

Account type changes who owns the identity

A local account exists on one Windows device.

A Microsoft account connects sign-in and Microsoft services through a cloud identity.

Organizations may also use domain or other centrally managed identities.

Before resetting a password or changing group membership, identify which system owns the identity.

Changing a local password does not repair a cloud identity. Changing a cloud password does not automatically fix local permissions.

Recognize Windows user roles

At A+ depth, recognize roles such as:

• standard user;
• administrator;
• guest;
• power-user concepts in legacy or compatibility contexts.

A guest-style account should not become the answer to normal managed access. A power-user label from an older environment should not be treated as a modern least-privilege design without checking what authority it actually provides.

The meaningful question is always:

What privilege does this identity really have?

UAC separates daily work from elevation

User Account Control creates a visible elevation boundary when an administrative action is required.

A process may run with standard authority until an approved elevation occurs.

Why not disable UAC because prompts are annoying?

Because the prompt is part of the control.

If one application asks for elevation every launch, investigate why the application requires it.

Removing the elevation boundary for the whole system is not a targeted fix.

Run as administrator elevates the process

"Run as administrator" gives the selected process elevated authority under the Windows/UAC model.

That is different from granting permanent standing privilege for every daily task.

Temporary process elevation is narrower than permanent administrative use.

Share permissions and NTFS permissions can both apply

Suppose a user reaches:

\\filesrv\dept

There may be at least two applicable permission layers:

share permission
      ↓
NTFS file/folder permission
      ↓
effective access

If either relevant layer restricts the requested action, the user can still receive Access Denied.

The server being reachable proves the network path.

It does not prove authorization to the folder.

Inheritance changes where permission comes from

A folder can inherit permissions from its parent.

A user may receive access through group membership and inherited ACLs even when no explicit user entry appears on the folder.

When access is surprising, inspect the source of the effective permission.

Do not keep adding explicit entries until the symptom disappears.

That creates a mess future technicians inherit too.

File attributes are not access control

Attributes such as hidden or read-only can affect user-interface behavior.

They are not substitutes for NTFS permissions.

A hidden file is not secure. A read-only attribute is not a complete authorization model.

Defender Antivirus protects against malicious software, not authorization errors

Microsoft Defender Antivirus can inspect for malicious or unwanted software according to its configuration and current security intelligence.

Useful state includes:

• protection active;
• current definitions/security intelligence;
• scan/history evidence.

Defender does not decide whether Alice can read the Finance folder.

Different control, different risk.

Windows Defender Firewall controls traffic

The firewall can allow or block network traffic by application, service, port, protocol, and profile.

If one approved application is blocked while other network functions work, create the narrowest justified rule under policy.

Do not disable the whole firewall.

A control should be adjusted to the requirement, not removed because it became visible.

Windows sign-in can use several authentication methods

Windows may support:

• password;
• PIN;
• fingerprint;
• facial recognition;
• SSO;
• passwordless / Windows Hello concepts.

A successful fingerprint sign-in proves the authentication process accepted that factor under current policy.

It does not prove the user is an administrator or can access every file.

Authentication method and authorization remain separate.

BitLocker protects a volume at rest

BitLocker can encrypt supported Windows volumes.

The risk it reduces is physical loss or theft exposing stored data without the required key material.

The new dependency is recovery-key management.

If motherboard, TPM, or boot state changes and recovery is required, somebody needs access to the approved recovery material.

Security without recovery planning is unfinished architecture.

BitLocker To Go protects supported removable media

Removable-drive encryption can protect sensitive data on a USB device or other supported removable storage.

That addresses loss and theft risk.

It also creates compatibility and recovery requirements for authorized endpoints.

EFS protects selected NTFS files and folders

Encrypting File System can encrypt selected files or folders using user-associated key material under supported Windows configurations.

That is different from full-volume BitLocker encryption.

The scopes differ.

Do not treat every encryption acronym as interchangeable.

Active Directory changes the authoritative boundary

At technician depth, recognize concepts such as:

• domain join;
• login scripts;
• organizational units;
• Group Policy;
• security groups;
• home folders;
• folder redirection.

A local Windows setting may be overwritten because central policy owns it.

Worked case:

user changes local setting
setting returns
gpresult: domain policy controls setting

The endpoint is not malfunctioning.

The technician needs to work with the policy owner.

Worked case: folder is reachable but denied

Evidence:

server: reachable
share: reachable
user: authenticated
user group: wrong group in supplied state
NTFS inheritance: enabled

What becomes weaker?

• DNS failure;
• network outage;
• password failure.

The permission and group boundary is the strongest current explanation.

Correct the intended relationship according to policy, then verify required access and a negative case that should remain denied.

Build ten Windows security tickets

For each supplied case, document:

identity owner
authentication result
account role
authorization / group boundary
share / NTFS / inheritance / attribute state
policy / firewall / encryption control
smallest justified change
privilege required
recovery-key or policy dependency
positive verification
negative verification where appropriate

Before you move on

Keep this chain visible:

authentication
≠ authorization
≠ elevation
≠ firewall policy
≠ encryption

Windows can enforce all of them at once.

Next we harden wireless, workstation, and mobile systems without confusing "more restrictions" with "better security."