To successfully migrate users, groups, computers, and associated resources from Company A's Active Directory forest to Company B's forest using the Active Directory Migration Tool (ADMT), ensuring minimal disruption, preservation of security identifiers (SIDs), and maintenance of user access to resources.

1. Understanding the Migration Scenario

In scenarios such as mergers, acquisitions, or organizational restructuring, it's often necessary to consolidate Active Directory environments. An inter-forest migration involves moving objects between two separate AD forests, which can be complex due to differences in configurations, policies, and trust relationships.

2. Pre-Migration Planning

2.1. Assess the Current Environments

• Inventory Objects: List all users, groups, computers, and service accounts in Company A's forest.
• Analyze Dependencies: Identify applications and services that rely on AD authentication.
• Review Group Policies: Document existing Group Policy Objects (GPOs) and their settings.
• Check DNS Configurations: Ensure DNS settings are correctly configured for name resolution between forests.

2.2. Define the Target Environment

• Design OU Structure: Plan the Organizational Unit (OU) hierarchy in Company B's forest to accommodate migrated objects.
• Establish Naming Conventions: Decide on consistent naming for users, groups, and computers.
• Set Up GPOs: Prepare necessary GPOs in the target environment to maintain security and compliance.

3. Establishing Trust Between Forests

3.1. Create Forest Trust

• Use Active Directory Domains and Trusts: On a domain controller in Company B's forest, open the tool and create a new forest trust pointing to Company A's forest.
• Select Trust Type: Choose "Forest Trust" and ensure it's transitive.
• Set Trust Direction: Configure the trust as two-way to allow bidirectional authentication.

3.2. Verify Trust

• Validate Trust: Use the "Validate" option to ensure the trust is functioning correctly.
• Check Name Resolution: Confirm that DNS name resolution works between forests.

4. Preparing the Migration Environment

4.1. Install ADMT

• Download ADMT: Obtain the latest version of ADMT from Microsoft's official website.
• Install on Target Domain: Set up ADMT on a member server in Company B's forest.
• Configure SQL Server: ADMT requires a SQL Server instance; install SQL Server Express if necessary.

4.2. Set Up Password Export Server (PES)

• Install PES on Source Domain: On a domain controller in Company A's forest, install the PES service.
• Generate Encryption Key: On the ADMT server, run the following command:

admt key /option:create /sourcedomain:CompanyA.local /keyfile:"C:\Key\key.pes" /keypassword:YourPassword

• Transfer Key File: Copy the generated key file to the PES server in Company A's forest.
• Configure PES: During installation, provide the path to the key file and the corresponding password.

5. Configuring Source and Target Domains

5.1. Enable Auditing

To migrate SID history, auditing must be enabled on both source and target domains.

• Edit Default Domain Controllers Policy:

  • Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy.
  • Enable "Audit account management" and "Audit directory service access" for success and failure.

• Update Group Policy:

  gpupdate /force
  

5.2. Create Migration Group

In the source domain (Company A), create a local group named CompanyA$$$. This group is required for SID history migration.

• Using Active Directory Users and Computers:
  • Create a new group in the "Users" container.
  • Name it CompanyA$$$.
  • Set the group scope to "Domain Local" and type to "Security".

5.3. Modify Registry for TcpipClientSupport

On the primary domain controller in the source domain, enable TcpipClientSupport.

• Registry Path:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  

• Add DWORD: TcpipClientSupport with a value of 1.

• Restart Server: Reboot the domain controller to apply changes.

6. Performing the Migration

6.1. Migrate Groups

• Open ADMT: Launch the ADMT console on the target domain.
• Select Group Account Migration Wizard: Follow the wizard to select source and target domains.
• Choose Groups: Select the groups to migrate.
• Configure Options:
  • Enable SID history migration.
  • Update group memberships.
• Run Migration: Execute the migration and review the logs for any errors.

6.2. Migrate Users

• Select User Account Migration Wizard: In ADMT, choose the user migration wizard.
• Choose Users: Select users from the source domain.
• Set Target OU: Specify the Organizational Unit in the target domain.
• Configure Options:
  • Migrate passwords using PES.
  • Enable SID history migration.
  • Translate roaming profiles and user rights.
• Run Migration: Start the process and monitor for issues.

6.3. Migrate Computers

• Select Computer Migration Wizard: Use ADMT to initiate computer migration.
• Choose Computers: Select the computers to migrate.
• Install Agent: ADMT will install an agent on each computer to facilitate the migration.
• Configure Options:
  • Translate local profiles.
  • Update user rights.
• Run Migration: Execute and ensure computers reboot into the new domain.

6.4. Security Translation

To maintain access to resources, perform security translation.

• Select Security Translation Wizard: In ADMT, choose this option.
• Choose Objects: Select users and computers requiring translation.
• Configure Options:
  • Translate file and folder permissions.
  • Update local group memberships.
  • Translate user profiles.
• Run Translation: Execute and verify access to resources.

7. Post-Migration Tasks

7.1. Validate Migration

• Check Object Integrity: Ensure all users, groups, and computers exist in the target domain.
• Verify Access: Confirm users can access necessary resources.
• Review Logs: Analyze ADMT logs for any errors or warnings.

7.2. Decommission Source Domain

• Disable Accounts: In Company A's domain, disable migrated user and computer accounts.
• Monitor for Issues: Wait for a predefined period to ensure stability.
• Remove Trust: Once confident, remove the trust relationship between forests.
• Decommission Domain Controllers: Safely demote and decommission domain controllers in the source domain.

Conclusion

By following this detailed guide, organizations can effectively migrate Active Directory objects between forests using ADMT. Proper planning, thorough testing, and careful execution are critical to ensure a smooth transition with minimal impact on users and services.

References

• Microsoft Learn: Active Directory Migration Tool (ADMT)
• Varonis: Active Directory Migration Tool (ADMT): Your Essential Guide
• Microsoft Docs: How to troubleshoot inter-forest sIDHistory migration with ADMTv2

Introduction

Let’s face it: the cyber threat landscape is evolving faster than ever. With more devices, more data, and more vulnerabilities, staying ahead of attackers is a serious challenge. That’s where SIEM (Security Information and Event Management) solutions come into play. These tools are like the central nervous system of modern cybersecurity operations—collecting, analyzing, and responding to security data in real-time.

In this guide, we’ll explore how to deploy one of the most popular open-source SIEM platforms: Wazuh. But this isn’t just a technical manual. We’ll dig into the what, why, and how of Wazuh, walk you through a real-world lab setup using VirtualBox, and make sure you’re not just following commands—but truly understanding the power of what you’re building.

What Exactly is Wazuh?

Imagine having eyes and ears on every server, desktop, and device in your network. That’s what Wazuh does. It’s an open-source security monitoring platform born from the original OSSEC project but now fully evolved into a modern SIEM powerhouse. Wazuh monitors your systems, detects intrusions, enforces compliance policies, analyzes logs, and helps you respond to incidents—all from one central dashboard.

Behind the scenes, Wazuh works like a well-coordinated orchestra. It has lightweight agents that sit on each machine, keeping tabs on system activity. These agents send data to a manager component that processes everything using a ruleset. Then, the indexer (a customized Elasticsearch fork) stores and structures that data, and finally, the dashboard (based on Kibana) lets you visualize and interact with the alerts and events.

Wazuh can be deployed in the cloud, on-premises, or in hybrid environments. It supports Windows, Linux, macOS, and even Docker containers. Whether you’re monitoring a few endpoints or thousands, Wazuh is built to scale.

Why Wazuh and Not Something Else?

There are plenty of commercial SIEMs out there—Splunk, QRadar, ArcSight to name a few. But here’s the kicker: they can be expensive, complex to license, and not always customizable. Wazuh flips the script. It’s free, open-source, and incredibly powerful. You get full control over your SIEM stack with no vendor lock-in.

On top of that, Wazuh integrates seamlessly with the Elastic Stack, so you can leverage the speed and scalability of Elasticsearch along with the visualization power of Kibana. And with features like active response, compliance auditing, and file integrity monitoring baked in, it’s more than just a log collector—it’s a full-fledged security operations platform.

How Wazuh Works – The Magic Behind the Curtain

Think of Wazuh as a five-layer system. First, you have the Wazuh Agents, tiny programs installed on endpoints that watch everything—logins, file changes, system events. They talk securely to the Wazuh Manager, which processes all that juicy data, comparing it against known rules and generating alerts when something fishy happens.

Next comes Filebeat, a log shipper that ferries the alerts from the manager to the Wazuh Indexer. This indexer is like a giant library that catalogs every alert and log entry so you can search, filter, and analyze them in real time. Finally, the Wazuh Dashboard gives you a sleek web interface to visualize it all. Pie charts, timelines, filters—you name it. It’s like your security command center.

Altogether, these components create a closed-loop system that detects, processes, stores, and visualizes every event across your network.

Why Build This Lab?

If you want to understand cybersecurity, theory isn’t enough. You need practice. This lab simulates a real-world enterprise setup with multiple endpoints, a firewall, and centralized SIEM monitoring. You’ll not only install Wazuh, but configure a firewall (pfSense), generate network traffic, simulate attacks, and watch the alerts pop up live.

It’s the perfect playground for students, aspiring SOC analysts, blue teamers, or IT admins making the leap into cybersecurity. And since we’re using VirtualBox, you don’t need expensive hardware or cloud infrastructure. Just a decent PC and some time to tinker.

The Lab Setup – What You’re Building

We’re building a mini enterprise network inside your Windows 11 machine using VirtualBox. Picture this: your host machine is running four virtual machines. One is a firewall to segment the network and simulate real-world conditions. Two are Wazuh components—one for the indexer and one for the server/dashboard. And then you’ve got two endpoints—a Linux desktop and a Windows machine—to act as monitored systems.

The internal network is set to 10.10.20.0/24. The firewall has IP 10.10.20.1 and connects to the internet via NAT. The Wazuh Indexer gets 10.10.20.10, and the Server/Dashboard takes 10.10.20.11. The endpoints get their IPs via DHCP. Each VM is carefully configured with realistic resource allocations to mimic production behavior.

Getting Started – Prepare the Playground

First, install VirtualBox and its Extension Pack from the official website. You’ll also need the ISO files for Ubuntu Server, Ubuntu Desktop, Windows 10 or 11, and pfSense. Create a host-only network in VirtualBox to simulate your internal lab network. Let’s call it vboxnet0. Disable its DHCP server—we’ll assign static IPs manually for consistency.

Start by setting up the pfSense firewall. Give it two network adapters: one NAT (for internet access) and one on vboxnet0 for LAN. Install pfSense, configure interfaces, and assign the LAN IP to 10.10.20.1.

Next, create the Wazuh Indexer VM. Use Ubuntu Server, allocate 3GB RAM and 2 CPUs. Assign it IP 10.10.20.10 and install the Wazuh Indexer using official packages. Repeat the process for the Wazuh Server/Dashboard VM, assigning IP 10.10.20.11 and installing the Wazuh manager, Filebeat, and the dashboard.

Finally, spin up your Linux and Windows endpoints. Use DHCP to assign them IPs automatically. These will serve as monitored systems, where you’ll install the Wazuh agent and simulate events.

Installing the Pieces – Step by Step

On the Wazuh Indexer VM:

sudo apt update && sudo apt install wazuh-indexer -y

On the Wazuh Server/Dashboard VM:

sudo apt update && sudo apt install wazuh-manager filebeat wazuh-dashboard -y

Enable and start the services, then access the dashboard via https://10.10.20.11. Default login is admin/admin. Make sure to change the password after logging in.

On your Linux endpoint:

curl -sO https://packages.wazuh.com/4.x/apt/install.sh
sudo bash install.sh --agent
sudo /var/ossec/bin/agent-auth -m 10.10.20.11
sudo systemctl enable --now wazuh-agent

On the Windows endpoint, download the agent installer from the Wazuh site, install it, and configure it to point to the manager’s IP.

Watching It All Come Together

Log in to your Wazuh dashboard and navigate to the Agents tab. If everything’s working, you’ll see your endpoints listed and connected. Trigger some events—like modifying system files, creating users, or installing software—and watch the alerts roll in.

This is the real magic of Wazuh. You get full visibility across your systems, real-time alerting, and an intuitive dashboard to manage everything.

Where to Go From Here

Once your lab is running, don’t stop there. Try integrating threat intelligence feeds. Tune the rules to reduce false positives. Enable email or Slack notifications. You can also explore advanced log pipelines using Logstash, or even forward logs from cloud services into Wazuh.

This lab is just the beginning. Mastering Wazuh means diving deep into alert tuning, detection engineering, and automation. It’s your first step into the world of blue team operations.

References

Wazuh Official Docs: https://documentation.wazuh.com
Elastic Stack Overview: https://www.elastic.co/what-is/elk-stack
Wazuh GitHub: https://github.com/wazuh/wazuh
pfSense Firewall: https://www.pfsense.org/download/
Filebeat Documentation: https://www.elastic.co/guide/en/beats/filebeat/current/index.html
OSSEC Project: https://www.ossec.net
SANS SIEM White Papers: https://www.sans.org/white-papers/siem/
Compliance Features: https://documentation.wazuh.com/current/compliance/index.html

This guide is designed to empower curious minds to build real security solutions with real tools. Stay tuned for upcoming posts on detection tuning, active response, and cloud SIEM integration.