Active Directory Phase 2: AD DS and the First Domain Controller¶

Confirmed design¶

Setting	Value
Forest root DNS name	`ad.arphaxad.dev`
NetBIOS domain name	`ARPHAXAD`
First domain controller	`DC-05.ad.arphaxad.dev`
DNS zone visibility	Internal only
Public DNS changes	None

The existing arphaxad.dev website and its public DNS records remain under the current hosting provider. The Active Directory child namespace is hosted privately by Windows DNS and is reachable only from approved internal networks and VPN paths.

Confirmed progress¶

the AD DS role is installed
the AD administration tools are installed
the Install-ADDSForest deployment command is available
the first writable domain controller was promoted successfully
the ad.arphaxad.dev forest and domain were created
Windows DNS and the Global Catalog were selected during promotion
forest and domain functional levels were set to Windows Server 2016
no public DNS delegation was created
prerequisite checks passed with expected non-blocking warnings
the server restarted and accepted an ARPHAXAD\Administrator sign-in
whoami and hostname returned the expected domain identity and DC-05
the active adapter points to the domain controller for DNS
NTDS, DNS, Netlogon, KDC, and DFSR are running
the domain and forest names, NetBIOS name, functional levels, and PDC Emulator are correct
the DC A record and LDAP domain-controller SRV record resolve correctly
Windows DNS uses the OPNsense VLAN 20 gateway as its forwarder
public DNS resolution, public HTTPS, the existing arphaxad.dev website, and the internal AD name all passed validation

Role installation was confirmed on August 11, 2026. Promotion, initial sign-in, core services, domain identity, DNS discovery and forwarding, AD diagnostics, SYSVOL, NETLOGON, DFS Replication, and time-service checks were confirmed on August 12, 2026.

Promotion procedure used¶

In Server Manager, select Promote this server to a domain controller.
Select Add a new forest and enter ad.arphaxad.dev as the root domain.
On Domain Controller Options:
- set both functional levels to Windows Server 2016
- keep DNS server selected
- keep Global Catalog (GC) selected
- leave Read only domain controller (RODC) unavailable because the first DC must be writable
- enter a strong, separately stored DSRM password
On DNS Options, do not create a DNS delegation. The AD child namespace is intentionally private and is not delegated from public DNS.
Confirm ARPHAXAD as the NetBIOS domain name.

Keep the default database, log, and SYSVOL paths:

C:\Windows\NTDS
C:\Windows\NTDS
C:\Windows\SYSVOL

Review the configuration and run the prerequisite checks.
Continue only after all prerequisite checks pass; the expected DNS delegation warning is non-blocking in this design.
Select Install and allow Windows to restart automatically.
Sign in as ARPHAXAD\Administrator, using the Administrator password rather than the DSRM recovery password.

Administrator and DSRM passwords are different

net user Administrator * changes the normal Administrator password. It does not set the DSRM password. The DSRM password is supplied during promotion and is reserved for offline directory recovery.

Concepts used in this phase¶

Active Directory¶

Active Directory is Microsoft's directory system for centrally storing and managing identities, computers, groups, permissions, and security policy.

Active Directory Domain Services role¶

The AD DS role is the Windows Server feature that installs the directory service software and management tools; installing the role prepares the server but does not by itself create a domain.

Domain¶

An AD domain is an administrative and authentication boundary containing objects such as users, groups, computers, and policies that share a DNS name; this lab's domain is ad.arphaxad.dev.

Forest¶

An AD forest is the highest-level Active Directory structure and security boundary; it can contain multiple related domains, although this lab uses one forest with one domain.

Forest root domain¶

The forest root domain is the first domain created in a new forest and provides the forest's name, schema, and foundational administrative groups; here it is ad.arphaxad.dev.

Domain controller¶

A domain controller, or DC, is a server running AD DS that stores a copy of the directory, authenticates users and computers, applies directory policy, and advertises its services through DNS.

Promoting the server¶

Promotion converts an ordinary Windows Server with the AD DS role installed into a domain controller; for the first DC, promotion also creates the new forest, domain, and AD-integrated DNS zones.

DNS and the AD DNS zone¶

DNS translates names into addresses and also publishes service-location records; Active Directory relies on its private ad.arphaxad.dev DNS zone so clients can locate domain controllers and authentication services.

Parent domain and subdomain¶

arphaxad.dev is the registered parent domain, while ad.arphaxad.dev is a child name beneath it; the child can exist only inside the lab even though the parent has a public website.

Public DNS versus internal DNS¶

Public DNS continues to answer internet queries for the website, while the Windows DNS server answers internal queries for ad.arphaxad.dev; internal clients use Windows DNS first, which forwards unrelated queries toward OPNsense and public DNS.

A record¶

An A record maps a DNS name to an IPv4 address; promotion creates the DC's private A record inside Windows DNS, so no public A record containing the private VLAN address is required.

SRV record¶

An SRV record tells clients where a particular service is available; domain controllers automatically register records for services such as LDAP and Kerberos under names including _ldap, _kerberos, and _msdcs.

DNS delegation¶

A DNS delegation tells one DNS system that another nameserver is authoritative for a child zone; it is unnecessary here because public clients must not query or reach the private Windows DNS server directly.

FQDN versus URL¶

DC-05.ad.arphaxad.dev is the server's fully qualified domain name, or FQDN, not a web URL; a URL would include a protocol and service, such as https://DC-05.ad.arphaxad.dev, only if a web service were deliberately installed.

NetBIOS domain name¶

The NetBIOS domain name is the short, legacy-compatible form of the domain used in sign-in names such as ARPHAXAD\username; the DNS form remains ad.arphaxad.dev.

User principal name¶

A user principal name, or UPN, is the email-like sign-in form such as username@ad.arphaxad.dev; a verified alternate suffix such as username@arphaxad.dev can be added during a future Entra phase.

Kerberos¶

Kerberos is Active Directory's primary authentication protocol: after a successful sign-in, it issues time-limited tickets that let a user access approved domain services without repeatedly sending a password.

LDAP¶

LDAP is the protocol applications and administration tools use to search, read, and modify directory objects such as users, groups, and computers; it is not the same thing as the directory database itself.

Global Catalog¶

The Global Catalog is a searchable partial index of objects across the forest that helps users and applications locate directory objects; the first domain controller will be a Global Catalog server.

NTDS database¶

NTDS.dit is the database file in which the domain controller stores directory objects and their attributes; it is protected and managed by AD DS rather than edited directly.

SYSVOL¶

SYSVOL is the replicated folder on a domain controller that stores Group Policy templates and domain logon scripts and is shared with domain members.

DSRM password¶

The Directory Services Restore Mode password is a separate recovery credential used when starting a domain controller in a special offline repair mode; it must be strong and stored in the password manager, not in this repository.

Domain and forest functional levels¶

Functional levels specify the oldest Windows Server domain-controller features the domain or forest must support; because this is a new single-DC lab, the promotion wizard's supported modern defaults will be used and recorded.

DNS forwarder¶

A DNS forwarder is the next DNS server asked when Windows DNS is not authoritative for a name; this allows the DC to resolve internet names through OPNsense without putting a public DNS server directly on its network adapter.

Time synchronization¶

Accurate time is essential because Kerberos rejects authentication when clocks differ too much; after promotion, the domain controller becomes the time authority for domain members and its upstream time source must be validated.

How internet access and DNS resolution work¶

The VM's static configuration supplies three different pieces with different jobs:

its VLAN 20 address identifies the VM on the infrastructure subnet
its default gateway points to the OPNsense VLAN 20 interface for traffic destined outside that subnet
its DNS client points to Windows DNS on the DC itself so AD service discovery is never bypassed

For ordinary internet traffic, such as an HTTPS connection, the packet path is:

DC-05
  -> VirtIO network adapter
  -> vmbr1 with VLAN tag 20
  -> OPNsense VLAN 20 interface and firewall rule
  -> OPNsense outbound NAT
  -> OPNsense WAN on vmbr0
  -> upstream residential router and NAT
  -> internet destination

The return traffic follows the existing state in reverse. OPNsense and the upstream router reverse their NAT translations and deliver the response back to the DC. The VM therefore needs no public address and no inbound port forward for outbound internet access.

DNS resolution happens before a name-based connection can begin:

DC-05 application asks for a name
  -> Windows DNS on DC-05
     -> if the name is in ad.arphaxad.dev, answer locally
     -> otherwise forward the query to OPNsense Unbound
        -> Unbound resolves or forwards the public query
        -> answer returns to Windows DNS and then the application

After DNS returns an address, the application opens its connection through the gateway, firewall, and NAT path described above. DNS finds the destination; routing and NAT carry the packets to it.

How both DNS environments coexist¶

Internet user
  -> public DNS for arphaxad.dev
  -> existing hosted website

Domain-joined Windows client
  -> Windows DNS on DC-05
     -> ad.arphaxad.dev answered from the internal AD DNS zone
     -> other names forwarded to OPNsense and then public DNS

The Windows DNS server is authoritative only for the child zone ad.arphaxad.dev, not for the parent arphaxad.dev. It therefore does not hide or replace the public website records. The DC and AD service records stay private, and no additional inbound WAN port is opened.

Implementation sequence¶

Install the AD DS role and management tools.
Verify that the role installation succeeded.
Promote the server as the first DC in a new forest named ad.arphaxad.dev, using ARPHAXAD as the NetBIOS name.
Install AD-integrated DNS and keep the server as a Global Catalog.
Store the DSRM password securely and restart after prerequisite checks pass.
Confirm the domain controller's DNS client setting points to itself and validate its A and LDAP SRV records.
Confirm OPNsense is the Windows DNS forwarder and validate internal and public resolution plus outbound HTTPS.
Validate DNS records, AD health with dcdiag, SYSVOL and NETLOGON shares, DFS Replication, authentication identity, and time service.

Implementation will be performed and validated in small steps rather than as one uninterrupted procedure.