High School IntermediateModule I3Lesson 1 of 8

I3.1 Windows Accounts and Profiles

Review fictional Windows identities by account type, owner, role, privilege, group membership, activity, expiration, sign-in method, profile state, lifecycle, and approved purpose.

Lesson Progress

Windows Accounts and Profiles

High School IntermediateI3: Windows Security Basics • Lesson 1 of 8

13% complete

Readiness Check

Before You Start

0/5 ready

Professional Hook

An Enabled Account Is Not Automatically a Valid Account

A Windows device may contain standard users, administrators, temporary support accounts, organizational identities, service identities, disabled accounts, and old profiles. The defender must determine which accounts still have an approved owner, purpose, privilege level, duration, and dependency.

Weak response

“Delete every account that has not signed in recently.”

Strong response

“Confirm the owner, role, privilege, lifecycle, dependencies, profile data, sign-in evidence, and approved need before making a controlled change.”

Objective 1

Explain the difference between local accounts, connected organizational accounts, standard users, administrators, service identities, and temporary support accounts.

Objective 2

Describe how Windows user profiles store settings, data, application state, cached information, and evidence tied to an account.

Objective 3

Evaluate fictional accounts using owner, role, privilege, activity, expiration, group membership, sign-in method, profile state, and approved purpose.

Objective 4

Distinguish confirmed account facts from likely explanations, missing evidence, alternate explanations, and unsupported assumptions.

Objective 5

Create a professional account-and-profile review with prioritized findings, named owners, controlled actions, validation, rollback, and review dates.

Why This Matters

Identity Errors Can Become Device-Wide Security Problems

A stale administrator, shared account, ownerless service identity, orphaned profile, or expired support account can preserve access long after the original need ends. Strong account governance reduces privilege, supports accountability, protects data, and improves incident response.

Account Types

Different Windows Identities Need Different Controls

Standard user account

Supports normal daily work without broad system-wide authority.

Healthy evidence

Named owner, current role, approved applications, recent activity, limited groups, standard profile, and normal sign-in protections.

Main risks

May still expose data through downloads, browsers, shared folders, removable media, weak passwords, or unsafe behavior.

Defender questions

Does the owner still need the account? Are group memberships narrow? Is the profile current? Are downloads, browser state, and local data managed safely?

Local administrator account

Supports approved device administration, maintenance, deployment, or troubleshooting.

Healthy evidence

Named owner, separate standard account, documented approval, limited use, strong sign-in protection, monitoring, and periodic review.

Main risks

Permanent broad privilege increases impact if the account is shared, stale, misused, or poorly monitored.

Defender questions

Is administrator membership still required? Is the account separate from daily work? Is use time-bounded and logged? Is the owner current?

Connected organizational account

Provides managed access to organizational applications, files, policies, settings, and device resources.

Healthy evidence

Active organizational status, assigned device, current groups, approved profile, managed sign-in protection, and offboarding records.

Main risks

Old group assignments, profile data, cached sign-in state, and shared-device access may outlive the original role.

Defender questions

Does the account still belong on this device? Are role groups current? Is profile data appropriate? Has offboarding or transfer been completed?

Service identity

Runs an approved service, scheduled activity, automation, or application component.

Healthy evidence

Named technical owner, exact service mapping, narrow privilege, restricted sign-in rights, documented credential management, and monitoring.

Main risks

Overprivilege, interactive sign-in, unknown ownership, broad folder access, stale credentials, and hidden dependencies.

Defender questions

Which service uses the identity? Can it sign in interactively? What resources can it access? Is the owner current? Is the credential rotation process documented?

Temporary support account

Provides short-term access for support, deployment, migration, repair, or vendor activity.

Healthy evidence

Ticket, owner, approver, exact scope, expiration, temporary group membership, activity review, and confirmed closure.

Main risks

Temporary accounts often remain enabled, privileged, or assigned to groups after the approved work ends.

Defender questions

Has the expiration passed? Is the account still enabled? Does any active dependency remain? Were groups and profile data removed or transferred?

Disabled or retired account

Preserves historical ownership, audit context, or controlled access to retained profile data after active use ends.

Healthy evidence

Sign-in disabled, ownership transferred, jobs reassigned, groups removed, profile retention approved, and review date recorded.

Main risks

May still own files, scheduled activity, services, encrypted data, shared resources, or cached credentials.

Defender questions

Is sign-in blocked? Has ownership transferred? Are services and jobs reassigned? Is profile retention justified and time-bounded?

Core Concept

Account, Profile, Privilege, and Ownership Are Related but Different

The account identifies the security principal. The profile stores user-specific settings and data. Group membership and privilege determine authority. Ownership and lifecycle records explain why the account should exist. A complete review connects all four.

Account

Who or what authenticates and receives access.

Profile

Which user-specific data, settings, and application state remain.

Privilege

What the identity can change or control.

Ownership

Who approves, reviews, and remains responsible.

Profile Anatomy

A User Profile Is More Than a Folder Name

Desktop and user folders

Documents, Downloads, Desktop, Pictures, and other user-managed content.

Does the profile contain sensitive or business data that should be moved, protected, retained, or deleted under policy?

Application settings

User-specific application preferences, cached configuration, local databases, and extensions.

Could stale settings, extensions, or application state continue after the account role changes?

Browser state

Bookmarks, history, downloads, profiles, cached data, extensions, and stored sign-in state.

Are there privacy, exposure, or account-sharing concerns that require approved cleanup?

Local application data

Per-user application files, logs, tokens, databases, and temporary state.

Which data is required for the role, and which data should be protected, transferred, or removed?

Profile path and ownership

Profile directory, owning account identifier, access permissions, last-use time, and profile status.

Does the profile still map to an active and approved account owner?

Cached organizational state

Offline files, synchronized content, local policy state, or application sign-in cache.

What remains accessible if the device is offline or the organizational account is disabled?

Key Vocabulary

Windows Identity and Profile Terms

Local account

An account created and managed primarily on one Windows device.

Connected organizational account

An account linked to an organizational identity system and used to access managed devices, files, applications, and services.

Standard user

An account intended for everyday work with limited authority to make system-wide changes.

Administrator

An account or group with elevated authority to install software, change system settings, manage accounts, and alter protected resources.

User profile

The collection of user-specific folders, settings, application data, cached state, and preferences associated with an account.

Local group

A Windows group on one device that grants a defined set of permissions or privileges to its members.

Account lifecycle

The process of creating, approving, using, reviewing, disabling, transferring, and removing an account.

Last sign-in

Evidence showing when an account most recently authenticated or established a session under the available records.

Sign-in method

The approved mechanism used to authenticate, such as a password, PIN, smart card, or organizational credential.

Profile ownership

The relationship between an account and the user-specific files, settings, and application data stored in its profile.

Temporary account

A time-bounded identity created for support, deployment, testing, migration, vendor work, or another approved short-term purpose.

Orphaned profile

A profile that remains on a device after the associated account is disabled, deleted, transferred, or no longer actively used.

Account Lifecycle

Manage Accounts from Approval through Removal

1

Request and approve

Document the owner, business purpose, device scope, privilege level, duration, approver, and expected profile needs.

2

Create and configure

Assign the correct account type, groups, sign-in protections, profile location, and restrictions.

3

Use and monitor

Review sign-ins, group changes, privilege use, profile growth, support tickets, and unusual activity.

4

Review and recertify

Confirm that the owner, role, access, privilege, profile data, and expiration remain appropriate.

5

Disable and transfer

Block sign-in, transfer file ownership, reassign services or jobs, remove groups, and protect required profile data.

6

Retain or remove

Apply approved retention, archive or remove the profile, update records, and confirm the account cannot be used.

Evidence Analysis

What Windows Account Evidence Can and Cannot Prove

Evidence source

Account inventory

Can support

Account name, type, status, owner, creation date, expiration, and local or organizational relationship.

Limitation

Does not prove current business need, actual human identity, or all effective privileges.

Evidence source

Local group membership

Can support

Which local roles or privilege groups include the account.

Limitation

Does not show every permission gained through files, applications, network services, or organizational groups.

Evidence source

Sign-in records

Can support

Successful or failed authentication, time, device, source, method, and session context under available logging.

Limitation

Does not always prove the physical person, purpose, or full activity performed after sign-in.

Evidence source

Profile metadata

Can support

Profile path, owner mapping, last use, size, status, and local data presence.

Limitation

Does not prove every file is still required or that all sensitive data has been identified.

Evidence source

Owner and role records

Can support

Approved user, job or student role, support responsibility, expiration, and current need.

Limitation

Documentation may be stale or may not match the technical state.

Evidence source

Service and scheduled-task mappings

Can support

Which services, jobs, or automation still depend on an account.

Limitation

Does not prove the dependency is still needed or correctly configured.

Evidence source

Support and change records

Can support

Why an account was created, who approved it, what changes occurred, and when access should end.

Limitation

Does not prove the account was actually removed or restricted afterward.

Evidence source

File ownership and access

Can support

Which files, folders, or resources are owned by or accessible to an account.

Limitation

Does not prove that all access is approved or that ownership matches current responsibility.

Defensive Workflow

Complete a Windows Account Review in Six Steps

1

Confirm system and scope

Identify the fictional Windows device, approved role, owner, time window, and allowed evidence sources.

2

Inventory accounts and profiles

Record account type, status, owner, groups, privilege, expiration, sign-in method, profile path, and last use.

3

Connect dependencies

Map accounts to files, services, scheduled activity, applications, shares, groups, and organizational roles.

4

Compare with lifecycle records

Check approvals, tickets, role changes, offboarding, expiration, retention, and transfer requirements.

5

Classify findings

Separate confirmed facts, likely explanations, missing evidence, alternate explanations, and unsupported claims.

6

Recommend controlled action

Assign an owner, define the exact approved change, preserve needed data, validate dependencies, and document rollback or recovery.

Fake Dashboard

Fake Windows Account Governance Dashboard

Training dashboard for the fictional Northstar Learning Services workstation fleet.

Enabled local accounts

46

Thirty-eight are standard users, four are administrators, two are service identities, and two are temporary support accounts.

Accounts past expiration

3

Two temporary support accounts and one contractor account remain enabled after their approved end date.

Orphaned profiles

5

Five profiles remain after account disablement and require retention, ownership, and transfer review.

Fake SOC Alert

Expired Support Account Retains Local Administrator Privilege

Source: Fake Windows Identity Governance Monitor • Time: 10:36 AM

High Severity
The fictional account temp-support-17 expired eight days ago, remains enabled, belongs to the local Administrators group, and has a profile containing deployment notes. The support ticket is closed, and the listed owner confirms no current support need.
Defensive recommendation: Preserve account, group, sign-in, profile, file ownership, service, scheduled-task, and ticket evidence; confirm no active dependency; then remove administrator membership, disable the account, transfer required data, and validate the device.

Fake Log Panel

Fake Windows Account Review Timeline

training-log-viewer.log
09:58:00 INVENTORY device='training-win-04' role='staff-learning-workstation' owner='learning-ops'
10:01:17 ACCOUNT name='temp-support-17' type='local' status='enabled'
10:02:44 GROUP account='temp-support-17' membership='Administrators'
10:05:03 LIFECYCLE expiration='8_days_ago' ticket='SUP-1042' ticket_status='closed'
10:08:29 SIGNIN account='temp-support-17' last_success='12_days_ago' source='approved-support-console'
10:12:11 PROFILE path='C:\Users\temp-support-17' size='1.8GB' contains='deployment-notes'
10:18:52 SERVICE dependency='none_found'
10:22:15 TASK dependency='none_found'
10:27:40 OWNER current_need='false' data_transfer_required='true'
10:36:09 CORRELATION finding='expired_admin_account_with_profile_data' confidence='high'

Training note: this is fake data for defensive analysis practice only.

Analyze the Evidence

Which Account Decision Is Best Supported?

The fictional temporary support account expired eight days ago.
The support ticket is closed.
The listed owner confirms that no current support need remains.
The account still belongs to the local Administrators group.
No service or scheduled-task dependency appears in the supplied evidence.
The profile contains deployment notes that may require transfer.
The last successful sign-in came from the approved support console twelve days ago.

What is the strongest next action?

Common Mistakes

Mistakes That Weaken Windows Account Reviews

Assuming every enabled account belongs to a current user.
Treating administrator membership as normal for convenience.
Using one shared account for multiple people and losing accountability.
Deleting a profile before checking files, application data, encryption, ownership, services, and retention.
Disabling an account without checking scheduled tasks, services, file ownership, or business dependencies.
Assuming no recent sign-in means the account is unnecessary without checking automation or offline use.
Treating a familiar display name as proof of identity.
Ignoring stale group memberships after a role change.
Leaving temporary support accounts enabled after the ticket closes.
Keeping broad profile data forever because deletion feels risky.
Stating that a failed sign-in proves malicious intent.
Publishing real usernames, device names, profile paths, sign-in records, or ownership details in a portfolio.

Safe Practice Lab

Complete a Fictional Windows Account-and-Profile Review

Fictional Environment

Meadowbrook Staff Workstation Review

Review twelve fictional Windows identities: standard users, administrators, service identities, temporary accounts, disabled accounts, and connected organizational accounts.

Required Analysis

  1. Classify every account by type and approved purpose.
  2. Record owner, status, privilege, groups, expiration, sign-in method, and last activity.
  3. Map each account to profiles, files, services, jobs, applications, and shares.
  4. Identify stale, shared, overprivileged, ownerless, expired, and orphaned items.
  5. Separate confirmed facts, likely explanations, gaps, and unsupported assumptions.
  6. Assign a risk priority and named owner.
  7. Write controlled disablement, transfer, retention, validation, and rollback steps.
Use only the supplied fictional evidence. Do not inspect, disable, delete, reset, unlock, reassign, or modify any real account, profile, group, sign-in method, file, service, or task without explicit authorization.

Scenario Decision Lab

A Disabled Account Still Owns Important Project Files

A fictional former project lead's account is disabled, but hundreds of team files still list that account as owner. The project remains active, and the new team lead needs controlled access.

Scenario Decision Lab

A Service Identity Can Sign In Interactively

A fictional service identity runs an approved synchronization service but also has interactive sign-in rights and belongs to a broad local group. The technical owner is known.

Defender Habits

Windows Account and Profile Review Checklist

Check Your Understanding

I3.1 Mini Quiz: Windows Accounts and Profiles

Choose your answers first. Explanations appear only after submission.

1. What is the main difference between a standard user and an administrator?

2. Why should temporary support accounts have an expiration date?

3. What does a user profile contain?

4. An account has not signed in for six months. What is the strongest conclusion?

5. Why should a retired account's file ownership be reviewed?

6. Which evidence best supports removing a temporary account from the local Administrators group?

7. What should happen before deleting an orphaned profile?

Portfolio Prompt

Portfolio Prompt

Create a fictional Windows Account and Profile Governance Report for twelve identities. Include account type, owner, purpose, status, privilege, local groups, expiration, sign-in method, last activity, profile path, profile data, services, tasks, file ownership, shares, lifecycle stage, finding, confidence, risk, owner, action, validation, rollback, and review date.

Use only fictional devices, usernames, groups, profile paths, sign-in records, tickets, and organizations.
Include at least one standard user, administrator, connected account, service identity, temporary account, and retired account.
Include one expired administrator, one orphaned profile, one service dependency, one file-ownership transfer, and one stale group membership.
Do not include real usernames, device names, profile paths, identifiers, sign-in times, or internal records.

Key Takeaways

What You Should Remember

1.Windows accounts, profiles, privilege, group membership, ownership, and lifecycle must be reviewed together.
2.An enabled account is not automatically valid, and an inactive account is not automatically safe to delete.
3.Temporary and administrator accounts require named ownership, narrow privilege, expiration, and periodic review.
4.Profiles may contain required files, application state, browser data, and sensitive content that must be handled carefully.
5.Disabled accounts may still own files, services, scheduled tasks, or encrypted data.
6.Strong recommendations preserve evidence, confirm dependencies, transfer required data, and validate controlled change.

Navigation

Continue Module I3