Setting Up Active Directory Domain Services (AD DS)

Almost every Active Directory attack path starts from a working domain, so being comfortable building one is worthwhile — both to understand how the pieces fit together and to stand up a lab for practising the techniques covered elsewhere on this site. This writeup walks through a complete AD DS build: installing the role, promoting the first domain controller for a brand-new forest, creating a user, joining a client, verifying the domain is healthy, and finally importing and linking Microsoft's Windows 11 security-baseline Group Policy.

Environment

Domain controller: WIN-PVE0V3E6E2T (Windows Server)
Forest / domain: schome.local
Client: HP-Envy (Windows 11)
DC IP: 192.168.29.39

Installing the AD DS Role

With a fresh Windows Server installed, open Server Manager and choose Manage → Add Roles and Features. Step through the wizard to the Server Roles page and select Active Directory Domain Services, then let the role (and its required features) install.

Add Roles and Features Wizard with Active Directory Domain Services selected — Selecting the Active Directory Domain Services role in the Add Roles and Features Wizard.

Promoting the Server to a Domain Controller

Installing the role does not create a domain on its own. Once it finishes, Server Manager shows a post-deployment notification. Click the flag icon and select Promote this server to a domain controller to launch the configuration wizard.

Post-deployment configuration prompt to promote the server to a domain controller — The post-deployment task prompts us to promote the server to a domain controller.

Because this is the first domain controller, choose Add a new forest and set the root domain name. Here the forest and domain are schome.local. Continue through the wizard — set a Directory Services Restore Mode (DSRM) password on the Domain Controller Options page, accept the DNS and default path options, let the prerequisites check pass, and install. The server reboots when the promotion completes.

Deployment Configuration page adding a new forest named schome.local — Creating a new forest with the root domain `schome.local`.

Creating a User in Active Directory

After the reboot the server is a domain controller. Open Active Directory Users and Computers (ADUC) from the Tools menu in Server Manager.

Server Manager Tools menu with Active Directory Users and Computers highlighted — Opening ADUC from the Tools menu.

The new domain already contains the default containers and built-in groups. To add a user, right-click the Users container and choose New → User.

Creating a new user object in the Users container in ADUC — Creating a new user object under `schome.local/Users`.

Fill in the account details and logon name. In this lab the account is satej.chaudhari, which becomes satej.chaudhari@schome.local (or the pre-Windows 2000 form SCHOME\satej.chaudhari). Set a password on the next page to finish creating the account.

New Object - User dialog with the account details filled in — Specifying the user's name and logon name.

Joining a Client to the Domain

Next, join a workstation to the domain. The one important prerequisite is DNS: the client's preferred DNS server must point at the domain controller (192.168.29.39), because domain join and Kerberos rely on DNS to locate the DC. On the client, run sysdm.cpl, open Change, select Domain, and enter schome.local. After supplying domain credentials, the machine joins and a "Welcome to the schome.local domain" message is shown. Reboot to complete the join.

System Properties showing the HP-Envy client joined to the schome.local domain — The HP-Envy client successfully joins the `schome.local` domain.

Verifying the Domain

From the client, nltest confirms the domain controller is reachable and advertising the expected services. A healthy response lists the DC, its address, the domain and forest names, and flags such as PDC GC DS LDAP KDC.

nltest /dsgetdc:schome.local

nltest output confirming the domain controller for schome.local — `nltest /dsgetdc` confirms the DC and that the command completed successfully.

Creating an Organizational Unit

Group Policy is applied to Organizational Units (OUs), so to test a policy cleanly it helps to create a dedicated OU. Back on the DC, create a new OU — here named GPO-Test — leaving Protect container from accidental deletion ticked.

Creating a new Organizational Unit named GPO-Test — Creating the `GPO-Test` Organizational Unit.

Move the client's computer object (HP-ENVY) out of the default Computers container and into the new OU so any policy linked to GPO-Test will apply to it. ADUC warns that moving objects can change how policy applies — which is exactly the intent here — so confirm the move.

Moving the HP-ENVY computer object into the GPO-Test OU — Moving the `HP-ENVY` computer account into the `GPO-Test` OU.

Importing the Windows 11 Security Baseline

Rather than hand-configure hardening settings, we can import Microsoft's published security baseline. Download the Windows 11 security baseline from the Microsoft Security Compliance Toolkit and extract it; the GPOs folder contains the baseline exported as GPO backups (GUID-named folders plus a manifest.xml).

Windows 11 security baseline GPO backup folders in File Explorer — The Windows 11 (25H2) security-baseline GPO backups.

In the Group Policy Management Console (GPMC), create a new GPO under Group Policy Objects — here named Win11 25H2 Baseline Test.

Creating a new GPO named Win11 25H2 Baseline Test in GPMC — Creating an empty GPO to receive the imported baseline settings.

Right-click the new GPO and choose Import Settings. The wizard asks for a backup location and then lists the backed-up GPOs it found. Select the appropriate MSFT Windows 11 baseline entry (for example the domain/member computer policy) as the source.

Selecting Import Settings on the new GPO — Starting the Import Settings wizard on the new GPO.

Import Settings wizard listing the backed-up MSFT Windows 11 baseline GPOs — Choosing the source baseline GPO to import from.

Linking and Applying the GPO

Creating the GPO does not apply it — it has to be linked to an OU. Right-click the GPO-Test OU and choose Link an Existing GPO, then select the baseline GPO.

Linking an existing GPO to the GPO-Test OU — Linking the baseline GPO to the `GPO-Test` OU.

The OU's Linked Group Policy Objects tab now shows the baseline with its link enabled, so it will apply to the computer we moved into the OU.

GPO-Test OU showing the linked Win11 25H2 Baseline Test GPO — The baseline GPO is linked to the OU and enabled.

On the client, force a policy refresh and confirm the logged-on user to verify everything is working. Both the computer and user policy should update successfully.

gpupdate
whoami

gpupdate completing successfully and whoami returning the domain user — Policy applies on the client, and `whoami` confirms the domain account `schome\satej.chaudhari`.

Reviewing and Extending the Baseline

It is worth opening the GPO in the Group Policy Management Editor to see what the baseline actually sets. Under Computer Configuration → Windows Settings → Security Settings you can review the enforced account policies, audit policy, and system-service states (for example, the startup mode of the Remote Registry service).

Group Policy Management Editor showing the baseline's System Services settings — Reviewing the baseline's enforced System Services settings.

The same editor is where you extend the policy for the environment. For instance, under Windows Defender Firewall with Advanced Security → Inbound Rules, the New Inbound Rule Wizard can add a predefined rule — such as allowing Windows Management Instrumentation (WMI) — to support remote management.

New Inbound Rule Wizard adding a predefined WMI firewall rule via GPO — Adding a predefined firewall inbound rule (WMI) through the GPO.

Conclusion

That completes a working Active Directory environment: a new forest and domain controller, a domain user, a domain-joined client, and a security baseline delivered through Group Policy. From here the same lab is a foundation for practising enumeration and the attack paths covered in the other Active Directory material on this site.

A couple of points are worth remembering. DNS is the quiet prerequisite for almost everything — domain join, Kerberos, and GPO application all depend on clients resolving the DC — so point client DNS at the domain controller first. And Group Policy only takes effect once a GPO is both linked to an OU and applied to objects within it, which the gpupdate step confirms.