Windows 11 · Lesson 02

Users, Groups & Administrators

Review Windows identities carefully, separate legitimate users from privileged users, and correct unnecessary access without breaking required accounts or services.

Identity review is not “delete every account you do not recognize.” Strong Windows defense compares scenario authorization, current group membership, account purpose, dependencies, activity, and privilege before changing the system.

Lesson Snapshot

Identity categories4

Review sequence6 steps

Main principleLeast privilege

GoalCorrect identities

Learning objectives

What identity review should help you do

Explain the difference between an authorized account, an authorized administrator, a disabled account, and an account that requires investigation.

Review local Windows 11 users and groups without assuming every unfamiliar account is malicious.

Use scenario evidence to decide which users should exist and which users should have elevated privileges.

Apply least privilege by correcting unnecessary administrator access without removing legitimate users.

Recognize built-in and special accounts that require context before modification.

Verify identity changes so required access remains available and privilege changes actually took effect.

Core concept

Account existence and privilege are separate questions

A user can be completely legitimate while still having too much privilege. If the scenario authorizes the account but not administrative access, the correct response may be to change group membership rather than remove the account.

Identity warning

Unfamiliar does not automatically mean unauthorized

Windows can contain built-in, system-managed, service, and application-related accounts. Investigate purpose and dependency before destructive actions.

Strong evidence should come before account deletion or other irreversible identity changes.

Identity classification

Four categories for every account you review

Authorized administrator

A user explicitly allowed to have elevated administrative privileges for the scenario or system role.

Response

Keep the account and required privilege. Verify it belongs only to the groups it actually needs.

Authorized standard user

A legitimate user who should be able to sign in or use the system but does not require administrative privilege.

Response

Keep the account, remove unnecessary elevation if present, and preserve required access.

Unauthorized account

An account whose existence conflicts with clear scenario requirements or other strong evidence.

Response

Document the evidence, consider dependencies, then use the least disruptive justified remediation.

Unknown / needs investigation

An account is unfamiliar or not clearly explained, but the available evidence is not strong enough for a destructive decision.

Response

Investigate ownership, activity, group membership, dependencies, and scenario context before acting.

Review sequence

A practical identity review from scenario to verification

Build the scenario identity map

Write down every authorized user and every authorized administrator separately. Do not merge these two lists.

Inventory local accounts

Review the local user list, enabled state, descriptions, and other account details before changing anything.

Review privileged groups

Check Administrators and other groups that grant meaningful system access or management capability.

Compare scenario to system

Classify each account based on evidence: authorized administrator, authorized standard user, unauthorized, or unknown.

Correct privilege before deleting

If a legitimate user only has the wrong privilege, fix the group membership instead of removing the user account.

Verify access and membership

Confirm the new group state and make sure required users and administrators still have the access the scenario expects.

Evidence questions

Ask before changing an account

Is the account explicitly listed in the scenario?

Is the user authorized to exist but not authorized as an administrator?

What groups is the account currently in?

Is the account enabled or disabled?

Does a service, scheduled task, file, or application appear to depend on the account?

Is there recent login or activity evidence that matters to a forensic question?

Is this a built-in or system-managed account rather than a normal user?

What is the least disruptive justified correction?

Administrator review

Privilege deserves extra scrutiny

Administrators membership

Compare every member against the scenario. Administrative access should be limited to users who actually need it.

Nested or indirect privilege

Remember that group membership can grant privilege indirectly. Review relevant privileged groups instead of checking only one user at a time.

Temporary elevation

If a legitimate user appears to have unnecessary elevation, determine whether the privilege is required by the scenario before removing it.

Service and task context

Some services or scheduled tasks may run under specific accounts. Understand that dependency before disabling or deleting an account.

Built-in and system accounts

Recognize context before modification

Windows may contain accounts that exist because of the operating system or enabled features. Their presence should be understood before the team treats them like ordinary scenario users.

Administrator

Windows includes a built-in Administrator account. Its state and use should be reviewed in context rather than treated exactly like an ordinary named user.

Guest

The built-in Guest account is normally restricted and should be reviewed carefully if enabled. Do not confuse the built-in account with a normal user merely named similarly.

DefaultAccount

Windows may include system-managed accounts that exist for operating-system functions. Their presence alone is not evidence of compromise.

WDAGUtilityAccount

Some Windows editions or features may create specialized system accounts. Understand purpose before modifying or deleting them.

Group concepts

More than one group can affect access

Administrators

Members can make broad system changes. Membership deserves careful scenario comparison and verification.

Users

Standard users normally receive routine access without full administrative control.

Remote Desktop Users

Membership may matter when the scenario requires Remote Desktop access for specific non-administrator users.

Backup Operators and other privileged groups

Some groups grant specialized rights. Do not assume only Administrators matters when reviewing privilege.

Windows tools

Where identity information can be reviewed

Computer Management

Win + R → compmgmt.msc → System Tools → Local Users and Groups → Users / Groups

Local Users and Groups provides a graphical view of local accounts and group membership on supported Windows editions.

Settings

Settings → Accounts → Other users

Useful for common account views and sign-in configuration, though it does not expose every local security detail.

Control Panel / legacy tools

Control Panel → User Accounts → User Accounts

Some account and group views still exist in traditional Windows administrative interfaces and can provide useful context.

PowerShell

Start → search PowerShell → Run as administrator when the command requires elevation

Useful for fast inventory and verification when you understand the command and are working in an authorized environment.

PowerShell inspection

Fast identity visibility in authorized practice

These examples are inspection-focused. Read the output and compare it with the scenario before making changes.

List local users

Get-LocalUser

Shows local accounts and basic state information so the team can compare the system to the scenario.

List local groups

Get-LocalGroup

Shows available local groups and helps identify where privileges may be assigned.

Review Administrators

Get-LocalGroupMember -Group "Administrators"

Displays current local Administrators membership for comparison with authorized administrators.

Inspect one user

Get-LocalUser -Name "exampleuser"

Shows detailed local account information for a specific fictional or authorized practice user.

Decision cases

Identity decisions should match the evidence

Legitimate user, excessive privilege

Taylor is listed as an authorized user but not as an administrator. Taylor is currently a member of Administrators.

Weak response

Delete Taylor because the account appears in a privileged group.

Better response

Keep Taylor's legitimate account, remove only the unnecessary administrator membership, and verify Taylor remains able to use the system as required.

Unfamiliar account with unclear purpose

An account named svc_media is not mentioned in the user list, but a required application appears to use a service with a similar name.

Weak response

Delete the account immediately because it is not in the user list.

Better response

Investigate service ownership, logon configuration, application dependencies, and scenario requirements before deciding whether the account is unnecessary.

Clearly unauthorized administrator

The scenario explicitly identifies one authorized administrator. A second ordinary user is also in Administrators with no stated need for elevation.

Weak response

Disable every administrator except the named one without checking whether the other account is still a required standard user.

Better response

Correct the unauthorized privilege while preserving any legitimate account existence required by the scenario.

Built-in account

The built-in Guest account appears in the account inventory.

Weak response

Treat it exactly like a newly created suspicious user.

Better response

Recognize it as a built-in account, review its enabled state and policy context, and make a decision based on the system requirements.

Verification

Prove the final identity state is correct

Account existence

Confirm every user who must remain on the system still exists.

Enabled state

Confirm accounts are enabled or disabled according to the intended secure state and scenario.

Group membership

Re-open the group or re-run the inspection command to prove the privilege change took effect.

Required access

Confirm authorized users can still perform the functions they are supposed to perform.

Administrator access

Confirm the team has not removed all valid administrative access needed to continue managing the image.

Evidence preservation

Confirm account changes did not destroy information still needed for forensic questions or troubleshooting.

Fictional defensive lab

Build the correct user and privilege state

Step 01

Read the fictional scenario

Authorized administrators: Morgan. Authorized standard users: Avery, Jordan, Riley. RDP is required for Morgan. A forensic question asks about failed sign-ins from the previous evening.

Step 02

Review the fictional system state

Administrators currently contains Morgan, Jordan, and a user named tempadmin. Avery, Jordan, Riley, and tempadmin all exist as enabled local accounts.

Step 03

Classify each identity

Morgan is an authorized administrator. Avery, Jordan, and Riley are authorized standard users. tempadmin conflicts with the scenario and requires evidence-based remediation.

Step 04

Choose the least disruptive changes

Jordan should remain a user but lose unnecessary administrator privilege. tempadmin requires review of activity and dependencies before the account is removed or disabled.

Step 05

Protect forensic evidence

Before destructive changes, review relevant sign-in evidence so the failed-login question can still be answered.

Step 06

Verify

Confirm Morgan is the only authorized administrator, Avery/Jordan/Riley remain available as standard users, required RDP still works, and forensic findings are documented.

Common mistakes

Identity-review habits that create problems

Authorized user = authorized admin

A person may be allowed to have an account without being allowed to have elevated privilege.

Deleting instead of de-privileging

Removing a legitimate account can break required access when the real problem is only excessive group membership.

Unknown account = malicious account

Unfamiliar service or system accounts require context and evidence before destructive action.

Checking only Administrators

Other groups may grant meaningful rights or support required access such as Remote Desktop.

Ignoring task or service dependencies

An account may be tied to a required service, scheduled task, or application. Check dependencies first.

No post-change verification

A successful removal command or GUI change does not prove the final identity state is correct.

Reflection

Test your identity reasoning

Question 1

Why should authorized users and authorized administrators be written as separate lists?

Question 2

Why is removing administrator membership often safer than deleting a legitimate user?

Question 3

What makes a built-in Windows account different from an ordinary user account?

Question 4

What evidence would you gather before removing an unfamiliar service account?

Question 5

Why should groups other than Administrators sometimes be reviewed?

Question 6

What should be verified after changing user or group membership?

Identity checklist

Review before leaving the account area

Write the authorized-user list.

Write the authorized-administrator list separately.

Inventory local users.

Check enabled and disabled account states.

Review Administrators membership.

Review other relevant privileged or access groups.

Identify built-in or system-managed accounts before changing them.

Check service, scheduled-task, or application dependencies for unfamiliar accounts.

Separate account existence from account privilege.

Correct unnecessary privilege with the least disruptive change.

Protect account-related forensic evidence before destructive actions.

Verify users and groups after every meaningful change.

Confirm required administrators still have management access.

Document unresolved identity questions for later review.

Next Windows lesson

Password & Account Policies

Next, learn how password length, complexity, history, lockout, expiration, and related policy choices affect Windows account security and user access.

Open Lesson 03 →

Back to Windows 11 CyberPatriot Hub

← Previous Lesson Next Lesson →