Building a Windows Domain from Scratch

Overview

I built a small Windows Active Directory environment with one Windows Server 2025 VM as the domain controller and one Windows 11 Enterprise VM as the domain member workstation.

The project started with two clean, isolated virtual machines and ended with a working forest named corp.shamarlab.test, internal DNS, an organized OU structure, domain users and security groups, a joined Windows 11 client, group-based SMB and NTFS permissions, and Group Policy that configured both the workstation and the Accounting user experience.

The goal was to practice the administration tasks that make Active Directory useful in an organization: centralized identity, computer membership, DNS-based service discovery, organizational structure, security group design, resource authorization, and policy-based configuration. I did it all manually in the Windows administrative tools so I would understand what each component does and how the pieces depend on one another.

Lab architecture

The build, step by step

Seven phases, sixteen steps. Each step shows what I did, the screenshot that proves it, and why it matters.

Phase 1Baseline & network

1. 1

   Start from a clean, known baseline

   The environment began as two clean VirtualBox VMs. DC01 signed in with the local .\Administrator account and CLIENT01 with the local .\LabAdmin account. Neither was joined to a domain. I took clean-install snapshots first, so I had a recovery point before making any Active Directory changes.

   Enlarge

   Why it matters

   This is the before picture: two independent Windows systems with local accounts only. It makes the later move to CORP domain accounts easy to see.

2. 2

   Give the domain controller an address that never changes

   The NAT network handed out DHCP addresses. A domain controller and DNS server shouldn’t move, so I made DC01 static and pointed it at itself for DNS. Later, CLIENT01 got a static address that points at DC01 for DNS.

   Default gateway for both: 10.77.0.10

   Host	DHCP (before)	Static (after)	Preferred DNS
   DC01	10.77.0.3	10.77.0.10/24	10.77.0.10 (itself)
   CLIENT01	10.77.0.4	10.77.0.20/24	10.77.0.10 (DC01)

   A direct ping between the two VMs timed out at first. I didn’t treat that as a broken lab: both machines could ping the NAT gateway, and DNS and Active Directory traffic later worked correctly. The timeout was most consistent with host firewall behavior, not a failed virtual network.

   Troubleshooting takeaway

   A ping result tests only one kind of network traffic. On its own it doesn’t prove whether Active Directory services are healthy.

Phase 2Create the domain

1. 3

   Install AD DS and promote DC01

   In Server Manager I installed the Active Directory Domain Services role. Installing the role adds the server components and admin tools, but it doesn’t create a domain by itself. I then chose Promote this server to a domain controller and created a new forest with the root domain corp.shamarlab.test.

   • DC01 became the writable first domain controller, a DNS server, and the Global Catalog for the new forest
   • NetBIOS domain name: CORP
   • A lab-only Directory Services Restore Mode (DSRM) password
   • Default database, log, and SYSVOL paths
   • Prerequisite check passed, then the server promoted and rebooted

   Enlarge

   Why it matters

   The first direct, graphical proof that the forest and domain exist, and that DC01 now manages an Active Directory namespace instead of running as a standalone server.

2. 4

   Validate AD-integrated DNS

   Active Directory depends on DNS for more than name resolution. It uses DNS for service discovery: a client asks DNS where the domain controller and the LDAP service are. So DC01 hosts the AD-integrated DNS zone, and CLIENT01 uses DC01 for DNS instead of an outside resolver.

   Enlarge

   I also checked name resolution and service discovery, and confirmed the domain controller was sharing SYSVOL and NETLOGON. Then I took a known-good snapshot named DC Promoted – AD Healthy.

   Why it matters

   These records let domain members find DC01 and the services they need to join the domain, authenticate, and pull Group Policy. It proves Active Directory and DNS are integrated correctly.

Phase 3Organize identities

1. 5

   Design the OU structure

   Instead of leaving everything in the default containers, I created a top-level Corp OU with child OUs for Users, Groups, Workstations, and Servers, and department OUs (Accounting, IT, Sales) under Users. That makes the directory easier to administer and, more importantly, gives Group Policy a clean scope for department users and workstations.

   Enlarge

   Why it matters

   This hierarchy drives the rest of the lab. The Workstations OU later receives a computer-side GPO, and the Accounting OU receives a user-side drive mapping.

2. 6

   Create domain user accounts

   I created three fictional employees in their department OUs. Each got a Department attribute matching the OU and a temporary, lab-only password that had to be changed at next sign-in.

   User	Sign-in name	OU & Department
   Maya Chen	mchen	Accounting
   Jordan Ellis	jellis	Sales
   Taylor Brooks	tbrooks	IT

   Enlarge

   Local vs. domain identity

   A local account like CLIENT01\LabAdmin exists on one computer only. An account like CORP\mchen lives in Active Directory, so it can sign in to any domain-joined computer and reach domain resources, subject to policy and group membership.

3. 7

   Build the group model with AGDLP

   I created three Global security groups for department membership (GG-Accounting, GG-Sales, GG-IT) and added each user to their department’s group. Then I created a Domain Local group, DL-AccountingShare-Modify, to represent one specific permission on one resource.

   Instead of adding Maya to the permission group directly, I nested GG-Accounting inside DL-AccountingShare-Modify. That’s the simplified AGDLP model:

   AAccountsmchen, jellis, tbrooks

   GGlobal groupsGG-Accounting, GG-Sales, GG-IT

   DLDomain LocalDL-AccountingShare-Modify

   PPermissionsSMB + NTFS on the share

   Enlarge

   Why this model scales

   The design separates who the user is from what the resource allows. If an employee changes departments, I change their Global group membership, and the file share never has to be reconfigured for one person. That’s easier to audit and maintain than putting individual users on every ACL.

Phase 4Join the workstation

1. 8

   Point CLIENT01 at AD DNS and prove discovery works

   Before the join, I set CLIENT01 to 10.77.0.20/24 with 10.77.0.10 as its default gateway and DC01 (10.77.0.10) as its preferred DNS server. DNS was the critical setting: the workstation has to query AD DNS to discover the private corp.shamarlab.test domain and its domain controller.

   CLIENT01 PowerShell, excerpt of Figure 7 Copy

   PS> ipconfig /all
      IPv4 Address. . . . . : 10.77.0.20(Preferred)
      Default Gateway . . . : 10.77.0.10
      DNS Servers . . . . . : 10.77.0.10
   
   PS> nslookup dc01.corp.shamarlab.test
   Name:    dc01.corp.shamarlab.test
   Address: 10.77.0.10
   
   PS> nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.shamarlab.test
   _ldap._tcp.dc._msdcs.corp.shamarlab.test   SRV service location:
             port         = 389
             svr hostname = dc01.corp.shamarlab.test

   Enlarge

   Reading the output

   The “DNS request timed out” and “Server: UnKnown” lines come from nslookup trying to reverse-resolve the DNS server’s own address, and this lab has no reverse lookup zone. The forward and SRV queries both answer correctly.

   Why it matters

   It proves the client can use internal DNS to locate the domain controller and the LDAP service Active Directory clients rely on, before attempting the join.

2. 9

   Join the domain and sign in as a domain user

   With discovery working, I opened System Properties, changed CLIENT01’s membership from a workgroup to the corp.shamarlab.test domain, authenticated the join with CORP\Administrator, accepted the welcome message, and restarted the workstation.

   Enlarge

   Why it matters

   Direct evidence that Maya isn’t using a local account. She’s authenticated as a CORP domain user on a domain-joined Windows 11 workstation.

3. 10

   Move the computer object into the Workstations OU

   A domain join creates a computer object in Active Directory. I moved CLIENT01 into Corp\Workstations, because the workstation baseline GPO is linked there. Object placement determines policy scope.

   Enlarge

Phase 5Administer accounts

1. 11

   Reset a password, then disable and re-enable an account

   With the domain running, I practiced everyday account administration in Active Directory Users and Computers. I reset Maya Chen’s domain password and required a change at next sign-in, which shows the difference between resetting a domain credential in Active Directory and changing a local workstation password.

   I also disabled Jordan Ellis’s account to test its Enabled/Disabled state, then re-enabled it for continued lab use. Disabling keeps the account object and its group memberships but blocks normal authentication, which is what you want for a temporary suspension or an offboarding workflow.

   Enlarge

   Why it matters

   An account can have a perfectly valid password and still be denied, because the Active Directory account itself is disabled. Access control is independent of the password.

2. 12

   Change a user’s role through group membership

   I temporarily moved Maya from Accounting to Sales: removed her from GG-Accounting, added her to GG-Sales, and changed her Department attribute to Sales. Then I restored her original state by adding GG-Accounting back, removing GG-Sales, and changing Department back to Accounting.

   That showed the difference between the two: the Department field is descriptive metadata, while security group membership is what actually drives authorization, including the file share later on.

   The security-token concept

   When group membership changes, a user who is already signed in may keep using a security token that contains the old memberships. Signing out and back in issues a fresh token, which is why access changes are usually verified after a new logon.

Phase 6Secure a resource

1. 13

   Build the Accounting share with two permission layers

   To connect the identities to a real resource, I created C:\Shares\Accounting on DC01 with an Accounting-ReadMe.txt file inside, and shared the folder as Accounting, which gives the UNC path \\DC01\Accounting.

   Layer	Granted to	Permission
   SMB share	CORP\DL-AccountingShare-Modify	Change + Read
   NTFS (Security)	CORP\DL-AccountingShare-Modify	Modify (no Full Control)
   Left intact	SYSTEM and administrative entries	Existing permissions

   That creates two authorization gates: a user must be allowed by the SMB share permission and by the NTFS ACL.

   Enlarge

   Why it matters

   The file-system permission sits on the resource-oriented Domain Local group, not on Maya. The permission chain is mchen → GG-Accounting → DL-AccountingShare-Modify → NTFS and SMB access.

2. 14

   Verify end-to-end access as Maya

   Signed in to CLIENT01 as corp\mchen, I browsed to Network › DC01 › Accounting and confirmed I could open, edit, save, create, and delete files in the share.

   Enlarge

   Effective access path

   CORP\mchen → GG-Accounting → DL-AccountingShare-Modify → SMB share permission + NTFS Modify → \\DC01\Accounting

   Why it matters

   End-to-end proof that the domain identity, the group nesting, the DNS and network path, the SMB share, and the NTFS permissions all work together.

Phase 7Centralize configuration with Group Policy

1. 15

   Computer-side GPO: a logon banner for every workstation

   I created a GPO named CORP - Workstation Baseline and linked it to Corp\Workstations. Under Computer Configuration › Policies › Windows Settings › Security Settings › Local Policies › Security Options, I set the interactive logon message:

   Policy setting	Value
   Interactive logon: Message title for users attempting to log on	ShamarLab Authorized Use
   Interactive logon: Message text for users attempting to log on	Training environment. Authorized lab use only.

   Because it’s a computer-side policy, it follows the CLIENT01 computer object. Moving CLIENT01 into the Workstations OU earlier is what put it in scope. After forcing a policy refresh and restarting CLIENT01, the banner appeared before sign-in.

   Enlarge

   Why it matters

   The workstation’s behavior changed because of a GPO linked to its OU, not because anyone configured the client by hand. That’s centralized computer configuration through Group Policy.

2. 16

   User-side Group Policy Preferences: map the Accounting drive

   I created a second GPO, CORP - Accounting Drive, and linked it to Corp\Users\Accounting. Under User Configuration › Preferences › Windows Settings › Drive Maps, I added an Update action that maps \\DC01\Accounting as the Accounting drive on letter A:.

   This policy is user-side. Maya receives it because her user object sits in the Accounting OU, so the same CLIENT01 workstation can present different settings depending on which domain account signs in.

   Enlarge

   Computer vs. user policy

   CORP - Workstation Baseline applies because CLIENT01 is in the Workstations OU. CORP - Accounting Drive applies because Maya is in the Accounting user OU. This distinction is one of the main reasons OU placement matters in Active Directory.

Final state

At the end, DC01 was the domain controller and DNS server for corp.shamarlab.test, and CLIENT01 was a working domain member. The directory had a deliberate OU hierarchy, department users, department security groups, and a nested resource-permission group. The Accounting share used the group model for authorization, and Group Policy centrally configured both a workstation setting and a user resource mapping.

Final configuration checklist

• corp.shamarlab.test forest and domain created on DC01
• DC01 provides AD DS and internal DNS at 10.77.0.10
• CLIENT01 uses 10.77.0.10 for DNS and is joined to the CORP domain
• The Corp OU contains Users, Groups, Workstations, and Servers, with department child OUs
• Maya Chen, Jordan Ellis, and Taylor Brooks exist as department domain users
• GG-Accounting, GG-Sales, and GG-IT are Global security groups
• GG-Accounting is nested inside DL-AccountingShare-Modify
• CLIENT01 resides in Corp\Workstations
• Maya can use \\DC01\Accounting through the intended group-based permission path
• CORP - Workstation Baseline applies a centralized logon banner to CLIENT01
• CORP - Accounting Drive maps the Accounting share as A: for the Accounting user scope

Skills demonstrated

Takeaway

The finished lab demonstrates the complete identity-to-resource path: build the domain, organize it, create identities and groups, join a workstation, authenticate a user, authorize a resource, and apply centralized policy.

Configuration reference