Windows Server 2025 and Windows 11 (24H2 and newer) are the first Windows releases that include native post-quantum cryptographic primitives in the operating system. These changes are intended to reduce long-term exposure to data captured today and decrypted in the future. Windows does not yet provide a complete quantum safe security stack. It only includes the base cryptographic primitives and hybrid mechanisms needed to begin transitioning away from classical algorithms. What follows is what is actually present in the platform today, where it can be used, and what it cannot yet do. Terminology Base cryptographic primitives This means Windows now has low-level implementations of PQC algorithms such as: ML-KEM for key exchange ML-DSA for digital signatures These live in SymCrypt and can be called by higher-level components. They are the equivalent of having AES or RSA functions available, not a full encryption product. They do not  by themselves: Replace RSA or ECC Automatically secure traffic Enforce policy Integrate into existing enterprise controls They are just the math engines. Hybrid mechanisms Hybrid means Windows does not use PQC on its own. Instead it: Combines classical crypto (ECC like X25519) With PQC (ML-KEM) Mixes both secrets into one session key This protects you if either algorithm is later broken, but it also means: PQC is not yet trusted enough to stand alone Classical crypto is still required everywhere So Windows is not “post-quantum only.” It is post-quantum assisted. Core PQC Algorithms in Windows Microsoft has implemented the NIST standardised post-quantum algorithms directly into SymCrypt , the core cryptographic library used throughout Windows. The following primitives are now present in modern Windows builds: ML-KEM (formerly CRYSTALS-Kyber) Used for post-quantum key exchange and encapsulation. Windows includes support for ML-KEM-512, 768, and 1024. ML-DSA (formerly CRYSTALS-Dilithium) Used for digital signatures, certificate validation, and identity verification. These algorithms are integrated into the same core crypto engine that backs BitLocker, TLS, Kerberos, and CNG functions. This integration is necessary if the platform is ever to support PQC beyond academic demonstrations. Where PQC Exists in the Windows Stack SymCrypt and CNG PQC algorithms are exposed through the same cryptographic pipeline used by existing Windows security features, via CNG-backed providers. This means the operating system is capable of performing post-quantum operations natively, without third-party crypto libraries. However, these API surfaces are still considered early access or preview grade. Public, documented stable APIs for third-party developers are not yet available. The capability is present, but not fully supported for production use outside of Microsoft’s own components. Certificates and PKI Windows certificate stores can parse and retain PQC algorithm identifiers and hybrid certificate chains. Microsoft has demonstrated internal ADCS builds capable of issuing PQC and hybrid certificates, but as of early 2026 this is not a general availability feature. There is no supported workflow for running a full quantum-safe enterprise PKI yet. Windows can store and process PQC formats, but does not yet provide a complete operational lifecycle for PQC certificates. Hybrid TLS, The Only Practical Model All practical PQC deployments in Windows today use hybrid key exchange. Windows combines a classical key exchange algorithm such as X25519 with ML-KEM during TLS 1.3 handshakes, and both secrets are mixed into the session key. If the post-quantum algorithm were later found to be weak, the classical layer would still protect the session. If a quantum computer someday breaks the classical layer, the PQC portion remains intact. Hybrid key exchange is currently the only deployment model that provides backward compatibility and forward security. This support exists only in TLS 1.3. TLS 1.2 and earlier cannot negotiate hybrid key exchange with PQC algorithms. Operational Side Effects Post-quantum cryptography increases the sizes of the following: Signature sizes key blobs certificate chains Handshake payloads are larger than their classical counterparts. A classical ECDSA signature is roughly 64 bytes. An ML-DSA (Post-Quantum) signature can be over 2,400 bytes. In practice, this means: Firewalls and load balancers may drop or fragment PQC handshakes. MTU and fragmentation settings may need adjustment. HTTP header limits and reverse proxy configurations might need raising to accommodate larger certificate headers. These impacts are concrete and should be tested early in any deployment. What “Enabled” Actually Means PQC is not globally enabled across Windows as a system-wide security mode. It is selectively used by Microsoft-controlled stacks such as Edge and specific TLS paths, and in internal services where hybrid negotiation is already implemented. For developers, PQC types are beginning to appear in upcoming .NET releases, but they remain in preview and subject to change. For administrators, there is no single switch, no Group Policy, and no supported way to enforce PQC system-wide yet. PQC adoption in Windows is an incremental platform change and cannot be enabled through a single configuration setting. Final Reality Check The operating system now includes native support for post-quantum algorithms at the cryptographic provider layer. That is the actual milestone. It is not yet quantum safe end-to-end. It is not yet enterprise ready. It is not a complete solution. Broader deployment depends on standards maturity, application support, and enterprise tooling.

Windows 10 has officially reached its end of life. After a decade of service, Microsoft is pulling the plug on regular security updates and patches. This means no more fixes for newly discovered vulnerabilities, regardless of how critical they may be. Now, I know what you’re thinking: “What’s the plan, Microsoft?” Well, they expect everyone to migrate to Windows 11. But honestly, it feels like Microsoft is out of touch with reality. The Hardware Dilemma Windows 11 comes with a self-imposed set of hardware requirements. Most notably, it mandates a Trusted Platform Module 2.0 (TPM) and specific processor generations: Intel's 8th Gen Core (Coffee Lake, 2017) or newer, or AMD's Ryzen 2000 series (Zen +, 2018) or newer. Let’s dig a little deeper into this situation. What Are Microsoft Thinking? With TPM enabling BitLocker to protect your data from the threat of someone physically stealing your laptop, you can almost admire Microsoft’s logic. Obviously, that’s a far bigger risk than a few hundred million unpatched Windows 10 machines being exposed to the Internet. Because, of course, laptops are being stolen by the truckload every night, while malware and remote exploits are just fringe concerns. Brilliantly deducted. Microsoft’s obsession with this stance is leaving millions of Windows 10 devices unpatched and exposed to the Internet. That’s the blueprint for the largest collection of remotely exploitable systems the world has ever seen. Genius, really. Windows 10 vs Windows 11: Who’s Really Using What? Windows 11 has finally surpassed Windows 10 in market share. Around 55 percent of active Windows desktops now run Windows 11, while roughly 42 percent remain on Windows 10. That's 42% of the world’s Windows machines running an operating system that’s no longer receiving security updates. It's estimated that between 400 and 450 million Windows 10 devices exist. Let that number sink in. Nearly half a billion devices are now unpatched and will soon become vulnerable. TPM 2.0 simply isn’t present on roughly 30 percent of Windows-capable devices. Since TPM only became standard on mainstream hardware from around 2018 onward, and was made mandatory for Windows 11 in 2021, anything older than 5 to 8 years is unlikely to have a TPM. It’s Not Like the Hardware Isn’t Fast Enough! Most older PCs can run Windows 11 without breaking a sweat. They’re powerful enough to handle most workloads. So why the hardware restrictions? It feels like a forced upgrade rather than a necessary one. The Fear Factor Microsoft seems to be betting on a mass migration, a sudden leap from Windows 10 to Windows 11 driven by fear of being vulnerable. The message is clear: upgrade your hardware, buy a new PC, or live with unpatched vulnerabilities. It’s a calculated gamble that enough users will cave rather than risk running unsupported systems. Of course, support can be extended for free if you sign up for a Microsoft account for an additional year of support. Otherwise, it’s a paid service. The Truth of the Matter Microsoft, come down from your ivory tower. You’re not Apple, and your products aren’t objects of desire or status. There’s no more passion for your products; people run Windows because they haven’t yet discovered the alternatives like Apple, Linux, and ChromeOS. Admit Your Mistake If you’re willing to burn over 400 million devices because of an arbitrary decision, one that leaves them open to remote attacks while blocking any legitimate upgrade path to Windows 11, then maybe we should all consider alternatives before choosing any Microsoft product. Market Share: A Declining Landscape Windows devices have been losing ground for years. Mobile devices have taken over daily computing for most people, who now handle email, banking, shopping, streaming, and social media entirely on their phones. The traditional PC has become an optional extra. So if Microsoft keeps giving people reasons not to buy a PC, what do they think will happen? Enforcing nonsensical hardware barriers, locking features behind accounts nobody wants, and deliberately blocking perfectly good machines from upgrading will only drive customers away. Push hard enough, and they won’t just skip an upgrade; they’ll abandon the platform altogether. Once a customer fully switches to mobile or jumps to Apple, ChromeOS, or Linux, they’re gone for good. They won’t be coming back just because Microsoft finally decides to be reasonable. And right now, money is tight. Inflation has hammered disposable income, and consumers aren’t lining up to replace perfectly good hardware. Microsoft picked the worst possible moment to demand a hardware refresh in a market where users are already drifting toward mobiles and away from Windows entirely. Rant Over... Well, Almost As a die-hard Microsoft engineer, I feel better for letting that rant go public. There have been too many times in the last few years that Microsoft has misstepped and angered its customer base. Let’s name a few: Xbox repeatedly, Out of Tune (Intune), the bag of spanners that is massively inferior to SCCM, deprecating MDT, CoPilot, and AI stuffed into every corner of the OS and every app, sub-optimal and untested patches, reboots at the absolute worst times, ads on enterprise devices, ads in every facet of the OS, and finally, Windows Recall.

The Road to the World's Most Secure Home Lab: Implementing IPSec Between Windows Domain and Rocky Linux So far, in the pursuit of the world's most secure home lab, I've implemented several key strategies. Today, I’ll dive into the specifics of implementing IPSec between my Windows Domain and Rocky Linux. What's Covered in This Blog This post covers the implementation of IPSec, focusing on the integration between my Windows Domain and Rocky Linux. What Is Zero Trust - Recap Zero Trust is a security framework that assumes no user, device, or network segment is inherently trustworthy, regardless of where it sits in the network. The core principles include: Verify explicitly : Always authenticate and authorize access. Use least privilege access : Limit access to only what's necessary. Assume breach : Design as if attackers are already in the network. IPSec and Its Back Story If you haven’t already, start with Part 4 , where I implement IPSec in a Windows environment using certificates. And yes, you guessed it, there’s more certificate configuration ahead. Wooohoooo, living the dream! Rocky Linux Rocky Linux version 10 is today’s Linux OS of choice and will be installed onto a Hyper-V platform. Rocky will serve as a Wazuh monitoring platform as part of the Zero Trust implementation for the home lab. The installation of Wazuh isn’t covered here; it’ll be the focus of the next article. Microsoft's SCOM might seem like the obvious choice for me, but there’s a longer-term goal to move away from Microsoft. As the company pivots to a Cloud and AI-first strategy, on-prem support and partner benefits are steadily being erased. This shift removes my ability and choice to deploy what and where I want. PfSense/Managed Switch VLAN To support the Rocky Linux servers and Wazuh, a new VLAN on the 192.168.90.0/24 subnet will be required. This aligns with the Zero Trust principle of service segregation. Initially, pfSense is configured to allow unrestricted traffic between VLAN 20 , VLAN 30 , and VLAN 90 in both directions. Don’t forget to update the managed switch to also allow the new VLAN tag of 90. A step-by-step guide for setting up VLANs, firewalls, etc., for pfSense is available in Part 2 . IPSec Additional GPO for SSH An additional GPO exemption allowing SSH (port 22) access between the member server and the Rocky Linux hosts will ease deployment. This allows copy and paste between host and VM. Current Domain IPSec Settings Crucial! Windows domain traffic via GPO only supports IKEv1, not that Microsoft will make this obvious or configurable. Make a note of the current IPSec settings; any deviation will result in IPSec negotiation failure. The following IPSec settings are known to work reliably. While some configurations using AES-GCM 128 and 256 are supported, AES-GCM 192 is not supported on Rocky Linux. If you plan to deviate from this setup, be sure to confirm that your chosen ciphers are supported on both Windows and Linux. A step-by-step guide for setting up IPSec in a Windows Domain is available in Part 4 . I strongly recommend following that guide before attempting to add Linux to the mix. IPSec Settings in GPO - Just for Info Open GPO Management and navigate to the IPSec policies and edit: Computer Configuration > Policies > Windows Settings > Security Settings Right-click and select Properties on Windows Defender firewall and Advanced Security. Select the IPSec Settings tab. Open Main Mode's Customize... Select and edit the SHA384 integrity policy. Make a note of all the settings. Audit Quick Mode. Audit Authentication, which is using the Trusted Root certificate. DNS Create a host record for the intended Rocky host. Linux Packages for IPSec The latest release of Rocky Linux is installed as a Hyper-V VM, with 6GB RAM and 250GB disk. Finally, the virtual NIC is set for VLAN 90. During installation, disable the root account and ensure that the user you create is added to the wheel group to grant administrative (sudo) privileges. Connection from Server Once Rocky is properly installed, pfSense should assign it an IP address via DHCP. In my case, it was 192.168.90.100 . Here’s the command to set a static IP, gateway, and DNS. SSH from PowerShell I’ll be connecting from my Windows server with PowerShell—no more Putty for me! Hostname Update the hostname to match the DNS entry created earlier. Updates Start where you mean to finish. Apply any updates to ensure stability and security fixes are applied. AD Packages Install the packages that will allow Rocky to be a domain member. Strongswan Install the following two packages in order. Time and Timezone Rocky will source its time from the DCs, not only to support authentication protocols but also to ensure that log timestamps are accurate and consistent across the environment. Search for your locale; mine's London. Copy the result and then set the timezone. Enable and start the time sync service. Update `chrony.conf` with the following, so it points at the DCs: `server 192.168.20.245 iburst` `server 192.168.20.247 iburst` `server 192.168.90.249 iburst` Restart the time service. Run the following commands once IPSec is implemented to confirm time and time sync. AD or Not to AD This step is included in case Rocky needs to join the domain. However, for its intended role as a monitoring solution, it’s best to minimize open ports and limit connectivity between it and the domain to reduce the attack surface. To Join the Domain In Active Directory Users and Computers, pre-create the computer object `wazuh90` in the required OU. If you don't do this step, Rocky will be added to the AD Computer container. Discover your domain (use your actual domain name in ALL CAPS). Join the domain using an account with permissions. Pull password information for an Active Directory user. Pull some domain info. IPSec Certificate for Linux Preparation Advanced certificate requests using version 3 templates are not supported through the traditional web enrollment interface (certsrv) unless you're using legacy systems like Windows XP or Server 2003. Clients running Windows Vista or newer cannot request v3 template certificates via this method due to compatibility limitations. Microsoft’s recommended approach for handling version 3 templates is to use Certificate Enrollment Web Services (CEP/CES) or leverage Autoenrollment via Group Policy. Both support modern certificate features and provide a more secure and scalable enrollment process. I’m not deploying a CES server; that's for another day and another blog, and it’s unnecessary for our needs. CES is mainly used by Windows clients for advanced certificate enrollment. Linux doesn’t require it, since it still supports the legacy method. New Linux Certificate Template Let's prep a certificate. Open the CA management snap-in, and then right-click on Certificate Templates and Manage. Duplicate a Certificate Template Either duplicate the IPSec (Offline) certificate or the previously created 'Non-TPM' template for server or workstation. General Tab: Set the validity period to 1 year. Compatibility Tab: Set both Compatibility settings to Windows 2003. Failure to do this will mean the template won't be available in the certificate web console. Request Handling Tab: Allow the private key to be exported. Cryptography Tab: Set the Algorithm to Determined by CSP and key size to 2048. Subject Name Tab: Set to Supply in the request. Extensions Tab: Edit the Application Policies and add in: - Client Authentication - IP Security IKE Intermediate - IP Security Tunnel Termination - IP Security User - Server Authentication Security Tab: Add the user or group that will perform the certificate enrollment. Remove any group that auto-enrolls. Publish the Certificate Template Return to the main CA Management snap-in. Right-click on Certificate Templates . Select New > Certificate Template to Issue > select Toyo Linux IPSec. Certificate Enrollment In this section, we’ll walk you through the process of requesting a certificate for a Linux system using the Windows CA web interface. SSH onto Rocky. Private Key A private key is generated locally to ensure it never leaves the system. A CSR is then created using that key to securely request a certificate from the CA without exposing the key itself. Create a working directory. Create a private key that remains on the host; I'll secure it shortly. Create CSR Create a CSR derived from the Private key. Update the following with the FQDN of the Rocky host. Copy and paste into the SSH sessions. Cat the CSR, select all the text including the Begin and End Certificate Requests lines, and press Enter to copy to the Windows clipboard. Cert Request from CA Web Console The CSR needs to be copied to the CA Web console to complete the certificate enrolment. From the Windows Server, open a browser and enter the address to the CA Web server, e.g., https://certs.toyo.loc/certsrv. Select Request a certificate. Select Submit a Certificate request by using a base-64-encoded CMC. Paste the CSR into the Base-64-encoded window. Select the Toyo Linux IPSec template. Select Base 64 encoded. Click on Download certificate. Open the downloaded certificate with Notepad. Copy the entire contents to clipboard. Create the Certificate Return to the SSH session. From this point onwards, every command will require sudo. `sudo nano FQDN.crt` and paste the contents of the Windows clipboard. Ctrl + O to output the contents to file. Ctrl + X to exit Nano. Copy the Private Key and Certificate to Strongswan The private key and the certificate are required to be copied or moved to the strongswan directory and configured with the correct permissions. Copy the Private key. Set the private key to be readable and writable only by the file's owner. Set Root as the Owner. Repeat the steps to secure the private key in the home directory. Copy the certificate to the strongswan x509 directory. Set the certificate permissions so the owner can write and everyone else can read. Trusted Root CA The root CA certificate is required on the local host to establish trust in certificates issued by that authority. Without it, the system cannot validate or trust incoming connections or services secured with those certificates. In the CA web console, click the Home link, then select Download a CA certificate, certificate chain, or CRL. Select Base 64 and then Download CA Certificate. Open with Notepad and copy the contents. Ensure you're in the 'certs' working directory. Open nano and paste the Base64-encoded root certificate from your clipboard into the file. Ctrl + O to output the contents to file. Ctrl + X to exit Nano. Root Trust Copy the root CA certificate to the trusted anchors directory so the system recognizes it as a valid certificate authority. Copy the root CA to anchors so the browser trusts sites on my domain. Refresh the system’s trusted certificate store with the new certificate. Copy the root CA to the Strongswan x509CA directory. Set the certificate permissions so the owner can write and everyone else can read. Firewalls The following commands permanently open the required ports and protocols for IPSec traffic. Note that port 4500 and the AH protocol are not needed for non-VPN traffic or this specific configuration. sudo firewall-cmd --list-all sudo firewall-cmd --permanent --add-port=500/udp sudo firewall-cmd --permanent --add-protocol=esp sudo firewall-cmd --permanent --add-port=4500/udp sudo firewall-cmd --permanent --add-protocol=ah sudo firewall-cmd --reload Swanctl.conf and Not Strongswan StrongSwan is an open-source implementation of the IPSec protocol suite, used to establish secure, encrypted connections between hosts or networks. It uses IKE (Internet Key Exchange), typically IKEv2, to negotiate and manage security associations. Naturally, Microsoft only supports IKEv2 for VPNs, so we're stuck with IKEv1. Configuration is handled through `swanctl.conf`, and the `swanctl` utility is used to load, manage, and monitor IPSec connections in real-time. It supports certificates, EAP, and various authentication methods, making it ideal for inter-domain and subnet traffic, site-to-site, and remote access VPNs. `Swanctl` is to be used as the IPsec command is deprecated. `swanctl.conf` provides a more modular, flexible, and systemd-friendly way to manage StrongSwan. Backup the original `swanctl.conf`. Create a new `swanctl.conf` with nano. Download my swanctl.conf from Github and paste it into nano. Crucial! Update the highlighted values to exactly match your Windows domain. They’re explicit, and any mismatch will prevent the IPSec tunnel from negotiating: aes256-sha384-ecp384 = Key Exchange (Main Mode) Integrity algorithm - SHA384 Encryption algorithm - AES-CBC 256 Key exchange algorithm - EC DH P-384 esp_proposals = aes128gcm128 = Data Protection (Quick Mode) Encryption algorithm - AES-GCM 128 Integrity algorithm - AES-GMAC\GCM 128 In transport mode, only traffic that matches `local_ts` and `remote_ts` will be protected by IPSec. Any traffic not matching these rules will pass as normal, unencrypted traffic. Ctrl + O to output the contents to file. Ctrl + X to exit Nano. Instruct the Charon daemon to load plugins dynamically, making the setup more flexible and easier to manage across different use cases. Start Strongswan Service Up to this point, access to Rocky has primarily been from Windows via SSH. The upcoming steps may terminate your session, and any misconfiguration will terminate the connection. With that in mind, you may want to switch to direct console access before proceeding. Note: Ignore any errors or warnings for the sqlite plugin; it’s harmless noise. Remove the SSH Exemption in GPO The IPSec GPO exemption for SSH, between the Windows Server and Rocky. Enable and Start Strongswan Execute the following commands. Any misconfigurations, typos, or incorrect parameters with `swanctl.conf` will likely prevent the service from starting or successfully establishing an IPSec connection. Enable Strongswan service. Start Strongswan service. Load all parameters stored in the `swanctl.conf` file. Status of Strongswan Let’s go through a few configuration steps to verify that IPSec is running correctly and establishing a successful connection to the Windows endpoint. `swanctl.conf` does not allow exemptions and communicates exclusively over IPSec with Windows. So, I found that using `nslookup` is a better way to test the initial connection with Windows domain controllers. Check the status of the Strongswan service to ensure it is running and enabled. I prefer retrieving a backdated list of events, so I use the `-n` option. This is particularly useful when troubleshooting issues where viewing only the latest events might miss the critical error that triggered the problem. `journalctl -u strongswan -f` displays StrongSwan events in real-time as they occur. `sudo swanctl --list-conns` displays all configured IPSec connections from the `swanctl.conf` file, including their settings and current status. `sudo swanctl --list-certs` lists all loaded X.509 certificates, showing details like subject, issuer, validity period, and key usage. `sudo tcpdump -n esp or udp port 500` captures and displays network packets that are either ESP (IPsec encrypted) traffic or use UDP port 500, which is commonly used for IKE (Internet Key Exchange) in IPSec. Finally, let’s examine the Windows side of the IPSec connection. Open `wf.msc` and navigate to either the Main Mode or Quick Mode section. There, you should see the IPSec connection established between Rocky Linux and the Windows Server. It Never Works First Time.... Windows Firewall From my experience, the following `journalctl` messages usually mean that IKE or ESP traffic is being blocked by a firewall, either on the Windows endpoint or by pfSense. If there are no matching log entries on the Windows server, I take it as a sign that the packets never made it through. In that case, I’ll enable or check the firewall logs on pfSense to confirm if it’s dropping the traffic. journalctl -u strongswan -n 50 wazuh90.toyo.loc charon-systemd[8207]: sending packet: from 192.168.90.100[500] to 192.168.30.61[500] (180 bytes) wazuh90.toyo.loc charon-systemd[8207]: creating delete job for CHILD_SA ESP/0x00000000/192.168.20.245 wazuh90.toyo.loc charon-systemd[8207]: CHILD_SA ESP/0x00000000/192.168.20.245 not found for delete wazuh90.toyo.loc charon-systemd[8207]: giving up after 5 retransmits wazuh90.toyo.loc charon-systemd[8207]: establishing IKE_SA failed, peer not responding wazuh90.toyo.loc charon-systemd[8207]: creating acquire job for policy 192.168.90.100/32[udp/35655] === 192.168.20.245/32[udp/domain] with reqid {2} wazuh90.toyo.loc charon-systemd[8207]: initiating Main Mode IKE_SA windows-ipsec[1317] to 192.168.20.245 wazuh90.toyo.loc charon-systemd[8207]: generating ID_PROT request 0 [ SA V V V V V ] wazuh90.toyo.loc charon-systemd[8207]: sending packet: from 192.168.90.100[500] to 192.168.20.245[500] (180 bytes) wazuh90.toyo.loc charon-systemd[8207]: creating delete job for CHILD_SA ESP/0x00000000/192.168.20.247 wazuh90.toyo.loc charon-systemd[8207]: CHILD_SA ESP/0x00000000/192.168.20.247 not found for delete wazuh90.toyo.loc charon-systemd[8207]: giving up after 5 retransmits Syntax with swanctl.conf The first three log extracts show that the `swanctl.conf` file is misconfigured, either due to a typo or something in the syntax being incorrect. Starting the service immediately fails with an exit code, which usually points to a parsing error or a missing/invalid configuration directive. sudo systemctl start strongswan.service Job for strongswan.service failed because the control process exited with error code. See "systemctl status strongswan.service" and "journalctl -xeu strongswan.service" for details. Running `sudo swanctl --load-all` gives the same result, confirming that the daemon can’t even load the connection definitions. sudo swanctl --load-all Job for strongswan.service failed because the control process exited with error code. See "systemctl status strongswan.service" and "journalctl -xeu strongswan.service" for details. Checking `journalctl -u strongswan -n 50` reveals that `charon-systemd` is shutting down with `status=22`, which typically means there’s a configuration error (e.g., invalid parameters, wrong file paths for certificates, or unsupported options). journalctl -u strongswan -n 50 wazuh90.toyo.loc systemd[1]: strongswan.service: Control process exited, code=exited, status=22/n/a wazuh90.toyo.loc charon-systemd[2882]: SIGTERM received, shutting down wazuh90.toyo.loc systemd[1]: strongswan.service: Failed with result 'exit-code'. wazuh90.toyo.loc systemd[1]: Failed to start strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl. The final log extract, however, tells a slightly different story. Here, I can see the IKE negotiation starting, but it’s failing with “header verification failed.” This points to either an IKE proposal mismatch (e.g., incorrect algorithms or key sizes), a certificate identity issue, or even corrupted packets caused by a misbehaving firewall/NAT device. journalctl -u strongswan -n 50 wazuh90.toyo.loc charon-systemd[22855]: 192.168.20.247 is initiating a Main Mode IKE_SA wazuh90.toyo.loc charon-systemd[22855]: selected proposal: IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384 wazuh90.toyo.loc charon-systemd[22855]: generating ID_PROT response 0 [ SA V V V V ] wazuh90.toyo.loc charon-systemd[22855]: sending packet: from 192.168.90.100[500] to 192.168.20.247[500] (160 bytes) wazuh90.toyo.loc charon-systemd[22855]: header verification failed wazuh90.toyo.loc charon-systemd[22855]: received invalid IKE header from 192.168.20.247 - ignored Thanks for Your Time and Support... Another IPSec and certificate-based blog wrapped up, and just one more to go before my home lab’s Zero Trust panacea of perfection is fully implemented. Honestly, I loved working on this one. My first Linux IPSec deployment in prepping for this blog was Linux-to-Linux, and it was smooth, stable, and just worked. Then I brought Windows into the mix… and suddenly I was questioning my life choices and the tech I’ve devoted my time to. Back in the Vista days, when I was running 100% OpenSuse, I really should have stayed the course. Related Posts: Part 1 - Zero Trust Introduction Part 2 - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x Part 4 - IPSec for the Windows Domain Part 5 - AD Delegation and Separation of Duties Part 6 - Yubikey and Domain Smartcard Authentication Setup Part 7 - IPSec between Windows Domain and Linux using Certs

The Road to the World's Most Secure Home Lab.... So far in the pursuit of the World's most secure home lab, the following have been implemented: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x What's Covered in this Blog This post covers implementing IPSec using certificates for authentication and data encryption across my Windows Domain. This is not for the faint of heart. What Is Zero Trust - Recap Zero Trust is a security framework that assumes no user, device, or network segment is inherently trustworthy, regardless of where it sits in the network. The core principles include: Verify explicitly – Always authenticate and authorize access. Use least privilege access – Limit access to only what's needed. Assume breach – Design as if attackers are already in the network. How IPSec Addresses Zero Trust Security Zero Trust assumes the network is hostile, even internal traffic can't be trusted without verification. Every connection must be authenticated, authorized, and encrypted. IPSec (Internet Protocol Security) is a key enabler: IPSec Overview IPSec is a suite of protocols designed to secure IP communications by authenticating and encrypting each IP packet. It lends itself to Zero Trust by enforcing confidentiality, data integrity, origin authentication, and replay protection. When deployed in a Windows environment, IPSec leverages Active Directory and the Microsoft Public Key Infrastructure (PKI), also known a Certificate Authority (CA). End-to-End Encryption: All internal traffic should be encrypted. IPSec encrypts IP packets at the network layer, ensuring confidentiality and integrity from endpoint to endpoint, protecting data regardless of the underlying application or network. This can be challenging when accessing services that aren't inherently secure or encrypted, such as the Internet. Mutual Authentication: With a CA managing digital certificates, IPSec can perform strong mutual authentication between devices. Identity Assurance: The use of a CA provides control over credentials that defines certificate lifespans, whether to issue or revoke them as needed. IPSec Technical Components Security Associations (SA):  An IPSec Security Association (SA) are 2 unidirectional agreements between two endpoints defining traffic security, specifying the encryption, authentication methods, keys, and lifetime for that session. These are negotiated automatically via IKE (Internet Key Exchange), ensuring both sides agree on how to protect the data in transit. AH vs. ESP IPSec offers two main ways to protect packets:   Authentication Header (AH) – IP Protocol 51 Authenticates the entire IP packet (including headers) to ensure data integrity and source authenticity. AH does not encrypt the payload, your data remains visible. Rarely used in practice; largely obsolete in modern IPSec deployments. Encapsulating Security Payload (ESP) – IP Protocol 50 Encrypts and optionally authenticates the payload, provides: Confidentiality (via encryption) Data integrity and authentication (via HMAC) Modes: Transport Mode: Encrypts only the payload, IP header is exposed. Tunnel Mode: Encrypts the entire original IP packet and adds a new IP header. Obvious Choice: ESP is the standard choice for secure, encrypted communications in Windows IPSec. IKEv2 Microsoft strongly recommends IKEv2 as the default key management protocol: Supports certificate and EAP authentication methods. Built-in NAT Traversal with UDP port 4500 encapsulation. Robust against network disruptions and supports mobility. Provides streamlined, secure negotiation of SAs. Aligns well with 802.1X for device/network authentication. Windows IPSec implementations starting with Windows 7 and Server 2008 R2 default to IKEv2 for VPNs and IPSec tunnels. Unfortunately, this feature isn't supported through GPO, so we will have to settle for IKEv1. The impact of GPO's not natively supporting IKEv2 results in RSA certificates and not ECC IPSec Certificate support. You'll also need to remember it's IKEv1 when configuring swanctl.co nf for Linux. Quick and Main Modes Phase 1: IKE SA Establishment (Main Mode or Aggressive Mode) This phase establishes the ISAKMP/IKE Security Association, which provides a secure, authenticated channel for subsequent negotiation. It includes: Peer authentication using certificates, pre-shared keys, or Kerberos Diffie-Hellman key exchange to derive shared secrets Agreement on encryption, integrity, and hashing algorithms Traffic in this phase uses UDP port 500. Phase 2: IPSec SA Negotiation (Quick Mode) Phase 2 leverages the secure channel from Phase 1 to: Establish one or more IPSec Security Associations (SAs) Define the protected traffic flows using traffic selectors (source/destination IPs, ports, protocols) Generate fresh keying material for encryption and integrity Quick Mode messages are protected by the IKE SA established in Phase 1. The outcome is the creation of ESP SAs for actual packet level protection. Ports & Protocols: Crucial! Required Windows firewall rules, both Inbound and Outbound: UDP Port 500: IKE (initial negotiations) UDP Port 4500: IKE NAT Traversal (when devices are behind NAT) IP Protocol 50: ESP (for the encrypted data) IP Protocol 51: AH (don't use) Basic CA and GPO Configuration:  Ensure every Windows Domain client trusts the Windows Root CA, and deploy it using GPO if necessary. Enable auto-enrollment of certificates in Group Policy, certificate templates with the Autoenroll permission will do just that, and enroll automatically. Crucial! Certificates should not serve multiple purposes. The IPSec certificate must exclude other Application policies to avoid conflicts and processing errors. Additional Logging I've enabled the three IPSec auditing policies at the root of the Domain to assist with initial testing and troubleshooting. These settings generate a high volume of event logs, but once IPSec is stable and set to 'Required', logging can be reduced to capture only failures. Client Certificates No TPM..... Not all of my Windows clients and servers are blessed with a TPM, case in point, the Intel Skull Canyon and the Gen 6 NUC - Hyper-V host, they still cling to life with retirement being long overdue. Without the TPM there's no support for Microsoft Platform Crypto Provider. The fallback option when a TPM isn't available is to use the Microsoft Software Key Storage Provider, targeting the correct provider is managed through Active Directory groups controlling certificate enrollment. Create the following AD Groups. If you have followed the 802.1x blog, the client groups will have already been created: For Computer objects that do not support TPM RG_CA_WksAuthCert_Deny_TPM_Supt RG_CA_MemberServer_Deny_TPM_Supt For Computer objects that do support TPM RG_CA_MemberServer_Allow_TPM_Supt RG_CA_WksAuthCert_Allow_TPM_Supt Workstation Authentication Client - TPM Supported Workstation Authentication Template: Right-click Certificate Templates and select Manage. Right-click the Workstation Authentication template and select Duplicate Template.   General Tab: Template display name: Toyo Workstation IPSec Validity period: 1 years Renewal period: 6 weeks Check 'Publish certificate in Active Directory.' Compatibility Tab:  Set compatibility levels to Windows Server 2016 and Windows 10 Cryptography Tab:  Provider Category: Key Storage Provider Algorithm Name: RSA RSA is supported for key generation and storage in the TPM. ECC (Elliptic Curve Cryptography) isn't generally supported for TPM storage of certificates. Minimum key size: 2048 Request hash: SHA256 Requests must use one of the following providers: Microsoft Platform Crypto Provider Microsoft Platform Crypto Provider is the Key Storage Provider (KSP) that allows certificates and their private keys to be stored in the Trusted Platform Module (TPM). If no TPM is accessible, the certificate will fail to enroll. Subject Name Tab: Under 'Build from this Active Directory Information' Subject name format: Common Name is selected Include this information in the alternative sub name: Check DNS   Extensions Tab:  Select Application Policies and click Edit.... Ensure Client Authentication is present. Add IP Security IKE Intermediate > Click OK. This isn’t required for 802.1X, but it will be relevant in the next article on IPsec. Security Tab:  Ensure Domain Computers is removed Add RG_CA_WksAuthCert_Allow_TPM_Supt and Allow Read, Enroll and AutoEnroll. Click Apply and OK. Workstation Authentication Client - TPM Not Supported Toyo Workstation Authentication Template: Right-click the Toyo Workstation IPSec template and select Duplicate Template. General Tab: Update the name to show that the TPM isn't supported Cryptography Tab:  Provider Category: Key Storage Provider Algorithm Name: RSA Minimum key size: 2048 Request hash: SHA256 Requests can use any provider available on the subject's computer. Security Tab:  Ensure 'Domain Computers' is removed Add RG_CA_WksAuthCert_Deny_TPM_Supt and Allow Read, Enroll, and AutoEnroll. Click Apply and OK. Member Server Certificates Duplicate the 'Computer v2' certificate template General Tab: Template display name: Toyo Member Server IPSec. Validity period: 1 years Renewal period: 6 weeks Check 'Publish certificate in Active Directory.' Compatibility Tab:  Set compatibility levels to Windows Server 2016 and Windows 10 Cryptography Tab:  Provider Category: Key Storage Provider Algorithm Name: RSA RSA is supported for key generation and storage in the TPM. ECC (Elliptic Curve Cryptography) is supported for certificate storage in the TPM, it cannot be used with GPO configured IPSec. GPO IPSec policies rely on IKEv1 only, which limits authentication to RSA. Although PowerShell (Set-NetIPSecRule) can configure the key module to use IKEv2, this capability cannot be deployed or managed via Group Policy. Minimum key size: 2048 Request hash: SHA256 Requests must use one of the following providers: Microsoft Platform Crypto Provider Microsoft Platform Crypto Provider is the Key Storage Provider (KSP) that allows certificates and their private keys to be stored in the Trusted Platform Module (TPM). If no TPM is accessible, the certificate will fail to enroll. Subject Name Tab: Under 'Build from this Active Directory Information' Subject name format: Common Name is selected Include this information in the alternative sub name: Check DNS   Extensions Tab:  Select Application Policies and click Edit.... Remove Client Authentication and Server Authentication. Add IP Security IKE Intermediate > Click OK. Security Tab:  Ensure Domain Computers and Domain Controllers are removed Add RG_CA_MemberServer_Allow_TPM_Supt Allow Read, Enroll, and AutoEnroll. Click Apply and OK. Domain Controller Duplicate the 'Domain Controller Authentication' Template, which should be deployed already. All of my domain controllers are virtual and equipped with a vTPM, allowing them to use the Microsoft Platform Crypto Provider. If your environment differs, separate the certificate templates as previously outlined for clients and servers. General Tab: Template display name: Toyo Domain Controller IPSec. Validity period: 1 years Renewal period: 6 week Do not 'Publish certificate in Active Directory.' Compatibility Tab:  Set compatibility levels to Windows Server 2016 and Windows 10 Cryptography Tab:  Provider Category: Key Storage Provider Algorithm Name: RSA RSA is supported for key generation and storage in the TPM. ECC (Elliptic Curve Cryptography) is supported for certificate storage in the TPM, it cannot be used with GPO configured IPSec. GPO IPSec policies rely on IKEv1 only, which limits authentication to RSA. Although PowerShell (Set-NetIPSecRule) can configure the key module to use IKEv2, this capability cannot be deployed or managed via Group Policy. Minimum key size: 2048 Request hash: SHA256 Requests must use one of the following providers: Microsoft Platform Crypto Provider Microsoft Platform Crypto Provider is the Key Storage Provider (KSP) that allows certificates and their private keys to be stored in the Trusted Platform Module (TPM). If no TPM is accessible, the certificate will fail to enroll. Subject Name Tab: Under 'Build from this Active Directory Information' Subject name format: Common Name is selected Include this information in the alternative sub name: Check DNS   Extensions Tab:  Select Application Policies and click Edit.... Remove Client Authentication, Server Authentication and Smart Card Logon. Add IP Security IKE Intermediate > Click OK. Security Tab:  Leave the Default Security settings Click Apply and OK. Publish the New Templates:  In the Certification Authority console Right click Certificate Templates, select New, then Certificate Template to Issue.   Select your newly created Toyo Templates.  Restart the clients to automatically enroll the certificate or gpupdate /force IPSec Certificates The end result will be a dedicated set of certificates purpose built for IPSec that caters for devices with and without a TPM. The Somewhat Scary Stuff Begins Here.....IPSec Request The "Request IPSec" policy is a relatively safe starting point for introducing IPSec into your environment without disrupting existing communication. Rather than enforcing encryption, it negotiates secure connections when possible and gracefully falls back to plaintext. Create a new GPO for each tier of service, Domain Controller, Member Servers and Clients, name appropriately to show that these policies are specifically for IPSec. Try and refrain from using the root domain policy or bundling the update into another already established GPO. Don't create or modify Root level IPSec GPO's, not only is it bad practice, it could to lead to a rather serious outage of the entire Domain. Consistency across all GPOs is critical, any mismatch in settings will lead to IPSec negotiation failures. Exceptions for Routers and AP's: The Domain Controller IPSec policy was deployed first, with the following rules configured. In addition to the standard 'Request inbound and outbound' rule, exemptions were added for the router IP to allow Internet access and for the PiHole servers for DNS resolution. The Build LAN exception for 192.168.60.0/24 (VLAN60) allows communication with clients and servers that have yet to join the domain and, therefore, can't establish an IPSec tunnel due to missing certificates. The exceptions for VLAN60 include DC's and the CA servers. Some follow-up actions are needed to create the additional VLAN and Firewall in pfSense. GPO_IPSec_DomainControllers: Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Right click on Connection Security Rules and New Rule... Rule Type: Custom Endpoints: Any IP Address Requirements: Request authentication for inbound and outbound connections. Authentication Method: Advanced Customize..... Customize Advanced Authentication Methods: First Authentication Add Computer Certificate from this CA Select the Enterprise Root Certificate Protocols and Ports: Any. Profile: Check only the Domain profile. It's unlikely the DC's and Servers will roam, consider selecting all 3 profiles. Name: Add a meaningful name. IPSec Settings Tab: Right-click on Windows Defender Firewall with Advanced Security Click on the IPSec Setting Tab Customize.... Customize IPSec Defaults: For Main Mode, Quick Mode and Authentication Method, click on Advanced. Customize each in turn, following the guide below Key exchange (Main Mode): Click Add.. Integrity algorithm: SHA-256 Encryption algorithm: AES-CBC 256 Key exchange algorithm: Elliptic Curve Diffie-Hellman P-256 Key exchange options: Use Diffie-Hellman for enhanced security. Data Protection (Quick Mode): Require encryption for all connection security rules that use these settings: Enable this option to encrypt the data, without it, only the authentication process is encrypted. Protocol: ESP (recommended) Encryption algorithm: AES-GCM 128 Integrity algorithm: AES-GCM 128 Note: AES-GCM-128 and 256 are supported by Rocky Linux, AES-GMC-192 is not supported Authentication Method: First Authentication Add Computer Certificate from this CA Select the Enterprise Root Certificate Copy the First IPSec GPO: Don't make things difficult by recreating the GPO's for each tier of OU, copy and paste the first IPSec policy in Group Policy Objects: Navigate to Group Policy Objects Right click, GPO_IPSec_DomainController and Copy Paste and rename 'Copy of GPO_IPSec_DomainController' to GPO_IPSec_MemberServers Repeat, and create GPO_IPSec_Workstations. Link the GPO's to their corresponding OU. IPSec Require Mode and the Network Profile Race Condition Crucial! When IPSec is configured in Require mode within a domain, all inbound traffic must be authenticated, which results in a race condition during system startup. DC's, Windows clients and Servers rely on the Network Location Awareness (NLA) service to determine which firewall profile (Domain, Private, or Public) to assign based on whether it can reach a domain controller. However, if IPSec is in Require mode on the DC and the client hasn't yet established an IPSec Security Association (SA), all unauthenticated attempts to reach domain services (like LDAP or Kerberos) are silently dropped. This creates a loop: The client can't authenticate because it hasn’t established IPSec yet. It can’t establish IPSec because the DC won’t respond to unauthenticated traffic. As a result, the client falls back to the Public profile, blocking IPSec negotiation as it not enabled for IPSec. To get around this catch 22, the following IPSec Exemption Mode rules are required to allow unencrypted network communication at system startup. While this introduces gaps in the IPSec enforcement policy, the majority of ports remain configured with the 'Require' setting. Critically, the two most commonly targeted services—SMB (445) and RDP (3389) are still enforced, mitigating the highest-risk vectors. Note - Don't think setting Request for these ports is an option. DHCP UDP 67, 68 Clients, Server DNS UDP/TCP 53 DC, Clients, Server SMB\CIFS TCP 445 DC, Clients, Servers Kerberos UDP/TCP 88, 464 DC, Clients, Server LDAP TCP 389, 636 DC, Clients, Server ESP (IPsec payload) IP Protocol 50 N/A DC, Clients, Server IKEv1 and IKEv2 UDP 500 DC, Clients, Server DC Exemptions The domain controller exemptions permit Endpoint 1 to initiate connections from any source port to specific service ports (e.g., TCP/UDP 88 for Kerberos), and allow Endpoint 2 to send traffic from any source port to the same service ports on remote systems. Server and Client Exemptions Clients and servers initiating connections to a remote DC service port require Endpoint 2 to allow traffic from any source port to a specific destination port. Note: Both IPSec and exemption rules are initially configured with an open Any/Any endpoint  setting. This approach makes life a little easier when investigating connectivity issues. Once the environment is fully configured, tested and stable, a remediation step will be carried out to harden the policies to allow names services and subnets. Firewalls.... What the.......I did warn you. You may encounter a situation where enabling IPSec Request rules causes the Windows Firewall to enforce stricter behavior. Even previously reliable and well-established firewall rules may begin to block traffic unexpectedly, such as group policies failing to apply. Crucial! Firewalls, particularly the Windows Firewall, will be the most significant source of pain during implementation. While pfSense may present occasional challenges, the majority of connectivity and policy enforcement problems were from Windows. Ensure that Firewall logging is enabled and reporting correctly. Test the Request Policy: Update the policy on the DC's, Member Servers and Clients with gpupdate /force. Windows Firewall - wf.msc To confirm that IPSec is functioning correctly in Request mode, start by opening wf.msc (Windows Defender Firewall with Advanced Security). Under the Monitoring section, navigate to Security Associations > Main Mode and Quick Mode to view active IPSec tunnels. Clicking on Connection Security Rules shows the accumulation of policies that are actively being applied. Main Mode Quick Mode Eventlogs Open Event Viewer (eventvwr) Paste the following event IDs and filter for IPSec events, remove the chaff. 5440, 5441, 5442, 5450, 5451, 5452, 5453, 5454, 5455, 5456, 5457, 5458, 5459 Review the logs That’s the first step in implementing IPSec using Request mode, which carries minimal risk of service disruption. However, domain joined machines, including domain controllers, will still accept traffic from devices that aren’t using IPSec. This includes any unmanaged or potentially insecure IoT devices. Now it gets serious..... Now for the Really Scary Stuff .....IPSec Required Implementing Require IPSec policies enforces strict authentication and encryption, all inbound and outbound traffic will be encrypted, unless there's an exemption rule. Any misconfiguration of policy or certificates, expect a service outage. Thoroughly test all scenarios in a controlled environment before applying Require mode. You assume full responsibility for any service impact, and proceed at your own risk. Be prepared for some frustration, check the DC firewall rules, it may not be IPSec, and good luck!!!! The Plan Now that I've provided the appropriate warning and my conscience is clear, it's time to implement Require IPSec rules...gradually Given the above warning, switching from Request to Require without a staged rollout isn’t the smartest move. Request mode provides the necessary failsafe, it plays nicely and maintains connectivity during deployment, something Require mode does not. Even if IPSec tunnels appear to negotiate successfully in testing, enforcing Require can break communication with systems that are slightly off-kilter. Make sure you have physical access to the system and choose your test targets carefully. There’s a recovery mechanism, hacking the Registry, if things go sideways. Let’s avoid dragging out the crash cart if we can help it. Make sure every client, server and domain controller is on and their policies are up to date prior to proceeding. My target is a DC, I've plenty of them, easy to replace, minimal chance of data loss, and it helps being able to unpick the GPO and have it apply locally to that DC. Don't pick a DC with a FSMO role, especially the PDC emulator. Required GPO: Connect Group Policy Management to the target DC. This helps revert the GPO if network connectivity is lost. Create a new GPO, name it GPO_IPSec_Require. Remove Authenticated Users from the Security Filtering. Add the nominated DC, in my case TOYODC19-3 This filters the GPO to the named DC and no others Connection Security Rules: Edit the GPO and navigate to the Connection Security Rules Created a new Connection Security Rule. Using the previous procedure, match the settings except for the Requirement page. Select 'Require authentication for inbound and outbound connections' Post Require Checks: Run gpupdate on the DC. If the stars align and so do the certificates, CRL and policy, the more restrictive policy takes preseedence, Required Mode is now in operation. Congratulations. Verify access to other domain resources and network shares, testing as many connections as possible. Open wf.msc, confirm entries in Main and Quick mode Staged Deployment: This is a gradual deployment, only fools rush in....and they’re usually the ones pulling an all nigther trying to fix their mess. Link the 'GPO_IPSec_Require' to the Servers and Workstations OU's. Add to the Security Filtering additional computer objects, ensure both types of objects, those with and those without a TPM. Validate connectivity after a gpupdate. The extent of testing and validation depends on your risk acceptance level. If you're confident everything's working as expected, update the existing Request IPSec GPOs to Require. Once that's done, you can safely remove the temporary GPO_IPSec_Require, its served its purpose. Whoa there, Mine's not Working.... Another fine mess...the network isn’t connecting because IPSec can’t establish a secure tunnel. When in “Require” mode, no tunnel means no traffic, so you’re stuck until it’s fixed. Start by checking the Security Event IDs like 5450, 5451, or 5442. These will point to why the IPSec negotiation failed, whether it’s a certificate issue, authentication error, or policy mismatch. Then, open wf.msc and look under Monitoring > Security Associations for Main Mode and Quick Mode. If there are no active associations, that confirms the tunnels have either collapsed or never got created in the first place. If you can’t identify the problem right away, temporarily switch GPO_IPSec_Require back to “Request”. This is very unlikely to restore connectivity, if you werent already on the DC with GPO Management open, update the policy and gpupdate. With connectivity restored, resolve any issues highlighted in the Event logs, then try Required again. If the Event logs provide no clues, verify that both the separate authentication certificate and the IPSec certificate are properly enrolled, combining them into a single certificate will break IPSec. Thoroughly check all GPO IPSec settings for any misconfigurations. Request mode lets connections pass whether or not IPSec succeeds, while Require mode blocks anything that doesn’t meet IPSec strict criteria, which is why Request often “just works” while Require can fail if the environment isn’t perfectly configured. No Connectivity, no GPO... Without connectivity, there is little chance of any GPO ever reapplying, undoing the Require. There is one solution, delete the Registry hive for the GPO Settings: Open Regedt32 Browse to HKLM:\Software\Policies\Microsoft\WindowsFirewall. Delete WindowsFirewall. Reboot Another Step in the Journey to Zero Trust is Over After questioning my sanity, and whether I truly really wanted to go through with enabling IPsec, it's finally in place. It wasn’t without its challenges, enabling "Required" led to a fair bit of pain, including network profiles switching to Public from Domain, leading to denial of services and some other random dropped network connections. Still, I think (still not entirely sure) the effort was worth it. I'm now at least one step closer to Zero Trust, and what I’m convinced will be the world’s most secure home lab. Related Posts: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x Part 4 - IPSec for the Windows Domain Part 5  - AD Delegation and Separation of Duties Part 6  - Yubikey and Domain Smartcard Authentication Setup Part 7  - IPSec between Windows Domain and Linux using Certs

The Road to the World's Most Secure Home Lab.... So far in the pursuit of the World's most secure home lab, the following have been implemented: Related Posts: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x Part 4 - IPSec Part 5  - AD Delegation and Separation of Duties What's Covered in this Blog This post covers implementing YubiKey smart card authentication and how it's implemented with a Windows Enterprise CA. What Is Zero Trust - Recap Zero Trust is a security framework that assumes no user, device, or network segment is inherently trustworthy, regardless of where it sits in the network. The core principles include: Verify explicitly - Always authenticate and authorize access. Use least privilege access – Limit access to only what's needed. Assume breach – Design as if attackers are already in the network. How Smart Cards Address Zero Trust Security Zero Trust is built on the principle of “never trust, always verify.” It requires strict identity verification, least-privilege access, and continuous authentication. Strong Identity Verification: Smartcards use embedded chips to store cryptographic keys securely. They require something you have (the card) and something you know (a PIN), making them ideal for strong, multi-factor authentication. Credential Protection: Because authentication happens on the card itself, sensitive credentials are never exposed to the device, reducing the risk of phishing, keylogging, or malware-based theft. How YubiKey Functions as a SmartCard YubiKey devices support smart card functionality through their PIV (Personal Identity Verification) capability, which implements the NIST SP 800-73 standard. This allows organizations to use YubiKeys for authentication, signing, and encryption in enterprise environments. The PIV applet on the YubiKey securely stores cryptographic keys and certificates, enabling seamless authentication in Windows Active Directory domains. Yubikey Core SmartCard Functionality A YubiKey operates as a hardware security module that: Stores private keys securely in tamper-resistant hardware Performs cryptographic operations internally (signing, decryption) Prevents private key material from ever leaving the device Key Technical Components Secure Element: A dedicated cryptographic processor with: Protected memory for storing private keys and certificates Hardware-based random number generation Tamper-resistant design to prevent physical attacks Certificate Storage Architecture YubiKeys store certificates in a structured slot system: 24 Total Storage Slots: Slots 9a, 9c, 9d, and 9e are the primary slots used for certificates Each slot can store one certificate/key pair Slot 9a: Authentication (typically used for workstation login) Slot 9c: Digital Signature Slot 9d: Key Management (encryption/decryption) Slot 9e: Card Authentication YubiKey Smart Card Implementation To enable smartcard authentication in a Domain, we’ll need to configure Group Policy and create a certificate smart card template. GPO Settings Enable the following 3 settings under Computer Configuration > Admin Templates> Windows Components > Smart Card: Allow certificate with no extended key usage certificate attributes Allow ECC certificates to be used for logon and authentication Turn on Smart Card Plug and Play Service Note: When the Certificates employs Elliptic Curve, the 'Allow ECC certificates to be used for logon and authentication' must be enabled. YubiKey Smartcards Software YubiKey functionality requires the following: Drivers: Any system where the smartcard is used must have the appropriate drivers installed for the YubiKey to be recognized. Management Software: The YubiKey Manager software is needed to configure the devices and set users’ smartcard PINs. Download: The software can be downloaded from this link https://www.yubico.com/support/download YubiKey Manager To configure a YubiKey open the Manager application Insert the first YubiKey Navigate to Interfaces Deselect all USB types other than PIV To set the user's PIN, this is the pin used by the user during logon, navigate to: Applications, select PIV > PIN Management Configure PIN Select 'Use Default' or enter 123456 Enter a new PIN Smartcard Certificate Template Log in to the Certificate Authority (CA) server using an account with Domain Admin rights or delegated CA Manager permissions. At the Run prompt, enter certsrv.msc, navigate to Certificate Templates, right-click, and select Manage. According to YubiKey's guidance, you can use the Smartcard Logon template for deployment, and this is my intention. However, when the User certificate template is already issued and the Smartcard Logon template is later deployed for enrollment. Testing has shown that overlapping certificate purposes can lead to authentication failures, confusion on the part of which certificate is presented, during smartcard logon. Duplicate the Smartcard template. General Tab: Publish certificate in Active Directory Do not automatically reenroll if a duplicate certificate exists in Active Directory Compatibility tab: Windows Server 2016 Windows 10 / Windows Server 2016 Request Handling tab: Include symmetric algorithms allowed by this subject For automatic renewal of smart card certificates, use the existing key if a new key cannot be created. Prompt the user during enrollment. Cryptography tab: ​ Key Storage Provider' and 'ECDH_P384 (ECDH_P512 isn't supported) ​Requests must use one of the following providers Microsoft Smart Card Key Storage Provider Request hash is 256 ​ The table below compares the equivalent security levels of Rivest–Shamir–Adleman (RSA) and Elliptic Curve Cryptography (ECC). It highlights how ECC achieves the same level of security with significantly shorter key lengths and lower computational overhead. As ECC key sizes grow modestly, the corresponding RSA key sizes increase disproportionately. RSA ECC Devisable by 512 112 4.6 1024 160 6.4 2048 224 9.1 3072 256 12.1 7680 384 20 15360 512 30 Security tab: Add Authenticated Users and Autoenroll A named AD group could be used instead for a more targeted enrollment. Subject Name tab: User principal name (UPN) is enabled E-mail name is unchecked Add the email address to the User attributes as an alternative to removing. Enrolment will fail if the E-mail name is enabled and not provided at enrollment. Smartcard Enrollment Once the YubiKey drivers are installed on the client machine, the user can enroll for a Smartcard certificate. Enrollment: The user opens 'certmgr.msc' Navigate to Personal > Certificates Right click on Certificates > All Tasks > Request New Certificate Select Active Directory Select the Smartcard template and enroll. During the enrollment process, when prompted, enter the PIN that was configured earlier during YubiKey setup. The YubiKey smartcard is now configured for User logon. Smart Card Misconceptions and Important Next Steps Windows password authentication is vulnerable to brute force, dictionary, guessing, and phishing attacks. Smartcards significantly reduce these risks. Although commonly thought to eliminate passwords entirely, that's not entirely accurate. When a user account is configured for smartcard authentication within the User AD account, the password is reset one time to a random 120 character string. Failing to set the "Smart card is required for interactive logon" flag leaves the user's existing password unchanged, allowing them to continue logging in with their original, potentially insecure credentials. That Password is still there for SSO: During the AS_REP stage of Kerberos authentication, the Key Distribution Center (KDC) includes the NTLM hash of this password in the PAC to support fallback to SSO when Kerberos is unavailable. The random password is highly resistant to offline cracking, even against well-resourced attacks using tools like John the Ripper. The User password is not so resistant. Pass the Hash Enabling smartcard authentication still leaves user accounts exposed to Pass-the-Hash attacks. As previously stated, when the 'Smartcard is required for Interactive logon' is set, the user’s password is reset to a long, random value, but it remains static indefinitely. Without regular password rotation, the account stays vulnerable to Pass-the-Hash. To mitigate this risk, use the script below to refresh user passwords daily. $scTrue = Get-ADUser -Filter  -Properties  | where {$_.SmartcardLogonRequired -eq "True"} | Select-Object name,SmartcardLogonRequired foreach ($user in $scTrue) { $name = $user.name Set-ADUser -Identity $name -SmartcardLogonRequired:$false Set-ADUser -Identity $name -SmartcardLogonRequired:$true } Important: Do not create a scheduled task on a Domain Controller running under a Domain Admin account to flip the smartcard attribute, this is reckless and a serious abuse of privileged credentials. The correct approach is to: Create a dedicated service account with delegated 'Write' permissions to the smartcard logon attribute on the Users OU. Assign the service account 'Log on as a batch job' rights on a hardened member server with the Active Directory tools installed. Create a scheduled task that runs daily, encoding the PowerShell script in Base64 and embedding it directly in the Task Scheduler's action tab. That's the Easy Part of the Zero Trust Completed.... The home lab’s in pretty good shape, certs everywhere, and a solid step toward Zero Trust. But let’s be honest, plastering certificates on every domain object is just providing a false sense of security. There are still gaps, some can be secured, whilst others probably not. Those Linux devices, the pfSense, the wifi AP and the printer all require my attention. The biggest challenge is monitoring, it's resource hungry and needs an enormous amount of effort to correctly configure. Despite the effort, monitoring will provide a major feature in the Zero Trust architecture, allowing me insight and visibility into the Home Lab. There's no rest for the wicked and even less for those trying to keep the wicked at bay... thanks and hope content so far is proving insightful. Next up is IPSec for Linux, after a break and some sleep. Related Posts: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x Part 4 - IPSec for the Windows Domain Part 5  - AD Delegation and Separation of Duties Part 6  - Yubikey and Domain Smartcard Authentication Setup Part 7  - IPSec between Windows Domain and Linux using Certs

The Road to the World's Most Secure Home Lab.... So far in the pursuit of the World's most secure home lab, the following have been implemented: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x Part 4 - IPSec What's Covered in this Blog This post covers the implementation of a fully scripted AD OU structure and delegation model. What Is Zero Trust - Recap Zero Trust is a security framework that assumes no user, device, or network segment is inherently trustworthy, regardless of where it sits in the network. The core principles include: Verify explicitly – Always authenticate and authorize access. Use least privilege access – Limit access to only what's needed. Assume breach – Design as if attackers are already in the network. How AD Delegation and Separation of Duties Address Zero Trust Security Zero Trust relies on minimizing trust and continuously verifying access. Active Directory delegation and separation of duties help enforce this principle by: Delegating Permissions: Assigning only necessary privileges to users, ensuring least-privilege access for each role. Separation of Duties: Splitting administrative tasks across different users or teams to prevent any one person from having too much control, reducing risks and ensuring accountability. These practices ensure access is strictly controlled and monitored, forming a key part of a Zero Trust framework. Revisited Most of this blog is repurposed from a previous article, the good news is that the delegation model is fully scripted and downloadable: Part 1 , includes how to prep and run the script. Script , downloadable from github. You may notice the domain name has changed. This home lab uses a full delegation model that’s evolved organically over more than a decade, unscripted, functional and secure, it's configured with URA deny policies to keep separation between tiers. This scripted approach isn't necessarily better, but it's shareable, the script can do in minutes, what would take a week manually. Aim of the Game The objective is to establish an Organizational Unit (OU) structure that aligns with a clear and consistent delegation model. This approach incorporates well-defined naming standards to enhance comprehensibility and facilitate ease of navigation and management within the structure. AD Group Best Practice Group management will follow Microsoft's best practice of assigning Domain Local groups against the object, eg an OU or GPO. The Domain Local group is then added as a 'Member of' a Domain Global group. The user is added to Domain Global as a 'Member'. The naming convention I've persisted with over the years, again from Microsoft, is naming delegation groups 'Action Tasks', a task being an individual permission set. And 'Roles', a role being a collection of Tasks or individual permissions. AG is Action Task Global Group AL is Action Task Domain Local Group RG is a Role Global Group RL is a Role Domain Local Group Again, something that I've persisted with over the years is that Groups and OUs are named based on their Distinguished Name (DN). Let's break down an example of a group name: AG_RG_Member Servers_SCCM_Servers_ResGrpAdmin AG\AL\RG\RL - Action Task Global, AL for AT Domain Local, R for Role RG\OU\GPO - Restricted Group, OU or GPO - Type of object delegation Member Servers - The Top-Tier OU name SCCM - The Application or Service eg SCCM or Certificates Servers - It's for Computer objects ResGrpAdmin - ResGrpAdmin is a Restricted Group providing Admin privileges. ResGrpUser is a Restricted Group providing User privileges. CompMgmt, create\delete and modify Computer objects. UserMgmt, create\delete and modify User objects. GroupMgmt, create\delete and modify Group objects. GPOModify, edit GPO settings. SvcMgmt, create\delete and modify user objects. FullCtrl, full control over OU's and any child objects. JSON OU Configuration Traditionally, there are only 3 tiers, the lower the tier the less trustworthy: Zero = Domain Controllers and CA's One = Member Servers Two = Clients and Users Given that this script can potentially generate numerous levels or hierarchies, it seemed more suitable to avoid the term "tier" and instead opted to label the top-level OU's as "Organizations" for a more meaningful representation. The JSON configuration provided creates an OU structure based on a default OU structure for many businesses, where Orgainisation1 is for Member Servers and Orgainisation2 is for Clients and Users. In addition, Organisation0 provides Admin Resources OU for the management of all delegation, role and admin account provision. Organisation0 - Admin Resources Organisation0 , creates a top-level management OU named Admin Resources ' This OU serves as the central hub for all delegation and management groups across subsequent Organizations. Each Organization benefits from having its own dedicated management OU within the Admin Resources OU. Organisation specific delegation groups, roles, and admin accounts are created. This approach allows for potential future delegation. Admin Accounts Member Servers Admin Tasks Member Servers Admin Roles Member Servers "OU": { " Organisation0 ": { "Name":"Admin Resources", "Path":"Root", "Type":"Admin", "Protect":"false", "AdministrativeOU":"Administrative Resources", "AdministrativeResources": [ "AD Roles,Group", "AD Tasks,Group", "Admin Accounts,User" ] }, Organisation1 - Member Servers Organisation1 represents the typical Member Server OU and it's of the Type Server . The type Server designates a behavioural difference for assigning policy. AppResources designates application service OU's that will be created eg Exchange. Service Resources is used for creating OU's based on a set of standard administrative functions for example Servers and the delegation and object type of Computers. " Organisation1 ": { "Name":"Member Servers ", "Path":"Root", "Type":"Server", "Protect":"false", "AdministrativeOU":"Service Infrastructure", "AdministrativeResources": [ "AD Roles,Group", "AD Tasks,Group", "Admin Accounts,User" ], "AppResources":"Certificates,MOSS,SCCM,SCOM,File Server,Exchange", "ServiceResources": [ "Servers,Computer", "Application Groups,Group", "Service Accounts,SvcAccts", "URA,Group" ] }, Organisation2 - Client Services Organisation2 represents the typical User Services OU and it's of the Type 'Clients'. " Organisation2 ": { "Name":"User Services", "Path":"Root", "Type":"Clients", "Protect":"false", "AdministrativeOU":"Service Infrastructure", "AdministrativeResources": [ "AD Roles,Group", "AD Tasks,Group", "Admin Accounts,User" ], "AppResources":"Clients", "ServiceResources": [ "Workstations,Computer", "Groups,Group", "Accounts,User", "URA,Group" ] } } Hundreds and thousands It's possible to add further top-level OU's by duplicating an Organisation, then updating the Organisation(*) and Name values as they need to be unique. It's possible to add hundreds or even thousands of Organisations, with this possibility in mind, the management and delegation structure reflects this within the design. Levels of OU Delegation As we delve deeper into the structure of each organization, we encounter a hierarchy consisting of three levels of delegation, using Member Servers as an example: Organisation = Member Servers (Level 1) Application Service = Certificates (Level 2) Resources = Computer, Groups, Users and Service Accounts (Level 3) OU delegation controls the level of access to manage objects eg create a Computer or Group object. Level 1 Level 1 is the organisation level in this case it's the Member Server OU. It's delegated with AL_OU_Member Servers_FullCtrl . The group provides full control over the OU, sub-OU's and all objects within. The arrow serves as an indicator, denoting the point at which the group's application takes effect within the structure. Level 2 Level 2 is the Service Application level, in this case, Certificate services. AL_OU_Member Servers_Certificates_FullCtrl is applied a level below Member Servers and provides full control over itself and any subsequent objects. Level 3 At Level 3, the delegation involves the management of Service Applications resources, which includes items such as Server objects and service accounts. The 4 default OU's allow the delegation and management of their respective resource types, for example, the Application Groups OU permits the creation and deletion of Group objects via AL_OU_Member Servers_Certifcates_Applications Groups_GroupMgmt . Application Groups - Application specific Groups Servers - Server or Computer objects Service Accounts - Service Accounts for running the application services URA - User Rights Assignments for services that require LogonAsAService etc Restricted Groups and User Rights Assignment (URA) Levels In this delegated model, Restricted Groups facilitate access by allowing administrative access whilst User Rights Assignments (URA) allow admins or users to log on over Remote Desktop Protocol (RDP). There are two primary levels of organization. The first level encompasses the entire organization, including all subsequent Organizational Units (OUs). The second level consists of a dedicated Servers OU for each specific Service Application. Level 1 of Restricted Groups The GPO GPO_Member Server_RestrictedGroups is linked to the Member Servers OU and has the following groups assigned: URA: Allow log on through Terminal Services: AL_RG_Member Servers_ResGrpAdmin AL_RG_Member Servers_ResGrpUser Restricted Group: Administrators: AL_RG_Member Servers_ResGrpAdmin Remote Desktop Users: AL_RG_Member Servers_ResGrpUser This is how it looks when applied in GPO. Within this delegation model, the ability to manage Group Policy Object (GPO) settings is also delegated to ensure comprehensive control and management of the environment. via AL_GPO_Member Servers_GPOModify Group. Level 2 of Restricted Groups The GPO GPO_Member Server_Certificates_Servers_RestrictedGroups is linked to the sub-OU Servers under Certificates and has the following groups assigned, that of the Organisation and of the Service Application: URA: Allow log on through Terminal Services: AL_RG_Member Servers_ResGrpAdmin AL_RG_Member Servers_ResGrpUser AL_RG_Member Servers_Certifcates_ResGrpAdmin AL_RG_Member Servers_Certificates_ResGrpUser Restricted Group: Administrators: AL_RG_Member Servers_ResGrpAdmin AL_RG_Member Servers_Certifcates_ResGrpAdmin Remote Desktop Users: AL_RG_Member Servers_ResGrpUser AL_RG_Member Servers_Certificates_ResGrpUser This is how it looks when applied in GPO. As above Group Policy Object (GPO) settings are also delegated via AL_GPO_Member Servers_Certificates_Servers_GPOModify Bringing it all together with Roles In this demonstration, an account named 'CertAdmin01' has been specifically created to oversee the management of resources within the Certificates OU. The account is added to the role group RG_OU_Member Servers Certificates_AdminRole . Opening the RG_ group and then selecting the 'Members Of' tab displays the nested RL_ group. Drilling down into the RL_ group displays the individual delegated task groups. Delegated Admin To test the certificate Admin (CertAdmin01) deploy an additional server, adding to the domain and ensuring the computer object is in the Certificate Servers OU. Login as CertAdmin01 to the new member server and install the GPO Management and AD Tools. Browse to Member Server and then Certificates OU and complete the following tests: Right-click on Applications Group > New > Group Right-click on Servers > New > Computer Right-click on Service Accounts > New > User Right-click on URA > New > Group. Open Group Policy Management and Edit GPO_Member Servers_Certificates_Servers_RestrictedGroup. Open Compmgmt.msc and confirm that the Administrators group contains the 2 _ResGrpAdmin groups and the local Administrator. AL_RG_Member Servers_Certificates_Servers_ResGrpAdmin AL_RG_Member Servers_ResGrpAdmin Confirm that CertAdmin01 is unable to create or manage any object outside the delegated OU's. Nearly there.....SCM Policies and ADMX Files As part of the delivery and configuration of the OU structure, Microsoft's Security Compliance Manager (SCM) GPOs and a collection of Administrative (ADMX) templates are included. SCM GPOs: Microsoft's SCM offers a set of pre-configured GPOs that are designed to enhance the security and compliance of Windows systems. These GPOs contain security settings, audit policies, and other configurations that align with industry best practices and Microsoft's security recommendations. ADMX Templates: ADMX files, also known as Administrative Template files, extend functionality within Group Policy Management enabling settings for Microsoft and 3rd party applications. Within a Domain, ADMX files are copied to the PolicyDefinition directory within Sysvol. Zipped... Both SCM and ADMX files are zipped and will automatically be uncompressed during the OU deployment. However, if you would like to add your own policies and ADMX files you can. SCM Policy Placement The SCM policies are delivered in their default configuration, without any modifications or merging. The policies are placed directly into the designated target directory, imported and linked to their respective OU. For example, the Member Server directory content will be linked to any OU that is of type 'Server'. The SCM imported policies are prefixed with 'MSFT,' indicating that they are Microsoft-provided policies. There are a substantial number of these policies linked from the root of the domain down to client and server-specific policies. As far as delegation the SCM policies remain under the jurisdiction of the Domain Admin with control to effect change delegated to the _'RestrictedGroup' policies. One More Step in the Windows Journey to Zero Trust Remains You’ve successfully kicked your Domain Admins off the workstations, and they didn't even see it coming, well done. There's one final Microsoft hoop to jump through and you thought I had finished with certificates: Next up is Smartcard authentication. Related Posts: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x Part 4 - IPSec for the Windows Domain Part 5  - AD Delegation and Separation of Duties Part 6  - Yubikey and Domain Smartcard Authentication Setup Part 7  - IPSec between Windows Domain and Linux using Certs

The Road to the World's Most Secure Home Lab.... So far in the pursuit of the World's most secure home lab, the following have been implemented: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense What's Covered in this Blog This post explains how to implement EAP-TLS 802.1X authentication using FreeRADIUS alongside a Windows Enterprise CA for domain joined clients. What Is 802.1X and What Authentication Types Can Be Used? IEEE 802.1X is a network access control standard that enforces authentication before allowing devices to connect to a wired or wireless network, preventing unauthorized access to network resources. 802.1X works by involving three components: Supplicant: The device trying to connect (e.g., a laptop) Authenticator: The network device (e.g., switch or wireless access point) Authentication Server: Typically a RADIUS server that verifies credentials (pfSense) What Is Zero Trust - Recap Zero Trust is a security framework that assumes no user, device, or network segment is inherently trustworthy, regardless of where it sits in the network. The core principles include: Verify explicitly – Always authenticate and authorize access. Use least privilege access – Limit access to only what's needed. Assume breach – Design as if attackers are already in the network. How 802.1x Addresses Zero Trust Security Device and User Authentication at the Network Edge: 802.1x enforces authentication before a device can even communicate on the network. By validating the identity of both users and devices before granting access, it ensures that only trusted entities can join the network. Dynamic Access Based on Identity: After successful authentication, network access can be dynamically assigned based on user roles or device attributes, such as through VLAN tagging or access control lists. This supports Zero Trust’s principle of least-privilege access and helps isolate systems by trust level. Continuous Monitoring and Enforcement: When integrated with a Network Access Control (NAC) system, 802.1X allows ongoing assessment of device posture and compliance, with the ability to quarantine or restrict access if the device falls out of policy. Microsoft’s native NAC solution, Network Access Protection (NAP), has been deprecated and is no longer available. pfSense does not support full NAC functionality, Third-party solutions such as PacketFence, Aruba ClearPass, or Cisco ISE are required to fulfill this role. Segmentation and Isolation: 802.1x pairs well with network segmentation strategies. Devices that fail authentication or are unknown can be automatically placed into restricted VLANs, such as guest or quarantine zones. This limits exposure and aligns with Zero Trust’s goal of minimizing lateral movement. Authentication Options MAC Address Authentication For devices that can't run 802.1X (like printers or IP phones), the switch can authenticate based on the device's MAC address. This is the least secure and is typically used as a fallback method. PEAP with Active Directory (Username/Password-Based Authentication) PEAP (Protected Extensible Authentication Protocol) creates a secure TLS tunnel to protect the authentication exchange. Inside that tunnel, it commonly uses MSCHAPv2, which authenticates users via their Active Directory username and password. While this provides a basic layer of security, MSCHAPv2 has known vulnerabilities. If an attacker manages to capture the encrypted challenge, they can potentially crack it using brute-force or dictionary attacks. The effectiveness of this method ultimately depends on strong password hygiene and the security of your Active Directory environment, which can be a weak link in many setups. EAP-TLS with Certificates (Certificate-Based Mutual Authentication) EAP-TLS, on the other hand, uses digital certificates for both the client and the server to perform mutual authentication. Both sides must present valid certificates, creating a highly secure, trust-based environment. Since no passwords are exchanged, this method is immune to common credential-based attacks like brute-force, phishing, or credential stuffing. It also offers strong cryptographic protections, making it highly resistant to replay and man-in-the-middle (MiTM) attacks. Why I'm Choosing EAP-TLS Given the significantly stronger security model and elimination of password-based vulnerabilities, the obvious choice for my environment is EAP-TLS. It provides robust, certificate-based authentication. 802.1X and RADIUS Configuration Okay, let's set up 802.1X authentication on the pfSense using FreeRADIUS and an Enterprise Certificate Authority (CA). This is a long one, better grab that coffee now... Configure the Microsoft Enterprise CA On the CA server, open the Certification Authority console (certsrv.msc). Create a RADIUS Server Certificate Template:  Right-click Certificate Templates and select Manage. Right-click the RAS and IAS Server template (or Workstation Authentication as a base) and select Duplicate Template.   Compatibility Tab:  Set compatibility levels to Windows Server 2016 General Tab:  Template display name: pfSense RADIUS Server. Validity period: 2 years Do not check 'Publish certificate in Active Directory.' Request Handling Tab:  Purpose: Signature and encryption. Do not allow the private key to be exported, ensure it is unchecked. Cryptography Tab:  Provider Category: Key Storage Provider Algorithm Name: ECDH_P384 Minimum key size: 384 Request hash: SHA384 Subject Name Tab:  Select Supply in the request. pfSense will generate the necessary information based on your inputs. Click OK on the warning popup. Extensions Tab:  Select Application Policies and click Edit.... Remove Client Authentication, if present. Make sure the Server Authentication is present > Click OK. Select Key Usage and click Edit.... Ensure the Digital signature is checked. Allow key exchange only with key encipherment (key encipherment) is checked. Ensure 'Make' this extension critical is unchecked. Security Tab:  Ensure Authenticated Users have Read permission. Create an AD Group and assign 'FULL Control'. Group name is 'RG_CA_pfSense_Radius_Req' Add the account that will be used to create and enroll the Radius certificates Click Apply and OK. Publish the New Template:  In the Certification Authority console Right click Certificate Templates, select New, then Certificate Template to Issue.   Select your newly created pfSense RADIUS Server Template.  Configure pfSense & Generate CSR Install FreeRADIUS Package: Log in to your pfSense web interface. Navigate to System > Package Manager > Available Packages. Search for 'radius'. Click Install and confirm. The installation will take a while. Import the CA Certificate: From the CA, export the Root CA certificate: Right-click your CA name > Properties. On the General tab, click View Certificate. Go to the Details tab, click Copy to File.... Export Next > Select Base-64 encoded X.509 Next > Choose a filename > pfSenseRootCA.cer On pfSense: Navigate to System > Certificates > Authorities Click Add. Descriptive name: Enter something meaningful Method: Import an existing Certificate Authority. Certificate data: Paste the entire content of pfSenseRootCA.cer Click Save. Generate Certificate Signing Request (CSR) on pfSense:  Navigate to System > Certificates > Certificates. Click Add/Sign. Add/Sign a New Certificate: Method: Create a Certificate Signing Request. Descriptive name: Toyo pfSense Radius Server. External Signing Request Key type: ECDSA Key length: secp384r1 [HTTPS] - match the template Digest Algorithm: sha384 - match the template Common Name (CN):  radius.toyo.loc Crucial!  This MUST be the Fully Qualified Domain Name (FQDN) or IP address of the RADIUS server. From DNS console on the DC: Create an 'A Record' to the LAN interface - pfsense.toyo.loc @ 192.168.0.1 Create an ALIAS (CNAME) named 'radius' that resolves to pfsense.toyo.loc Country Code: GB State or Province: Hook City or Locality: Hants Organization: Tenaka.net Organizational Unit: IT Department. Home Lab Certificate Attributes:  Certificate Type: Server Certificate Alternative Names: The IP of the pfSense LAN address 192.168.0.1 Add SAN Row FQDN or Hostname: radius.toyo.loc Add SAN Row FQDN or Hostname: radius IP Address: 192.168.0.1 FQDN or Hostname: pfsense FQDN or Hostname: pfsense.toyo.loc Export the CSR Export the newly created CSR by clicking on the arrow with the door icon. Issue the Certificate using the CSR Ensure your account has admin rights and is a member of the 'RG_CA_pfSense_Radius_Req' Group open CMD or PowerShell. Run command: certreq -submit -attrib "CertificateTemplate:pfSenseRADIUSServer" "C:\cert\pfSense+CSR.req" pfSense+CSR.req is the csr previously downloaded CertificiateTemplate:pfSenseRADIUSServer is the Template Name and not the Display Name A dialog will pop up asking you to select the CA; choose your issuing CA and click OK. Another dialog will ask where to save the issued certificate (.cer). Choose a location and filename of 'pfSense Radius Cert.cer' Click Save.   Import Issued Certificate into pfSense Navigate to System > Cert. Manager > Certificates Find the CSR entry you created earlier (Toyo pfSense RADIUS Server CSR). Click the Edit icon (pencil). Open the issued certificate file 'Toyo pfSense RADIUS Server.cer' with Notepad. Copy the entire content (including BEGIN/END lines). Paste this content into the Final Certificate data field. Add a description Click Update. The entry should now change from a CSR to a valid certificate, showing its issuer and validity dates. Certificate Revocation List (CRL) You have 7 days... Crucial!   When certificate revocation checking is enabled, a valid CRL must be configured to verify whether certificates have been revoked. If revocation checking is enabled but the CRL is unavailable, clients will be unable to confirm their certificate status and authentication will fail. Crucial!   In EAP-TLS, both the client and pfSense validate certificates. A critical part of this validation is checking whether a certificate has been revoked, which it does using the CRL . If the CRL has expired or is not available, pfSense will consequently fail authentication for the client. The default expiry is 7 days. With the current pfSense configuration, CRL updates are handled manually, and the CRL expires every 7 days. This is sub-optimal if the CRL isn’t updated on time, client authentication will fail across the board, locking users out of the Wi-Fi. Automating this is on the backlog... honest. The CRL validity is being extended to 6 months, which isn’t ideal. The key caveat is that any time a certificate is revoked, the CRL on pfSense must also be updated to reflect the change. CRL Publishing Parameters: On the CA, right click Revoked Certificates > Properties. Update the CRL publication interval to 6 Months. Update Publish Delta CRLs to weekly. Publish the CRL with the new expiry date. Right click Revoked Certificates > All Tasks > Publish CRL Export\Import The CRL will require exporting to a Base64 file and then pasting into pfSense. Copy the latest crl from C:\Windows\System32\CertSrv\CertEnroll\ to C:\Certs and then convert it to Base64. certutil -encode "c:\certs\TOYO-TOYO01-CA(3)+.crl" c:\certs\crl_base64.txt Navigate to System > Cert. Manager > Certificates > Revocation On the drop-down, select CA (Toyo CA) and Add Select 'Import an existing Certificate Revocation List' Add a Descriptive name Copy and paste the crl_base64.txt content. Save There should now be a CRL entry. Configure FreeRADIUS on pfSense Navigate to Services > FreeRADIUS. Interfaces Tab:  Click Add. Interface IP Address: Select the pfSense LAN IP address 192.168.0.1 Port: 1812 (standard RADIUS Authentication port). Interface Type: Authentication. IP Version: IPv4. Description: LAN Radius Authentication Click Save. Click Add again. Interface IP Address: Select the same pfSense IP address. Port: 1813 (standard RADIUS Accounting port). Interface Type: Accounting. IP Version: IPv4. Description: LAN Radius Accounting Click Save. NAS / Clients Tab:  This is where you define your switches or wireless access points that will forward authentication requests to pfSense. Click Add. Client IP Address: Zyxel Wifi AP is @ 192.168.0.253 Client IP Version: IPv4. Client Shared Secret: Some ridiculously long password You must configure the same secret on your switch/AP. (Zyxel Wifi AP) Ensure the secret conforms to best practice Client Shortname: Enter the hostname of the AP Add other switches, routers, and AP devices as needed. Click Save. EAP Tab:  The EAP tab configures authentication methods like EAP-TLS or PEAP used for secure 802.1X network access. EAP: Check the Disable weak EAP types: MD5, and GTC Default EAP Type: TLS. Disable Weak EAP Types: Checked. Minimum TLS version: 1.2 Certificates for TLS: On each of the drop-downs, select the relevant CA settings Note: If the SSL Revocation List option is set and misconfigured, clients will fail to validate their certificates and won't be able to connect to the 802.1x SSID. It's possible to select None for testing purposes, but this is not a suitable option for production. EAP-TLS: Include Length: Yes Fragment Size: 1024 Check Cert Issuer: Enable CA Subject: Blank Check Client Certificate: EAP-TLS Cache:  Leave the defaults PEAP and TTLS: Leave other EAP types like PEAP, TTLS settings at their default values. Click Save. Settings Tab:  Select the Settings Tab. General Configuration: Leave the General Configuration settings at their default values. Logging Configuration: This is a personal preference, the Radius Logging Destination is updated to output to the radius.log All other settings remain default. Click Save. Configure Switch/AP (Zyxel Wifi) The original Zyxel NWA50AX is another casualty of implementing Zero Trust, it turns out it doesn’t support 802.1X or WPA2 Enterprise. So, after discovering that fun fact the hard way, I swapped it for an NWA130BE. £160 later, we finally have proper 802.1X support. SSID Profile Wizard: A new SSID was created, subtly named, of course, and initially configured with VLAN ID 1. While this configuration allowed clients to connect, it failed to automatically switch them to VLAN 40 and the Client interface. However, since automatic VLAN switching wasn’t functioning as expected, the VLAN ID was explicitly set to 40 within the SSID configuration. I guess I was asking too much for £160. Security Profile Wizard: Select WPA2 and Enterprise Primary Radius Server Activated: Enable Radius Server IP Address: 192.168.0.1 Radius Server Port: 1812 (authentication port, to match the port assigned on the pfSense) It's time to pull out that shared secret set in the NAS/Clients section of the pfSense earlier. Save Configure Windows Clients The pfSense firewall will require a tweak to allow Clients on VLAN 40 to access the Switch/AP Navigate to the Firewall > Rules > VLAN40_Clients. Add an 'allow' rule between the Zyxel Wifi alias on 192.168.0.253 and the alias for clients. Basic CA and GPO Configuration:  Ensure every Windows Domain client trusts the Windows Root CA, and deploy it using GPO if necessary. Enable auto-enrollment of certificates in Group Policy, certificate templates with the Autoenroll permission will do just that, and enroll automatically. Deploy Workstation Authentication Client Certificate - TPM Supported: It would almost feel wrong not to deploy more certificates. This time, the clients are getting the full treatment. Not all of my Windows clients and servers are blessed with a TPM, case in point, the Intel Skull Canyon and the Gen 6 Hyper-V host, they still cling to life with retirement being long overdue. Without the TPM there's no support for the Microsoft Platform Crypto Provider. The fallback option when a TPM isn't available is to use the Microsoft Software Key Storage Provider, which is managed through Active Directory groups that control certificate enrollment. Create the following AD Groups: For Computer objects that do not support TPM RG_CA_WksAuthCert_Deny_TPM_Supt For Computer objects that do support TPM RG_CA_WksAuthCert_Allow_TPM_Supt Workstation Authentication Template: Right-click Certificate Templates and select Manage. Right-click the Workstation Authentication template and select Duplicate Template.   Will assume that the Workstation Authentication or Computer templates are NOT deployed. General Tab: Template display name: Toyo Workstation Authentication Validity period: 1 years Renewal period: 6 weeks Check 'Publish certificate in Active Directory.' Compatibility Tab:  Set compatibility levels to Windows Server 2016 Cryptography Tab:  Provider Category: Key Storage Provider Algorithm Name: RSA RSA is supported for key generation and storage in the TPM. ECC (Elliptic Curve Cryptography) isn't generally supported for TPM storage of certificates. Minimum key size: 2048 Request hash: SHA256 Requests must use one of the following providers: Microsoft Platform Crypto Provider Microsoft Platform Crypto Provider is the Key Storage Provider (KSP) that allows certificates and their private keys to be stored in the Trusted Platform Module (TPM). If no TPM is accessible, the certificate will fail to enroll. Subject Name Tab: Under 'Build from this Active Directory Information' Subject name format: Common Name is selected Include this information in alt sub name: Check DNS   Extensions Tab:  Select Application Policies and click Edit.... Ensure that the Client Authentication is present. Security Tab:  Ensure Domain Computers is removed Add RG_CA_WksAuthCert_Allow_TPM_Supt Allow Read, Enroll, and AutoEnroll. Click Apply and OK. Deploy Workstation Authentication Client Certificate - TPM is Not Supported: Toyo Workstation Authentication Template: Right-click Certificate Templates and select Manage. Right-click the Toyo Workstation Authentication template and select Duplicate Template. General Tab: Update the name to show TPM arent supported Cryptography Tab:  Provider Category: Key Storage Provider Algorithm Name: RSA Minimum key size: 2048 Request hash: SHA256 Requests can use any provider available on the subject's computer. Security Tab:  Ensure 'Domain Computers' is removed Add RG_CA_WksAuthCert_Deny_TPM_Supt Allow Read, Enroll, and AutoEnroll. Click Apply and OK. Publish the New Templates:  In the Certification Authority console Right click Certificate Templates, select New, then Certificate Template to Issue.   Select your newly created Toyo Workstation Authentication Templates.  Restart the clients to automatically enroll the certificate or gpupdate /force The Final Step (Honest) - Connect the Client to the Wifi Confirm that the Toyo Workstation Authentication certificate has been enrolled on the clients: As an Administrator, run certlm.msc. Confirm the certificate is present. After all that effort, the final step feels a bit anticlimactic, just select the 'Toyo-802.1X' Wi-Fi network and connect. No passwords required. Review the connection settings: GPO Settings For the Home Lab environment, these GPO settings may be somewhat excessive given there are only four domain joined laptops. However, the GPO will enforce connection to the specified Wi-Fi access point and hide all other SSIDs from view Create a new GPO and link it to the Domain workstations OU. Edit Computer Configuration > Policies > Windows Settings > Security Settings > Wireless Network (IEEE 802.11) Policies. Right-click and Create A New Wireless Network Policy for Windows Vista and Later Releases. General Tab: Update the Policy Name: 802.1x Toyo Wifi Add a description. Click Add. Select Infrastrucuture. Connection Tab: Update the Profile Name: Toyo 802.1X Enter the Network Name(s)(SSID): Toyo-802.1X Ensure that only 'Connect automatically when this network is in range' is selected. Security Tab: Authentication: WPA2-Enterprise Encryption: AES-CCMP Select a network authentication method: Microsoft Smartcard or other certificate Authentication Method: Computer Authentication Click OK Network Permissions Tab: The following settings will hide all other SSID's except those named in this GPO: Select Prevent connections to ad-hoc networks Select Prevent connections to infrastructure networks Uncheck Allow user to view denied networks Select Only Group Policy profiles for allowed networks Support Stuff Given the complexity that is now building within the network, it's not unexpected that there's going to be a few bumps along the way. The following section should help point you in the right direction. pfSense Logs Enable the FreeRadius logs by navigating to Services > FreeRadius > Settings Personal choice, I prefer the radius.log output. Enable temporary SSH access by navigating to System > Advanced > Secure Shell Enable Secure Shell Server Add a Firewall rule to allow TCP port 22 Secure Shell into the pfSense. ssh admin@pfsense.toyo.loc cat /var/log/radius.log When you're done, shut the door behind you, disable SSH and kill the firewall rule." Windows Client Logs When it comes to troubleshooting 802.1X on Windows, the built-in logging and diagnostic tools are: As an Admin, run the following netsh command netsh wlan show wlanreport The netsh wlan show wlanreport  command generates an HTML report that provides a detailed overview of recent Wi-Fi connection history, including connection successes, failures, signal quality, and reasons for disconnects. The following event logs offer a more traditional, readable output for analyzing connection issues. A Step to Zero Trust We made it...eventually, what a long post and a whole lot of certificates. I’ll keep it short from here. Thanks for sticking with it. Next up: IPsec. Don’t miss it... Everyone loves IPSec Related Posts: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x Part 4 - IPSec for the Windows Domain Part 5  - AD Delegation and Separation of Duties Part 6  - Yubikey and Domain Smartcard Authentication Setup Part 7  - IPSec between Windows Domain and Linux using Certs

What Is Zero Trust - Recap Zero Trust is a security framework that assumes no user, device, or network segment is inherently trustworthy, regardless of where it sits in the network. The core principles include: Verify explicitly – Always authenticate and authorize access. Use least privilege access – Limit access to only what's needed. Assume breach – Design as if attackers are already in the network. What's Covered in this Blog This post covers implementing pfSense Netgate 4200, a cheap POE managed switch, VLANs and point-to-point Firewalls. How Do VLANS and Firewalls Address Zero Trust VLAN Tagging: Enforcing Logical Segmentation Virtual LANs (VLANs) break a physical network into multiple, isolated broadcast domains. Each VLAN behaves like a separate network, even if all devices are plugged into the same switch. With 802.1Q tagging, VLANs add a tag to Ethernet frames to denote which virtual segment the traffic belongs to. This enables: Separation of devices by function or trust level (e.g., IoT, guest, management, servers). Containment of potential breaches, malware on a smart TV can't reach your file server. Firewalls: Traffic Policy Enforcement Once VLANs are defined and routed, the firewall rules take over. Each VLAN has its own interface, letting you apply granular, interface-specific policies such as: Blocking traffic between VLANs by default Only allowing explicit communication paths (e.g., IoT devices can talk to the internet but not to the LAN) Logging and monitoring attempts to cross VLAN boundaries Zero Trust for the Home Lab and pfSense This marks the first step in a series of technical changes to the home lab. As outlined in Part 1 , the goal is to implement a Zero Trust model or get as close to it as possible, while avoiding cloud dependencies and keeping costs to a minimum. The old Zyxel USG 60W device has finally been retired, it's out of support, no more firmware updates. This is a basic Zero Trust requirement; keep it updated. Its replacement is a pfSense Netgate 4200. As discussed, one of the key changes is the introduction of 802.1Q VLAN tagging throughout the network. Rather than treating everything behind the firewall as implicitly trusted, I'm segmenting traffic by function: End User Devices, Infrastructure, DNS and IoT. Each VLAN gets its own virtual interface on pfSense, with point-to-point firewall rules and independent DHCP configurations. This rollout has downstream implications. For starters, the Windows Hyper-V hosts will be updated to support trunked VLANs on the switch and the external Virtual Switch will be assigned the Server VLAN. Each virtual machine will map to a specific VLAN, ensuring that VMs are isolated according to their function and access needs. The pfSense management interface will be moved to a dedicated physical LAN port, isolated from all other LANs and VLANs by firewall rules. Additionally, the Pi-hole DNS servers and Domain Controllers, which previously sat on a flat LAN, will require some reconfiguration. DNS Forwarders on the DC's will require re-pointing to the new PiHole IP Addresses. In addition, the DC's Sites and Services will require updating. Setup and Initial Config With the initial setup complete, I've allocated the following: Port 1 is connected to the ISP's router Port 2 to the NETGEAR 16-Port PoE GS316EP Managed Switch. Port 3 is reserved for the Management interface. Interfaces and VLANs Overview The physical interfaces are renamed to their correct designation of WAN, LAN and MGMT. Create the following VLANs and their tags under Interfaces > VLANs: Tag 1, default tag for management and assigned to the LAN interface Tag 10 is for DNS\PiHoles Tag 20 is reserved for Domain Controllers Tag 30 is for Member Servers Tag 40 is for Domain Clients Tag 50 is for Domain Devices such as Printers Tag 60 is reserved for SIEM and Monitoring Tag 100 is for any IOT Assigned the newly created VLANs to the LAN interface, which is igc2. KEA DHCP ISC DHCP is deprecated, despite it being the default option, so swap it out for Kea: Go to System > Advanced > Networking.  Under "DHCP Options," select "Kea DHCP" as the "Server Backend DHCP Settings DHCP is to be enabled for each Interface. Go to Services > DHCP Server Under each Interface, "Enable DHCP on LAN Interface" The LAN interface will remain enabled to support devices that don't natively support VLAN tagging via their web management pages. The risk of losing access to systems like the solar inverter will cause an unwelcome distraction. Note: There is no DHCP Scope for the Domain Controllers on VLAN 20. LAN  DHCP Scope IP Range 192.168.0.100 to 192.168.0.200 DNS points to the Internet 1.1.1.1, 4.4.4.4, 8.8.8.8 MGMT DHCP Scope IP Range 192.168.99.100 to 192.168.99.200 DNS points to the PiHole Servers - 192.168.10.70 and 192.168.10.71 DNS DHCP Scope (PiHole) IP Range 192.168.10.100 to 192.168.10.200 DNS points to its own PiHole Servers - 192.168.10.70 and 192.168.10.71 Member Servers  DHCP Scope IP Range 192.168.30.100 to 192.168.30.200 DNS points to the Domain Controllers - 192.168.20.245, 192.168.20.247, 192.168.20.249 Domain Clients DHCP Scope IP Range 192.168.40.100 to 192.168.40.200 DNS points to the Domain Controllers - 192.168.20.245, 192.168.20.247, 192.168.20.249 Firewall Intro pfSense firewall rules manage separate rules for each interface (LAN, WAN and VLAN) and are processed top-down, meaning the first rule that matches a packet is the one that gets applied. If no rule matches, pfSense blocks the traffic by default. Now for the fun part: initially, every interface, except for the WAN, was configured with permissive any-to-any firewall rules. This meant all devices could communicate freely across all networks. Once system stability was confirmed and I verified that I hadn't broken the system during the transition to VLAN tagging, the rules were gradually tightened to enforce proper network segmentation. The end result is detailed below. In keeping with Zero Trust principles, permissive subnet rules were removed, effectively eliminating lateral movement, particularly between individual client systems. Alias's pfSense firewall aliases let you group IPs, networks, ports, or protocols under a single name. Instead of writing multiple rules for each item, you create one alias and reference it across your firewall rules, making rule management simpler, cleaner, and easier to update. For example, create an alias like Mgmt_Consoles with the IPs of all management addresses, then use that alias in your rules instead of listing each IP individually. I've the following Aliases: Alias_ClientDevices, for printers Alias_Clients Alais_DomainControllers Alias_MemberServers Alias_PiHoles Each has been populated either in the case of the DCs by statically assigned IP's, or by reserving the IP address in DHCP, then updating the corresponding alias. WAN The default behaviour for the WAN Interface is to block RFC 1918 and Bogon network ranges. RFC 1918 is a standard published by the Internet Engineering Task Force (IETF) that defines a set of private IP address ranges. These aren't routable on the public internet These private IP ranges are: 10.0.0.0 to 10.255.255.255 (10.0.0.0/8) 172.16.0.0 to 172.31.255.255 (172.16.0.0/12) 192.168.0.0 to 192.168.255.255 (192.168.0.0/16) A bogon network refers to a block of IP addresses that should not be seen on the public internet. These are addresses that are either unallocated by IANA or reserved for special use, like private networks or multicast. Examples of Bogon IP Ranges: 0.0.0.0/8 – “This” network 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 – RFC 1918 private addresses 127.0.0.0/8 – Loopback 169.254.0.0/16 – Link-local APIPA LAN The LAN contains the least trusted devices, such as mobile phones, smart TVs, the RoboRock vacuum, and the solar inverter. As a result, none of these devices is permitted to communicate with any other interface, including the Zyxel Wi-Fi router's management interface at 192.168.0.253. The two allow rules permit communication within the device's own LAN subnet and outbound access to the internet on ports 80 (HTTP) and 443 (HTTPS). The alias, Mgmt_Consoles is used to block access to each interface’s default gateway on ports 80 and 443. This overrides pfSense’s default behavior, which permits access to the web management interface from all interfaces. MGMT The MGMT interface, by design, is allowed to communicate with all other interfaces. I've blocked most management access with the exception of direct connection or via a Member Server. VLAN10_DNS As with the other interfaces, access to pfSense's Web Management, Servers, MGMT, and Clients VLANs, is explicitly blocked Aliases for PiHoles are implemented, allowing only named IP's, the 2 devices, from accessing each other from within the subnet. Outbound DNS traffic (port 53) is permitted to allow name resolution via the Internet. Ports 80 and 443 are allowed to enable the Pi-hole instances to retrieve updates and patches. General Approach to Domain Services The VLANs for DCs, Servers and Clients allow unrestricted traffic between each VLAN. Ideally, firewall rules should be tightened to permit only the necessary services and ports. However, since the plan is to implement IPSec, the effort required to apply stricter rules at this stage aren't justified. IPsec will provide the necessary security controls and require only a couple of ports to be open, and not the plethora of rules required between DCs and Domain members etc. VLAN20_DCs The Domain Controllers provide authentication services and therefore require unrestricted communication with client and server aliases, as well as with each other. DNS traffic (TCP/UDP port 53) is allowed between the Domain Controllers and the Pi-hole instances, while port 123 is open to the Internet to support time synchronization services. VLAN30_Servers Servers are permitted to communicate with each other, as well as with DCs and Client devices, SCCM makes this a nessessity. The ClientDevice rule also enables support for network printing. Additionally, all servers are allowed outbound access to the Internet on ports 80 and 443 to facilitate Windows Updates. Note: DC's, Hyper-V hosts, SCCM, SCOM and Certificate services and shouldn't share the same VLANs. VLAN40_Clients The clients are exposed to the Internet and susceptible to various attacks during routine browsing and application use. A key principle of Zero Trust is to prevent lateral movement that could be used to discover and escalate privileges. The following measures are in place to help mitigate this risk: Client VLAN Isolation: The client VLAN is configured to block client-to-client communication; no firewall rules permit traffic between hosts within the same subnet. URA Logon Restrictions: As outlined in the referenced link below, Server and Domain Admin accounts are explicitly denied logon rights to client machines via User Rights Assignments. https://www.tenaka.net/post/deny-domain-admins-logon-to-workstations Clients are only permitted unrestricted communication with the DC and the Servers VLANs. External outbound traffic is restricted to web access on ports 80 (HTTP) and 443 (HTTPS). Admin Access The default configuration is for the LAN interface to apply anti-lockout rules to pfSense's management interface. The rules have been removed in favour of the MGMT interface, so proceed with caution: Navigate to System > Advanced > Admin Access Locate the 'Anti-lockout' check box and remove. Netgear Managed Switch Of all the devices involved in the VLAN migration, the NETGEAR 16-Port PoE Switch (GS316EP) was the only one that caused real issues. Due to a fatal error on my part, the switch had to be factory reset. Losing the configuration wasn’t a major problem, but diagnosing the loss of access to the switch that led to the reset was frustrating. The issue stemmed from allowing the switch to obtain its IP address via DHCP. Once the trunk uplink, connecting both pfSense and the switch, was assigned, the switch lost its ability to pick up a DHCP IP address, resulting in a loss of management access. The most likely cause is that VLAN 1 traffic may be dropped as it's explicitly tagged and the switch or router will be expecting untagged traffic. Assign a static IP address to the switch. Enable 'Basic 802.1Q VLAN'. Create the desired VLANs Assign Truck (uplink) to the following connections: Port 1 is the connection to pfSense Port 2 is the connection to the Wifi Access Point Ports 3 and 4 are the connections to the Hyper-V Hosts Assign VLAN Tags to the relevant device: Ports 5 and 6 are for the PiHoles on VLAN 10 Ports 7 through 12 are for Clients on VLAN 40 WIFI Access Point To assign a VLAN to a Wi-Fi network, you need to configure the VLAN ID directly in the settings of the wireless access point (AP) or wireless controller. These are part of the settings when configuring the SSID and WIFI password. Manually Set for Windows Client and Server (Non-Hyperv) To manually tag a VLAN on a Windows machine: Open Control Panel > Network and Sharing Centre > Change Adapter Settings Right-click > Properties > go to the Advanced tab. Look for a setting like VLAN ID, Priority & VLAN, or Packet Priority and VLAN. Set the VLAN ID you want and click OK. Once configured, all traffic from that adapter will be tagged with the specified VLAN ID. Note: Not all NIC drivers support VLAN tagging through Windows natively. Intel, Broadcom, and some Realtek adapters typically do, but it often requires their vendor-specific drivers (not just the Microsoft default). If the VLAN option is missing, you may need to install the manufacturer’s advanced network driver suite. Hyper-V Servers The Intel (now ASUS) NUCs are equipped with only a single network interface, which limits the ability to physically separate VLANs across multiple NICs. Meaning Hyper-V management traffic and VM traffic that defaults to the virtual switch go through VLAN 30 To mitigate this, and I certainly don't want Kali on the same interface as my Member Servers is to set the VLANs within the network adapter settings of the individual VM, thus keeping with the Zero Trust approach intact. Additionally, again deviating from strict Zero Trust principles, the physical hosts serve multiple roles, including File and Print services, as well as DFSR replication. Raspberry PI and PiHole VLAN Before moving the PiHoles VLAN, it's important to complete the following steps. VLANs aren't supported out of the box. Install the latest updates and then the vlan package. sudo apt update sudo apt install vlan Load the 8021q kernel module, which is essential for enabling VLAN tagging on network interfaces. sudo modprobe 8021q echo "8021q" | sudo tee -a /etc/modules Define how VLANs are created and configured. sudo nano /etc/systemd/network/25-vlan.network [Match] Name=eth0.VLAN_ID [Network] DHCP=yes This file instructs systemd-networkd how to create and manage the VLAN interface sudo nano /etc/systemd/network/25-vlan.netdev [NetDev] Name=eth0.VLAN_ID Kind=vlan [VLAN] Id=VLAN_ID Update the VLAN tagging on the network switch that the Pi's are plugged into. Restart the network interface. sudo systemctl restart networking sudo systemctl status networking Confirm the IP has updated from 192.168.0.70 to 192.168.10.70. ip addr show Conclussion Firstly, thanks for following along. There’s a lot of moving pieces and implementing VLAN tagging can present a few challenges. However, this is the first critical step toward achieving a more complete Zero Trust architecture. Related Posts: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x Part 4 - IPSec for the Windows Domain Part 5  - AD Delegation and Separation of Duties Part 6  - Yubikey and Domain Smartcard Authentication Setup Part 7  - IPSec between Windows Domain and Linux using Certs

Introduction If you're a regular visitor to this site, you’ve probably noticed I enjoy 'messing' with security, especially when it comes to Windows. I've put a lot of effort into securing my home lab over the years, it would be a pretty tough nut to crack. But the saying goes, "Pride before a fall". Of course, I'm a realist and know full well that nothing is 100% secure and there are vulnerabilities that I'm in denial about, but it helps to hide behind layers of firewalls, WDAC, and delegation. There’s this concept called Zero Trust Architecture; it’s intriguing, and I’ll explain what it means in a moment. But with my Home Lab in mind, I’ve been wondering, what aspects of it can realistically be implemented using consumer-grade equipment? How close can I get to that elusive state of Security Nirvana without breaking the bank or the Home Lab. This series of articles will first explore the theory behind each of the Zero Trust security enhancements, followed by its practical implementation, the fun part. Although the theory is wordy and a bit.... boring, it's important to understand the principles and how they apply to the implementation of the tech. The goal? To create the world’s most secure home lab. This should be entirely doable, after all, who else is unhinged enough to even try? Zero Trust Architecture Zero Trust Architecture (ZTA) is a security framework based on the principle of "never trust, always verify." Unlike traditional security models that rely on network perimeters, Zero Trust focuses on securing individual resources by enforcing strict identity verification, least privilege access, and continuous monitoring. The Problem with Traditional Security Models The Perimeter-Based Security Model In the past, organizations secured their networks using firewalls, VPNs, and other perimeter-based defenses. The assumption was that once inside the network, users and devices could be trusted. However, this approach has several flaws: Insider Threats: Employees or compromised accounts can misuse their privileges. Remote Work & Cloud Adoption: Users no longer work within a controlled corporate network. Advanced Cyber Threats: Attackers can breach a single point in the network and move laterally to access sensitive data. Core Principles of Zero Trust Architecture To successfully implement Zero Trust, organizations follow these key principles: Verify Explicitly: Authenticate and authorise every access request based on multiple data points, such as user identity, device health, location, and behavior. Use multi-factor authentication (MFA) to ensure secure logins. Use Least Privilege Access: Grant users and applications only the minimum access they need to perform their tasks. Implement Just-In-Time (JIT) access and role-based access control (RBAC). Assume Breach: Design the network with the assumption that threats exist both inside and outside. Implement micro-segmentation to contain potential intrusions. Continuously monitor and analyze network traffic for anomalies. Implementing Zero Trust: A Step-by-Step Guide Micro-Segmentation and Network Security Break up the network into smaller, isolated segments to limit lateral movement. Use software-defined perimeters (SDP) to restrict access to applications based on user identity and context. Deploy next-generation firewalls and intrusion detection systems to monitor network activity. Implement IPSec to encrypt and authenticate traffic between devices, enforcing secure communication within and across network segments. Use 802.1X and RADIUS for network-level access control, tying access policies to user identity and device trustworthiness. Enforce policy-based routing and segmentation at both physical and virtual levels. Device and Endpoint Security Implement endpoint detection and response (EDR) solutions to detect and mitigate threats. Enforce device compliance checks, ensuring only secure, managed devices can access resources. Use mobile device management (MDM) solutions to secure BYOD (Bring Your Own Device) environments. Continuously assess device posture, including OS patch levels, security configurations, and threat exposure. Implement Strong Identity and Access Management (IAM) Enforce multi-factor authentication (MFA) for all users. Implement Single Sign-On (SSO) to streamline authentication. Adopt passwordless authentication methods such as biometrics or security keys. Continuously verify user identities using risk-based authentication (RBA), which adjusts security policies based on user behavior. Leverage RADIUS for centralized authentication and accounting, particularly for network access control and device-level authentication. Integrate 802.1X for port-based network access control, ensuring that only authenticated users and compliant devices gain network access. Enforce Least Privilege and Access Controls Use role-based access control (RBAC) to restrict access based on job roles. Implement attribute-based access control (ABAC), which considers additional factors like device security posture and user location. Utilize Just-In-Time (JIT) access to grant temporary permissions when needed. Review access regularly to minimize privilege creep and enforce the principle of least privilege. Continuous Monitoring and Threat Detection Deploy Security Information and Event Management (SIEM) solutions to collect and analyze security logs. Use User and Entity Behavior Analytics (UEBA) to detect anomalies in user behavior. Implement automated threat response to isolate compromised accounts or devices in real-time. Home Lab State of Play This lab isn’t just a casual test environment, it’s been running continuously for over a decade, operating 24/7 as a secure, managed domain for browsing and related services. The family acts as the user base, providing constant, real-world UAT, often quite vocally when something breaks. The domain serves as a representative platform for the technologies I’m learning, testing, and developing. The current state, and state is nearer the mark, is a mostly flat network with an out-of-support Zyxel USG60W with multiple Firewall rules dependent on the device's IP and MAC. I’m running multiple Intel NUCs hosting Hyper-V, one is well overdue for retirement and out of support, which in turn runs a Windows 2019 Domain environment. AppLocker and Group Policy are actively deployed, while WDAC is managed via SCCM. There's extensive delegation and a strict separation of privileges throughout the environment. Laptops protect their data with Bitlocker TPM and Pin. DNS queries are handled by two PiHoles with fairly strict filtering lists. As for monitoring, SCOM was decommissioned some time ago due to NUC resource limitations, so currently, there's no centralized monitoring in place. A serious lack of time and it just works has led to the system being largely neglected. This forms an ideal starting point and mirrors what’s often seen in corporate environments, underfunded infrastructure, overworked admins stretched to the breaking point. The Zero Trust Plan of Attack Building on the core principles of Zero Trust to "never trust, always verify" and keeping budget limitations in mind, I’ll explore each technology and explain how it tackles specific challenges. Each of these will be documented in the upcoming blogs. Micro-Segmentation and Network Security Software-Defined Perimeters. This may be a step too far for the home lab. Networking: Replace the Zyxel with a pfSense Netgate 4200 and implement VLANs. Firewall: Transition from Zyxel policies to pfSense. IPSec: Assume compromise and that the network is hostile. Implement a VPN - Not required. PiHole, DNSSec and DNSTLS. Device and Endpoint Security Device Compliance, implement NAP - No longer possible with Windows Server. Endpoint Detection and Response (EDR). Mobile Device Management (MDM) is currently handled through SCCM. There are no plans to transition to Microsoft Azure, particularly Intune, as it lacks enterprise features and would expand the lab's attack surface. The approach is to maintain secure data processing on-premises while using the cloud for processing and storing less sensitive data. Implement Strong Identity and Access Management (IAM) Single-Sign-On, is currently supported within the Microsoft Domain, but not so for all the Linux devices. Authenticate and verify Devices, implement Radius Server and 802.1x MFA, Yubikey smartcard and pins will be implemented. Risk-Based Authentication. Enforce Least Privilege and Access Controls Attribute-Based Access Control (ABAC) Role-Based Access Control (RBAC) Just-In-Time access requires as a minimum PowerShell commands to enable group membership TTL (Time-to-Live), this could be extended further with a Bastion Forest, MIM, PAM and PIM. Continuous Monitoring and Threat Detection Security Information and Event Management (SIEM), implement an event management solution that supports both Windows and Linux. User and Entity Behavior Analytics (UEBA), implement PFSense's IPA and IDA solutions. Realtime response Threat intelligence feeds (pfBlockerNG) Intrusion detection and prevention systems (Snort/Suricata) The Keys to the Zero Trust Kingdom In a Windows environment, an Enterprise Certificate Authority (CA) is the trust anchor for machine identities, user certificates, network authentication, and service encryption. It’s a critical component in any enterprise PKI and foundational to implementing a Zero Trust security model. But without a Hardware Security Module (HSM), your CA's private keys are exposed to unnecessary risk. I don't have an HSM, they're quite expensive. This needs to be called out for the enterprise implementation of Zero Trust. Where to Start..... The CA holds the keys, but the network forms the foundation of Zero Trust, making it the logical place to start. Replacing the outdated Zyxel hardware is the first step, followed by implementing proper network segmentation and firewall policies. The only question... what have I started? Related Posts: Part 1  - Zero Trust Introduction Part 2  - VLAN Tagging and Firewalls with pfSense Part 3 - pfSense and 802.1x Part 4 - IPSec for the Windows Domain Part 5  - AD Delegation and Separation of Duties Part 6  - Yubikey and Domain Smartcard Authentication Setup Part 7  - IPSec between Windows Domain and Linux using Certs

While building automation for domain deployment , OU structure, and delegation , I experienced one of those, too hard to do now, which nearly slipped past me, scripting the creation of a WMI filter for the PDC Emulator role. Time Source The goal is to make sure the PDC, and only the PDC, manages authoritative time. This particular GPO includes a root NTP server setting, whether that’s an IP address, a local atomic clock, or an external internet time source, and it’s vital that only the PDC syncs with it. Every other domain controller should, in turn, sync from the PDC, maintaining a proper hierarchy and preventing clock chaos. Not Keen on WMI Filters I’ll be honest, I don’t generally like WMI filters in GPO. They introduce performance hits and slow down policy processing, especially in larger environments. But in this case, it’s a pragmatic exception. The filter ensures that only the PDC receives and applies the external time configuration, keeping time consistent across the domain and preventing catastrophic drift when an upstream time source fails spectacularly. Prevent death and destruction I’ve experienced this first-hand, the time source collapsed in a heap, and the PDC leapt forward a full 24 hours in an instant. The aftermath was... memorable. It's hard to believe the chaos inflicted when time goes awry. MaxPhaseCorrention - Thank MS's Default value To guard against that kind of chaos, the GPO settings MaxPosPhaseCorrection and MaxNegPhaseCorrection limit how far the system clock is allowed to jump forward or backward during synchronization. The issue is that Microsoft's default value is 86400 seconds or 24 hours, these overly generous settings have the potential to lead to carnage. The recommendation is to set both POS and NEG settings to 3600 or 1 hour. These settings and the WMI filter ensure the domain’s time stays sane, stable, and immune to upstream meltdowns. GPO Settings - Prevent the Meltdown These are the current settings provided from GitHub , with the annex at the end of the blog providing the technical details. Computer Configuration/Policies/Administrative Templates/System/Windows Time Service: Global Configuration Settings MaxNegPhaseCorrection = 3600 MaxPosPhaseCorrection = 3600 Computer Configuration/Policies/Administrative Templates/System/Windows Time Service/Time Providers: Configure Windows NTP Client = Enabled NTPServer = 192.168.30.1,0x8 Type = NTP CrossSiteSyncFlags = 2 ResolverPeerBackoffMinutes = 15 ResolverPeerBackoffMaxTimes = 7 SpeicalPollInterval = 1024 EventLogFlags = 0 Enable Windows NTP Client = Enabled Enable Windows NTP Server = Enabled Script Prep Download both the script and the zip file from GitHub . Copy the files to the PDC into the 'C:\ADBackups\PDCNTP\' directory. Don’t use another domain controller. Running GPO scripts from a secondary DC introduces extra latency when connecting back to the PDC, which can cause failures. Extract the zip file, ensuring the GUID directory is nested within the 'PDCNTP' directory. C:\ADBackups\PDCNTP\{A5214940-95CC-4E93-837D-5D64CA58935C}\ If you prefer to use your own GPO export, that’s fine, as long as the path is correct, the script will automatically resolve the appropriate GUID and BackupID. Execution of the Script With Domain Admin privileges, open an elevated PowerShell window and execute the following commands CD to C:\ADBackups\PDCNTP\ ; .\Create_WMI_NTP_PDC.ps1 Open Group Policy Management. Confirm that the GPO has been created and linked to the Domain Controller OU Update the IP Address for the NTP Server, it's unlikely we share the same time server IP. The only remaining task for me is to integrate the NTP GPO into the fully automated Domain deployment script . Enjoy and thanks for your time. ANNEX - Breakdown of GPO Settings Computer Configuration > Policies > Administrative Templates > System > Windows Time Service > Global Configuration Settings MaxNegPhaseCorrection Current value: 3600 (1 hour) Purpose: Defines the maximum number of seconds the clock can be moved backward when synchronizing time. If the correction exceeds this, Windows logs an event instead of applying the adjustment. Relevance: Prevents the PDC from winding time back too far due to an erratic NTP source, which can break Kerberos authentication and replication. Alternative values: 0 — disables large backward corrections entirely. 300 — 5 minutes (useful for high-availability or sensitive environments). 86400 — 24 hours (default Microsoft value, overly generous for a PDC). 4294967295 (0xFFFFFFFF) — disables the limit completely (not recommended). MaxPosPhaseCorrection Current value: 3600 (1 hour) Purpose: Defines the maximum number of seconds the clock can be moved forward. Relevance: Protects against catastrophic jumps when an upstream NTP server malfunctions. This provides a 1-hour safety window in either direction, preventing massive jumps while still allowing normal synchronization drift to be corrected automatically. Alternative values: 300 — a conservative 5-minute correction limit. 900 — 15 minutes (a good balance for stable networks). 86400 — 24 hours (default). 4294967295 — disables the limit (unsafe on domain controllers). Computer Configuration > Policies > Administrative Templates > System > Windows Time Service > Time Providers Configure Windows NTP Client = Enabled Enables policy control of NTP client behaviour to enforce the following parameters. NTPServer = 192.168.30.1,0x8 Purpose: Defines the external NTP source the PDC syncs with. The ,0x8 flag tells Windows to use client mode. Alternative formats and examples: pool.ntp.org ,0x8 — public NTP pool. time.google.com ,0x8 — Google’s NTP service. ntp.nist.gov ,0x8 — US NIST time source. gps-clock.local,0x8 — local GPS or atomic reference. Relevance: This should be a reliable and stratum-1 or stratum-2 source. The PDC is the only domain controller that should query an external NTP server. Type = NTP Purpose: Forces synchronization using the NTP protocol with the specified NTPServer. Other valid values: NT5DS — Default for domain-joined machines (syncs from domain hierarchy). AllSync — Uses all available sync mechanisms (rarely needed). NoSync — Disables synchronization entirely. Relevance: For the PDC, NTP ensures it pulls time from the defined external source, not from another DC. CrossSiteSyncFlags = 2 Purpose: Controls cross-site time synchronization. Value meanings: 0 — Allow synchronization across all sites. 1 — Only sync from DCs in the same site. 2 — Never sync from DCs in other sites (recommended for PDC). Relevance: Keeps the PDC isolated as the domain’s root time authority, avoiding cross-site time loops. ResolverPeerBackoffMinutes = 15 Purpose: Specifies how long the service waits before retrying after a failed NTP sync. Alternatives: 5 — More aggressive retry. 30 — More relaxed retry, suitable for unreliable WANs. ResolverPeerBackoffMaxTimes = 7 Purpose: Defines the maximum number of exponential backoff attempts before giving up. Alternatives: 3 — Faster failover (good for testing). 10 — More patient retry window. SpecialPollInterval = 1024 Purpose: Sets how often (in seconds) the PDC polls the NTP source — roughly every 17 minutes. Alternatives: 3600 — Once per hour (lighter network load). 900 — Every 15 minutes (more aggressive for accuracy). 86400 — Once per day (not advised for volatile networks). Relevance: Frequent polling maintains accurate time and compensates for drift. EventLogFlags = 0 Purpose: Controls event logging verbosity. Values: 0 — Only critical errors. 1 — Informational and error events. 2 — All events, including debugging. Relevance: On a PDC, 0 keeps logs clean while still alerting to serious time issues. Enable Windows NTP Client = Enabled Purpose: Ensures the time service actively synchronizes with the defined NTP source. Relevance: Essential for keeping the PDC accurate and stable. Enable Windows NTP Server = Enabled Purpose: Turns the PDC into an NTP server for the domain. Relevance: Other DCs and domain members sync from the PDC rather than directly from the external NTP source, maintaining a clean and authoritative time hierarchy.

Windows ADK PE for Windows 11 22H2 fails to install completely generating the following errors. Error 1 Clicking on the Windows PE tab crashes MMC generating the following error: Could not find a part of the path 'C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\WinPE_OCs'. Google suggests the ADK PE isn't installed..... Error 2 It's not possible to update the boot images. Unable to open the specified WIM file. ---> System.Exception: Unable to open the specified WIM file. ---> System.ComponentModel.Win32Exception: The system cannot find the path specified. Something is definitely wrong and missing Both errors suggest missing files, with error 1 providing a path: C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\ Comparing the latest ADK PE for Windows 11 22H2 to an older installation something is very wrong. The x86 and Arm directories are missing..... ADK PE for Windows 11 22H2 ADK PE for Windows 10 1809 Is this a one-off... The initial problem presented itself whilst upgrading MDT and ADK installed on a 2012 R2 Server. A new instance of 2022 Server and Windows 11 were equally affected. Each instance of ADK PE was from a fresh download. Microsoft, I've got the contact details of some really good Test Managers. The Fix Not wishing to faff and spend too much time comparing downloads against different versions, it was taking me away from my planned day of Hack the Box. There's the recommended fix, downloading an earlier version on ADK PE, 1809 for Windows 10 should do the trick. Windows 11 is purely cosmetic under the hood it identifies as Windows 10. Alternatively, copy the missing contents from a working installation, not recommended and it's a bit quick and dirty. It's functional with some minor scripting errors with the MDT deployment wizard.

Introduction to Active Directory Disaster Recovery Back in the day, I was lucky enough to work with a Microsoft Premier Field Engineer. That was quite some time ago, and AD has evolved considerably since then. Using the original field engineer’s guide as a foundation, I’ve rewritten and updated the material for Windows Server 2016 and newer. The topics covered in this updated AD Disaster Recovery guide include: Backing up and restoring Active Directory Scheduling a script to export object reference data to assist during restores Identifying and verifying FSMO role holders, moving or seizing roles Enabling and restoring objects with the Recycle Bin. Performing non-authoritative and authoritative restores Rebuilding a failed domain controller from backup Restoring GPOs, DFSR and SYSVOL Metadata cleanup and lingering object removal Validating replication health after recovery Best Practices for Active Directory Backups The Obvious – Backups The obvious, but not to all, enable BACKUPS using Windows Backup or another backup product. Enable the AD Recycle Bin to reduce the necessity of an Authoritative Restore. Use Dedicated Backup Storage Store backups on a dedicated local or network volume, not on the same disk as the operating system. If using a share, restrict access to a dedicated service account with write-only permissions. Don’t allow share or NTFS permissions to Users or Authenticated Users Especially Full Control, you know who you are…. Muppet and you’re the apparent expert Always Include the System State Active Directory is stored within the NTDS.dit database, SYSVOL, the registry, COM+ class registration database, and critical boot files, all of which are part of the System State. Never rely on volume-level or file-based backups alone; they won’t capture the AD database metadata or replication data needed for restore. Backup SYSVOL as a file level backup. Export and Backup GPO’s to the file system. Export DNS and backup. Back Up All FSMO Role Holders Ensure every DC is protected, but at a minimum, always back up: Schema Master Domain Naming Master RID Master PDC Emulator Infrastructure Master Losing an un-backed FSMO holder complicates recovery, role seizure should be the last resort Retain Multiple Recovery Points Keep at least 7 days of rolling backups on local or nearline storage. Weekly or monthly copies offsite or offline (for ransomware isolation). Validate Backups Regularly A backup that can’t restore isn’t a backup. Perform test restores to non-production. Windows and Script Backup Configuration System State backup schedule configuration Add a drive dedicated to backups of 100Gb or greater Install the Windows Backup feature Open Windows Backup Create a daily backup schedule Select custom backup Backup the System State, C:\ADBackups, C:\Windows\NTDS, C:\Windows\SYSVOL Backup to the dedicated drive Service account setup Create a service account named svc_ADBackup Add the service account to both ‘DNSAdmins’ and ‘Group Policy Creator Owners’ Groups. The service requires both User Rights Assignments ‘Logon as Batch’ and Logon as a Service’ Either add directly to URA via GPO Management or preferably, create URA groups and assign to ‘Logon as Batch’ and ‘Logon as a Service’, then add the service account to the groups. The service account will require Full NTFS permission on 'C:\ADBackup\' and 'C:\Windows\System32\dns\' to create and delete files and directories. Don’t allow the service account permissions to amend the backup script. Do Not execute scripts with a service account that is a Domain Admin on a Domain Controller. Scheduled task creation for backup script This PowerShell script automates the creation of a reference snapshot to support Active Directory recovery by backing up DNS zones, Group Policy Objects (GPOs), and AD objects. It runs on Domain Controllers and organizes the backups by day of the week, maintaining a straightforward seven-day rotation. The script exports: DNS configuration details (forwarders, recursion, scavenging, zones, and server settings), backs up all DNS zone files GPO data with linked permissions and references. AD computers, users, groups, OUs, and GPO links Schedule setup: Create a Scheduled task Add the svc_ADbackup and password to ‘Run whether users is logged on or not’ Add a daily trigger Add action: powershell.exe -executionpolicy bypass -file "C:\ADBackups\ADBackup.v.0.1.ps1" Protect the DSRM Password The Directory Services Restore Mode (DSRM) password is required for any restore. Reset if unknown: Open CMD as Domain Admin Type ‘ntdsutil’ Type ‘set dsrm password’, press Enter Type ‘reset password on server %serverName%’, press Enter Type the new password * 2, press Enter Type q,q to quit ntdsutil Store the password securely (e.g., sealed envelope or password vault). Without it, you can’t boot into DSRM to perform an authoritative or non-authoritative restore. Reset every 180 days Active Directory Recycle Bin Overview The Active Directory Recycle Bin is a feature that provides the ability to restore deleted Active Directory objects without needing to perform an authoritative restore from backup media. Introduced in Windows Server 2008 R2, this feature significantly simplifies the recovery process for accidentally deleted AD objects and preserves all attributes during restoration. How to Enable the Active Directory Recycle Bin Prerequisites Before enabling the AD Recycle Bin, ensure the following requirements are met: Forest Functional Level: The forest must be at Windows Server 2008 R2 or higher functional level Schema Version: The AD schema must be updated to support the feature Permissions: You must be a member of the Enterprise Admins group Important Warning: Once enabled, the AD Recycle Bin cannot be disabled Enabling via PowerShell The recommended method for enabling the AD Recycle Bin is through PowerShell: Enable-ADOptionalFeature –Identity 'Recycle Bin Feature' –Scope ForestOrConfigurationSet –Target 'yourdomain.com' After running this command, you'll receive a warning about the irreversible nature of this operation. Type 'Y' to confirm. Enabling via Active Directory Administrative Center: Open Active Directory Administrative Center (ADAC) Navigate to your domain in the left pane Click on "Enable Recycle Bin" in the Tasks pane on the right Confirm the warning dialog Refresh ADAC to see the "Deleted Objects" container The feature typically takes approximately 15 minutes to replicate across all domain controllers in the forest. Recoverable Objects: The AD Recycle Bin can recover virtually all types of Active Directory objects, including: User accounts: All user attributes, group memberships, and properties are preserved Computer accounts: Including domain-joined computer objects Security and distribution groups: With all group memberships intact Organizational Units (OUs): Including all objects within the OU structure Contacts: Mail-enabled and standard contacts Group Policy Objects (GPOs): Though GPO links may need to be manually restored Other AD objects: Such as printers, shared folders, and custom schema objects When an object is deleted, it moves to the Deleted Objects container and enters a "deleted" state where it remains for the duration of the deleted object lifetime (180 days by default). During this period, most attributes are preserved, making full restoration possible. Limitations and Considerations Time-Based Limitations Deleted Object Lifetime: By default, deleted objects are retained for 180 days. After this period, objects enter a "recycled" state where most attributes are removed, leaving only a minimal subset. Once in the recycled state, full restoration is no longer possible. Recycled Object Lifetime: After the recycled object lifetime expires (an additional 180 days by default), objects are permanently removed through garbage collection and cannot be recovered. Functional Limitations Cannot Be Disabled: Once enabled, the AD Recycle Bin feature cannot be turned off. This is a permanent forest-level change. No Rollback: There is no way to revert to the previous tombstone based deletion model after enabling the feature. Storage Overhead: Deleted objects consume space in the Active Directory database until they are permanently removed through garbage collection. Organizations with frequent deletions may see increased database size. Replication Considerations: Deleted objects must replicate across all domain controllers, which can impact replication traffic in environments with many deletions. Recovery Limitations Container Objects: When recovering an OU or container, you must first restore the container itself before restoring child objects. The hierarchy must be rebuilt from the top down. Linked Attributes: While most attributes are preserved, some complex linked attributes or dependencies may require manual verification after restoration. No GUI for Recycled Objects: Objects in the recycled state (after the deleted object lifetime expires) cannot be viewed or restored through the Active Directory Administrative Center interface; PowerShell must be used. GPO Links: While GPOs themselves can be restored, GPO links to OUs are not automatically restored and must be manually re-established. Active Directory Recovery Methods Non-Authoritative Restore (Standard Recovery) Use non-authoritative restore when the domain controller hardware failed but the domain is otherwise healthy, this assumes that the DC is non-bootable. Deploying a fresh Domain Controller is almost always preferable to performing a non-authoritative restore. A clean build ensures you’re running from a known-good, current installation without inheriting potential corruption or stale metadata from backups. It allows you to install the latest patches, security baselines, and configuration hardening from the outset. Once joined to the domain, the new DC will automatically replicate the directory data from healthy peers, cleanly re-establishing consistency across the forest. FSMO roles can then be gracefully transferred or seized as needed, without the risk of reintroducing outdated or conflicting data. Prerequisites: Access to system state backup created before the failure At least one other healthy domain controller in the domain External backup media available and accessible Procedure: Install Server OS Install a new server of the same OS version and patch to the latest or at least to the same version as the now dead DC Install Windows Backup Feature Set network settings and IP Type msconfig and select Boot > Safe Boot > AD Repair or Boot into DRMS with Shift and F8 Reboot and logon as the local admin Mount volume or copy backup to local server Launch Windows Backup Click Recover… Select This Server Select Date of the restore point Select Recovery Type = System State Restore to the original location There is a check box to Authoritatively restore of AD – Don’t check Reboot the server after the restore completes and ensure newer objects are replicated from another DC. Restart domain controller in normal mode Restart-Computer -Force Post-Recovery Steps: Log back in as domain administrator after restart Run these commands on the recovered domain controller Replication with domain controllers repadmin /syncall /d /P Verify replication completes repadmin /replsummary repadmin /showrepl Check for replication errors Get-ADReplicationFailure -target DC01 | Format-Table Run diagnostic tests dcdiag /f:c:\dcdiag.log Verify DNS registration ipconfig /registerdns nslookup DCNAME Monitor Event Viewer for errors Directory Service logs Replication events DNS server logs Authoritative Restore (Selective Object Recovery) When to use an Authoritative Restore and when to use the Recycle Bin. The Active Directory Recycle Bin is excellent for recovering deleted objects, but it doesn’t help when existing objects or entire directory partitions are corrupted, overwritten, or lost due to replication issues or human error. That’s where an authoritative restore still matters. The Recycle Bin can only restore objects that were intentionally deleted and still exist in the deleted objects container. It can’t roll back changes, like group membership modifications, GPO edits, or accidental bulk updates, because those aren’t deletions; they’re legitimate writes replicated across all domain controllers. If an admin accidentally removes every user from a security group or a script wipes out configuration attributes, those changes replicate instantly, and the Recycle Bin won’t help. An authoritative restore allows you to recover data from a known-good backup and mark that version of the directory as the master copy during replication. This forces other domain controllers to accept the restored version as authoritative, overwriting the bad data across the forest. In short: Recycle Bin = undelete objects. Authoritative Restore = roll back to a previous state after corruption or unwanted changes. Both have their place, but they solve entirely different problems. Authoritative Restore Procedure Use authoritative restore to recover deleted Active Directory objects that should not be overwritten by replication from other domain controllers. The restored objects are marked as authoritative and will replicate outbound to other DCs. Prerequisites You must have a System State backup of the domain controller taken when the data was good. You must know which partition (naming context) you’re restoring: Domain partition: DC=yourdomain,DC=com Configuration partition: CN=Configuration,DC=yourdomain,DC=com Application partition: e.g. DC=ForestDnsZones,DC=yourdomain,DC=com Ensure other domain controllers are healthy, you’ll be restoring to one DC and then replicating out. Restore AD Partition Procedure Boot into Directory Services Restore Mode (DSRM) Type msconfig and select Boot > Safe Boot > AD Repair or Boot into DRMS with Shift and F8 Reboot Log in using the DSRM administrator password (set during DC promotion). Mount volume or copy backup to local server Launch Windows Backup Click Recover… Select This Server Select Date of the restore point Select Recovery Type = System State Restore to the original location There is a check box to Authoritatively restore of AD – Don’t check Don’t Reboot the server This step restores the AD database (NTDS.dit) from backup, but at this stage, it’s considered non-authoritative, other domain controllers would overwrite it during replication if you booted normally. Mark the Partition as Authoritative Open Command Prompt (still in DSRM). ntdsutil Type ‘activate instance ntds’ Type ‘authoritative restore’ Then specify the partition you want to make authoritative, for example: restore database or, to target a specific partition: restore subtree "DC=yourdomain,DC=com" restore subtree "CN=Configuration,DC=yourdomain,DC=com" When prompted, confirm. This process updates the Update Sequence Numbers (USNs) on all objects in that partition so that when replication resumes, other DCs treat this version as newer and replicate it outward. Type quit twice to exit ntdsutil. Reboot Normally Restart the domain controller normally. Once it starts, it will advertise as healthy and begin replicating the restored (authoritative) data to the rest of the forest. Validate Replication Run the following to verify replication and event logs: repadmin /showrepl repadmin /syncall /AdeP Check the Directory Service event log for replication success (Event ID 1109 and similar). Examples of Authoritative Restores Authoritative Restore of a Single OU Scenario: An administrator accidentally deletes the Sales OU, including all user and computer accounts, and the deletion has replicated to all DCs. Goal: Restore only the Sales OU and its objects from a System State backup. Steps: Boot the affected DC into Directory Services Restore Mode (DSRM). Restore the System State using Windows Server Backup: Do not reboot when prompted after the restore completes. Open a Command Prompt and run: ntdsutil activate instance ntds authoritative restore restore subtree "OU=Sales,DC=Domain,DC=com" quit, quit Restart the domain controller normally. Authoritative Restore of an Entire Domain Partition Scenario: A script corrupts large parts of the domain (e.g. user attributes overwritten or objects missing) across all domain controllers. Goal: Restore the entire domain partition to its last known good state. Steps: Boot into DSRM. Perform a System State restore as above. Before rebooting, run: ntdsutil activate instance ntds authoritative restore restore database quit, quit Reboot the DC normally. Authoritative Restore of a Configuration Partition Scenario: An improperly written schema extension or deleted configuration container (e.g. Exchange or DFS settings) breaks forest-wide functionality. Goal: Restore the Configuration naming context to a working version from backup. Steps: Boot into DSRM. Perform a System State restore as above. Before rebooting, run: ntdsutil activate instance ntds authoritative restore restore subtree "CN=Configuration,DC=Domain,DC=com" quit, quit Authoritative Restore of Sites Scenario: An improperly written schema extension or deleted configuration container (e.g. Exchange or DFS settings) breaks forest-wide functionality. Goal: Restore the Configuration naming context to a working version from backup. Steps: Boot into DSRM. Perform a System State restore as above. Before rebooting, run: ntdsutil activate instance ntds authoritative restore restore subtree "CN=Configuration,DC=Domain,DC=com" quit, quit This includes: Sites (CN=Sites) Subnets (CN=Subnets) Site links and link bridges Site link costs and replication schedules Authoritative Restore of Subnets Scenario: An improperly written schema extension or deleted configuration container (e.g. Exchange or DFS settings) breaks forest-wide functionality. Goal: Restore the Configuration naming context to a working version from backup. Steps: Boot into DSRM. Perform a System State restore as above. Before rebooting, run: ntdsutil activate instance ntds authoritative restore restore subtree "CN=Subnets,CN=Sites,CN=Configuration,DC=Domain,DC=com" quit, quit Authoritative Restore of a Deleted Group Policy Object (GPO) Scenario: A key GPO (e.g. Default Domain Policy) was deleted and the Recycle Bin isn’t enabled. Goal: Restore the deleted GPO from backup. Steps: Boot into DSRM. Perform a System State restore as above. Before rebooting, run: ntdsutil activate instance ntds authoritative restore restore subtree "CN={6AC1786C-016F-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=Domain,DC=com" quit, quit Restart the DC. Compare SYSVOL contents and re-link GPOs if needed. Partial Object Restore (Single User or Group) Scenario: A critical service account or group was deleted and is not recoverable via the Recycle Bin. Goal: Restore only that object without affecting the rest of the directory. Steps: Boot into DSRM. Perform a System State restore as above. Before rebooting, run: ntdsutil activate instance ntds authoritative restore restore object "CN=svc_SQL,OU=Service Accounts,DC=Domain,DC=com" quit, quit Authoritative Restore After a Forest-Wide Rollback Scenario: A misconfiguration or replication storm corrupts all domain partitions, and restoring a single DC is not sufficient. Goal: Perform a forest-level authoritative restore (usually from the forest root DC). Steps: Boot into DSRM. Perform a System State restore as above. Before rebooting, run: ntdsutil activate instance ntds (restore all naming contexts:) authoritative restore restore database quit, quit Reboot, allow replication to push authoritative copies to all other DCs FSMO Architecture Overview What are FSMO Roles FSMO (Flexible Single Master Operations) roles exist because certain Active Directory operations cannot be performed simultaneously across multiple domain controllers without creating logical inconsistencies, data corruption, or irreconcilable conflicts. These operations require a single authoritative source, a master role holder. There are five FSMO, roles two forest-wide and three domain-wide, that ensure consistency in schema, domain naming, object creation, and directory replication. Schema Master Scope: Forest-wideDefault location: First DC in the forest root domain Purpose: Controls all changes to the Active Directory schema, the master definition of all object classes and attributes. When products such as Exchange, SCCM, or Azure AD Connect extend the schema, the changes are applied only via the Schema Master. If unavailable: No schema updates or extensions can occur. Existing directory operations continue normally. Improper seizure consequences: If the Schema Master role is seized and the original DC is later brought online, schema version conflicts can occur. Both DCs may believe they are authoritative for schema updates. Replication may fail with “schema mismatch” errors. Corrupted or divergent schema versions can render the forest unrecoverable without a rebuild. Criticality: Low (short term), High (during schema updates) Domain Naming Master Scope: Forest-wideDefault location: First DC in the forest root domain Purpose: Controls the creation and deletion of domains and application directory partitions in the forest. It ensures that all domain names are unique and updates the forest-wide naming context. If unavailable: Cannot create or remove domains or application partitions. Daily operations and replication are unaffected. Improper seizure consequences: If the role is seized incorrectly or the original DC returns: The forest may contain duplicate domain or application partition records. “Orphaned” domain entries may remain in AD, causing replication or trust inconsistencies. Forest integrity checks (ntdsutil, repadmin /showrepl) may show naming collisions or metadata errors. Criticality: Low (short term), High (during forest restructuring) Relative ID (RID) Master Scope: Domain-wide Purpose: The RID Master allocates RID pools to all domain controllers within its domain. Each new security principal (user, group, or computer) is assigned a unique Security Identifier (SID), which consists of the domain SID plus a Relative ID (RID). The RID Master ensures that each domain controller issues unique RIDs, preventing SID duplication across the domain. If unavailable: DCs can continue creating new objects until their current RID pool runs out. Each domain controller receives a RID pool of 500 identifiers. When approximately half of the pool (250 RIDs) has been consumed, the DC automatically requests a new allocation from the RID Master. Once depleted, no new users, groups, or computers can be created. Improper seizure consequences: If the RID Master role is seized while the original DC is still active or later reintroduced: Multiple DCs may issue overlapping RID pools, resulting in duplicate SIDs. SID duplication breaks access control and causes permanent security inconsistencies. AD replication may fail due to RID conflicts (event ID 16650 or event ID 16658). A forest rebuild may be required to safely recover. Criticality: Medium (short term), High (if RID pool exhausted or duplicated) Primary Domain Controller (PDC) Emulator Scope: Domain-wide Purpose: The PDC Emulator is the operational backbone of the domain. It performs several time-sensitive and synchronization functions: Password authority: Receives immediate replication of password changes; resolves password mismatches during authentication. Time synchronization: Acts as the authoritative time source for the domain; the forest root PDC is the master clock for the forest. Group Policy master: Central point for GPO creation and editing (GPMC connects directly to it). Trust management: Maintains trust passwords and NT4 compatibility for legacy systems. If unavailable: Password changes stop replicating promptly; recently changed passwords may fail to authenticate. Kerberos time skew may cause logon and service ticket failures. GPO edits fail or are inconsistent. External trusts and legacy systems may fail authentication. Improper seizure consequences: If seized incorrectly or the old PDC Emulator is later reintroduced: Two DCs may both act as time authorities, creating time drift and Kerberos failures. Password replication loops or mismatches may occur, leading to logon failures. Group Policy edits may conflict or become corrupted. Trust relationships may intermittently fail. Criticality: Very High, immediate recovery or transfer required Infrastructure Master Scope: Domain-wide Purpose: Maintains cross-domain object references by updating phantom objects, lightweight records that represent objects (users, groups, or computers) from other domains. When a cross-domain object is renamed, moved, or deleted, the Infrastructure Master updates these phantom references to keep directory data consistent. If unavailable: Cross-domain group memberships or references display outdated or incorrect names. Access control continues to function (based on SIDs), but visible names become stale. In a single-domain forest, or where all DCs are Global Catalogs, this role has no functional impact. Improper seizure consequences: If the Infrastructure Master is seized incorrectly or the original DC is brought back online: Phantom object records may become inconsistent between DCs. Cross-domain group memberships can appear corrupted or out of sync. Event logs may show phantom cleanup or reference errors (event ID 1412). Requires metadata cleanup and GC resync to correct. Criticality: Low to Medium Special note on GCs: In a multi-domain forest, the Infrastructure Master should not reside on a Global Catalog unless all DCs are GCs. Otherwise, it will never detect outdated phantom references. Global Catalog (GC) Interaction Although not a FSMO role, the Global Catalog (GC) interacts closely with FSMO operations. It stores a partial replica of every object across the forest, enabling: Universal group membership resolution during logon. Forest-wide searches and object lookups. Phantom object validation for the Infrastructure Master. Best practice: host at least one GC per site for redundancy and authentication performance. FSMO Placement Commands cmd: netdom query fsmo PowerShell: Get-ADForest | Select-Object -Property SchemaRoleOwner, DomainNamingMasterRole Get-ADDomain | Select-Object -Property InfrastructureRoleMaster, RidRoleOwner, PDCEmulator How to Seize the Operations Master Roles FSMO roles are normally transferred gracefully using standard Active Directory management tools such as Active Directory Users and Computers, Domains and Trusts, or the Schema Management snap-in. These tools require the current FSMO holder to be online and reachable. However, in the event of a permanent failure or loss of connectivity to the role holder, the role must be seized by another domain controller. Role seizure is a last-resort operation and should only be performed if the existing FSMO host cannot be recovered within a reasonable time frame. Improper or premature seizure can cause directory inconsistencies and replication issues. Potential Risks of Role Seizure: Data Loss or Inconsistent Directory State When a FSMO role is seized, the new holder begins operating based on its current AD replication state. If replication was incomplete before the original FSMO server failed, the new role holder may be missing recent updates. To reduce this risk, wait for at least one full replication cycle to complete across all domain controllers before seizing the role, ensuring the target DC has the latest data. Duplicate Role Holders Because the original FSMO server is offline during the seizure, it does not receive notification that its role has been reassigned. If that server is later brought back online, such as after repair or restoration from backup, it may still consider itself the valid FSMO holder. Having two domain controllers performing the same FSMO role can lead to severe directory corruption or conflicting updates. To prevent this, once a FSMO role has been seized, the original role holder must never be brought back online. If the hardware is restored, it should be reinstalled and rejoined as a new domain controller rather than reintroduced with its previous Active Directory database. Role seizure is a powerful but dangerous tool, use it only when the failure is permanent and recovery is impossible. Steps: Open an elevated Command Prompt on the target domain controller. Type: ntdsutil Enter FSMO maintenance mode: roles Connect to the target DC: connections connect to server quit (Replace with the hostname of the DC taking over the roles.) (Optional) View current FSMO role assignments: select operation target list roles for connected server quit Seize the required FSMO roles using the appropriate commands: seize schema master seize naming master seize rid master seize pdc seize infrastructure master (Only run the commands for the roles that need to be seized.) Exit NTDSUTIL: quit, quit After Seizing the Roles: Verify new FSMO assignments netdom query fsmo AD Partitions Active Directory is divided into several naming contexts (partitions), each serving a specific replication and storage purpose. Here’s the complete list — including the two used by DNS: Schema Partition Distinguished Name (DN): CN=Schema,CN=Configuration,DC=,DC= Purpose: Defines all object classes and attributes in the forest. Replication Scope: Forest-wide (to all Domain Controllers). Example: CN=Schema,CN=Configuration,DC=,DC= Configuration Partition Distinguished Name (DN): CN=Configuration,DC=,DC= Purpose: Stores forest-wide configuration data (sites, services, replication topology, etc.). Replication Scope: Forest-wide. Example: CN=Configuration,DC=,DC= Domain Partition Distinguished Name (DN): DC=,DC= Purpose: Contains all domain-specific objects — users, groups, computers, OUs, and policies. Replication Scope: Domain-wide (replicates only to DCs in the same domain). Example: DC=,DC= ForestDNSZones Partition Distinguished Name (DN): DC=ForestDNSZones,DC=,DC= Purpose: Stores DNS zone data replicated forest-wide (used for DNS zones integrated at the forest level). Replication Scope: Forest-wide. Example: DC=ForestDNSZones,DC=,DC= DomainDNSZones Partition Distinguished Name (DN): DC=DomainDNSZones,DC=,DC= Purpose: Stores DNS zone data replicated within the domain only (used for domain-scoped DNS zones). Replication Scope: Domain-wide. Example: DC=DomainDNSZones,DC=,DC= List Partitions with Powershell $hh=@() ; $hh += "-" * 80 $root = Get-ADRootDSE Write-Host $hh Write-Host "Active Directory Partitions:" -ForegroundColor Cyan Write-Host $hh # Domain Partition Write-Host "Domain Partition: $($root.defaultNamingContext)" # Configuration Partition Write-Host "Configuration Partition: $($root.configurationNamingContext)" # Schema Partition Write-Host "Schema Partition: $($root.schemaNamingContext)" # Domain DNS Zones Partition Write-Host "DomainDNSZones Partition: DC=DomainDNSZones,$($root.defaultNamingContext)" # Forest DNS Zones Partition Write-Host "ForestDNSZones Partition: DC=ForestDNSZones,$($root.rootDomainNamingContext)" Using ADSI Edit to Connect to AD Partitions Step-by-Step: Run ADSI Edit (adsiedit.msc) on a Domain Controller or from RSAT. In the ADSI Edit console, right-click ADSI Edit and select Connect to… In the Connection Settings window, under “Select a well-known Naming Context”, choose one of the following: Default naming context > The domain partition Configuration > Forest-wide configuration data Schema > AD schema definitions To view DNS partitions (not listed by default), use “Select or type a Distinguished Name or Naming Context” and enter: For DomainDNSZones: DC=DomainDNSZones,DC=domain,DC=com For ForestDNSZones: DC=ForestDNSZones,DC=domain,DC=com Performing an authoritative restore of an Active Directory partition allows you to recover deleted or corrupted objects and ensure they replicate back to other Domain Controllers. Here’s a step-by-step guide, including the DNS partitions if needed. Prepare for the Restore Identify the partition to restore: Domain Partition: DC=domain,DC=com Configuration Partition: CN=Configuration,DC=domain,DC=com Schema Partition: CN=Schema,CN=Configuration,DC=domain,DC=com DomainDNSZones: DC=DomainDNSZones,DC=domain,DC=com ForestDNSZones: DC=ForestDNSZones,DC=domain,DC=com Ensure you have a recent backup (System State backup) of the partition. Reference the Authoritative Restore for full detailed instructions to restore a partition Open a command prompt in DSRM. ntdsutil Enter authoritative restore mode: activate instance ntds authoritative restore Mark the partition you want: Domain Partition: restore subtree "DC=domain,DC=com" Configuration Partition: restore subtree "CN=Configuration,DC=domain,DC=com" Schema Partition: restore subtree "CN=Schema,CN=Configuration,DC=domain,DC=com" DNS Partitions: restore subtree "DC=DomainDNSZones,DC=domain,DC=com"restore subtree "DC=ForestDNSZones,DC=domain,DC=com" Tip: Use quotes exactly as above; AD DNs are case-insensitive but spaces matter. DNS Zone Recovery This procedure defines how to back up and restore the DNS Server Zones. Although it’s possible to backup DNS Server configurations it’s only possible to restore manually. Backup Procedure The DNS backup script performs a full export of DNS zones and server configuration each day of the week. Prepare a backup directory Ensure $backupPath is defined in the parent backup script (e.g. C:\Backups\ADBackup.ps1). The script automatically creates a daily subfolder under DNS\. Schedule with a Service Account and add the following rights and permissions. User Rights Assignments for Logon As A Service and Logon as Batch are required. The service account will require Full NTFS permission on 'C:\ADBackup\' and 'C:\Windows\System32\dns\' to create and delete files and directories. Do Not add the service account to Domain Admins. DNS Server Restore If restoring to a new server: Install the DNS Server role Install-WindowsFeature DNS -IncludeManagementTools. Allow AD synchronization to restore DNS records to local DC. Restore DNS zones If a DNS zone becomes corrupted, loses records, or is accidentally deleted, it must be restored from a recent backup Copy the C:\ADBackup\DNS\\Zone.name to C:\Windows\System32\DNS. From CMD Type the following Dnscmd /zoneadd zone.name /primary /file zone.name Open the DNS Snap-in and for each Zone Click Type > Change and enable Store the zone in Active Directory Select Secure on the Dynamic Updates drop-down GPO Recovery Starting with Windows Server 2008 R2, Microsoft moved away from FRS replication system to Distributed File System Replication (DFSR) service for handling SYSVOL replication between domain controllers. When planning disaster recovery, you need to account for both the AD portion (which gets handled through normal DC backup and recovery procedures) and the SYSVOL files themselves. A corrupted or out-of-sync SYSVOL can render your entire GPO infrastructure useless even if Active Directory is perfectly healthy, which is why regular backups of the SYSVOL GPO Backup Overview GPO data exists in two parts: Active Directory component — stored in CN=Policies,CN=System, SYSVOL file component — stored in \\\SYSVOL\\Policies\ Links are not backed up with a GPO backup and must be restored manually. To preserve both components, GPOs must be backed up using the Backup-GPO PowerShell cmdlet. This command exports GPO settings into a portable XML structure containing both AD and SYSVOL data. GPO Backup Script The backup script automates the daily export of all GPOs to a designated path (C:\ADBackups\GPO\dayofweek) creating a clean snapshot of every policy in the domain. Executes a full backup of all GPOs using: Scheduled daily to retain a rolling weeks worth of GPO backups. Backup-GPO -All -Path $gpoBackupPath Records backup metadata (name, GUID, creation time) into GPOBackupReference.csv for audit and recovery reference. Script Summary try { # Clean existing backup directory if (Test-Path -Path $gpoBackupPath) { Get-ChildItem -Path $gpoBackupPath -Recurse | Remove-Item -Recurse -Force -ErrorAction SilentlyContinue } # Perform full GPO backup $gpoBackupResult = Backup-GPO -All -Path $gpoBackupPath -ErrorAction Stop $gpoCount = ($gpoBackupResult | Measure-Object).Count # Export reference file $gpoBackupResult | Select-Object DisplayName, GpoId, BackupDirectory, CreationTime | Export-Csv -Path "$gpoBackupPath\GPOBackupReference.csv" -NoTypeInformation Write-Host "GPO backup complete: $gpoCount GPOs backed up" -ForegroundColor Green } catch { Write-Error "Failed to backup GPOs: $_" } GPO Restoration Procedure If you suspect a GPO is corrupted, deleted or made unauthorised changes, remove the GPO from the Group Policy Management Console to prevent further policy replication or application issues. Process: Open GPO Management and navigate to Group Policy Objects. Right click Group Policy Objects > Manage Backups… Browse to C:\ADBackups\GPO\dayofweek and the last known good for that GPO Select GPO and Restore Restore Links manually using the Object Reference script or the scripted approach with GPO Restore Links script SYSVOL DFSR Recovery SYSVOL replication issues can prevent Group Policy from applying correctly across the domain, leading to inconsistent user and computer configurations. When SYSVOL becomes corrupted, out of sync, or replication halts entirely, domain controllers may hold differing versions of policy data, some with outdated or missing GPOs. This can manifest as Group Policy processing errors, missing logon scripts, or inconsistent security settings. In such cases, a restore may be required. A non-authoritative restore allows a domain controller to resynchronize its SYSVOL from a healthy partner, effectively discarding its local copy. An authoritative restore, on the other hand, designates a specific DC’s SYSVOL as the master source, forcing other DCs to replicate from it. Selecting the right approach depends on where the corruption originated and which copy of SYSVOL is known to be correct. D2 and D4 References by Microsoft Microsoft still insists on using the old D2 and D4 terminology from the FRS era when describing DFSR SYSVOL recovery. The actual flags haven’t existed since Server 2008, but apparently Redmond can’t quite let go of the good old days of File Replication Service. Non-Authoritative Restore Use when a single DC's SYSVOL is corrupted but other DCs have good copies. The restored DC will receive updated SYSVOL data from replication partners. SYSVOL contents are overwritten by authoritative sources. Prefer the PDC Emulator as the authoritative source if it has the most up-to-date SYSVOL contents. All ADSIEdit attribute edits must replicate via AD replication to all DCs before starting DFSR on those DCs. Use repadmin /syncall /AdeP to force replication. Monitor the DFSR event log (Applications and Services Logs > DFS Replication) for the event IDs mentioned below. Authoritative Restore Use when all DCs have corrupted SYSVOL or you need to force specific content across the domain. The restored DC becomes the authoritative source Other DCs receive SYSVOL data from the authoritative DC Non-Authoritative SYSVOL Restore (D2) Use this when a single DC’s SYSVOL is bad and you want it to rebuild from peers. Steps (per DC you want to repair): Open ADSIEdit.msc and connect to the default naming context. Navigate to the SYSVOL subscription object for the target DC: CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=,DC= Set the attribute msDFSR-Enabled = FALSE on that DN. Force AD replication to propagate that change to other DCs: repadmin /syncall /AdeP On the target DC, run: dfsrdiag pollad You should see Event ID 4114 in the DFSR log (sysvol replication stopped). On the same DN in ADSIEdit, set msDFSR-Enabled = TRUE. Force AD replication again: repadmin /syncall /AdeP On the target DC, run: dfsrdiag pollad You should see Event ID 4614 and 4604 indicating SYSVOL has been initialized and a D2 (non-authoritative sync) occurred. Verify SYSVOL shares, GPO contents and DFSR health Authoritative SYSVOL Restore (D4) Use this when other DCs are corrupt or missing SYSVOL and you have a single known-good copy. High level: stop/start DFSR, mark authoritative in AD on one DC (msDFSR-Options=1), mark others non-authoritative, force AD replication, start DFSR on authoritative server, flip flags and start others. Steps: All DC’s Stop DFSR service on all DCs in the domain and set Startup Type to Manual (prevents races): net stop dfsr sc config dfsr start= demand Authoritative DC: On the DC you want to be authoritative (preferably PDCe), in ADSIEdit edit the SYSVOL subscription DN: CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=,DC= Set msDFSR-Enabled = FALSE Set msDFSR-Options = 1 (this marks it authoritative — the D4 flag) Non-Authoritative DCs: On every other DC in the domain, edit the same DN and set: msDFSR-Enabled = FALSE Force AD replication and validate it succeeded across all DCs: repadmin /syncall /AdeP repadmin /showrepl wait until replication has propagated to all DCs. Authoritative DC: Start DFSR on the authoritative DC: net start dfsr dfsrdiag pollad Expect Event ID 4114 (replication stopped, normal after the stop), then later Event ID 4602 when the authoritative initialization completes. On the authoritative DC set msDFSR-Enabled = TRUE (ADSIEdit) and force AD replication again: repadmin /syncall /AdeP dfsrdiag pollad Event ID 4602 should appear indicating initialization (D4 completed). Non-Authoritative DCs: Start DFSR on each non-authoritative DC. net start dfsr On each, you will see Event ID 4114 indicating replication paused (expected). Then on each non-authoritative DC, set msDFSR-Enabled = TRUE in ADSIEdit (or you may perform this step before starting the service depending on your ordering), Force AD replication repadmin /syncall /AdeP dfsrdiag pollad These DCs will now replicate the authoritative SYSVOL contents from the D4 source. When all DCs report successful sync and Event IDs indicating initialization complete, return DFSR service startup type to Automatic on all DCs: sc config dfsr start= aut0 Verify: repadmin /replsummary and repadmin /showrepl show healthy replication. Get-DfsrBacklog -GroupName "Domain System Volume" -SourceComputer -DestinationComputer shows no backlogs. Confirm \\domain\SYSVOL content and GPOs match across DCs. Monitor DFSR Event Log for absence of 2213 (dirty shutdown) or persistent 5002/5004 errors. Important cautions & troubleshooting tips AD replication is mandatory between the ADSIEdit edits and any DFSR start/poll, if the AD attribute changes don’t replicate, the process fails. Use repadmin /showrepl to confirm propagation. Do not skip the dfsrdiag pollad and repadmin /syncall /AdeP cycles, these force DCs to pick up the ADSI edits. Prefer the PDC Emulator as the authoritative source since it typically has the most recent SYSVOL contents. If you encounter Event ID 2213 (dirty shutdown), follow Microsoft guidance for resuming replication (backup DFSR database, ResumeReplication as documented). If more than one DC is affected, expand the steps to include all affected DCs (the KB assumes a 2-DC example). Always test in an isolated lab before running in production if possible. Metadata Clean up When a domain controller (DC) is decommissioned properly using Active Directory Users and Computers or dcpromo, most of its metadata, such as NTDS settings, replication links, and server objects are automatically removed. However, if a DC fails or is forcefully removed, residual metadata often lingers in AD. These remnants can cause replication errors, ghost entries in Sites and Services, and general directory hygiene issues. This is where ntdsutil comes in. Running ntdsutil in metadata cleanup mode allows administrators to manually delete orphaned DC objects from the configuration naming context. Here are the correct steps, Microsoft’s own documentation doesn’t exactly make life easy, leaving out most of the critical parts of the metadata cleanup process. ntdsutil metadata cleanup connections connect to server quit select operation target list sites select site list domain select domain list servers in site select server quit remove selected server quit quit Go into Sites and Services and remove any remaining existence of the deleted DC.