Active Directory GPO Security Settings: Four Checks

What Are Active Directory GPO Security Settings?

Active Directory GPO security settings determine how Windows clients resolve local names, trust update metadata, protect LSASS, and authenticate access to policy shares. Four settings deserve a focused review: disabling LLMNR, using HTTPS for WSUS metadata, enabling LSA protection, and requiring mutual authentication and integrity for SYSVOL and NETLOGON.

Each addresses a different attack prerequisite. A secure update connection does not protect LSASS memory; disabling LLMNR does not disable NetBIOS name resolution. Review the policy value, the computers receiving it, and the protection actually in use before closing a finding.

Our GPO misconfiguration guide examines delegated edit permissions, policy links, LAPS, and password policy governance. This walkthrough covers four specific settings that can remain unsafe even when a GPO's administrative permissions are correct.

How It Works: Four Policies and Their Registry Values

Use the following settings as review targets. The expected values describe an intended configuration, not results from an audit of your environment.

1. Disable LLMNR; Handle NBT-NS Separately

Policy path: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution.

Registry key: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient; value: EnableMulticast, REG_DWORD 0. The policy's negative wording matters: Enabled turns LLMNR off. Microsoft documents the DNS Client policy mapping; its Windows Server baseline reference specifies the zero value.

LLMNR provides local name resolution when conventional DNS resolution is unavailable. An attacker able to influence that local exchange can redirect a client toward an attacker-controlled destination and induce authentication, as described in MITRE ATT&CK's name-resolution poisoning entry. Captured NTLMv2 responses are not plaintext passwords: Microsoft documents NTLM as a challenge-response protocol. Relaying authentication also depends on the destination service's protections.

NBT-NS is a separate exposure. Microsoft documents Win32_NetworkAdapterConfiguration.SetTcpipNetbios with TcpipNetbiosOptions=2 to disable NetBIOS over TCP/IP for an adapter. Treat that adapter-level method as a separate deployment decision, with its own compatibility checks. The LLMNR policy and the corresponding EtcSec check do not establish NetBIOS coverage.

2. Protect WSUS Metadata with HTTPS

Policy path: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location. Windows 10/11 policy templates place it under Manage updates offered from Windows Server Update Service.

Registry key: HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate; values: WUServer and WUStatusServer, both REG_SZ. Configure the deployed server's HTTPS URL in both fields. The companion HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer value is REG_DWORD 1 for WSUS use. These mappings are documented in Windows Update settings.

Microsoft's WSUS configuration procedure distinguishes HTTPS metadata from HTTP payload delivery. An attacker on the traffic path can tamper with unprotected update information. Assess clients actually using that server and the interceptable path; do not infer compromise of every domain-joined computer from one URL.

3. Enable LSA Protection with a Supported RunAsPPL Value

For Windows 11 22H2 and later, Microsoft's documented administrative-template path is Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process. The documented Group Policy Preferences alternative is Computer Configuration > Preferences > Windows Settings > Registry.

Registry key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa; value: RunAsPPL, REG_DWORD. 1 selects protection with a UEFI lock where supported; Microsoft bounds enforcement of 2, without that lock, to Windows 11 22H2 and later. On x86/x64 devices without UEFI support or with Secure Boot disabled, the configuration relies on the registry rather than a firmware lock. Restart after configuration. Follow Microsoft's LSA protection procedure.

Protected Process Light limits memory reads and code injection by unprotected processes. Missing protection can facilitate credential theft after an attacker obtains the necessary access. A registry value alone does not establish the running process's protection. Some modern clients enable LSA protection automatically; an absent collected GPO value needs investigation, not a categorical claim that LSASS is unprotected.

4. Require Mutual Authentication and Integrity for Policy Shares

Policy path: Computer Configuration > Administrative Templates > Network > Network Provider > Hardened UNC Paths.

Registry key: HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths. Set both REG_SZ value names, \\*\SYSVOL and \\*\NETLOGON, to RequireMutualAuthentication=1,RequireIntegrity=1. The Connectivity policy mapping establishes the policy location and registry key; the baseline reference specifies the required attributes.

Mutual authentication requires Kerberos server identity validation; integrity requires SMB signing. Microsoft describes UNC hardening and interception defenses, including the default hardening of SYSVOL and NETLOGON beginning with Windows 10 and Windows Server 2016.

Our SYSVOL cPassword guide explains why historical GPP secrets require cleanup and credential rotation, and already recommends UNC hardening. Here, the focus is the precise share patterns and connection requirements. Protecting transit does not remove stored secrets or repair excessive write permissions.

The Attack Chain: Separate Prerequisites, Separate Controls

These are four independent paths, not four mandatory stages of one exploit. Use this distinction when scoping an investigation:

A configuration finding supports hardening work. It does not establish that an attacker captured credentials, altered an update, dumped LSASS, or changed a policy in transit. Keep any incident conclusion tied to independent telemetry.

Detection: Measure the Target Computer

Start on a Windows target in each relevant policy scope. Microsoft's gpresult reference documents computer-scope RSoP output:

gpresult /scope computer /r

The summary helps identify applied GPOs. Use detailed RSoP output when investigating conflicting settings, then compare it with local values and runtime evidence. Repeat the checks for each target whose policy scope you are reviewing.

The following commands instantiate Microsoft's documented reg query syntax with the Learn-backed keys above. Run each separately.

Measure LLMNR Configuration

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast

Expect REG_DWORD 0. If the value is missing or different, reconcile the target's policy result before deciding the rollout succeeded. Review unexpected local name-resolution destinations as an investigation signal. Microsoft's Defender for Identity alert reference recognizes the LLMNR/NBT-NS poisoning and SMB relay technique family; it does not establish a universal Windows Event ID for this check.

Measure WSUS Configuration

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

Review WUServer, WUStatusServer, and the AU\UseWUServer entry together. Compare the URLs with the intended FQDN and HTTPS port, validate certificate trust, and confirm successful client update scans. An HTTPS string alone does not validate IIS, certificate handling, or actual client use. No specific WSUS attack Event ID is established by the sources used here.

Measure LSA Configuration and Startup

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL

For runtime confirmation, inspect System / WinInit / Event 12 after restart. It records protected LSASS startup. The wevtutil reference documents event querying; this example selects Event 12 records for inspection:

wevtutil qe System /q:"*[System[(EventID=12)]]" /rd:true /f:text /c:10

Confirm the provider is WinInit and the message concerns protected LSASS startup. The filter selects by ID, so unrelated providers may appear. In CodeIntegrity/Operational, audit Event 3065 concerns shared-section requirements and 3066 concerns Microsoft signing-level requirements; the image is still allowed to load in audit mode. Under protection, 3033 identifies signing-level failures and 3063 identifies shared-section failures. These events do not prove a successful credential dump. Missing retained startup evidence alone does not prove protection is disabled.

Measure UNC Configuration

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths"

Inspect both share patterns and required attributes. When entries are absent, account for the OS defaults before classifying exposure. Validate access to the real SYSVOL and NETLOGON destinations and their authentication and integrity guarantees. There is no specific UNC spoofing Event ID established here.

Remediation: Roll Out and Verify Each Control

Step 1: Disable LLMNR in a Pilot Scope

Enable the DNS Client policy described above. Re-run the LLMNR registry query and reconcile the computer's applied policies. Check that applications using local names continue to resolve their intended destinations. If NetBIOS remains necessary, record that dependency separately; if it can be disabled, manage the documented adapter method separately from the DNS Client setting.

Step 2: Configure WSUS TLS Before Changing Client URLs

Configure the server certificate, IIS bindings, and required TLS virtual roots according to Microsoft's WSUS procedure. From an elevated Command Prompt in C:\Program Files\Update Services\Tools, the documented command is:

wsusutil configuressl <certificate-name>

Replace the placeholder with the WSUS server's DNS name. Require TLS for the documented metadata services, including ClientWebService; do not require TLS for the entire WSUS website. Payload delivery still uses HTTP, with signature and hash validation. Update both client policy URLs to the deployed HTTPS endpoint; https://wsus.contoso.com:8531 is Microsoft's example, not a discovered server. Verify certificate trust and update scanning before broad rollout.

Step 3: Test LSA Compatibility, Enable Protection, and Restart

Use the LSA procedure's compatibility audit before enforcement. Resolve incompatible plug-ins and drivers, select the supported RunAsPPL option, restart, and verify protected startup. Audit events are not generated when Smart App Control is enabled or a kernel debugger is attached and enabled, so silence is not automatic compatibility approval. Review UEFI lock implications before selection: changing the registry alone does not remove the firmware variable. LSA protection and Credential Guard are complementary controls.

Step 4: Require Both UNC Attributes on Both Shares

Configure SYSVOL and NETLOGON explicitly in the Hardened UNC Paths policy. Test policy retrieval from each target scope and investigate authentication or access failures before expanding. Add RequirePrivacy only after checking encryption compatibility; unsupported endpoints can become inaccessible. Review write permissions and reusable secrets as separate work items, even when the transport requirements pass.

Keep a compact record for each rollout: target OS and scope, applied GPOs, before/after registry output, relevant runtime or connection evidence, and any unresolved dependency. Re-run the same measurements after policy changes so a later reviewer can distinguish a changed setting from a changed interpretation of defaults.

How EtcSec Detects This

The four etc-collector Detect() implementations reviewed for this article evaluate collected GPO registry data:

The registry helpers search the default domain-controller policy, then the default domain policy, then another available GPO. The code aggregates GPO values and does not prove the effective configuration of each workstation. It does not calculate per-computer link precedence, filtering, and inheritance. Contradictory or out-of-scope GPOs therefore need target-side confirmation.

The UNC helper searches for the two required attribute strings; it is not an effective-policy parser. A missing WUServer does not trigger the HTTP check, but that absence does not validate the update strategy. Similarly, missing PPL or UNC entries can require investigation of modern defaults. Use each finding to open a focused verification task, attach the target evidence, and close it only when the intended protection is demonstrated for the affected scope.