Windows Active Directory Hardening in Action

Picture generated by DALL-E

The security of Active Directory is often a critical concern, as it is responsible for managing user identities, providing essential services, and much more. Ensuring the security of this key infrastructure element is, therefore, absolutely crucial. This guide outlines fundamental concepts and simplified principles for hardening Windows and Active Directory, focusing on the Group Policy mechanism and its monitoring.

Shortly about AD

Active Directory consists of various objects, such as computers, users, groups, printers, and other services (e.g., applications, shared folders). When discussing computers in AD, this includes servers, which can serve as either Domain Controllers (DCs) or Member Servers (MSs).

• Domain Controller (DC): A server hosting the Active Directory Domain Services (AD DS) role, responsible for managing authentication, identity, and access within a domain. Sometimes, DCs are considered a distinct object type due to their critical role in the infrastructure.
• Member Server (MS): A server joined to the Active Directory domain that runs applications or services (e.g., file servers, web servers, SQL servers). Member Servers rely on the DC for authentication and authorization.

All these objects are organized into Organizational Units (OUs) — logical groupings for objects like user accounts, service accounts, or computer accounts. OUs can be structured based on departments (e.g., HR, IT, Accounting), resources (e.g., servers, printers, DCs), or security requirements (e.g., Restricted Access, Standard Access).

To configure objects in AD granularly, Group Policies are used.

• Group Policy Object (GPO), or simply Policy: A set of rules and requirements applied to target objects, such as enforcing password complexity or restricting certain actions on computers. GPOs enforce settings on users and computers.
• Group Policy Object Templates: Templates from which GPO definitions are derived, specifying what settings can be enforced.

Typically, GPOs are linked to Organizational Units or even the Domain Root (applying to all objects in the domain). However, Local Group Policies can also be configured on individual computers, independently of AD. A notable feature of Group Policies is that a single GPO can be created and linked to multiple OUs simultaneously, enabling efficient management across the domain.

Setup

This setup is based on Windows Server 2022 (en-US); however, the logic applies to all Windows Server versions newer than Windows Server 2000.

Virtual Machines

First, download the Windows Server 2022 ISO image. For our purposes, a license is not required, as the 90-day trial period is more than sufficient.

Let’s create two virtual machines using VirtualBox as the hypervisor in this example.

• Windows DC: This will serve as the future Domain Controller (DC) of our Active Directory.
• Windows Client: This will serve as the future Member Server in our Active Directory.

Virtual Network

Setting up the network is crucial, as all instances need to communicate with each other. To establish connectivity, a network interface with a DHCP server is created in VirtualBox. I named it vboxnet0. This step is necessary to create a virtual network within the current virtualization context.

The network is configured as 192.168.56.1/24. Each virtual machine needs to be set to use a Host-Only adapter for connectivity.

Finally:

• Domain Controller IP address: 192.168.56.5
• Member Server IP address: 192.168.56.6

If internet access is required, an additional NAT or Bridged adapter can be added. The only prerequisite is that the host machine must have internet access.

Domain Controller

One instance will be set up as the Domain Controller. To configure it, start Server Manager and launch the Add Roles and Features Wizard. Choose the Role-based or feature-based installation option to proceed.

The Active Directory Domain Services (AD DS) role is selected, along with essential tools such as Group Policy Management and AD DS Tools.

After installing the AD DS role, the server is promoted to a Domain Controller. This process involves creating or joining a domain, configuring DNS, and setting a Directory Services Restore Mode (DSRM) password. For this setup, the domain name ad.roman.az was selected.

The promotion establishes the server as the central system for authentication and directory management within the domain. It enables the server to manage users, computers, and Group Policies, providing centralized control over the domain environment.

Member Server

Before proceeding, we need to resolve the domain resolution issue. The problem is that ad.roman.az is currently known only to the Domain Controller (DC). For Active Directory to function properly, the DC must participate in domain name resolution. The simplest solution is to set the Domain Name Server (DNS) address to the DC’s IP address in the network adapter settings.

Once the network setup is complete, we can connect the “Windows Client” to the domain by navigating to System Properties > Computer Name > Change and selecting Domain. In the provided field, enter the Active Directory (AD) domain name.

After the reboot, we can open System Properties again to verify the changes.

Duality of Accounts

From this point onward, there are two types of accounts:

1. Domain Accounts: Accounts created and managed by Active Directory (AD).
2. Local Accounts: Accounts created directly on the machine, such as the Administrator account set up during the operating system installation.

Recommendations of CIS Benchmark

As a security standard, the recommendations from the Center for Internet Security’s (CIS) Windows Server 2022 Benchmark v2.0 are used. These recommendations are available as a PDF document or online but require a CIS Workbench account for access. The materials are comprehensive, providing detailed descriptions and highlighting all the necessary requirements.

The advantage of these recommendations is that most of them can be implemented through the AD Group Policy mechanism. This ensures that whenever a machine joins the domain, it automatically receives the necessary security configurations enforced by the policies.

Some policies are quite harsh and may be not applicable everywhere.

The recommendations are divided into three levels:

• L1: General recommendations applicable to all servers, focusing on practical and prudent security measures.
• L2: Designed for environments where security is critical.
• NG (Next Generation Security): Advanced Windows security features that have specific configuration dependencies and may not be compatible with all systems.

Additionally, recommendations are categorized as DC Only or MS Only, indicating whether they are specifically for Domain Controllers or Member Servers, respectively.

It’s important to note that no system is ever 100% secure. Security often requires a trade-off with functionality, and compromises are sometimes necessary to maintain operational balance.

Group Policy Templates

GPO templates

By default, Windows Server provides a wide range of policy templates out of the box. However, these templates do not cover every possible setting, so additional templates may be required.

As an example, there are additional Microsoft Administrative Templates for the MS Office, or Google Chrome Group Policy Administrative Templates. Templates Required for CIS Compliance

To ensure compliance with the CIS Benchmark, the following templates are needed:

• Standard Windows Server 2022 Administrative Templates: Included by default.
• Administrative Templates for Windows 11 (September 2022 Update): For managing policies on systems running Windows 11.
• PerfTrack Policy Template: Used for performance tracking configurations.
• MSS Legacy Templates: For managing legacy security settings.

To simplify the process, I compiled all the necessary templates into a single GitHub repository: Awesome-GPO-Templates-Windows-Server-2022.

Each template consists of two files:

• ADMX (or ADM for older versions): The template itself.
• ADML: Provides localization information, such as displaying policy settings in the appropriate language.

Installation

Normally, we have to put all ADMX files to the C:\Windows\PolicyDefinitions and ADML files to the corresponding language folder of that directory (en-US in our case). Nevertheless, that folder is used by Local Group Policy Editor. If we want to use our policies across the Domain Controller it is not an appropriate choice. That is why we should consider two paths:

• \\ad.roman.az\SYSVOL\ad.roman.az\Policies\PolicyDefinitions — a shared directory of the domain that plays a role of the Central Store. By default, the is no PolicyDefinitions folder, so we need to create it in advance. Then, just put all ADMX/ADML files here as in Local Group Policies case.
• C:\Windows\SYSVOL\sysvol\ad.roman.az\Policies — replication of the Central Store in Domain Controller. DC simply copies that folder and then uses it. Therefore, there is no need to copy ADML/ADMX files to the different DC if we have more that one.

Finally, we should see the message in the Group Policy Editor that all administrative templates are retrieved from the Central Store.

A cool thing is that there is no need to copy or replicate templates to the Member Servers and other computers/objects since they will receive actual configs/registry settings, not ADMX/ADML files.

Writing Policies

The first thing that comes to mind is to write one policy per one CIS recommendation.

… and then link it to the Domain Root so all objects in AD get that policies and start to be “secure”.

However, the current approach is not practical due to the following challenges:

1. Controller Login: Instead of sending a single “big pack of settings,” the Domain Controller (DC) must transmit numerous smaller settings, which the target computer then applies one by one. This can cause delays during the login process and may overload the DC.
2. Heterogeneous Objects: Not all computers and servers should receive the same policies. For instance, MS Only policies are not applicable to Domain Controllers. To ensure granularity, policies should be assigned to Organizational Units (OUs) that correspond to their purpose and required security level.

To address these issues, it is better to create OUs and organize the CIS recommendations into multiple policies based on their specific nature and applicability.

Helpful Commands

• gpupdate: Refreshes local policy data, applying any new policies or updating existing ones.
• gpupdate /force: Forces a complete reapplication of all policies, overwriting local data.
• gpresult /r: Displays a summary of applied and declined policies.
• gpresult /h GPReport.html: Generates a detailed HTML report of the applied policies and their settings.

Installing Ready Policies

If we look to the \\ad.roman.az\SYSVOL\ad.roman.az\Policies\ directory, it seems to be technically possible to just copy all the folders with policies (named after their GUIDs) and put it here.

To simplify the job, Microsoft Security Compliance Toolkit with Windows Server 2022 Security Baseline can used. To install it, we need to download the achieve with the policies and execute Baseline-ADImport.ps1 script to import that policies to AD. Unfortunately, they do not cover all requirements of CIS and still manual work or better policies dumps is required.

Monitoring

Monitoring can be implemented by Wazuh — free SIEM and XDR. To make it simpler I just download and deploy VM Box of Wazuh from the official web-site.

Of course, Wazuh needs to be in the same network as the other machines, so we configure it to use the same Host-Only adapter. Once set up, the Wazuh dashboard can be accessed at: https://192.168.56.7/app/wz-home. The default credentials are admin:admin.

Each target machine needs to download the Wazuh agent. To do this, navigate to: Server Management > Endpoint Summary > Deploy Agent in the Wazuh dashboard.

Execute the provided PowerShell script as an administrator on the target machine. Note that admin privileges and internet access are required. Once the script is executed, start the Wazuh agent service.

In addition to regular monitoring, you can evaluate compliance levels using the Security Configuration Assessment (SCA) Module. To do this, navigate to Endpoint Summary, select Configuration Assessment, and choose the target agent.

In contrast, this is the same machine after joining the Active Directory (AD) and having all policies applied.

Much better. Fun fact: if the machine leaves the domain, the vast majority of policies will lose their effect, leaving you with fewer than 40 policies again.

Conclusion

Active Directory (AD) is a powerful tool for centralized management, enabling streamlined control over users, computers, and security policies. By properly configuring OUs, applying CIS Benchmarks, and leveraging Group Policies, administrators can enhance security and ensure compliance. However, maintaining AD requires careful planning, as changes like joining or leaving the domain significantly impact policy enforcement. With tools like Wazuh for monitoring and compliance assessment, organizations can further strengthen their security posture while maintaining operational efficiency.

Disclaimer

The configurations and recommendations provided in this guide are intended primarily for lab environments and testing purposes. While they may serve as a foundation for real-world implementations, they should be thoroughly evaluated and adapted to meet the specific needs and security requirements of your production environment. The authors are not responsible for any issues or damages resulting from the application of this information. Always consult with qualified IT professionals and refer to official documentation when implementing security measures or configuring Active Directory.