Competition Checklist · 07 · Identity
Accounts & Privilege Checklist
Compare users, administrators, domain groups, sudo rights, remote-access groups, and service identities against the mission before removing accounts or changing privilege.
The safest competition workflow is to classify each identity, preserve evidence for suspicious changes, remove only excess privilege, and verify required access afterward.
Quick Use
Identity rule
Account existence and privilege are separate decisions
A user can be approved to exist but still have too much privilege. Fix the specific problem instead of deleting an account when only a group membership or sudo rule is wrong.
Opening pass
Classify identities before changing them
Read the approved-user and approved-administrator requirements before changing account state.
An unfamiliar account is not automatically unauthorized, and a required service account may not look like a normal user.
Record every privileged group before removing anyone.
Local Administrators, Domain Admins, sudo, adm, wheel, and other privileged groups may contain legitimate operators.
Separate account existence from account privilege.
A user may be allowed to exist but not allowed to hold administrative rights.
Check recent account and group changes before cleanup.
Creation, enablement, disablement, password changes, and privilege changes can provide important evidence.
Identify service and automation accounts.
Disabling a service identity can break required applications, scheduled tasks, or server roles.
Plan verification before making the change.
Know how you will confirm that approved access still works after privilege or account remediation.
Windows local identity
Review local users and sensitive groups
Local users
Get-LocalUser
net user
Every local user is classified as approved, unauthorized, disabled, built-in, service-related, or unresolved.
Local Administrators
Get-LocalGroupMember Administrators
net localgroup Administrators
Only approved users and required service identities retain administrative membership.
Remote Desktop Users
Get-LocalGroupMember "Remote Desktop Users"
Only approved users retain remote interactive access when RDP is required.
Other sensitive groups
Get-LocalGroup
Get-LocalGroupMember <GroupName>
Backup Operators, Hyper-V Administrators, Remote Management Users, and other sensitive groups are reviewed when present.
Active Directory
Review domain identities when the environment uses AD
Domain users
Get-ADUser -Filter * | Select-Object SamAccountName,Enabled
Use only on systems where Active Directory tools are available. Compare identities with the mission roster.
Domain Admins
Get-ADGroupMember "Domain Admins"
Only explicitly approved domain administrators retain membership.
Other privileged domain groups
Get-ADGroupMember "Enterprise Admins"
Get-ADGroupMember "Administrators"
Review privileged groups that exist in the environment and avoid assuming every domain uses the same structure.
Inactive or disabled identities
Search-ADAccount -AccountDisabled -UsersOnly
Search-ADAccount -AccountInactive -UsersOnly -TimeSpan 30.00:00:00
Inactive or disabled accounts are investigated in context before deletion or reactivation.
Linux identity
Review users, sudo, and effective privilege
Users
getent passwd
cut -d: -f1,3,4,7 /etc/passwd
Interactive users are compared with the approved roster before changes.
sudo group
getent group sudo
getent group wheel
Only approved users retain membership in the platform's administrative group.
Effective sudo rights
sudo -l -U <username>
Review what the account can actually execute instead of relying only on group membership.
sudoers rules
sudo visudo -c
sudo grep -RInE 'NOPASSWD|ALL=\(ALL' /etc/sudoers /etc/sudoers.d 2>/dev/null
Unexpected broad or passwordless privilege is investigated and justified before modification.
Account state
Do not reduce an identity to only enabled or disabled
Enabled / disabled
An unauthorized account may need to be disabled rather than deleted if evidence or rollback matters.
Password state
Confirm whether the account has a usable password, locked password, expired password, or another authentication mechanism.
Interactive shell
On Linux, a service account may exist legitimately but use a noninteractive shell.
Last logon
Recent activity can help determine whether an account is active, stale, or suspicious.
Group memberships
Privilege can come from nested or secondary group membership, not only a direct administrator flag.
Service dependency
An account may be required by a service, scheduled task, application pool, backup job, or automation.
Privilege sources
Administrative access can come from more than one place
Local Administrators membership
Domain Admins or other privileged domain groups
sudo or wheel membership
sudoers rules
Remote Desktop Users
Remote Management Users
service logon rights
scheduled-task run-as identity
service account credentials
delegated file or share permissions
application-specific administrative roles
Windows event quick reference
Use logs to explain identity and privilege changes
4624
Successful logon
Correlate approved or suspicious sessions with later privilege or configuration changes.
4625
Failed logon
Review repeated failures, unusual usernames, and unexpected source systems.
4672
Special privileges assigned
Identify privileged sessions that deserve deeper review.
4720
User account created
Investigate newly created accounts against the approved roster.
4722
User account enabled
Review unexpected enablement of previously disabled accounts.
4725
User account disabled
Confirm whether account disablement was expected or suspicious.
4728
Member added to global security group
Important when reviewing domain privilege changes.
4732
Member added to local security group
Review additions to Administrators and other sensitive local groups.
Decision model
Match the response to the actual identity problem
Approved + correct privilege
Leave the account in place and document why it is expected.
Approved + too much privilege
Remove only the excess privilege, then verify the user can still perform required duties.
Unauthorized + active
Preserve evidence, confirm the roster, then disable or otherwise contain according to the mission.
Unauthorized + privileged
Treat as high priority. Preserve group and log evidence before removing privilege or disabling the account.
Service account + required
Do not disable it. Verify least privilege and required service functionality instead.
Unknown
Do not guess. Record the account, investigate dependencies, recent use, groups, and mission context before changing it.
High-priority findings
Unauthorized privilege deserves immediate attention
Unapproved local Administrator
Record current group membership, recent logons, and account-change events before removing privilege.
Unexpected Domain Admin
Preserve group-change and authentication evidence, confirm the mission roster, then remove membership only if unauthorized.
Linux user with broad NOPASSWD sudo
Record the exact sudoers rule, account purpose, and recent sudo activity before narrowing access.
New account followed by privileged logon
Correlate account creation, group changes, logon events, process activity, and timestamps before containment.
Service account using excessive privilege
Identify the dependent service, required rights, logon type, and current function before reducing privilege.
Approved user in wrong security group
Remove only the incorrect group membership and verify required access still works.
Do not blindly change
Common account-cleanup mistakes
Do not delete an account just because the username is unfamiliar.
Do not remove a built-in account without understanding its role.
Do not disable a service account before identifying dependent services and tasks.
Do not remove all administrators except yourself.
Do not assume Remote Desktop Users and Administrators are equivalent.
Do not trust only the account name; inspect group membership and effective rights.
Do not use recursive or bulk privilege changes when one membership is the actual problem.
Do not erase account-change evidence before documenting it.
Verification sweep
Prove approved access still works after remediation
Approved users
Every required user can still authenticate or perform the access the mission requires.
Administrators
Only approved administrators retain local or domain administrative membership.
Linux sudo
Approved users have only the sudo rights they actually need.
Remote access
Only approved users retain remote-management access when the mission requires it.
Service accounts
Required services and scheduled tasks still function under their intended identities.
Logs
Important account, group, and privileged-logon evidence was preserved before remediation.
Dependencies
No application, share, scheduled task, or service broke because an identity was changed.
Documentation
The change log records who was changed, why, what evidence supported it, and how the result was verified.
Accounts & Privilege final checklist
Finish with least privilege and preserved functionality
The approved-user roster was reviewed before account changes.
The approved-administrator roster was reviewed before privilege changes.
Local Administrators membership matches the mission.
Domain privileged groups were reviewed when Active Directory is present.
Linux sudo or wheel membership matches the mission.
Effective sudo rights were reviewed, not just group membership.
Remote Desktop and remote-management groups were reviewed where relevant.
Service and automation accounts were identified before disablement.
Account creation and group-change evidence was checked when relevant.
Unauthorized privilege was removed with the narrowest justified change.
Approved users still have required access.
Required services still function after account changes.
Unresolved identities are documented instead of guessed.
The change log records all high-impact account and privilege remediation.