Shared Printing Broke After the Print RPC Hardening (CVE-2021-1678)? Patch Clients First
You hardened the print spooler against CVE-2021-1678 (or a security baseline did it for you), and now network printing is broken between your print server and clients. Or you’re about to enable the hardening and want to do it without taking printing down.
The mistake that breaks printing: the fix for CVE-2021-1678 raises the authentication level on the printer IRemoteWinspool RPC interface, controlled by a registry value. Most guides just tell you to set that value — and skip the prerequisite. Before you enable server-side enforcement, every client must already have the January 12, 2021 Windows update (or later). A hardened (enforcing) server talking to an unpatched client = failed RPC = no printing. The other common bad advice is to “fix” it by setting the value to 0, which simply removes the protection.
The control: RpcAuthnLevelPrivacyEnabled
The hardening is a single REG_DWORD at:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print
RpcAuthnLevelPrivacyEnabled = 1→ enforcement on (raised auth level on the printer IRemoteWinspool interface) — the secure state.RpcAuthnLevelPrivacyEnabled = 0→ protection disabled — not recommended.- Value absent → default behaviour for your patch level.
The correct order (so printing doesn’t break)
- Patch every client first. Confirm all machines that print to the server have the January 12, 2021 cumulative update or later installed. This is the step that prevents the outage.
- Then enable enforcement on the server: set
RpcAuthnLevelPrivacyEnabled = 1and reboot the spooler/server. - Test printing from a patched client. With both ends current, RPC negotiates the higher auth level and printing works — securely.
If printing is already broken
- Don’t set the value to
0as a permanent fix — that drops the CVE-2021-1678 protection. - Instead, find the unpatched clients and update them (they’re the ones failing). Once patched, they print again against the enforcing server.
- If you need printing back immediately while you patch stragglers, removing/zeroing the value is a temporary stopgap only — re-enable
= 1as soon as clients are current.
If a single workstation shows the printer as “offline” rather than failing with an RPC error, that’s a different problem — see printer says offline in Windows 11. For broader standalone-server hardening, see hardening a standalone Windows Server.
FAQ
Where do I set this — server or clients? The RpcAuthnLevelPrivacyEnabled enforcement value goes on the print server. The prerequisite patch must be on the clients (and the server). Order matters: patch clients, then enforce on the server.
Will enforcement break non-Windows print clients? Clients that can’t negotiate the higher RPC auth level may fail. Inventory non-Windows printing paths before enforcing, and update their drivers/agents.
Is leaving it disabled (0) really that bad? It re-exposes a spooler RPC elevation-of-privilege vector. Treat 0 as temporary only; the goal state is 1 with all clients patched.
Sources: Microsoft — Managing deployment of printer RPC binding changes for CVE-2021-1678 (KB4599464)