PrintNightmare & Point and Print

UPDATE: Part II here: https://www.anthonyfontanez.com/index.php/2021/08/16/printnightmare-point-and-print-part-ii/

UPDATE 2: Added additional information about Package Point and Print

UPDATE 3: The Security Baseline for Windows 11 includes an updated SecGuide.admx template that can natively control the new registry item.

Printers suck. We all know it. PrintNightmare has been through a few evolutions as of late. Now, as part of the 2021-08 Cumulative Update for Windows 10 (KB5005652—Manage new Point and Print default driver installation behavior (CVE-2021-34481)), unless you go and create/set a specific registry item, Point and Print will now be locked down and require administrative rights to install drivers from any print server. My assumption is that this is to catch all of the Point and Print misconfigurations out there once and for all. While the vulnerabilities are still present on the system, this may help mitigate compromise, however, you may find yourself with many Help Desk tickets for printer installations. In this post, I’m going to go over a “proper” Point and Print configuration, that will allow you to continue to let users without admin rights install printers, along with some additional “best practices” that I would consider putting in place if not already.

Point and Print Configuration

Point and Print allows users to install shared printers and drivers easily by downloading the driver from the print server. These settings can be found in Group Policy under “Computer Configuration\Policies\Administrative Templates\Printers”.

Point and Print Restrictions Group Policy Setting

The above shows how I have Point and Print configured in my lab.

  • Users can only point and print to “print.ad.ajf8729.com”
  • Elevation prompts are bypassed for driver installations/updates

Seeing the values set in the registry via PowerShell:

This is typically seen as an insecure configuration, due to bypassing the UAC prompts. But since the trusted server list is configured, this will block any attempts to point and print to printers shared on an untrusted server with the following message, regardless of local admin privileges:

Attempting to connect to a printer on an untrusted server

Enter the 2021-08 Cumulative Update…

After installing the 2021-08 Cumulative Update for Windows 10, the above policy will get thrown out the window, due to the introduction of a new registry item. If this item is not created, set to 1, or undefined, the Point and Print policy is essentially ignored, and admin rights will be required to install any print drivers. In order to counter this, the new item must be created, and set to 0.

This item can easily be configured via Group Policy Preferences, ConfigMgr Configuration Item, or Intune Proactive Remediation:

Group Policy Preference configuration
ConfigMgr Configuration Item
ConfigMgr Configuration Item Requirement

Intune Proactive Remediation: please see https://github.com/windows-admins/Intune/tree/main/Proactive%20Remediations/PrintNightmare for sample scripts.

UPDATE: The Security Baseline for Windows 11 includes an updated SecGuide.admx that has a native setting to control this new registry item. It is located under “Computer Configuration\Administrative Templates\MS Security Guide”.

Limit print driver installation to Administrators

Any of these configurations will allow the previously configured Point and Print policy to continue to function as expected after the 2021-08 Cumulative Update is installed.

Package Point and Print

After some additional troubleshooting with Johannes in the WinAdmins Community, we discovered that he did not have Package Point and Print settings configured, where I did (mentioned in the next section). While I was not 100% sure how that setting worked initially, I had configured it in tandem with the regular Point and Print settings. After doing some more research (Point and Print with Packages & Package-Aware Print Drivers), it seems like it comes down a setting in the INF file. You can see which drivers are package-aware in the Print Management console, under Drivers -> “Packaged” column:

Print Management Console – Drivers

Combining the normal Point and Print settings with the Package Point and Print Settings is simple; it’s a single GPO setting to enable it and configured trusted servers:

Package Point and Print – Approved Servers

Configuring this setting is highly recommended if you are configured regular Point and Print as I described earlier.

Additional “Best Practices”

Along with the above configuration, there’s a few other settings I would include in your overall printer configuration policies as a baseline.

Harden your trusted print servers

If you go the route of not requiring elevation to install printers from trusted servers, the print server itself becomes the sensitive target. Hardening the server becomes critical to protect your infrastructure.

  • Review who has administrative rights to these servers, how their firewalls are configured, and what is installed on them.
  • Enable print driver isolation on every driver possible to help prevent bad drivers from taking down the entire system.
  • Ensure the servers are as up to date as possible.
  • Utilize the PrintBrm utility to backup your print server configurations, and to move to a new operating system if necessary.
Additional settings under “Computer Configuration\Policies\Administrative Templates\Printers”

  • “Allow Print Spooler to accept client connections”
    • This should be set to Disabled on all endpoints that are not print servers, to ensure that clients cannot connect to printers shared from them. Ideally, inbound File/Print sharing firewall rules are blocked/disabled/restricted on endpoints; but if not, this is an easy stopgap until endpoint firewall rules are better configured.
  • “Package Point and print – Approved Servers”
    • This is similar to the standard Point and Print setting, but for “packaged” drivers. Configure this to the same trusted server(s) as the standard Point and Print trusted server(s). See the above newly added section for further details.
Disable the Print Spooler service on Domain Controllers/Member Servers

The Print Spooler service should ideally be disabled on all servers that do not require it. Disabling it on Domain Controllers will stop automatic pruning of stale printers published to the directory, so be prepared to do this manually or via script if necessary. Disabling the service can easily be done via Group Policy Preferences:

Group Policy Preference to disable the Spooler service
Firewall Rules

In the long term, endpoint firewall rules should be configured to prevent File/Print Sharing where necessary. While I intend to go into much more depth about firewall configurations in a later post, here is a quick glace at a bare-bones basic endpoint firewall policy for a client machine:

Windows Firewall configuration for the Domain Profile
Windows Firewall customization for the Domain Profile
Basic firewall policy for a user-facing endpoint

The above policy only allows SMB access from one host, and RDP from a single subnet. Local firewall rules configured on the system itself are not applied, meaning everything must be configured in policy. This is a very secure configuration, and can take a bit of work to get to. Be on the lookout for a future post going into greater detail about this.

11 thoughts on “PrintNightmare & Point and Print”

  1. https://www.reddit.com/r/sysadmin/comments/pa0lup/kb5005652/haa4r4k?utm_source=share&utm_medium=web2x&context=3

    Quote:
    We asked premier support for more details on this. This is my question and their answer: “If we change the “RestrictDriverInstallationToAdministrators” to 0, will we still be vulnerable to remote exploits from ANYWHERE? Or, just from the list of “these servers”? Or, not at all, just vulnerable to local exploit?
    Yes, if you change RestrictDriverInstallationToAdministrators=0 you will still be vulnerable to remote exploits from anywhere.”

    If true then a approved list will not help when RestrictDriverInstallationToAdministrators=0 ?

    1. The vulnerability is still present no matter what; setting RestrictDriverInstallationToAdministrators to 0 just allows existing Point and Print configurations to continue to function. The “trusted” print server(s) still need to be secured and hardened as normally. My solution is intended to balance security with usability. As long as your configured server(s) are secured and only trusted drivers loaded on them, I feel that it is a good balance. Using V4 drivers is an even better solution as the clients do not need to download a driver anymore, and Point and Print is no longer used.

      Edit: The 2021-09 CU appears to have an actual “fix”, but either way, Point and Print restrictions is still a good policy to implement.

  2. I’ve been stuck with these settings on my lab. I have added one internal print server in the policy, yet my test users are able to point and print to servers not listed in the policy.

    Have you guys seen this behavior?

    -eg

    1. Are you specifying an FQDN or a short name? FQDN is required. Also, are you setting it in both point and print, and package point and print, depending on if the drivers are package-aware.

      1. I’m using FQDN.

        For kicks I added to the same policy to the Users side as well and same behavior. I only have one print server (PRINT1-XXX-XX.mydomain.com), yet my test users are able to point and print to other servers.

          1. Good question. Yes, drivers were previously installed on those test VMs.
            I’m using packaged Type 3 drivers on the print server.

            1. I think if the drivers were previously installed, they might not need to be downloaded, and the printer connection will still function, but if the server isn’t in the trusted list, it should still be blocked. Not quite sure what might be going on.

          2. I just did my test on another VM, no print drivers at all. The policy is applied as I can see it in rsop; I rebooted the VM, even though it doesn’t need to be. Yet, I’m still able to point and print from a server not on the policy list.

Comments are closed.