Skip to content

Active Directory Phase 4: Windows Client Domain Join

Purpose

Prepare the Windows 11 client, connect it to the AD-aware DNS service on DC-05, join it to ad.arphaxad.dev, and prove that a standard domain user can authenticate to the workstation.

This phase uses the Windows GUI wherever practical so it can be completed from the Proxmox console without transferring long commands.

Concepts used in this phase

Domain-joined computer

A domain-joined computer has its own AD computer account and a secure trust relationship with the domain, allowing domain identities and centrally managed policies to be used on that machine.

Computer account

A computer account is the workstation's identity in AD. It stores attributes needed for authentication, DNS registration, and Kerberos service identities; it is separate from the human user who signs in.

DNS dependency

An AD client must use the domain's DNS server because that server publishes the service records that locate domain controllers, Kerberos, LDAP, and other AD services. Public DNS resolvers do not contain these internal records.

DHCP versus static addressing

DHCP automatically supplies a workstation's address, gateway, and other network settings. The domain controller needs a stable address, but an ordinary client normally remains on DHCP and only needs to use the correct AD DNS server.

Local account versus domain account

A local account exists only on one workstation. A domain account is stored in AD and can be authenticated by a domain controller from any authorized domain-joined computer.

Secure channel

The secure channel is the authenticated relationship between the workstation's computer account and the domain. Windows maintains it using an automatically rotated computer-account password.

Intended result

At the end of this phase:

  • the client VM uses vmbr1 with VLAN tag 20
  • Windows 11 has a supported domain-join edition and is updated
  • VirtIO drivers and the QEMU Guest Agent are working
  • the client has a final workstation name
  • its IPv4 address and default gateway come from VLAN 20 DHCP
  • its preferred DNS server is the private address of DC-05
  • the computer account is created in Lab\Workstations
  • the client joins ad.arphaxad.dev
  • the everyday domain user can sign in
  • domain, DNS, and secure-channel behavior are validated

Public-safe example values

Setting Public-safe example Implementation rule
Client name CL-01 Use a short, unique workstation name
Proxmox bridge vmbr1 Internal bridge
VLAN tag 20 Infrastructure segment for this two-VM lab
Address assignment DHCP No client static address required
Default gateway 10.42.20.1 OPNsense VLAN 20 interface
Preferred DNS 10.42.20.10 Private address of DC-05
AD domain ad.arphaxad.dev Internal AD DNS namespace
Computer OU OU=Workstations,OU=Lab,DC=ad,DC=arphaxad,DC=dev Explicit join destination

Live addresses, account names, passwords, and MAC addresses remain outside the public repository.

Step 1: Verify the client foundation

Verify Proxmox networking

Shut down the Windows client before changing virtual hardware. In Proxmox:

  1. Select the Windows client VM and open Hardware.
  2. Edit its network device.
  3. Confirm Bridge is vmbr1.
  4. Confirm VLAN Tag is 20.
  5. Prefer VirtIO (paravirtualized) as the network model.
  6. Confirm there is no second client adapter connected to vmbr0.
  7. Start the VM.

Verify Windows readiness

Sign in with the temporary local administrator created during Windows setup.

  1. Open Settings > System > About.
  2. Confirm the edition is Windows 11 Pro, Enterprise, or Education. Windows 11 Home cannot join an on-premises AD domain.
  3. Record the current device name privately.
  4. Open Settings > Windows Update and install required updates.
  5. Restart if requested and repeat until no required restart remains.
  6. In Settings > Apps > Installed apps, confirm the VirtIO guest tools are installed.
  7. In Proxmox, confirm the QEMU Guest Agent is enabled and guest information is available.
  8. Keep Windows Defender Firewall enabled.

Do not join the domain yet. DNS, the final client name, and connectivity will be configured and tested in the next step.

Windows Update, the VirtIO guest tools, and the QEMU Guest Agent were installed and verified on August 16, 2026.

Step 2: Set the client name and AD DNS server

Set the final computer name

Rename the computer before joining it so the intended name becomes the AD computer-account name from the beginning.

  1. Open Settings > System > About.
  2. Select Rename this PC.
  3. Enter the final short, unique workstation name. CL-01 is the public-safe example used by this runbook.
  4. Select Next, then restart the client.
  5. Sign back in with the local administrator and return to System > About to confirm the new name.

Keep DHCP addressing and override only DNS

  1. Open Control Panel > Network and Internet > Network and Sharing Center.
  2. Select Change adapter settings.
  3. Right-click Ethernet and select Properties.
  4. Select Internet Protocol Version 4 (TCP/IPv4) and then Properties.
  5. Keep Obtain an IP address automatically selected.
  6. Select Use the following DNS server addresses.
  7. Enter the private VLAN 20 address of DC-05 as Preferred DNS server.
  8. Leave Alternate DNS server blank.
  9. Select OK, then Close.

Do not enter OPNsense, a public resolver, or another external DNS service as an alternate. If Windows can bypass DC-05, domain-controller discovery can become inconsistent. DC-05 forwards non-AD queries to OPNsense, so the client can still resolve internet names through this path:

Windows client -> DC-05 DNS -> OPNsense -> external DNS

Check time and basic name resolution

  1. Open Settings > Time & language > Date & time.
  2. Keep Set time automatically enabled and confirm the clock and time zone are correct. Kerberos authentication depends on closely synchronized time.
  3. Open Command Prompt and enter nslookup DC-05.ad.arphaxad.dev.
  4. Confirm the answer returns the private address assigned to DC-05.
  5. Open a normal website to confirm that external resolution and internet access still work through the DNS forwarding path.

Do not join the domain until the client name, DC lookup, and external browsing all work.

The client name, DHCP addressing, DC-05 DNS setting, domain-controller name resolution, and forwarded internet resolution were confirmed on August 16, 2026.

Step 3: Prestage and join the client

The normal Windows GUI does not provide a destination-OU field. Precreating the computer account keeps it in Lab\Workstations while retaining a GUI-only workflow.

Prestage the computer account on DC-05

Sign in to DC-05 with the named domain-administrator account.

  1. Open Active Directory Users and Computers.
  2. Open Lab > Workstations.
  3. Right-click the OU and select New > Computer.
  4. Enter the client's exact final computer name, such as CL-01.
  5. Beside User or group, select Change.
  6. Enter GG-Workstation-Joiners, select Check Names, and select OK.
  7. Finish creating the computer object.
  8. Confirm the object appears in Lab\Workstations.

The selected group is allowed to complete the join for this prestaged computer account. The object must exactly match the Windows device name.

Join Windows 11 to the local AD domain

On the client, remain signed in with the local administrator:

  1. Open Settings > Accounts > Access work or school.
  2. Select Connect.
  3. Select Join this device to a local Active Directory domain. Do not select the Microsoft Entra ID option.
  4. Enter ad.arphaxad.dev and select Next.
  5. When credentials are requested, use the dedicated workstation-join account, entered as ARPHAXAD\<private-join-account> or with its full UPN.
  6. Enter its password and continue.
  7. If Windows asks which domain user will use the device, specify the everyday domain user and keep the account type Standard user. Do not make the join account a local administrator.
  8. Confirm the welcome message for ad.arphaxad.dev.
  9. Restart Windows when prompted.

Do not delete the local administrator. It remains the recovery path if domain authentication or DNS later fails.

After the restart, the next step verifies the computer object, domain sign-in, DNS registration, and secure relationship before Group Policy is introduced.

The first join attempts failed even though the domain accounts existed and were enabled. The dedicated join account still required a password change at its next sign-in, which the domain-join credential prompt could not complete. Resetting that password while clearing User must change password at next logon allowed the prestaged join to succeed on August 17, 2026.

The dedicated account was able to sign in after the restart, confirming domain authentication, but it is not the intended everyday desktop identity.

Step 4: Validate standard domain authentication

  1. On the client, sign out of the dedicated workstation-join account.
  2. At the Windows sign-in screen, select Other user. If it is not shown, select Switch user first.
  3. Enter the everyday account as ARPHAXAD\<private-everyday-account> or use its full UPN.
  4. Enter the temporary password created in Phase 3.
  5. If prompted, replace it with a new unique password. This interactive sign-in is the correct place to satisfy User must change password at next logon.
  6. Allow Windows time to create the user's first local profile.
  7. Open Settings > System > About and confirm the computer is joined to ad.arphaxad.dev.
  8. On DC-05, refresh Lab\Workstations in Active Directory Users and Computers and confirm the client computer object remains there.

The dedicated join account should not be used for ordinary work. The local administrator also remains available only for workstation recovery and local maintenance.

The everyday domain account successfully authenticated to the client and created its Windows profile on August 17, 2026, validating the domain join and standard-user authentication path.

Why the client remains on VLAN 20

For the initial two-VM lab, placing the DC and client on VLAN 20 removes inter-VLAN firewalling as a troubleshooting variable. This is an intentional learning-stage simplification. A later exercise can move workstations to a dedicated client VLAN and explicitly permit the required AD traffic through OPNsense.

Official references