This document describes a Windows-focused virtual lab for blue team and Security Operations Center (SOC) training.
The lab is built entirely from defensive components:
- Windows Active Directory domain
- Multiple Windows clients and servers
- pfSense virtual firewall/router
- Central logging and monitoring (SIEM-style)
- Optional SOAR-style automation and deception/honeypot hosts
There are no dedicated attacker machines in this design. It is intended to:
- Generate realistic Windows security telemetry
- Practice log collection, correlation, and alerting
- Exercise incident triage and response playbooks
- Integrate later with a separate offensive lab if desired
This section explains why each tool was chosen for this Windows Security Operations Lab, how it compares to alternatives, and its viability in 2026 and beyond.
Why QEMU/KVM?
- Open-source and actively maintained: QEMU/KVM is the standard Linux virtualization solution, with continuous development and security updates as of 2026.
- Performance: Near-native performance with hardware acceleration (Intel VT-x/AMD-V), essential for running multiple Windows VMs simultaneously.
- Cost: Free and open-source, unlike VMware vSphere or Hyper-V Server (which requires Windows Server licensing).
- Integration: Native integration with Linux hosts, perfect for security professionals already using Linux.
Alternatives Considered:
- VMware Workstation: Commercial, requires licensing. Better GUI but QEMU/KVM + virt-manager provides equivalent functionality for free.
- VirtualBox: Free but lower performance, especially for Windows Server workloads. QEMU/KVM offers better I/O performance.
- Hyper-V: Windows-only, requires Windows Server host. QEMU/KVM works on any Linux distribution.
2026+ Viability: ✅ Excellent - QEMU 8.0+ and KVM are actively developed, support latest Windows Server 2022 and Windows 11, and receive regular security patches.
Why libvirt/virt-manager?
- Standard tooling: libvirt is the de-facto standard for Linux VM management, used by major cloud providers and enterprise environments.
- CLI and GUI:
virsh(CLI) andvirt-manager(GUI) provide flexibility for both automation and manual management. - Network management: Built-in network creation and management (
virsh net-*commands) simplifies lab networking. - Compatibility: Works seamlessly with QEMU/KVM, no additional licensing.
Alternatives Considered:
- Cockpit: Web-based management, good for remote access but virt-manager provides better local VM console experience.
- Proxmox: Full hypervisor platform, overkill for a lab environment. libvirt is lighter and more flexible.
2026+ Viability: ✅ Excellent - libvirt 10.0+ actively maintained, virt-manager receives regular updates, full Windows 11/Server 2022 support.
Why pfSense?
- Enterprise-grade: pfSense is based on FreeBSD and used in production environments worldwide, providing realistic firewall experience.
- Feature-rich: Includes stateful firewall, NAT, VPN, IDS/IPS capabilities, traffic shaping, and extensive logging.
- Free: Community Edition (CE) is free and fully functional for lab use.
- Windows integration: Works seamlessly with Windows Event Log forwarding and can integrate with Windows SIEM solutions.
Alternatives Considered:
- OPNsense: pfSense fork with modern UI, but pfSense has larger community and more documentation.
- VyOS: CLI-only, steeper learning curve. pfSense web UI is more accessible for lab learning.
- iptables/netfilter: Native Linux but requires extensive configuration. pfSense provides GUI and better Windows integration.
2026+ Viability: ✅ Excellent - pfSense CE 2.7+ actively maintained, regular security updates, supports modern protocols (TLS 1.3, IPv6, etc.).
Why Windows AD?
- Industry standard: Active Directory is the dominant directory service in enterprise Windows environments (estimated 90%+ market share).
- Real-world relevance: Learning AD is essential for Windows security professionals, as most Windows attacks target AD.
- Rich telemetry: AD generates extensive security logs (logon events, privilege changes, object access) perfect for SOC training.
- Integration: Native integration with Windows Event Forwarding, Group Policy, and Windows security tools.
Alternatives Considered:
- Samba AD: Open-source AD implementation, but lacks some advanced features and has compatibility issues with some Windows tools.
- FreeIPA: Linux-focused, doesn't provide Windows AD experience needed for blue team training.
2026+ Viability: ✅ Excellent - Windows Server 2022 AD DS is current, Microsoft continues active development, AD remains core to Windows security.
Why WEC?
- Native Windows solution: Built into Windows Server, no additional licensing or installation required.
- Efficient: Uses Windows Remote Management (WinRM) for secure, efficient log forwarding.
- Standard protocol: Uses standard Windows Event Log format, compatible with all Windows SIEM solutions.
- Group Policy integration: Can be deployed and configured via Group Policy across entire domain.
Alternatives Considered:
- NXLog: Third-party log forwarder, requires licensing for advanced features. WEC is free and native.
- Winlogbeat: Part of Elastic Stack, good for ELK but WEC is more universal and works with any SIEM.
2026+ Viability: ✅ Excellent - WEC is core Windows functionality, fully supported in Windows Server 2022 and Windows 11.
Why Sysmon?
- Microsoft tool: Free, officially supported by Microsoft, regularly updated with new detection capabilities.
- Comprehensive: Tracks process creation, file creation, network connections, registry changes, and more.
- Industry standard: Used by security teams worldwide, extensive community configurations available (SwiftOnSecurity, etc.).
- SIEM integration: Generates Windows Event Logs that integrate seamlessly with WEC and SIEM platforms.
Alternatives Considered:
- Process Monitor (ProcMon): GUI tool, not suitable for continuous monitoring and SIEM integration.
- ETW (Event Tracing for Windows): Lower-level, requires more configuration. Sysmon provides higher-level, security-focused events.
2026+ Viability: ✅ Excellent - Sysmon 15.0+ actively maintained by Microsoft, latest version supports Windows 11 and Server 2022, regular updates with new detection capabilities.
Why Multiple Options? Different SIEMs serve different use cases and learning objectives:
Wazuh:
- Open-source: Free, no licensing restrictions, perfect for learning.
- Comprehensive: Includes HIDS, log analysis, vulnerability detection, and compliance monitoring.
- Active development: Regularly updated, active community, good documentation.
- Windows integration: Native Windows agent, excellent Sysmon integration.
Splunk Enterprise:
- Industry leader: Most widely used SIEM in enterprise environments (Fortune 500 companies).
- Powerful: Advanced search, correlation, and visualization capabilities.
- Evaluation available: 60-day free evaluation, perfect for lab learning.
- Career relevance: Learning Splunk is valuable for SOC analyst careers.
Graylog:
- Open-source core: Free open-source version available.
- Modern interface: Clean web UI, good for learning log analysis concepts.
- Elasticsearch backend: Uses Elasticsearch for storage, good performance.
2026+ Viability:
- Wazuh: ✅ Excellent - Version 4.7+ actively maintained, regular releases, strong Windows support.
- Splunk: ✅ Excellent - Industry standard, continuous development, latest version supports modern Windows.
- Graylog: ✅ Good - Active development continues, though smaller community than Wazuh/Splunk.
Recommendation: Start with Wazuh for free, comprehensive learning. Use Splunk evaluation if you want enterprise experience.
Why PowerShell?
- Native Windows: Built into Windows Server and Windows 10/11, no additional installation required.
- Powerful: Can manage AD, Windows services, event logs, registry, and more.
- Industry standard: Used by Windows administrators and security professionals worldwide.
- SOAR integration: Most Windows SOAR platforms use PowerShell for automation.
Alternatives Considered:
- Python: Cross-platform but requires installation, less native Windows integration.
- Bash: Not native to Windows, requires WSL or additional tools.
2026+ Viability: ✅ Excellent - PowerShell 7+ (cross-platform) and Windows PowerShell 5.1 actively maintained, core to Windows administration.
Why These Versions?
- Windows Server 2022: Latest stable release as of 2026, includes latest security features and AD improvements.
- Windows Server 2019: Still widely deployed in enterprises, learning both versions provides broader experience.
- Windows 11: Current client OS, represents modern Windows security features.
- Windows 10: Still common in enterprises, provides compatibility testing.
2026+ Viability: ✅ Excellent - All versions receive security updates, Windows Server 2022 supported until 2031, Windows 11 is current.
The tables below assume all VMs for a given lab profile are powered on simultaneously.
| Lab Profile | Intended Use | Minimum Host CPU | Recommended Host CPU | Minimum Host RAM | Recommended Host RAM | Minimum Free Disk | Recommended Free Disk |
|---|---|---|---|---|---|---|---|
| Profile A – Core AD + Logging | Single DC, 1 SIEM/server, 1–2 clients | 4 cores | 6–8 cores | 16 GB | 24 GB | 300 GB | 400 GB |
| Profile B – SOC Monitoring Lab | DC, file server, SIEM server, 2–3 clients | 6 cores | 8–12 cores | 24 GB | 32 GB | 450 GB | 600 GB |
| Profile C – SOC + Deception Lab | Redundant DCs, SIEM, honeypot, 3–4 clients | 8 cores | 12–16 cores | 32 GB | 48 GB | 600 GB | 800 GB+ |
Notes
- Use thin-provisioned virtual disks (e.g.,
qcow2) wherever possible. - If resources are tight, power off non-essential clients while focusing on server configuration.
All lab profiles share a similar high-level design:
- A single routed internal network (for example,
10.10.0.0/24) - A pfSense VM acting as:
- Default gateway
- Firewall between the lab and any external network
- Optional DHCP server for the internal segment
- Optional DNS forwarder
- One or more Windows Server hosts providing:
- Active Directory Domain Services (AD DS)
- DNS for the Windows domain
- Additional roles such as file services, logging collectors, and security tooling
- Multiple Windows 10/11 clients joined to the domain
Example internal addressing (you may adjust the exact ranges):
- pfSense LAN:
10.10.0.1/24 - Domain Controller(s):
10.10.0.10–11 - Member servers (file, SIEM, automation, honeypot):
10.10.0.20–39 - Clients:
10.10.0.100–150
Goal: A compact Windows domain with centralized logging suitable for:
- Practicing Active Directory administration
- Enabling Windows Event Forwarding (WEF/WEC)
- Sending events to a local SIEM-style instance on a Windows server
graph TB
subgraph Edge["pfSense Firewall / Router"]
PFS["pfSense VM<br/>WAN: DHCP / NAT<br/>LAN: 10.10.0.1/24"]
end
subgraph Domain["Windows Domain: corp.local (10.10.0.0/24)"]
DC1["DC1 - Windows Server 2019/2022<br/>Domain Controller + DNS<br/>10.10.0.10"]
SOC1["SOC-SRV - Windows Server 2019/2022<br/>Event Collector + SIEM-style Server<br/>10.10.0.20"]
WIN1["WIN10-1 - Windows 10/11 Pro<br/>Domain-Joined Client<br/>10.10.0.101"]
WIN2["WIN10-2 - Windows 10/11 Pro (optional)<br/>Domain-Joined Client<br/>10.10.0.102"]
end
PFS --- DC1
PFS --- SOC1
PFS --- WIN1
PFS --- WIN2
DC1 --- SOC1
WIN1 --- SOC1
WIN2 --- SOC1
| VM Name / Role | OS | vCPU (Min / Rec) | RAM (Min / Rec) | Disk (Min / Rec) | NICs | Primary Purpose |
|---|---|---|---|---|---|---|
| PFS (pfSense) | pfSense CE | 1 / 2 cores | 1 GB / 2 GB | 16 GB / 20 GB | 2 (WAN, LAN) | Gateway, firewall, DHCP/DNS forwarder |
| DC1 (Domain Controller) | Windows Server 2019/2022 | 2 / 4 cores | 4 GB / 8 GB | 60 GB / 80 GB | 1 (LAN) | AD DS, DNS for corp.local, optional DHCP |
| SOC-SRV (Logging / SIEM-style) | Windows Server 2019/2022 | 2 / 4 cores | 6 GB / 8–12 GB | 100 GB / 150 GB | 1 (LAN) | Windows Event Collector (WEC), Sysmon logs, SIEM-style dashboarding |
| WIN10-1 (Client) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 6 GB | 50 GB / 60 GB | 1 (LAN) | Standard domain workstation for user activity |
| WIN10-2 (Optional Client) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 6 GB | 50 GB / 60 GB | 1 (LAN) | Additional workstation for testing policies and multiple users |
Recommended defensive configuration in this profile:
-
On DC1
- Install and configure Active Directory Domain Services and DNS.
- Enable advanced auditing (account logon, object access, policy changes, etc.).
- Configure Group Policy to:
- Deploy Sysmon configuration to clients and servers.
- Enable Windows Event Forwarding to
SOC-SRV.
-
On SOC-SRV
- Configure Windows Event Collector (WEC) subscriptions to receive logs from:
- Domain Controller (
DC1) - All domain-joined clients (
WIN10-*)
- Domain Controller (
- Install a SIEM-style solution on Windows Server (for example, an evaluation or free tier) to:
- Ingest Windows Security, Sysmon, and Application logs.
- Build simple dashboards (logon failures, new logon types, service installations).
- Configure baseline alerts (e.g., repeated failed logons, new service creation).
- Configure Windows Event Collector (WEC) subscriptions to receive logs from:
-
On Clients
- Join each client to the
corp.localdomain. - Apply Group Policies for:
- Sysmon installation and configuration.
- Forwarding of key event channels to
SOC-SRV.
- Join each client to the
Goal: Expand the environment into a small SOC lab with:
- A dedicated file/utility server
- A more capable SIEM server
- 2–3 domain-joined clients
graph TB
subgraph Edge["pfSense Firewall / Router"]
PFSB["pfSense VM<br/>WAN: DHCP / NAT<br/>LAN: 10.20.0.1/24"]
end
subgraph DomainB["Windows Domain: blue.local (10.20.0.0/24)"]
DCB["DC1 - Windows Server 2019/2022<br/>Domain Controller + DNS<br/>10.20.0.10"]
FILEB["FILE-SRV - Windows Server 2019/2022<br/>File / Utility Server<br/>10.20.0.20"]
SIEMB["SIEM-SRV - Windows Server 2019/2022<br/>Central SIEM-Style Platform<br/>10.20.0.30"]
MGMTB["SEC-MGMT - Windows 10/11 Pro<br/>Analyst / Admin Workstation<br/>10.20.0.40"]
C1B["WIN10-1 - Client 1<br/>10.20.0.101"]
C2B["WIN10-2 - Client 2<br/>10.20.0.102"]
C3B["WIN10-3 - Client 3 (optional)<br/>10.20.0.103"]
end
PFSB --- DCB
PFSB --- FILEB
PFSB --- SIEMB
PFSB --- MGMTB
PFSB --- C1B
PFSB --- C2B
PFSB --- C3B
DCB --- SIEMB
FILEB --- SIEMB
C1B --- SIEMB
C2B --- SIEMB
C3B --- SIEMB
MGMTB --- SIEMB
| VM Name / Role | OS | vCPU (Min / Rec) | RAM (Min / Rec) | Disk (Min / Rec) | NICs | Primary Purpose |
|---|---|---|---|---|---|---|
| pfSense (PFSB) | pfSense CE | 2 / 2 cores | 2 GB / 2–4 GB | 20 GB / 30 GB | 2 | Gateway, firewall, DHCP/DNS relay or forwarder |
| DC1 (DCB) | Windows Server 2019/2022 | 2 / 4 cores | 4 GB / 8 GB | 60 GB / 80 GB | 1 | Domain Controller, DNS for blue.local |
| FILE-SRV (FILEB) | Windows Server 2019/2022 | 2 / 4 cores | 4 GB / 8 GB | 80 GB / 120 GB | 1 | File shares, script storage, log archive share |
| SIEM-SRV (SIEMB) | Windows Server 2019/2022 | 3 / 4–6 cores | 8 GB / 12–16 GB | 150 GB / 200–300 GB | 1 | SIEM platform, event collector, correlation and alerting |
| SEC-MGMT (MGMTB) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 8 GB | 60 GB / 80 GB | 1 | Security analyst workstation with consoles, dashboards, and tools |
| WIN10-1 (C1B) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 6 GB | 50 GB / 60 GB | 1 | Standard user workstation |
| WIN10-2 (C2B) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 6 GB | 50 GB / 60 GB | 1 | Standard user workstation |
| WIN10-3 (C3B, Optional) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 6 GB | 50 GB / 60 GB | 1 | Additional client for load and policy testing |
In this profile, you can practice:
-
Centralized logging
- Configure
SIEM-SRVto ingest:- Windows Security and Sysmon logs from all servers and clients
- File access logs from
FILE-SRV
- Use subscriptions and agents appropriate to your chosen platform.
- Configure
-
SOC workflows
- Use
SEC-MGMTas the analyst console:- SIEM web interface
- Remote Event Viewer and PowerShell remoting
- Documentation and runbooks
- Use
-
File server monitoring
- On
FILE-SRV, enable advanced auditing for:- File read/write/delete on specific shares
- Permission changes and ownership changes
- Forward these events into
SIEM-SRVfor correlation.
- On
Goal: Extend the SOC lab with deception techniques by adding a highly monitored honeypot server in the Windows environment.
graph TB
subgraph Edge["pfSense Firewall / Router"]
PFSC["pfSense VM<br/>WAN: DHCP / NAT<br/>LAN: 10.30.0.1/24"]
end
subgraph DomainC["Windows Domain: sec.lab (10.30.0.0/24)"]
DC1C["DC1 - Windows Server 2019/2022<br/>Primary DC + DNS<br/>10.30.0.10"]
DC2C["DC2 - Windows Server 2019/2022<br/>Secondary DC + DNS<br/>10.30.0.11"]
SIEMC["SIEM-SRV - Windows Server 2019/2022<br/>Central SIEM-style Platform<br/>10.30.0.30"]
HONEYC["HONEY-SRV - Windows Server 2019/2022<br/>Deception / Honeypot Server<br/>10.30.0.40"]
MGMT2C["SEC-MGMT - Windows 10/11 Pro<br/>Analyst Workstation<br/>10.30.0.50"]
C1C["WIN10-1 - Client 1<br/>10.30.0.101"]
C2C["WIN10-2 - Client 2<br/>10.30.0.102"]
C3C["WIN10-3 - Client 3 (optional)<br/>10.30.0.103"]
end
PFSC --- DC1C
PFSC --- DC2C
PFSC --- SIEMC
PFSC --- HONEYC
PFSC --- MGMT2C
PFSC --- C1C
PFSC --- C2C
PFSC --- C3C
DC1C --- SIEMC
DC2C --- SIEMC
HONEYC --- SIEMC
C1C --- SIEMC
C2C --- SIEMC
C3C --- SIEMC
| VM Name / Role | OS | vCPU (Min / Rec) | RAM (Min / Rec) | Disk (Min / Rec) | NICs | Primary Purpose |
|---|---|---|---|---|---|---|
| pfSense (PFSC) | pfSense CE | 2 / 3–4 cores | 2 GB / 4 GB | 20 GB / 30 GB | 2 | Gateway, firewall, optional additional interfaces if you split subnets later |
| DC1 (DC1C) | Windows Server 2019/2022 | 2 / 4 cores | 4 GB / 8 GB | 60 GB / 80 GB | 1 | Primary DC, holds FSMO roles, DNS for sec.lab |
| DC2 (DC2C) | Windows Server 2019/2022 | 2 / 4 cores | 4 GB / 8 GB | 60 GB / 80 GB | 1 | Secondary DC for redundancy and replication testing |
| SIEM-SRV (SIEMC) | Windows Server 2019/2022 | 3 / 4–6 cores | 8 GB / 12–16 GB | 200 GB / 300 GB+ | 1 | Central log storage, correlation, dashboards, and alerting |
| HONEY-SRV (HONEYC) | Windows Server 2019/2022 | 2 / 4 cores | 4 GB / 8 GB | 80 GB / 120 GB | 1 | Deception host with deliberately exposed but closely monitored services |
| SEC-MGMT (MGMT2C) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 8 GB | 60 GB / 80 GB | 1 | SOC analyst workstation, remote admin of all servers |
| WIN10-1 (C1C) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 6 GB | 50 GB / 60 GB | 1 | User workstation |
| WIN10-2 (C2C) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 6 GB | 50 GB / 60 GB | 1 | User workstation |
| WIN10-3 (C3C, Optional) | Windows 10/11 Pro | 2 / 2 cores | 4 GB / 6 GB | 50 GB / 60 GB | 1 | Optional additional client |
Key defensive patterns to implement:
-
Directory Services and Redundancy
- Configure AD replication between
DC1CandDC2C. - Test failover: simulate DC outages and validate client logon behavior.
- Configure AD replication between
-
SIEM Integration
- Forward Security, Sysmon, and key Application logs from:
- Both domain controllers
- All clients
HONEY-SRV(critical)
- Build correlation rules for:
- Logon anomalies
- New service creation
- Process executions from unusual paths on the honeypot
- Forward Security, Sysmon, and key Application logs from:
-
Honeypot Design (
HONEY-SRV)- Join to domain with restricted rights.
- Expose commonly targeted services (for lab use only), such as:
- RDP listener with strong passwords but extensive logging
- SMB shares with decoy folders and honey files
- Enable:
- Detailed object access auditing on decoy shares
- Additional Sysmon rules focused on suspicious tools and processes
- Ensure all activity on
HONEY-SRVis forwarded and clearly labeled in the SIEM.
If resources permit, you can implement automation workflows that react to SIEM alerts:
- Use scripts and tools on
SIEM-SRVorSEC-MGMTto:- Automatically disable suspicious user accounts
- Move machines into quarantine Organizational Units
- Collect additional data via remote PowerShell or WMI queries
- Store automation scripts on
FILE-SRVorINFRA-style servers (depending on profile) and document:- Trigger conditions (for example, a high-severity SIEM alert)
- Required approvals (manual step in training scenarios)
- Exact actions taken by each script
This provides SOAR-like behavior using built-in Windows and scripting capabilities without additional products.
-
Create pfSense VM
- Configure one WAN interface (NAT from host) and one LAN interface for the lab.
- Confirm lab clients can reach
10.10.0.1/10.20.0.1/10.30.0.1according to the chosen profile.
-
Deploy Domain Controller(s)
- Install Windows Server, set static IPs, and configure DNS.
- Promote to Domain Controller and create your lab domain.
-
Deploy Member Servers (File / SIEM / Honeypot)
- Join each server to the domain.
- Install relevant roles and features (file services, event collector, SIEM platform).
- Configure log forwarding and retention policies.
-
Deploy Clients
- Install Windows 10/11 Pro, assign IPs via DHCP or statically, and join the domain.
- Apply Group Policies for security baselines, logging, and monitoring.
-
Harden and Instrument
- Enable advanced auditing and Sysmon on all endpoints.
- Confirm events flow end-to-end from endpoints into the SIEM dashboards.
-
Document Use Cases
- Define specific scenarios (suspicious logons, file access anomalies, service modifications).
- Practice triage, escalation, and reporting using the SOC workstation.
This Windows Security Operations Lab provides a flexible foundation for defensive training and can be integrated with a separate offensive lab by carefully adjusting pfSense rules to allow controlled traffic between environments.
The Windows Security Operations Lab is intended to run on a Linux host using QEMU/KVM and libvirt/virt-manager, in the same way as described in README.md.
# Check CPU virtualization support (Intel VT-x or AMD-V)
egrep -c '(vmx|svm)' /proc/cpuinfo
# Alternative: show a line with virtualization flags
grep -E '(vmx|svm)' /proc/cpuinfo | head -1- Expected: A value greater than
0and virtualization flags (vmxorsvm) present. - If
0, enable virtualization in BIOS/UEFI and reboot.
# Update package database
sudo pacman -Sy
# Install QEMU/KVM, libvirt and related tools
sudo pacman -S --needed qemu virt-manager virt-viewer dnsmasq vde2 bridge-utils openbsd-netcat ebtables iptables
# Verify binaries
which qemu-system-x86_64
which virt-manager
which virsh# Update package lists
sudo apt update
# Install QEMU/KVM and virtualization tools
sudo apt install -y qemu-kvm qemu-utils libvirt-daemon-system libvirt-clients bridge-utils virt-manager virt-viewer dnsmasq
# Verify binaries
which qemu-system-x86_64
which virt-manager
which virshsudo systemctl enable libvirtd
sudo systemctl start libvirtd
# Check status
sudo systemctl status libvirtdAdd your user to the libvirt or kvm groups if required by your distribution, then log out and back in.
mkdir -p "${HOME}/VMs/windows-soc-lab"
ls -ld "${HOME}/VMs/windows-soc-lab"This section creates a single isolated libvirt network for the Windows SOC lab. pfSense will provide routing and (optionally) NAT to the internet from within that network.
tee /tmp/win-soc.xml <<'EOF'
<network>
<name>win-soc</name>
<bridge name="br-win-soc"/>
<forward mode='isolated'/>
<ip address='10.30.0.1' netmask='255.255.255.0'>
<dhcp>
<range start='10.30.0.100' end='10.30.0.200'/>
</dhcp>
</ip>
</network>
EOF
# Define and start the network
virsh net-define /tmp/win-soc.xml
virsh net-start win-soc
virsh net-autostart win-soc
# Verify network
virsh net-list --all- Attach all Windows lab VMs (pfSense, domain controllers, SIEM, honeypot, clients) to the
win-socnetwork. - pfSense LAN interface will use a static IP, for example
10.30.0.1or10.30.0.254depending on your preference. - pfSense WAN interface should use the default
virbr0or another NAT network to reach the internet for updates.
The commands below provide scriptable examples for creating the main Windows Security Operations Lab VMs with QEMU/KVM. You may also perform these steps through virt-manager if you prefer a graphical workflow.
mkdir -p "${HOME}/Downloads/pfsense"
# Check https://www.pfsense.org/download/ for latest version
PFS_VERSION="2.7.2"
PFS_ISO="pfSense-CE-${PFS_VERSION}-RELEASE-amd64.iso"
PFS_URL="https://atxfiles.pfsense.org/mirror/downloads/${PFS_ISO}"
echo "Downloading pfSense ISO..."
curl -L --progress-bar -o "${HOME}/Downloads/pfsense/${PFS_ISO}" "${PFS_URL}"
# Verify file exists
ls -lh "${HOME}/Downloads/pfsense/${PFS_ISO}"# Parameters
VM_NAME="pfsense-win-soc"
VM_RAM="2048" # 2 GiB
VM_CPUS="2"
VM_DISK_SIZE="20" # 20 GiB
DISK_PATH="${HOME}/VMs/windows-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/pfsense/${PFS_ISO}"
mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"
virt-install \
--name "${VM_NAME}" \
--ram "${VM_RAM}" \
--vcpus "${VM_CPUS}" \
--disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
--cdrom "${ISO_PATH}" \
--network network=win-soc,model=virtio \
--graphics vnc,listen=0.0.0.0 \
--noautoconsole \
--os-type generic \
--os-variant genericAfter installation, configure:
- WAN interface: attach to the default NAT network (
virbr0) in virt-manager or viavirsh attach-interface. - LAN interface: attach to
win-socand set IP (for example,10.30.0.1).
Obtain a Windows Server evaluation ISO from the official source:
https://www.microsoft.com/en-us/evalcenter/(Windows Server Evaluation Center)
Assuming a Windows Server ISO at ${HOME}/Downloads/ISOs/WinServer2019.iso:
VM_NAME="win-dc1"
VM_RAM="8192" # 8 GiB
VM_CPUS="4"
VM_DISK_SIZE="80" # 80 GiB
DISK_PATH="${HOME}/VMs/windows-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/WinServer2019.iso"
mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"
virt-install \
--name "${VM_NAME}" \
--ram "${VM_RAM}" \
--vcpus "${VM_CPUS}" \
--disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
--cdrom "${ISO_PATH}" \
--network network=win-soc,model=virtio \
--graphics spice \
--video qxl \
--os-type windows \
--os-variant win2k19After installation:
- Set a static IP (for example,
10.30.0.10). - Configure DNS to point to itself.
- Install Active Directory Domain Services and promote the server to a Domain Controller for your chosen domain (
corp.local,blue.local, orsec.lab).
Repeat the previous process with adjusted VM names, resources, and static IPs:
# Example for SIEM server
VM_NAME="win-siem"
VM_RAM="12288" # 12 GiB
VM_CPUS="4"
VM_DISK_SIZE="200" # 200 GiB
DISK_PATH="${HOME}/VMs/windows-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/WinServer2019.iso"
mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"
virt-install \
--name "${VM_NAME}" \
--ram "${VM_RAM}" \
--vcpus "${VM_CPUS}" \
--disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
--cdrom "${ISO_PATH}" \
--network network=win-soc,model=virtio \
--graphics spice \
--video qxl \
--os-type windows \
--os-variant win2k19Assign static IPs such as:
10.30.0.30forwin-siem10.30.0.40for a honeypot server10.30.0.20for a file or utility server
Join each server to the domain, then install the appropriate roles (file services, event collector, SIEM platform, honeypot applications).
Obtain official Windows 10/11 installation media (for example, from the Microsoft Software Download pages) and then:
VM_NAME="win10-1"
VM_RAM="6144" # 6 GiB
VM_CPUS="2"
VM_DISK_SIZE="60" # 60 GiB
DISK_PATH="${HOME}/VMs/windows-soc-lab/${VM_NAME}.qcow2"
ISO_PATH="${HOME}/Downloads/ISOs/Win10.iso"
mkdir -p "$(dirname "${DISK_PATH}")"
qemu-img create -f qcow2 "${DISK_PATH}" "${VM_DISK_SIZE}G"
virt-install \
--name "${VM_NAME}" \
--ram "${VM_RAM}" \
--vcpus "${VM_CPUS}" \
--disk path="${DISK_PATH}",format=qcow2,size="${VM_DISK_SIZE}" \
--cdrom "${ISO_PATH}" \
--network network=win-soc,model=virtio \
--graphics spice \
--video qxl \
--os-type windows \
--os-variant win10After installation:
- Configure either DHCP (from pfSense) or a static IP within the
10.30.0.0/24range. - Join the machine to your Windows domain.
- Ensure that logging and monitoring agents or policies described earlier are applied.
After creating your Windows Server VM, follow these steps to configure Active Directory Domain Services.
On Host:
# Download virtio-win.iso
DOWNLOAD_DIR="${HOME}/Downloads"
mkdir -p "$DOWNLOAD_DIR"
VIRTIO_URL="https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso"
VIRTIO_FILE="${DOWNLOAD_DIR}/virtio-win.iso"
echo "Downloading virtio-win.iso..."
if curl -L --progress-bar -o "$VIRTIO_FILE" "$VIRTIO_URL"; then
echo "✓ Download complete: $VIRTIO_FILE"
ls -lh "$VIRTIO_FILE"
else
echo "✗ Download failed. Check internet connection."
exit 1
fiIn virt-manager:
- Shut down Windows Server VM (if running)
- Open VM details → Add Hardware → Storage
- Select Select or create custom storage → Browse to
$HOME/Downloads/virtio-win.iso - Device type: CDROM → Click Finish
In Windows Server VM:
- Start the VM
- Open File Explorer → This PC → Open CD drive (virtio-win)
- Run
virtio-win-gt-x64.msi - Follow installation wizard → Reboot VM
In Windows Server VM:
- Open Settings → Network & Internet → Ethernet
- Click on the network adapter → Edit under IP settings
- Select Manual
- Configure:
- IP address:
10.30.0.10(for DC1, adjust per profile) - Subnet mask:
255.255.255.0 - Gateway:
10.30.0.1(pfSense LAN) - DNS:
127.0.0.1(will change after AD install)
- IP address:
- Click Save
In Windows Server VM:
- Open Server Manager
- Click Add Roles and Features
- Wizard steps:
- Select Role-based or feature-based installation
- Select current server
- Check:
- Active Directory Domain Services
- DNS Server
- DHCP Server (optional)
- Click Next through remaining steps → Install
- Wait for installation to complete
In Windows Server VM:
- In Server Manager, click notification flag (yellow triangle)
- Click Promote this server to a domain controller
- Deployment Configuration:
- Select Add a new forest
- Enter Root domain name:
corp.local(orblue.local,sec.labper profile)
- Domain Controller Options:
- Set Directory Services Restore Mode (DSRM) password (remember this!)
- Leave other options as default
- Complete wizard → Click Promote
- Server will automatically reboot
After reboot, log in as domain administrator:
- Open Network Settings → Change DNS to
127.0.0.1or10.30.0.10 - Open Active Directory Users and Computers (
dsa.msc) - Navigate to
corp.local→Users - Create test users:
john.doe(regular user)jane.smith(regular user)svc_siem(service account for SIEM)admin_user(administrative user)
On Domain Controller:
- Open Group Policy Management (
gpmc.msc) - Right-click Default Domain Policy → Edit
- Navigate to: Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies
- Enable:
- Account Logon → Audit Account Logon Events: Success and Failure
- Account Management → Audit Account Management: Success and Failure
- Logon/Logoff → Audit Logon: Success and Failure
- Object Access → Audit File System: Success and Failure
- Policy Change → Audit Policy Change: Success and Failure
- Close Group Policy Editor
- Force policy update:
gpupdate /force
Configure centralized logging and SIEM-style analytics on your Windows SOC server.
On SIEM Server (SOC-SRV or SIEM-SRV):
-
Enable Windows Event Collector Service:
# Open PowerShell as Administrator wecutil qc- When prompted, type
Yto enable the service - Service will start automatically
- When prompted, type
-
Configure Firewall Rule:
# Allow Event Collector traffic New-NetFirewallRule -DisplayName "Windows Event Collector" -Direction Inbound -LocalPort 5985,5986 -Protocol TCP -Action Allow
On SIEM Server:
# Create subscription to collect from Domain Controller
$SubscriptionName = "Domain-Controller-Logs"
$DCName = "DC1.corp.local"
$Logs = @("Security", "System", "Application")
wecutil cs $SubscriptionName.xml
# Edit subscription XML (or create manually)
$SubscriptionXML = @"
<Subscription>
<SubscriptionId>$SubscriptionName</SubscriptionId>
<SubscriptionType>SourceInitiated</SubscriptionType>
<Description>Collect Security, System, Application logs from DC</Description>
<Enabled>true</Enabled>
<Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
<ConfigurationMode>Custom</ConfigurationMode>
<Delivery Mode="Push">
<Batching>
<MaxItems>100</MaxItems>
<MaxLatencyTime>1000</MaxLatencyTime>
</Batching>
</Delivery>
<QueryList>
<Query Id="0" Path="Security">
<Select>*</Select>
</Query>
<Query Id="1" Path="System">
<Select>*</Select>
</Query>
<Query Id="2" Path="Application">
<Select>*</Select>
</Query>
</QueryList>
</Subscription>
"@
$SubscriptionXML | Out-File -FilePath "$SubscriptionName.xml" -Encoding UTF8
wecutil cs "$SubscriptionName.xml"On Source Machines (DC, Clients):
# Configure source machines to forward events
# Run on each Windows machine that will forward logs
# Add SIEM server to Event Log Readers group
$SIEMServer = "SIEM-SRV.corp.local"
$Group = [ADSI]"WinNT://./Event Log Readers,group"
$Group.Add("WinNT://$SIEMServer/Administrator")
# Or use Group Policy:
# Computer Configuration → Policies → Administrative Templates → Windows Components → Event Forwarding
# Enable "Configure target Subscription Manager"Download Sysmon:
- Visit:
https://learn.microsoft.com/sysinternals/downloads/sysmon - Download
Sysmon64.exeto SIEM server and all endpoints
Create Sysmon Configuration:
<!-- Save as sysmonconfig.xml -->
<Sysmon schemaversion="4.90">
<HashAlgorithms>SHA256</HashAlgorithms>
<EventFiltering>
<ProcessCreate onmatch="exclude">
<Image condition="end with">\chrome.exe</Image>
<Image condition="end with">\firefox.exe</Image>
</ProcessCreate>
<FileCreateTime onmatch="exclude">
<Image condition="end with">\chrome.exe</Image>
</FileCreateTime>
<NetworkConnect onmatch="exclude">
<Image condition="end with">\chrome.exe</Image>
<Image condition="end with">\firefox.exe</Image>
<DestinationPort>80</DestinationPort>
<DestinationPort>443</DestinationPort>
</NetworkConnect>
<ProcessTerminate onmatch="include"/>
<ImageLoad onmatch="include">
<Signed condition="is">false</Signed>
</ImageLoad>
</EventFiltering>
</Sysmon>Install Sysmon on All Machines:
# Run on each Windows machine
.\Sysmon64.exe -i sysmonconfig.xml -accepteula
# Verify installation
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | Select-Object -First 5On SIEM Server (Linux-based Wazuh server, or use Windows-compatible SIEM):
Option A: Wazuh (if SIEM server is Linux):
- Install Wazuh server on Linux VM (see LINUX-LAB.md section on SIEM)
- Install Wazuh agent on Windows machines:
# Download Wazuh agent for Windows # Install agent and configure manager IP to point to SIEM server
Option B: Windows-Compatible SIEM (Splunk, Graylog, etc.):
- Download evaluation version of Splunk Enterprise or Graylog
- Install on Windows Server SIEM VM
- Configure inputs to read Windows Event Logs:
# Splunk Universal Forwarder installation # Configure inputs.conf to monitor: # [WinEventLog://Security] # [WinEventLog://System] # [WinEventLog://Application] # [WinEventLog://Microsoft-Windows-Sysmon/Operational]
On Domain Controller:
- Open Group Policy Management (
gpmc.msc) - Create new GPO: "SIEM Event Forwarding"
- Edit GPO:
- Computer Configuration → Policies → Administrative Templates → Windows Components → Event Forwarding
- Enable "Configure target Subscription Manager"
- Enter:
Server=http://SIEM-SRV.corp.local:5985/wsman/SubscriptionManager/WEC,Refresh=60
- Link GPO to Domain Controllers OU and Domain Computers OU
- Run
gpupdate /forceon all machines
Configure a Windows Server as a deception/honeypot host.
On HONEY-SRV:
-
Join to Domain:
- Configure static IP:
10.30.0.40 - Join to
corp.localdomain - Use domain admin credentials
- Configure static IP:
-
Create Decoy Shares:
# Create decoy folders New-Item -Path "C:\Shares\Confidential" -ItemType Directory New-Item -Path "C:\Shares\Financial" -ItemType Directory New-Item -Path "C:\Shares\HR" -ItemType Directory # Create honey files "Fake confidential data - DO NOT ACCESS" | Out-File "C:\Shares\Confidential\secret.txt" "Fake financial data" | Out-File "C:\Shares\Financial\budget.xlsx" # Share folders New-SmbShare -Name "Confidential" -Path "C:\Shares\Confidential" -FullAccess "Everyone" New-SmbShare -Name "Financial" -Path "C:\Shares\Financial" -FullAccess "Everyone"
-
Enable Detailed Auditing on Decoy Shares:
# Enable object access auditing auditpol /set /category:"Object Access" /success:enable /failure:enable # Configure auditing on folders $Acl = Get-Acl "C:\Shares\Confidential" $AuditRule = New-Object System.Security.AccessControl.FileSystemAuditRule("Everyone","FullControl","ContainerInherit,ObjectInherit","None","Success,Failure") $Acl.SetAuditRule($AuditRule) Set-Acl "C:\Shares\Confidential" $Acl
-
Enable RDP with Extensive Logging:
# Enable RDP Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections" -Value 0 Enable-NetFirewallRule -DisplayGroup "Remote Desktop" # Enable detailed RDP logging Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "LogonUserName" -Value 1
-
Install and Configure Sysmon (use aggressive configuration):
# Use Sysmon configuration focused on detecting suspicious activity .\Sysmon64.exe -i honeypot-sysmonconfig.xml -accepteula
-
Forward All Logs to SIEM:
- Configure Windows Event Forwarding to
SIEM-SRV - Ensure all Security, Sysmon, and Application logs are forwarded
- Configure Windows Event Forwarding to
Implement automated response workflows using PowerShell and Windows built-in tools.
On SIEM-SRV or FILE-SRV:
New-Item -Path "C:\SOAR\Scripts" -ItemType Directory
New-Item -Path "C:\SOAR\Logs" -ItemType DirectoryCreate Disable-SuspiciousUser.ps1:
# C:\SOAR\Scripts\Disable-SuspiciousUser.ps1
param(
[Parameter(Mandatory=$true)]
[string]$Username,
[Parameter(Mandatory=$true)]
[string]$Reason
)
$LogFile = "C:\SOAR\Logs\automation.log"
$Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
# Log action
"[$Timestamp] Disabling user: $Username - Reason: $Reason" | Out-File -FilePath $LogFile -Append
try {
Disable-ADAccount -Identity $Username
"[$Timestamp] Successfully disabled user: $Username" | Out-File -FilePath $LogFile -Append
# Send notification (example)
# Send-MailMessage -To "admin@corp.local" -Subject "User Disabled" -Body "User $Username disabled: $Reason"
Write-Host "User $Username disabled successfully"
} catch {
"[$Timestamp] ERROR disabling user $Username : $_" | Out-File -FilePath $LogFile -Append
Write-Error "Failed to disable user: $_"
}Create Move-MachineToQuarantine.ps1:
# C:\SOAR\Scripts\Move-MachineToQuarantine.ps1
param(
[Parameter(Mandatory=$true)]
[string]$ComputerName
)
$LogFile = "C:\SOAR\Logs\automation.log"
$Timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
# Create Quarantine OU if it doesn't exist
$DomainDN = (Get-ADDomain).DistinguishedName
$QuarantineOU = "OU=Quarantine,$DomainDN"
if (-not (Get-ADOrganizationalUnit -Filter "DistinguishedName -eq '$QuarantineOU'" -ErrorAction SilentlyContinue)) {
New-ADOrganizationalUnit -Name "Quarantine" -Path $DomainDN
}
# Move computer to Quarantine OU
try {
$Computer = Get-ADComputer -Identity $ComputerName
Move-ADObject -Identity $Computer.DistinguishedName -TargetPath $QuarantineOU
"[$Timestamp] Moved $ComputerName to Quarantine OU" | Out-File -FilePath $LogFile -Append
# Apply restrictive GPO to Quarantine OU
# (Create GPO that blocks network access, etc.)
Write-Host "Computer $ComputerName moved to quarantine"
} catch {
"[$Timestamp] ERROR moving $ComputerName : $_" | Out-File -FilePath $LogFile -Append
Write-Error "Failed to move computer: $_"
}Create Monitor-SIEMAlerts.ps1:
# C:\SOAR\Scripts\Monitor-SIEMAlerts.ps1
# This script would query your SIEM API or log files for high-severity alerts
# Example: Query Wazuh API, Splunk API, or read from event logs
$SIEMLogPath = "C:\SIEM\Alerts\high-severity.json" # Example path
$Threshold = 5 # Number of failed logons before action
# Query for repeated failed logons
$FailedLogons = Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625
StartTime = (Get-Date).AddMinutes(-10)
} | Group-Object -Property @{Expression={$_.Properties[5].Value}} | Where-Object {$_.Count -ge $Threshold}
foreach ($User in $FailedLogons) {
$Username = $User.Name
Write-Host "Detected $($User.Count) failed logons for $Username"
# Trigger automation
& "C:\SOAR\Scripts\Disable-SuspiciousUser.ps1" -Username $Username -Reason "Repeated failed logon attempts"
}Create Scheduled Task:
$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-File C:\SOAR\Scripts\Monitor-SIEMAlerts.ps1"
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 5) -RepetitionDuration (New-TimeSpan -Hours 24)
Register-ScheduledTask -TaskName "SOAR-MonitorAlerts" -Action $Action -Trigger $Trigger -RunLevel Highest- QEMU/KVM Documentation:
https://www.qemu.org/documentation/- Official QEMU documentation - KVM Virtualization:
https://www.linux-kvm.org/page/Main_Page- KVM project homepage - libvirt Documentation:
https://libvirt.org/docs.html- Complete libvirt API and tool documentation - virt-manager:
https://virt-manager.org/- GUI for managing virtual machines - virsh Command Reference:
https://libvirt.org/manpages/virsh.html- Command-line tool documentation
- pfSense CE:
https://www.pfsense.org/- Official pfSense website and downloads - pfSense Documentation:
https://docs.netgate.com/pfsense/- Complete pfSense documentation - pfSense Community Forum:
https://forum.netgate.com/- Community support and discussions
- Windows Server Evaluations:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2022- Download Windows Server 2022 evaluation - Windows Server 2019 Evaluation:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2019- Download Windows Server 2019 evaluation - Windows 10/11 Enterprise Evaluation:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise- Download Windows 10/11 evaluation - VirtIO Drivers for Windows:
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/- Download virtio-win.iso
- Windows Sysinternals / Sysmon:
https://learn.microsoft.com/sysinternals/downloads/sysmon- Download and documentation - Sysmon Configuration Examples:
https://github.com/SwiftOnSecurity/sysmon-config- Community-maintained Sysmon configurations - Windows Event Forwarding (WEC):
https://learn.microsoft.com/windows-server/administration/windows-commands/wecutil- WEC command reference - Windows Event Forwarding Guide:
https://learn.microsoft.com/windows-server/identity/ad-ds/manage/component-updates/command-line-procedures/event-forwarding- Complete WEC setup guide
- Active Directory PowerShell Module:
https://learn.microsoft.com/powershell/module/activedirectory/- AD PowerShell cmdlet reference - Group Policy Management:
https://learn.microsoft.com/windows-server/identity/ad-ds/getting-started/windows-server-2012-r2-and-2012/active-directory-group-policy- GPO documentation - Active Directory Domain Services:
https://learn.microsoft.com/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview- AD DS overview and setup
- Wazuh Documentation:
https://documentation.wazuh.com/current/index.html- Complete Wazuh documentation - Wazuh Windows Agent:
https://documentation.wazuh.com/current/user-manual/agent/agent-installation/windows/windows-agent-package.html- Windows agent installation guide - Splunk Enterprise:
https://www.splunk.com/en_us/download/splunk-enterprise.html- Download Splunk Enterprise (60-day evaluation) - Splunk Universal Forwarder:
https://www.splunk.com/en_us/download/universal-forwarder.html- Download Splunk Universal Forwarder - Splunk Documentation:
https://docs.splunk.com/Documentation/Splunk- Splunk product documentation - Graylog Documentation:
https://go2docs.graylog.org/- Graylog official documentation - Graylog Installation Guide:
https://go2docs.graylog.org/5-2/installing-graylog/install-graylog-on-microsoft-windows.html- Windows installation guide
- PowerShell Documentation:
https://learn.microsoft.com/powershell/- Complete PowerShell documentation - PowerShell Scripting Guide:
https://learn.microsoft.com/powershell/scripting/overview- PowerShell scripting reference - Active Directory PowerShell Cmdlets:
https://learn.microsoft.com/powershell/module/activedirectory/- AD management cmdlets