Windows Server · Lesson 04
Review domain users, groups, computers, privileged memberships, and organizational structure without disrupting authentication, services, or required administration.
Active Directory is not simply a list of users. It is an identity and authorization system that many server roles, applications, administrators, and clients depend on.
Lesson Snapshot
Learning objectives
Use Active Directory Users and Computers to review domain users, groups, computers, and organizational units safely.
Recognize the difference between local privilege and domain privilege.
Identify high-impact groups such as Domain Admins and other administrative groups without changing membership blindly.
Review user-account properties, disabled status, group membership, and logon context before taking action.
Recognize service, application, and administrative dependencies tied to domain accounts.
Apply least privilege while preserving required domain authentication, services, and management access.
Active Directory concepts
An identity stored in Active Directory and authenticated by domain controllers according to domain policy and group membership.
A collection of users, computers, or other groups used to assign access and privilege across the domain.
An Active Directory object representing a domain-joined computer and its relationship with the domain.
A container used to organize Active Directory objects and often apply delegated administration or Group Policy.
A group whose members receive administrative rights over the domain, servers, services, or sensitive resources.
A domain account or managed identity used by a service, scheduled task, application, or server role instead of a person.
Core idea
A single privileged domain account may administer multiple servers, users, workstations, policies, or services.
High-impact warning
Disabling an account or removing group membership can break services, scheduled tasks, applications, and administration.
Tool map
Server Manager → Tools → Active Directory Users and ComputersQuick action
Win + R → dsa.msc
Primary console for reviewing domain users, groups, computers, OUs, and many account properties when AD DS tools are installed.
Active Directory Users and Computers → View → Advanced FeaturesQuick action
Enable only when you need the additional tabs and containers.
Shows additional objects and account properties. Use carefully because more administrative options become visible.
Active Directory Users and Computers → right-click the domain → FindQuick action
Search users, groups, or computers by name.
Useful when the directory is large and you need to locate a specific account or group quickly.
Active Directory Users and Computers → locate user → right-click → PropertiesQuick action
Review General, Account, Member Of, and other relevant tabs.
Inspect before changing. Group membership and account status can affect services and administrative access.
Active Directory Users and Computers → locate group → right-click → Properties → MembersQuick action
Review membership and purpose before changing it.
Administrative groups require especially careful review because one membership change can affect the entire domain.
Start → search PowerShell → Run as administrator when requiredQuick action
Use the ActiveDirectory module when installed.
Useful for read-only inventory with Get-ADUser, Get-ADGroup, Get-ADGroupMember, and Get-ADComputer.
Directory structure
The top of the directory namespace. Objects and OUs appear beneath it.
Often contains built-in or default users and groups, though real environments may organize identities into custom OUs.
May contain computer accounts that have not been moved into a custom OU.
Contains domain-controller computer accounts and is especially sensitive because Group Policy and administration can differ here.
Organizations often use OUs for departments, servers, workstations, service accounts, or delegated administration.
Contains built-in domain groups and security principals that should not be treated like ordinary custom groups.
User review
Is this account explicitly authorized by the scenario?
Is the account enabled or disabled?
What is the account's username and display name?
Which groups is the account a member of?
Does the account have domain-wide or server-specific privilege?
Is the account used by a service, task, application, or script?
Is the account required for RDP or another administrative workflow?
Does the account appear to be a normal human user or a service identity?
Do recent logs show successful or failed logons for the account?
What evidence would justify disabling, deleting, or reducing its privilege?
Privileged groups
Members typically receive broad administrative control over the domain and domain-joined systems.
Membership should be limited to identities that clearly require domain-wide administration.
Highly privileged in multi-domain forests and normally unnecessary for ordinary daily administration.
Treat membership as extremely sensitive and verify every member's purpose.
Can modify the Active Directory schema and is rarely needed for routine operations.
Unexpected membership deserves careful investigation.
Built-in administrative group with powerful rights in the domain context.
Review carefully and understand nested memberships before making changes.
Can manage many user and group objects depending on domain configuration.
May be legitimate but grants substantial identity-management authority.
Can receive powerful operational rights on domain controllers and related systems.
Review membership and necessity instead of assuming these groups are harmless.
PowerShell inspection
Get-ADUser -Filter * -Properties Enabled, LastLogonDate | Select-Object Name, SamAccountName, Enabled, LastLogonDateCreates a broad read-only domain-user inventory when the ActiveDirectory module is available.
Get-ADUser -Filter 'Enabled -eq $false' | Select-Object Name, SamAccountNameShows disabled accounts for review without changing them.
Get-ADGroup -Filter * | Select-Object Name, GroupScope, GroupCategoryInventories domain groups and shows their scope and security/distribution category.
Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, SamAccountName, ObjectClassReviews direct Domain Admins membership.
Get-ADPrincipalGroupMembership -Identity "username" | Select-Object NameShows the groups associated with a specific identity. Replace username with the account being reviewed.
Get-ADComputer -Filter * -Properties Enabled, LastLogonDate | Select-Object Name, Enabled, LastLogonDateCreates a broad inventory of computer accounts.
Privilege reasoning
The account appears directly in the privileged group's Members list.
A user may inherit privilege because a group they belong to is itself a member of another privileged group.
Some administrators require elevated rights for a specific job, but broad domain privilege should still be justified.
Accounts may have been elevated for maintenance and never reduced afterward.
A service account may have been granted too much privilege because it was convenient rather than necessary.
Old accounts or groups can remain privileged after staff, software, or responsibilities change.
Account properties
Disabled accounts cannot normally be used interactively, but they may still matter as evidence or configuration references.
Review password-related account flags and domain policy context rather than assuming one setting is correct everywhere.
Shows direct group membership and is one of the most important privilege-review areas.
Account properties can restrict logon hours or computers in some environments.
May reveal dependencies or expected user environment.
Useful documentation when maintained properly, but never treat the description alone as proof of authorization.
Classification
The account or group has a clear, documented domain, service, application, or administrative purpose.
Keep it and reduce excessive privilege only after confirming the required function still works.
The identity is clearly unauthorized, obsolete, or excessive and has no required dependency.
Preserve evidence first, then disable or remove access in the narrowest justified way.
The identity's purpose, privilege, ownership, logon history, or dependencies are unclear.
Review services, tasks, logs, group nesting, applications, and scenario requirements before changing it.
Controlled change examples
Change
Disable-ADAccount -Identity "exampleuser"Use only after confirming the account is not required by a service, task, application, or scenario requirement.
Verify
Get-ADUser -Identity "exampleuser" -Properties Enabled | Select-Object SamAccountName, EnabledChange
Remove-ADGroupMember -Identity "Domain Admins" -Members "exampleuser"Confirm the account does not require domain-wide administration and that another authorized administrator remains available.
Verify
Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, SamAccountNameComputer accounts
An enabled computer account may represent an active domain-joined system.
LastLogonDate can help identify stale-looking objects, but it should not be the only evidence used for deletion.
The object's OU can affect Group Policy and administrative scope.
Computer accounts belonging to required servers must be protected carefully.
Deleting or resetting a computer account can disrupt the machine's domain relationship.
If the scenario requires a client or server, its domain object is part of that requirement.
Evidence sources
Can contain account logon, privilege, and account-management events useful for context.
Shows whether a domain identity is used to run a required service.
Shows whether scheduled tasks run under a domain account.
Shows privilege paths and resource-access relationships.
Can show whether the identity or one of its groups is required for file access.
The strongest source for determining who and what must remain authorized.
Decision cases
A domain user is directly listed in Domain Admins but is not named in the scenario.
This is high-impact privilege, but the account may still support required administration or a service.
Response
Check services, tasks, recent logons, nested groups, role ownership, and scenario authorization before removing privilege or disabling the account.
The account is disabled and not used by any known service or task.
Disabled status reduces immediate risk, but deletion may remove useful evidence or break an undocumented dependency.
Response
Preserve relevant evidence and verify no dependency before deciding whether deletion is appropriate.
A required application service runs under a domain account that has Domain Admins membership.
The service may be required while the privilege is excessive.
Response
Document the dependency, determine the minimum rights required, and reduce privilege only after controlled testing.
A computer account has not logged on recently and is not named in the scenario.
The object may be stale, offline, or simply unused during the observed period.
Response
Confirm the system is not required before disabling or removing the computer account.
Fictional defensive lab
Step 01
On the fictional domain controller, use Server Manager → Tools → Active Directory Users and Computers or Win + R → dsa.msc.
Step 02
Identify the domain root, Domain Controllers OU, Users container, Computers container, and any custom OUs.
Step 03
Open Domain Admins and other high-impact groups. Record each direct member before making changes.
Step 04
A user named LegacyAdmin appears in Domain Admins but not in the scenario. Review its properties, group membership, service usage, task usage, and recent evidence.
Step 05
If LegacyAdmin has no required dependency or authorization, remove unnecessary privilege or disable the account while preserving evidence.
Step 06
Confirm authorized administrators can still manage the domain, required services remain healthy, domain authentication works, and no required task or application failed.
Common mistakes
A privileged account may still support required administration or a service.
Deletion can destroy useful evidence and make rollback harder.
Privilege may come through group nesting rather than direct membership.
Account descriptions are useful context but can be outdated or misleading.
Last activity alone does not prove the machine is unnecessary.
Identity changes can affect logon and domain services even when ADUC still opens normally.
Reflection
Question 1
Why is Domain Admins membership more significant than local Administrators membership on one member server?
Question 2
Why should nested group membership be considered during a privilege review?
Question 3
Why can a service account be required even if no person logs in with it?
Question 4
What evidence should exist before disabling a domain account?
Question 5
Why can deleting a computer account disrupt a required system?
Question 6
What should be verified after a high-impact Active Directory identity change?
Verification checklist
Authorized domain administrators remain able to manage the environment.
Required domain users can still authenticate.
Required service accounts still allow their services to run.
Required scheduled tasks still run under valid identities.
No unnecessary direct Domain Admins membership remains.
Required computer accounts remain intact.
Domain authentication and DNS-dependent functions still work.
Relevant account-management and logon events were reviewed after high-impact changes.
Competition checklist
Open Active Directory Users and Computers using the correct path.
Identify the domain root and major OUs/containers.
Review Domain Admins and other high-impact groups.
Check direct and nested privilege where relevant.
Review suspicious user properties before changing them.
Check services and tasks for account dependencies.
Review required service accounts carefully.
Review computer accounts before disabling or deleting them.
Classify identities as Required, Unnecessary, or Investigate.
Preserve evidence before disabling or removing suspicious accounts.
Use the narrowest justified change.
Verify domain authentication and required services afterward.
Next Windows Server lesson
Next, learn how domain policy is organized, where GPOs apply, how inheritance and precedence work, and how to review effective security settings without editing the wrong policy.