Windows Server · Lesson 03
Review local identities, administrative privilege, service accounts, scheduled-task principals, and remote-access groups without breaking required server functions.
The key question is not simply whether an account looks unfamiliar. The key question is what the identity does, what depends on it, and how much privilege it actually needs.
Lesson Snapshot
Learning objectives
Distinguish local accounts, domain accounts, built-in accounts, service identities, and privileged groups on Windows Server.
Use Computer Management, Local Users and Groups, and PowerShell to review local identities when they are applicable.
Recognize when local account management is limited or different on a domain controller.
Review Administrators and other privileged groups without removing accounts blindly.
Identify service-account dependencies before disabling or changing an account.
Apply least privilege while preserving required server roles, applications, and remote administration.
Identity map
An account stored on the individual server. Local users are common on member servers but are not the main identity model on a domain controller.
An account stored in Active Directory and usable according to domain permissions, group membership, and policy.
A Windows-created account or group with a special purpose. Built-in does not automatically mean unnecessary.
An identity used by a Windows service, scheduled task, application, or server role rather than a human user.
A group whose members receive administrative or security-sensitive rights.
A machine identity used in Active Directory so systems can authenticate and participate in the domain.
Core idea
A required account does not automatically need administrative rights. Preserve the function while reducing unnecessary privilege whenever the scenario permits.
Domain-controller warning
Domain controllers manage identity through Active Directory rather than the normal local-user model used by member servers.
Tool map
Win + R → compmgmt.msc → System Tools → Local Users and Groups → Users / GroupsUse on member servers where Local Users and Groups is available. This snap-in is not the normal account-management path on a domain controller.
Win + R → lusrmgr.mscProvides a direct view of local users and groups on supported non-domain-controller systems.
Start → Server Manager → ToolsProvides links to administrative consoles, including Computer Management and domain tools when installed.
Win + R → services.msc → double-click a service → Log On tabShows whether a service runs under Local System, Network Service, Local Service, or a named account.
Win + R → taskschd.msc → Task Scheduler Library → open a task → General tabShows which identity runs the task and whether it uses elevated privileges.
Start → search PowerShell → Run as administrator when requiredUseful for read-only inventory and verification when the cmdlets apply to the server's role.
Domain-controller note
A domain controller does not use local users and local groups in the same way as a normal member server.
Domain identities are primarily managed through Active Directory tools.
Do not assume that missing Local Users and Groups means the system is broken.
On a domain controller, review Active Directory users, groups, and domain privilege instead of treating it like a standalone server.
Account review questions
Is this server a member server or a domain controller?
Does this account have an explicit scenario purpose?
Is the account enabled?
Is it a member of Administrators or another privileged group?
Does any service run under this account?
Does any scheduled task run under this account?
Does the account own required files, shares, or application data?
Is the account used for RDP or another required administrative path?
Is the account local or domain-based?
What evidence would justify disabling, removing, or reducing its privilege?
Important groups
Members receive broad local administrative rights and should be limited to identities that actually require them.
Can be used to authorize non-administrative RDP access when the scenario requires remote desktop.
Standard local group for ordinary local user rights on a member server.
Has powerful backup and restore capabilities and should be reviewed carefully if used.
Allows reading event logs without full administrative privilege.
May grant access to performance monitoring or logging without full administrative access.
Built-in identities
The built-in Administrator account is highly privileged. Review its state, purpose, naming, and scenario requirements before changing it.
The built-in Guest account is normally highly restricted and commonly disabled, but verify the actual scenario before making assumptions.
Some built-in system-managed accounts support Windows functionality and should not be treated like ordinary user accounts.
LocalSystem, LocalService, and NetworkService are Windows service identities, not normal human accounts.
PowerShell inspection
Get-LocalUser | Select-Object Name, Enabled, LastLogon, PasswordRequired, PasswordExpiresReviews local user state on systems where local-account cmdlets apply.
Get-LocalGroup | Select-Object Name, DescriptionLists local groups for privilege and role review.
Get-LocalGroupMember -Group "Administrators"Shows current local administrative membership on applicable member servers.
Get-LocalGroupMember -Group "Remote Desktop Users"Reviews local RDP group membership when the group is used.
Get-CimInstance Win32_Service | Select-Object Name, State, StartName, PathNameShows which identities services use so account dependencies are not missed.
Get-ScheduledTask | Select-Object TaskPath, TaskName, @{Name="RunAs";Expression={$_.Principal.UserId}}Helps identify tasks tied to a user or service identity.
Privilege signals
The account is explicitly present in the local Administrators group.
A domain group may be added to local Administrators, giving all of its members local privilege.
A named account may run a required service and therefore cannot be disabled casually.
A task may execute as the account, sometimes with highest privileges.
The account may be part of an intended remote-administration workflow.
An application or service may rely on the account's permissions or ownership.
Classification model
The account or group membership has a documented scenario, service, application, role, or administrative purpose.
Keep it and reduce privilege only if the required function can still operate safely.
The identity is clearly unauthorized or unused and has no required dependency.
Preserve relevant evidence, then disable, remove, or reduce privilege as justified.
Purpose, ownership, logon history, service dependency, or authorization is unclear.
Review services, tasks, logs, shares, application configuration, and scenario notes before changing it.
Service-account review
Check Services, Task Scheduler, applications, IIS application pools if applicable, backup tools, databases, and scripts.
Review group membership, local rights, and whether it is unnecessarily administrative.
Identify the exact service, task, application, or role that would fail.
If the function does not require full administration, use the smallest rights necessary.
Named service accounts may require coordinated password handling so dependent services do not break.
Old service accounts may remain after software is removed and should be investigated carefully.
Controlled change examples
Change
Disable-LocalUser -Name "exampleuser"Use only on an applicable member server after confirming the account has no required dependency.
Verify
Get-LocalUser -Name "exampleuser"Change
Remove-LocalGroupMember -Group "Administrators" -Member "exampleuser"Confirm the user still has the access needed for the scenario.
Verify
Get-LocalGroupMember -Group "Administrators"Decision cases
A local member server contains an unfamiliar enabled user in Administrators.
The privilege is high-risk, but the account may support a service or remote-management workflow.
Response
Review services, tasks, RDP authorization, logs, and scenario requirements before removing privilege or disabling the account.
A required application service runs under an account that is also in Administrators.
The account is required, but its administrative privilege may be broader than necessary.
Response
Document the dependency, determine the minimum rights the application needs, and reduce privilege only after testing in the authorized environment.
The account is disabled and has no recent logon or known service dependency.
Disabled state reduces immediate risk, but evidence is still needed before deletion.
Response
Check tasks, services, files, shares, and scenario notes before deciding whether to remove it permanently.
lusrmgr.msc does not provide the expected local-account view.
A domain controller manages identities differently from a normal member server.
Response
Move to Active Directory tools and domain-group review rather than forcing local-account procedures.
Fictional defensive lab
Step 01
In the fictional environment, APP-SRV is a member server hosting a required application and one SMB share.
Step 02
Use Computer Management → Local Users and Groups → Users and Groups to inventory local accounts and privileged membership.
Step 03
One account named AppSvc runs the required application service. Record the service name, startup state, and account before changing anything.
Step 04
Morgan is the required administrator, AppSvc is required but should be least-privileged, and TempAdmin is unknown and must be investigated.
Step 05
Document TempAdmin's privilege, tasks, logons, and service usage. If no dependency or authorization exists, remove unnecessary privilege or disable the account.
Step 06
Confirm Morgan still has administrative access, the required application runs, the SMB share works, and no required task or service failed.
Common mistakes
Service and application accounts may have unfamiliar names but legitimate dependencies.
Disabling first can preserve context and make rollback easier while you verify dependencies.
A service may fail if its account loses required rights.
Domain controllers require domain identity review through Active Directory tools.
Convenience-based privilege increases risk and should be reduced when the scenario permits.
A privilege change can accidentally break required remote administration.
Reflection
Question 1
Why should account review start by identifying whether the server is a member server or domain controller?
Question 2
What makes a service account different from a normal user account?
Question 3
Why can removing an account from Administrators break an application?
Question 4
Why is disabling often safer than immediately deleting an account?
Question 5
What evidence should exist before an account is classified as unnecessary?
Question 6
What should be verified after changing privilege?
Verification checklist
Authorized administrators still have the required access.
Required standard users remain enabled.
Required service accounts still allow their services to start.
Required scheduled tasks still run under valid identities.
RDP or other remote administration still works when required.
No unnecessary local administrator remains.
No required application or share was broken by an account change.
Important account-related events were reviewed after high-impact changes.
Competition checklist
Identify whether the system is a member server or domain controller.
Open the correct account-management tool for that role.
Inventory users and privileged groups.
Review Administrators membership.
Review Remote Desktop Users when RDP is required.
Check named service accounts.
Check scheduled-task principals.
Classify identities as Required, Unnecessary, or Investigate.
Preserve evidence before disabling or removing suspicious accounts.
Prefer least privilege over unnecessary administration.
Verify required services and applications after changes.
Verify remote administration after privilege changes.
Next Windows Server lesson
Next, move from local identity to domain identity: users, groups, computers, privileged memberships, account properties, and safe Active Directory review.