Deploying Microsoft security baselines with GPO

Most of the individual controls in this series (SMB signing, NTLM restrictions, LSA protection, WDigest, UAC for remote local accounts) are already configured, with sensible values, in Microsoft's security baselines. Organisations that deploy the baseline as a whole close dozens of findings at once and get a documented, versioned reference to measure drift against. Organisations that skip it tend to rebuild the same settings one incident at a time, inconsistently across OUs.

This guide covers deploying the baselines through Group Policy in a way that survives contact with production: getting the Security Compliance Toolkit, measuring the gap against your existing GPOs with Policy Analyzer, testing on single machines with LGPO, rolling out in rings, handling exceptions without editing the baseline, and detecting drift. It builds on the change-control practices in the Group Policy and SYSVOL pillar.

What the Security Compliance Toolkit contains

The Microsoft Security Compliance Toolkit (SCT) is a free download that bundles:

• Baseline packages per product and version: Windows 11 and Windows Server releases, Microsoft Edge, Microsoft 365 Apps. Each package contains GPO backups (in a GPOs folder), custom ADMX templates (SecGuide.admx and MSS-legacy.admx), a documentation spreadsheet listing every setting, and scripts: Baseline-ADImport.ps1 imports the GPOs into your domain, Baseline-LocalInstall.ps1 applies them to a standalone machine.
• Policy Analyzer, which compares sets of GPOs against each other or against a machine's effective state, and exports differences to Excel.
• LGPO.exe, a command-line tool to import, export and parse local Group Policy.

Server baselines are split by role: separate GPOs for domain controllers and member servers, plus a domain-level security GPO for account policies. Keep that split; DC and member server settings differ in ways that matter (user rights assignments, for example).

Choose the right baselines for your estate

Download the baseline that matches each operating system version you run, not only the newest one. Baselines are written for a specific release and occasionally configure settings that older releases do not have or interpret differently. In a mixed estate, target each baseline at the matching OS version through separate OUs (the cleanest option) or through WMI filters on the operating system version, which cost a little extra processing time at each refresh. Do not apply the Windows 11 baseline to servers or the member server baseline to domain controllers: user rights assignments and service settings differ between them for good reasons.

Also deploy the Microsoft Edge and Microsoft 365 Apps baselines where those products are installed, including on admin workstations and jump servers, where a hardened browser and Office configuration matter more than anywhere else. The domain security GPO in the server package sets password and lockout policy at domain level; compare it with your existing Default Domain Policy rather than linking a second GPO that competes with it.

Measure: gap analysis with Policy Analyzer

Before importing anything, find out how far your current GPOs are from the baseline. Back up your existing GPOs, then load both sets into Policy Analyzer.

# Back up current GPOs that apply to the target OUs
$backup = 'D:\Baselines\Current-' + (Get-Date -Format yyyyMMdd)
New-Item -ItemType Directory -Path $backup -Force | Out-Null
Get-GPO -All | Where-Object DisplayName -Match 'Server|Workstation|Domain Controller|Default' |
    ForEach-Object { Backup-GPO -Guid $_.Id -Path $backup | Out-Null }

In Policy Analyzer, use "Add" to import the GPO backup folder of your current GPOs and the GPOs folder of the baseline package; each becomes a .PolicyRules file. Select both and choose "View / Compare". The comparison highlights settings configured differently, settings only one side configures, and conflicts inside a set (two of your own GPOs setting the same value differently). Export to Excel and review with the service owners; this spreadsheet becomes your exceptions register.

Focus the review on the settings that most often cause impact:

Many of these are covered individually elsewhere: SMB signing enforcement, auditing and restricting NTLM and password policy. Use those guides' audit steps before accepting the baseline value for the NTLM and signing settings.

Test on single machines with LGPO

Before any domain change, apply the baseline locally to a lab machine that mirrors a production build, and capture the before state so you can revert.

# Save the current local policy, then apply the baseline GPO backup locally
.\LGPO.exe /b C:\Temp\LocalPolicy-Before
.\LGPO.exe /g 'D:\Baselines\Windows Server 2025\GPOs\{GUID-of-member-server-GPO}'

# Inspect a registry.pol in readable form
.\LGPO.exe /parse /m 'D:\Baselines\Windows Server 2025\GPOs\{GUID}\DomainSysvol\GPO\Machine\registry.pol'

Run the application's smoke tests, reboot, test remote management (RDP, WinRM, backup agents, monitoring agents), then compare the machine to the baseline in Policy Analyzer with "Compare to Effective State" (run elevated) to confirm what actually applied.

Enforce: import, link in rings, add exceptions

Copy the custom ADMX and ADML files to the Central Store first, otherwise the MS Security Guide and MSS settings show as extra registry settings in GPMC:

$dns = (Get-ADDomain).DNSRoot
$central = "\\$dns\SYSVOL\$dns\Policies\PolicyDefinitions"
Copy-Item '.\Templates\*.admx' $central
Copy-Item '.\Templates\en-US\*.adml' "$central\en-US"

Import the baseline GPOs. Baseline-ADImport.ps1 does this for the whole package; the equivalent for one GPO is:

# Use the exact GPO name shipped in your baseline package (it includes the version)
Import-GPO -Path 'D:\Baselines\Windows Server 2025\GPOs' `
    -BackupGpoName 'MSFT Windows Server 2025 - Member Server' `
    -TargetName 'SEC-Baseline-WS2025-MemberServer' -CreateIfNeeded

Neither method links the GPOs. Link them in rings, each ring an OU or a security-filtered group:

1. Ring 0: lab and IT-owned test servers. One week.
2. Ring 1: a representative slice of production, one or two servers per application. Two weeks.
3. Ring 2: the rest of the tier, in batches.
4. Domain controllers last, starting with one DC per site, after verifying the DC-specific GPO in the lab. Coordinate with the domain controller baseline.

New-GPLink -Name 'SEC-Baseline-WS2025-MemberServer' -Target 'OU=Ring1,OU=Servers,DC=corp,DC=example' `
    -LinkEnabled Yes -Order 2
New-GPLink -Name 'SEC-Baseline-Exceptions-Servers' -Target 'OU=Ring1,OU=Servers,DC=corp,DC=example' `
    -LinkEnabled Yes -Order 1

Link order 1 wins, so the exceptions GPO overrides the baseline for the few settings you have documented deviations for. Keep exceptions narrow: scope each one to the OU or security group of the affected servers, record the reason and owner in the GPO comment, and review them when the next baseline version is released. Protect all baseline and exception GPOs as Tier 0 if they are linked to DCs, following auditing GPO permissions.

Verify

On a machine in each ring, confirm the GPOs applied and the key values are live:

gpresult /scope computer /r
Get-GPResultantSetOfPolicy -ReportType Html -Path C:\Temp\rsop.html

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel, RunAsPPL
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature

Expected: both baseline GPOs listed as applied, LmCompatibilityLevel 5, RunAsPPL set, and signing required. Then keep checking. Schedule a monthly Policy Analyzer "Compare to Effective State" on a sample of machines from each tier, and diff Get-GPOReport -ReportType Xml exports of the baseline GPOs against the version you imported so that any edit to a baseline GPO shows up as a change, not as a surprise during an audit. A PingCastle assessment after rollout gives an independent view of which findings the baseline closed.

When Microsoft publishes a new baseline version, import it under a new name, compare old and new in Policy Analyzer, read the release notes for intentional changes, and move the ring links one ring at a time.

What it breaks

• LAN Manager authentication level 5 blocks NTLMv1 and LM clients: old NAS devices, printers and scanners doing scan-to-folder, and legacy applications. Audit NTLMv1 on DCs first.
• SMB signing required breaks access to and from devices that cannot sign, typically older NAS and multifunction printers, and can reduce throughput on high-volume file servers with older CPUs.
• Denying network logon to local accounts stops remote administration with local accounts, including some backup and monitoring agents configured with a local admin account. Use domain accounts or Windows LAPS with local logon only.
• LSA protection (RunAsPPL) prevents unsigned or non-compliant LSA plug-ins, such as older smart card middleware, password filters and some security agents, from loading. Enable LSA audit mode first and check events 3065 and 3066 in the CodeIntegrity operational log.
• Credential Guard in client baselines blocks NTLMv1, unconstrained delegation and MS-CHAPv2 single sign-on for protected credentials. Microsoft does not recommend Credential Guard on domain controllers.
• Account lockout settings can generate lockouts from stale credentials on mobile devices and mapped drives; watch event 4740 in the first weeks.

Related reading: the Group Policy & SYSVOL topic hub, domain controller hardening for DC-specific settings the baseline does not cover, and the hardening checklist for where baselines fit in a 90-day plan.