Managing accounts, OUs and Group Policy in my AD lab

Once I had more than one Windows machine to look after, logging into each one to change a setting stopped making sense. Active Directory became one of the tools I used most. It gave me one place to manage identities and policy, and it gave the activity I saw on Windows endpoints a context: which account, which machine, and whether that access was what I intended.

The domain, OU, group and GPO names below are examples, and every command output is labelled as example output. The reasoning, and the order I check things in, is how I run the domain.

Why a domain instead of local accounts

With local accounts, every machine is its own island. A password change, a new admin, or an audit setting has to be repeated per host, and nothing connects a logon on one machine to the same person on another. A domain changes three things:

• One identity per person. An account exists once, in AD DS, and every domain-joined machine trusts it.
• Policy that lands by location. Where a computer or user sits in the directory decides which Group Policy reaches it.
• Evidence I can correlate. The domain controller records credential checks, so I can follow one account across machines.

What I could control

Accounts and groups. Daily accounts and admin accounts are separate objects in separate OUs, so an admin account is never the one reading email. Access is granted to groups, not to people, so removing someone from a group removes the access everywhere at once.

Get-ADGroupMember -Identity "Lab Admins" | Select-Object Name, objectClass

Name            objectClass
----            -----------
adm-lab01       user
Tier1 Helpdesk  group

Organizational units and Group Policy scope. An OU is where an object lives; a GPO linked to that OU applies to everything inside it, unless inheritance is blocked or security filtering narrows it. When a setting did not show up on a machine, the first question was always which OU the computer was in.

gpresult /r /scope computer

COMPUTER SETTINGS
  CN=WS-01,OU=Workstations,OU=Lab Computers,DC=lab,DC=example
  Last time Group Policy was applied: 11/7/2026 at 8:02:11 AM
  Applied Group Policy Objects
      Restrict admin sign-in
      Workstation audit policy
  The following GPOs were not applied because they were filtered out
      Server baseline
          Filtering:  Not Applied (Empty)

A delegated-access example

Not every task needs a domain admin. Resetting a lab user’s password is a good example: I want a helpdesk group to do it, and nothing else.

1. Create a group, Helpdesk-Lab, and put the helpdesk accounts in it.
2. On the Lab Users OU, delegate only “Reset user passwords and force password change at next logon” to that group.
3. Test both directions: a helpdesk account resets a password in Lab Users, and the same account fails to reset an account in Lab Admins.

dsacls "OU=Lab Users,DC=lab,DC=example" | findstr /i "Helpdesk-Lab"

Allow LAB\Helpdesk-Lab    SPECIAL ACCESS for Reset Password   <Inherited to user>
Allow LAB\Helpdesk-Lab    SPECIAL ACCESS for pwdLastSet       <Inherited to user>

Groups, scope and the audit settings behind the evidence

Every event in the exercises below exists because of a setting I chose first. This is the layout I use, with the same illustrative names as the OU diagram:

Force audit policy subcategory settings has to be on, or a legacy category setting can quietly override the advanced ones and the events I expect never appear.

Sign-in and account audit evidence

Group Policy decides what Windows audits; the hosts decide where it is written. These are the events I lean on, and where each one appears:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4740 } -MaxEvents 3 | ForEach-Object { $x = [xml]$_.ToXml(); [pscustomobject]@{ Time = $_.TimeCreated; Account = $x.Event.EventData.Data[0].'#text'; Caller = $x.Event.EventData.Data[1].'#text' } }

Time                 Account    Caller
----                 -------    ------
2026-10-28 17:42:10  lab-user04  WS-03

A failed-logon investigation

The pattern I practise is short: read the sub status, find the source workstation, then look for what on that workstation is retrying. A sub status of 0xC000006A means the account exists and the password was wrong; 0xC0000064 means the account does not exist, which looks more like guessing.

What I wanted to learn from a Windows logon goes through the fields one by one, and SOC-0142 walks a simulated cluster of seven failures from first alert to an analyst’s decision.

Attack-lab exercises

The domain is also where I practise the other side: doing something an attacker or a careless admin might do, inside the lab, and checking that each layer saw it. My red and blue exercise VMs (VM 301 and 302) exist for this. Every exercise below has the same shape: an objective, a scope that stays inside the lab domain, the technique, the action, what Windows recorded, what the SIEM said, how I respond and the result.

These are practice walkthroughs: the outputs are written for this entry, and each result says so. The ATT&CK IDs are a mapping I added for this write-up, so a reader can place each exercise in a shared vocabulary.

The Kali Red and Blue page works the same domain from both sides, including a failed-logon search that came back empty because of a time-zone filter.

What the endpoint and the SIEM each told me

Putting the endpoint’s events next to the SIEM’s alerts for the same exercise is the comparison I get the most out of. In the first exercise’s example, Windows records 12 events and the SIEM raises two alerts. Neither number is wrong. The endpoint writes down every attempt, with the sub status that says whether the account exists. The SIEM writes down every time a rule’s threshold was crossed.

So the alert count tells me how many times a pattern happened, and the event count tells me how many attempts there were. The gap between the two bursts is only visible on the endpoint side, and it is the best lead: something retrying on a timer looks very different from a person retyping. The SIEM design entry traces all 12 events into those two alerts.

Wi-Fi with domain accounts

An AD-backed 802.1X Wi-Fi network is a natural next step, and I have written it up as a design in Who should get onto the lab Wi-Fi?. It is written as a practice design, with an example access point, NPS policy and test accounts.

What I learned

A domain is only as useful as the answers it lets me give. Location in the OU tree explains most policy surprises, groups explain most access, and the audit policy decides whether there is any evidence at all. When an exercise and its evidence disagree, the disagreement points at the layer to fix.

Takeaway: for every Windows question, write down three things before searching: which machine should have recorded it, which event ID it would be, and which GPO turned that auditing on.

Further reading: AD DS overview · Event 4625 · Delegation of control