top of page


  • Chris Bratton - Tech Journalist

Prioritise Windows security or keep using network printing? Suggestion from Admins

This week, Microsoft brought out another update for its remote network printing setup, which went offline after the latest patch. The patch was received on Tuesday to fix print vulnerabilities, but network admins suggest otherwise.

Printer RPC binding change came for CVE-2021-1678 (KB4599464) to manage update deployment. The security bypass vulnerability introduced within Printer Remote Procedure Call (RPC) binding is responsible for authentication.

Authentications are part of low-level security management that users handle directly with the help of a whole different service that evaluates input. Network printing is used within personal space but primarily for commercial use such as offices and businesses. The vulnerability may expose sensitive information to third parties with authentication bypass.

Microsoft recommendation

Microsoft updated client and server devices first back in January, and Windows updates to keep the protective layer on. The instalment failed to mitigate security vulnerability and made an impact on the print setup. “Enabling” Enhancement mode on windows devices was the initial suggestion. After the patch deployment in a smaller portion, the issue was fixed. Though many users complained against the vulnerability overlooked by such a dependable company, advanced users came up with their solution to reboot network printing and driver rollback by uninstalling updates.

The fix came in two phases, the first one with registry setting tweak that fixed authentication vulnerability and secondly through admin notice of September transitions enforcement phase. Patches on the devices themselves received a quick update as the vulnerability was discovered.

Nevertheless, IT forums and channels dint the topic vanish, but they dissected the matter and came into a community-driven solution. It was scary at first to find a vulnerability in the device of a renowned company, but then again, anything online can have exposure; attackers have to find it.

There are precautions before installing the update, according to the Microsoft deployment publication. A user must have SHA-2 installed, and a device restart is required. For windows server 2008 R2 service pack 1 (SP1), the latest SSU update is recommended. For windows server service 2008 (SP2), an ADV99001 (SSU) update is required. Lastly, users must also purchase Extended Security Update (ESU) on both SP1 and SP2 regardless of ESU subscription.

Another fix that immediately fixed the vulnerability is updating Group Policy Object (GPO) setting that targets specific functions on all computers within the Windows network, otherwise valued as “RestrictDriverInstallationToAdministrators = 0.” However, the setting is not recommended for intermediate users as they may face other problems.

The forums seemed quite furious on Microsoft as the company has not been able to come to a stable solution after all that time but restricted other settings that give access to it. Which seems entirely unreasonable, but then again, those setting may uncover other vulnerabilities at the current state and the developer team should be on a fix soon.

Various network printers may require a different level of access system and vendors. This makes the whole process non-identical in some ways, as the pairing system also varies. This leads to difficulties while patching up the system with drivers and GPOs applied to PCs. V4 printer driver is best known for its security and other versions of Windows as like Windows Server 2008 R2, and extended support said: “customers are required to purchase the Extended Security Update.” One network admin said he doesn’t know if this “breaks the printer nightmare fix.” But their >3,000 customers are waiting to print documents.

Sub registry subkey for the fix remains at “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print” while value is “RpcAuthnLevelPrivacyEnalbed” for “REG_DWORD” data type.

In the former update, the default behaviour was 0, but currently, after the September update, it came to 1.


bottom of page