2026-08-18 - Lessons from building a small Active Directory domain¶

Goal¶

Build enough of an on-premises Windows domain to understand how an administrator installs AD DS, organizes identities, delegates routine work, joins a client, applies policy, and troubleshoots authentication without creating an unnecessarily large environment.

What I built¶

DC-05, a Windows Server 2022 domain controller on VLAN 20
the internal forest-root domain ad.arphaxad.dev with NetBIOS name ARPHAXAD
AD-integrated DNS, Kerberos, LDAP, and the Global Catalog
a small OU structure for users, groups, privileged identities, and workstations
separate everyday, privileged, and delegated workstation-join identities
CL-01, a Windows 11 Enterprise client joined to the domain
a Group Policy and AppLocker exercise that moved from audit to enforcement

The implementation is documented in the Active Directory lab overview and its five phase runbooks.

Lessons I want to revisit¶

Active Directory depends on its DNS¶

A domain client must use the domain controller's DNS service so it can locate AD services through records such as LDAP and Kerberos SRV records. In this lab, CL-01 queried DC-05; DC-05 answered for ad.arphaxad.dev and forwarded external queries to OPNsense. That is how the client could discover the domain and still resolve internet names.

The AD namespace did not require a public A record or DNS delegation. The public arphaxad.dev website and the private ad.arphaxad.dev AD zone were served by different DNS systems depending on where the query originated. See Phase 2: AD DS, DNS, and the first domain controller and the public-safe IPAM.

OUs, groups, and permissions solve different problems¶

An OU organizes objects, sets an administrative boundary for delegation, and provides a place to link Group Policy. A security group represents a role or access requirement. Permissions belong to the group, while users gain those permissions through membership. This avoids rebuilding access-control entries whenever staff responsibilities change.

The lab kept the structure deliberately small and used GG-Workstation-Joiners to represent the device-enrollment role. See Phase 3: directory structure and identities.

Least privilege still needs an operational workflow¶

The workstation-join identity was delegated only the computer-object permissions needed in the Workstations OU. It did not need Domain Admin. The default domain machine-account quota was left unchanged because a one-client lab did not justify extra complexity, but the computer was prestaged in the correct OU so the delegated path could be tested.

This showed the difference between “an account can join a computer” and “the account can manage the domain.” Those should not be the same privilege.

Account state can look like a permissions failure¶

The first domain-join attempt failed even though the everyday and delegated accounts existed and were enabled. The join identity still had User must change password at next logon set. A domain-join credential prompt cannot perform that interactive password change, so clearing the flag during a password reset allowed the join to succeed.

The lesson is to verify the whole account state—not only whether the account is enabled—before changing delegation or firewall rules. The troubleshooting path is retained in Phase 4: Windows client domain join.

Group Policy scope is the combination of several controls¶

The AppLocker GPO was linked to the Workstations OU, so its computer-side settings reached CL-01. The deny rule then targeted GG-Lab-Users, limiting the restriction to the intended user role. OU placement answered which computers receive the policy; security-group targeting answered which users the rule affects.

Default executable allow rules were necessary so Windows and installed applications continued to work. A local administrator and privileged domain identity remained outside the denied group to preserve a recovery path.

Audit first, then enforce¶

AppLocker audit mode produced Event ID 8003, proving the rule matched while still allowing Registry Editor to run. Only after that evidence was checked was the executable collection changed to enforced mode. The visible block and enforcement event then proved the restriction worked.

This pattern applies beyond AppLocker: deploy narrowly, collect evidence, confirm recovery access, and enforce only when the expected impact is known. See Phase 5: Group Policy and application control.

Troubleshooting works best from dependencies upward¶

For a failed domain join or sign-in, check in this order:

client address, gateway, and VLAN placement
client DNS server and domain/SRV-record resolution
clock synchronization
account name, password, enabled state, and password-change flags
computer-object name, OU placement, and delegated permissions
client logs such as NetSetup.log and the relevant Event Viewer channels

This order avoids changing AD permissions when the real failure is DNS, time, or account state.

Small lab VMs can be disposable; the knowledge should not be¶

DC-05 and CL-01 are planned for deletion because host storage is limited. The phase runbooks, validation evidence, public-safe architecture, and this journal entry are the durable output. A Proxmox snapshot was optional for this learning environment and would not have been a substitute for an independent backup.

The rebuild begins with Phase 1: Windows Server foundation, while the current temporary footprint is recorded in Hardware & hosts and Network & topology.

What I would add in a larger environment¶

a second domain controller to practise replication and service continuity
tested system-state backup and authoritative/non-authoritative recovery
a dedicated client network with explicit inter-VLAN AD firewall rules
centralized event collection and alerts for authentication and policy events
certificate services only when a real use case requires them
Microsoft Entra integration as a separate hybrid-identity lab

Those additions matter in production, but they are not required to understand the core AD DS management workflow demonstrated here.