🏢Active DirectoryGPOComplianceNetworkMonitoring

PrintNightmare, Point-and-Print, GPO Hardening, Active Directory: The Two-Value Fix Nobody Finished

Stopping the spooler on your DCs removed one privileged target and left the driver-installation path open on every workstation. PrintNightmare is a two-value fix — here is the half most fleets never finished.

Younes AZABARBy Younes AZABAR15 min read
PrintNightmare, Point-and-Print, GPO Hardening, Active Directory: The Two-Value Fix Nobody Finished

PrintNightmare Point-and-Print GPO Hardening Active Directory-Wide: What It Covers

In July 2021 the industry converged on a single instruction: stop the Print Spooler on your domain controllers. That advice was correct, and it was incomplete. The control that actually closes the hole is PrintNightmare Point-and-Print GPO hardening Active Directory-wide, and it comes down to two registry values that most fleets have never audited together. Microsoft's own guidance for CVE-2021-34527 answers two questions back to back. "Are Domain Controllers known to be affected by the vulnerability? Domain controllers are affected if the print spooler service is enabled." And immediately after: "Are client systems and member servers that are not domain controllers known to be affected by the vulnerability? Yes. All editions of Windows are affected." Stopping a service on three or four DCs removed one privileged target and left the driver-installation path intact on every workstation and member server you own.

PrintNightmare is the public name for CVE-2021-34527, a Print Spooler remote code execution flaw that Microsoft rates Critical with a CVSS 3.1 base score of 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). At publication Microsoft's exploitability assessment recorded it as Publicly Disclosed: Yes; Exploited: Yes. CISA added it to the Known Exploited Vulnerabilities catalogue on 2021-11-03 with a remediation due date of 2022-05-03, and flags it as knownRansomwareCampaignUse: Known. It is not a theoretical finding.

It is also frequently confused with CVE-2021-1675, addressed by the June 8, 2021 update. Microsoft's answer in that CVE's FAQ is blunt: "Is this the vulnerability that has been referred to publicly as PrintNightmare? No, Microsoft has assigned CVE-2021-34527 to PrintNightmare. CVE-2021-1675 is similar but distinct from CVE-2021-34527." Both are in the CISA KEV catalogue and both are flagged for known ransomware use.

⚠️

⚠️ Warning: The patch is a precondition, not the control. Microsoft states plainly in KB5005010 that after installing the update you "must confirm" a specific registry and Group Policy state. A fully patched fleet with the wrong policy is still a vulnerable fleet.

How It Works: Two Registry Values, One Verdict

Both values live under the same key, documented in KB5005010 and KB5005652:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint

ValueTypeSafe stateWhat the other state means
RestrictDriverInstallationToAdministratorsREG_DWORD1, or not defined / not present0 allows non-administrators to install signed and unsigned drivers to a print server
NoWarningNoElevationOnInstallREG_DWORD0, or not defined1 "makes your system vulnerable by design" (MSRC)
UpdatePromptSettingsREG_DWORD0, or not definedNon-zero values "make the devices on which you've installed the CVE-2021-34527 update vulnerable" (KB5005010)

The interaction between the first two is the part that gets missed, and KB5005652 documents it precisely.

Setting RestrictDriverInstallationToAdministrators to 1 — or leaving it undefined — "will require administrator privilege to install any printer driver when using Point and Print. This registry key will override all Point and Print Restrictions Group Policy settings."

Setting it to 0 "allows non-administrators to install signed and unsigned drivers to a print server but does not override the Point and Print Group Policy settings."

So the override runs one way only. While the value is 1, a sloppy Point and Print policy cannot reopen driver installation. The moment somebody sets it to 0 — and KB5005652 explicitly describes admins doing exactly that, "to allow non-admins to install and update drivers" — the Point and Print Restrictions GPO becomes the only thing standing between an ordinary user and a driver installed as SYSTEM.

Microsoft's summary of that trade-off is one sentence, repeated twice in KB5005652: "There is no combination of mitigations that is equivalent to setting RestrictDriverInstallationToAdministrators to 1."

The default flipped, and updates do not enforce it

Two dates matter here, both from KB5005652:

  • Updates released July 6, 2021 or later shipped a default of 0 (disabled) for RestrictDriverInstallationToAdministrators.
  • Updates released August 10, 2021 or later shipped a default of 1 (enabled).

That is the good news. The catch is in the same article: "Windows updates will not set or change the registry key." A device that was explicitly stamped with 0 in July or August 2021 — by a script, a baseline, or a GPP registry item written to unblock printing — keeps that 0 through every subsequent cumulative update, indefinitely. The default only protects hosts where nobody wrote the value.

The Attack Chain

The vulnerable path is the driver-installation path, not the print path. KB5005010 draws the line explicitly: the fixes "do not directly affect the default Point and Print driver installation scenario for a client device that is connecting to and installing a print driver for a shared network printer... This scenario is different from the vulnerable scenario where an attacker is trying to install a malicious driver on the print server itself, either locally or remotely."

Step 1 - Find a host whose spooler accepts driver installation

Every Windows host running spoolsv.exe is a candidate, not just print servers and not just DCs. Microsoft's own FAQ confirms member servers and clients are in scope. An attacker with any domain credential enumerates hosts where the spooler is reachable — which, on a default-configured workstation fleet, is most of them. Note the CVSS vector: PR:L, low privileges required. A standard user account is enough.

Step 2 - Check whether the prompts are gone

If the target has RestrictDriverInstallationToAdministrators = 0 and NoWarningNoElevationOnInstall = 1, driver installation proceeds without an elevation prompt. Those are precisely the two values KB5005010 tells you to confirm, and precisely the state MSRC describes as vulnerable by design.

Step 3 - Install the driver

The spooler service "improperly performs privileged file operations" (MSRC description for CVE-2021-34527). A driver installed through this path executes in the spooler's context. Per the same MSRC description, an attacker "could run arbitrary code with SYSTEM privileges... install programs; view, change, or delete data; or create new accounts with full user rights."

Step 4 - Convert local SYSTEM into domain reach

SYSTEM on a workstation is the start of a lateral movement chain, not the end of an incident — containing it is exactly the job of a tier boundary that actually holds. This is why the DC-only remediation is so misleading: an attacker does not need your domain controller's spooler if every laptop in the fleet grants SYSTEM to any authenticated user. The delegated groups that used to own printing are worth auditing at the same time — before the July 2021 updates, per KB5005010, "the printer operators' security group could install both signed and unsigned printer drivers on a printer server", and those operator groups carry standing privilege nobody reviews.

🚨 Danger: The spooler kept producing Critical bugs after the July fix. August 2021 alone added CVE-2021-36936 (Critical, CVSS 8.8, publicly disclosed) and CVE-2021-36958 (Important, CVSS 7.8, publicly disclosed). Treat the spooler as attack surface to remove where you can, not a component to patch and forget.

The GPO That Silently Reopens It

Here is the part that turns a solved problem back into a live one, and it is not hypothetical — it is in Microsoft's own current documentation.

Microsoft Learn publishes a troubleshooting article, "Point and Print Restrictions policies are ignored in Windows" (originally KB 2307161), for a familiar operational symptom: "You apply the Point and Print Restrictions policies. A standard user tries to install a network printer. In this scenario, the Point and Print Restrictions policies are ignored, and the user is prompted for administrative credentials."

Its stated cause is a real and useful finding on its own: "Windows ignore the Point and Print Restrictions policies when the policies are implemented in the user policy context." The policy moved from User Configuration\Policies\Administrative Templates\Control Panel\Printers to Computer Configuration\Policies\Administrative Templates\Printers. If your audit reads the user-side location, you are reading a setting Windows discards.

But read the resolution steps. Under "How to permit users to connect only to specific print servers that you trust", the article instructs: "In the When installing drivers for a new connection box, select Do not show warning or elevation prompt." And its closing note goes further: "you can disable the driver installation warning messages and elevation prompts by completely disabling the Point and Print Restrictions policies. This action disables the enhanced printer driver installation security."

That guidance is the mirror image of KB5005010, which tells you to set both prompt boxes to "Show warning and elevation prompt" so the confirmation values read NoWarningNoElevationOnInstall = 0 and UpdatePromptSettings = 0. One Microsoft page hardens the prompts; another, still carrying a 2026 revision date, walks an administrator through switching them off to make printer deployment work.

Nobody has to act in bad faith for this to happen. A helpdesk ticket says users cannot add the third-floor printer. Someone finds the troubleshooting article, sets the prompt to "Do not show warning or elevation prompt", and links the GPO. Printing works. Six months later the fleet is back in the configuration MSRC calls vulnerable by design, and no patch cycle will ever flag it — because the hosts are fully patched. This is the same class of drift that makes GPO misconfiguration such a durable attack vector.

KB5005010's verdict on the combined state leaves no room for interpretation: if the registry values are 0/undefined and the Point and Print Restrictions GPO is unconfigured, "then you are not vulnerable to CVE-2021-34527 and no further action is needed. If either condition is not true, you are vulnerable."

Detection

Detection here has two halves: catch the exploitation attempt in the event log, and catch the configuration drift before anyone tries.

Event log detection

The Splunk Threat Research Team's analysis, I Pity the Spool: Detecting PrintNightmare CVE-2021-34527, documents the channels and event IDs worth ingesting:

IndicatorEvent IDChannelWhat it tells you
Adding a printer driver316Microsoft-Windows-PrintService/OperationalRecords the driver being added and the DLLs it references — the direct artefact of the driver-installation path
Print spooler failed to load a plug-in module808Microsoft-Windows-PrintService/AdminFires on failed load attempts, which is where unsuccessful exploitation surfaces
Plug-in module load failure (variant)4909Microsoft-Windows-PrintService/AdminSame failure class, logged on some builds under this ID
DLL written under spool\drivers\x64\n/a (file/image events)Sysmon ImageLoaded / CallTracespoolsv.exe writing or loading DLLs from the driver spool path

The operational catch, in Splunk's own words, is that "print service logs may not be enabled by default." An alert you never wrote because the channel was empty is not a detection. Check and enable the channel — /e:<Enabled> on wevtutil set-log "enables or disables a log", per the wevtutil reference:

wevtutil gl Microsoft-Windows-PrintService/Operational
wevtutil sl Microsoft-Windows-PrintService/Operational /e:true

If you are building out log coverage more broadly, the same reasoning applies to every channel your detections assume exists — see the audit policy categories nobody enables before they need the logs and the AD security event IDs that actually matter.

Configuration detection

This is the higher-yield half, because it finds the exposure rather than the exploitation. Read the three values on each host. Absence of the key is the safe state on updates from August 10, 2021 onward, so -ErrorAction SilentlyContinue returning nothing is a pass, not an error:

$key = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint'
Get-ItemProperty -Path $key -ErrorAction SilentlyContinue |
    Select-Object RestrictDriverInstallationToAdministrators,
                  NoWarningNoElevationOnInstall,
                  UpdatePromptSettings

Flag a host when RestrictDriverInstallationToAdministrators is 0, or when NoWarningNoElevationOnInstall or UpdatePromptSettings is non-zero. Run it against workstations and member servers, not only print servers and DCs — that scoping mistake is the entire subject of this article.

Separately, confirm whether the spooler is running at all. This is Microsoft's own first step in the CVE-2021-34527 workaround:

Get-Service -Name Spooler

On domain controllers specifically, a running spooler is its own finding, independent of the driver-installation policy — covered in our domain controller network hygiene checklist.

Remediation

💡

💡 Tip: Neither of the two registry changes below requires a reboot. KB5005652: "No restart is required when creating or modifying this registry value." KB5005010: "This policy change does not require a restart of the device or the print spooler service after applying these settings."

1. Set RestrictDriverInstallationToAdministrators to 1 everywhere. This is the single strongest control, and the one that overrides everything else. The command below is quoted verbatim from KB5005652 and must run from an elevated prompt:

reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" /v RestrictDriverInstallationToAdministrators /t REG_DWORD /d 1 /f

2. Prefer the Group Policy route for fleet scale. After installing updates released October 12, 2021 or later, KB5005652 documents a native policy: go to Computer Configuration > Administrative Templates > Printers and set Limits print driver installation to Administrators to "Enabled". Microsoft states this "will set the registry value of RestrictDriverInstallationToAdministrators to 1."

3. Fix the Point and Print Restrictions policy in the Computer scope. Per KB5005010, in Computer Configuration > Administrative Templates > Printers, set Point and Print Restrictions to "Enabled", then set both When installing drivers for a new connection and When updating drivers for an existing connection to "Show warning and elevation prompt". Verify afterwards that NoWarningNoElevationOnInstall = 0 and UpdatePromptSettings = 0. Configuring this "does not disable the Point and Print feature" — printing keeps working.

4. Audit for the user-scope trap. Because Windows ignores these policies in the user policy context, check whether a legacy GPO still sets them under User Configuration\Policies\Administrative Templates\Control Panel\Printers and is giving you false assurance.

5. If you genuinely cannot use the default, layer the partial mitigations — and know they are partial. KB5005652 lists them for environments that must run with RestrictDriverInstallationToAdministrators = 0, while repeating that no combination equals setting it to 1:

  • Verify RpcAuthnLevelPrivacyEnabled is 1 or not defined at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print. This is the Enforcement mode for CVE-2021-1678 documented in KB4599464; its enforcement phase began September 14, 2021, and a value of 0 is documented as "Not recommended... your devices are not protected."
  • Enable Users can only point and print to these servers in the Point and Print Restrictions policy and list trusted print servers by fully qualified name, separated by semicolons.
  • Enable Package Point and Print - Approved servers to restrict clients to package-aware drivers from named servers.

6. Remove the spooler where it is not needed. MSRC's workaround for CVE-2021-34527 remains valid, and on a domain controller the answer is usually to remove the service outright:

Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

If you need local printing but not inbound print serving, MSRC's Option 2 is to disable the "Allow Print Spooler to accept client connections" policy under Computer Configuration / Administrative Templates / Printers. Unlike the registry changes above, "you must restart the Print Spooler service for the group policy to take effect."

⚠️

⚠️ Warning: Sequence your updates. Per KB5005652, before installing updates released September 14, 2021 or later on print servers, print clients must already have an update released January 12, 2021 or later — otherwise those clients will not print. If users are prompted for credentials on every print job rather than only on driver install, KB5005652 attributes that to a time-zone issue fixed by the October 12, 2021 updates, or to a driver filename/version mismatch between the print client and server.

Where this sits in a broader remediation queue is covered in our guide to what to lock down first in Active Directory and how to validate it, and in the wider walkthrough of how to audit Active Directory security and prove remediation.

How EtcSec Detects This

EtcSec checks this configuration as three distinct findings, because they fail independently and get fixed by different teams.

PRINTNIGHTMARE_VULNERABLE (Critical) evaluates whether the elevation prompt is disabled GPO-wide — the state of NoWarningNoElevationOnInstall — rather than patch level alone. PA038_POINT_AND_PRINT_ELEVATION_OFF (High) reads the same registry value through the ANSSI PA-038 compliance lens: it fails when no GPO in scope enforces elevation, flagging the exact configuration MSRC describes as vulnerable by design. DC_SPOOLER_ACCESSIBLE (High) covers the narrower, better-known problem of a Print Spooler still running on a domain controller.

The reason all three exist is the gap this article opened with. A fleet can pass the DC check and fail the other two — spooler stopped on four domain controllers, elevation prompts disabled on four thousand workstations. The etc-collector reads the effective values from the Computer Configuration scope (Machine\Registry.pol) on every in-scope host, so a policy that Windows silently ignores in the user context does not read as compliant.

ℹ️

ℹ️ Note: EtcSec automatically checks for this vulnerability during every AD/Azure audit. Run a free audit to verify your environment.

Sources

Every technical claim above is drawn from the following, each verified against the live source:

Explore the identity security pages that support this topic