How can we allow the installation or update of the printer drivers with Group Policy Objects without the user being administrator after updating kb5005033?

Sandrine Marquis 151

The update kb5005033 broke the GPOs I use to install/update printer drivers on my domain.
Now users are prompt to enter the credentials of an administrator to install/update their printer driver.
I have more than 400 computers use by as many users in more than 20 locations.

here's the information of the update in question : https://support.microsoft.com/en-us/topic/august-10-2021-kb5005033-os-builds-19041-1165-19042-1165-and-19043-1165-b4c77d08-435a-4833-b9f7-e092372079a4

I use the following documentation to try to allow the users to install drivers from our reconsize servers with no success.. https://support.microsoft.com/en-us/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872

I'm out of options. any idea?

Matthew Ware 6 Reputation points

2021-08-12T22:22:50.93+00:00

I enabled point and print restrictions to my print server, and now end users are able to click the Update Driver button themselves without a UAC prompt.
Sandrine Marquis 151 Reputation points

2021-08-13T12:36:51.47+00:00

can you share with us what exactly you've done to enable this properly?
Anonymous

2021-08-13T13:26:38.117+00:00

Yes, but my users get their printers via login script, so they never see the prompt as it is done by applying the GPO before they get a desktop screen. This is a major issue for us and created mass havoc. Even if they try to install the printer manually from approved print server via point and print, they get a prompt for admin credentials to install the drivers. The only workaround I have figured out at this point is to remove KB5003033. MICROSOFT PLEASE RESPOND AND FIX!!!!!!
John Carr 76 Reputation points

2021-08-13T18:53:46.353+00:00

I've been making "some" progress on this, although its painful and annoying.

I went to our print server and updated every printer to use V4 / Type 4 drivers. But that didn't seem to totally fix the issue. Users could now click "add printer" and browse our AD and get a printer. But we Deploy printers via GPO.... Those were still messed up.

On one printer that had an updated driver, I undeployed it. GPUPDATE /FORCE on a workstation. The printer still showed on the workstation, but faded out. Then I deployed the printer to the GPO of that workstation. GPUPDATE /FORCE again. The faded printer was still there. I stopped the Print Spooler on the workstation. The faded printer was still there. Started the spooler. Waited a minute or so, that faded printer lit up. clicked it and the "Device driver unavailable" message was gone. User could print.

HOWEVER! I looked at the Printer Properties of the object, and got prompted to install Point and Print drivers. I declined. Maybe I should have agreed. But user could still print.

I'm not sure if this is a solution or a work around. Definitely not a solution for 500 users.
A. De Decker 21 Reputation points

2021-08-16T06:44:16.57+00:00

Reviewing kb5005652 will offer some solutions.
One of them is to deploy a new Registry key which will UNDO the restriction.
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint
RestrictDriverInstallationToAdministrators = 0 (REG_DWORD)

This way, it will all keep on working the way it was before KB5005033.
BE AWARE. This will also keep the Vulnerability active.
Mark Baines 6 Reputation points

2021-08-16T11:37:35.727+00:00

Do you make this registry addition on the Printer Server or at the user's end (e.g. Local device or Remote Desktop Server)?
Nicholas Nguyen 6 Reputation points

2021-08-16T21:52:17.663+00:00

Add it to your endpoints/user's end. Tried on a printer server to confirm, and you'll basically have to roll out the GPO to add this registry key for multiple devices.

Do follow the mitigations steps outlined in https://support.microsoft.com/en-us/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872, but you will still be vulnerable.
Wardell, Craig 6 Reputation points

2021-08-19T13:50:38.237+00:00

This worked for me. Rolled the registry tweak out via GPO.
We will be using this fix until we change the way we install printers.
Maybe via papercut MF going forward.
Anonymous

2021-08-27T17:15:28.66+00:00

Since KB5005033 caused some issues with our print servers requiring admin creds on installs we applied the following that allows users to install new printers from our print server without admin creds then we applied a scheduled task right after install to change the reg edit back to requiring admin creds on non domain printer installs and keeps the printer vulnerability fix applied.

Create a GPO
User > Preferences > Registry and add the new registry key "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" RestrictDriverInstallationToAdministrators as a DWORD value of 0

Add these Reg Keys as well to same location:
DWORD UpdatePromptSettings /v 0
DWORD NoWarningNoElevationOnInstall /v0

Scheduled Task will toggle admin creds required after printer install from print server; run as a cmd
/c reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" /v RestrictDriverInstallationToAdministrators /t REG_DWORD /d 1 /f

Adam Bise 1

I abandoned my print servers and deployed local queues via SCCM

[Driver App - System Context - No Deployment]
Install script:

cscript c:\windows\System32\Printing_Admin_Scripts\en-US\prndrvr.vbs -a -m "Xerox GPD PCL6 V5.810.8.0" -h "%~dp0UNIV_5.810.8.0_PCL6_x64_Driver.inf" -i "%~dp0UNIV_5.810.8.0_PCL6_x64_Driver.inf\x3UNIVX.inf"

Detection:

cscript c:\windows\System32\Printing_Admin_Scripts\en-US\prndrvr.vbs -l | findstr /c:"Xerox GPD PCL6 V5.810.8.0,3,Windows x64"

[Port App - System Context - No Deployment]
Install script:

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\Prnport.vbs" -a -me -r v1_10.10.10.10 -h 10.10.10.10 -o raw
netsh advfirewall firewall set rule group="SNMP Trap" new enable=Yes

Detection:

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\Prnport.vbs" -l | findstr /c:"Port name v1_10.10.10.10"

[Queue App - User Context - User Deployment - Dependency: driver and port apps]
Install script:

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\Prnmngr.vbs" -a -p "HR Printer" -m "Xerox GPD PCL6 V5.810.8.0" -r "10.10.10.10"

Detection:

cscript "C:\Windows\System32\Printing_Admin_Scripts\en-US\Prnmngr.vbs" -l | findstr /c:"Printer name HR Printer"

Kind of crazy to just abandon our print servers but at least now we have a secure and workable foundation to migrate to.

Darius Peterson 1 Reputation point

2021-09-02T12:39:53.733+00:00

I have a creative way to do it in SCCM--this is for a single printer. It basically migrates the Add Printer function to software center. I wrapped the powershell script in winforms for a nice user friendly feel, and even used an older way to add printers that can be wrapped in VBscript or any other language.

PDF describes how to test it and deploy it--change the txt file to a .ps1 to use it.

128715-migrate-printing-to-software-center-smallsize.pdf

128698-fulladdprintcode.txt
Filip Svoboda 1 Reputation point

2021-09-02T17:10:04.563+00:00

I prefer a more flexible setup in the domain, at least this one. It's a bit more secure :D

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint]
"Restricted"=dword:00000001
"TrustedServers"=dword:00000000
"ServerList"=""
"InForest"=dword:00000001
"NoWarningNoElevationOnInstall"=dword:00000001
"UpdatePromptSettings"=dword:00000002
"RestrictDriverInstallationToAdministrators"=dword:00000000

and open in startup script
explorer \pathtoprinter
User#29882 16 Reputation points

2021-09-03T18:19:26.04+00:00

This has me wondering, why does Microsoft not fix the vulnerability in the Print Spooler instead of blocking users from installing print drivers?

Or is this only a temporary mitigation, and we will see an actual fix for the print spooler at a later date?
Gary Smith 121 Reputation points

2021-09-08T14:34:26.72+00:00

Seems the reg value of 1 breaks some of my connections (2x are to a 2016 box). The others stay (all 2008 r2) valid after the reg value 0, reboot or gpupdate and reg value of 1.
Any further fixes?

I see its also affecting server 2019 RDS.. Any pointers for this?

Thanks
js2010 191 Reputation points

2021-09-23T14:56:48.91+00:00

Beware of the new RpcAuthnLevelPrivacyEnabled setting turned on by default on servers in September. This may break some printing (Osx) (especially if you haven't patched clients since January).

https://support.microsoft.com/en-us/topic/managing-deployment-of-printer-rpc-binding-changes-for-cve-2021-1678-kb4599464-12a69652-30b9-3d61-d9f7-7201623a8b25
Dooley CIV Brent 1 Reputation point

2021-11-01T15:05:40.907+00:00

Testing this solution in our environment which is Windows Server 2012/2016 and Windows 10 1909/20H2. We created the SCCM package but its not mapping the printer for user. Its installing the printer driver but even after a restart the printer is not mapped for the user. All of our printers are network printers on the print server(s). Looking through this is running as admin so SYSTEM context and yes I see the script is suppose to add the printer per the computer, so all users. But its not working for network based printers. Network based printers on a print server have always been per user.
'
Anyone else seeing this same issue.
Lamar McDonald 1 Reputation point

2022-05-12T18:13:52.517+00:00

I'm having the same issue. We have tested the registry edit
(HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint)
RestrictDriverInstallationToAdministrators = 0 (REG_DWORD)
DWORD UpdatePromptSettings /v 0
DWORD NoWarningNoElevationOnInstall /v0

The edit is working on all the users we've tested. However, does the registry edit open up a hole for the Print Nightmare exploit? We disabled the domain policy that allowed users to install printers due to the Print Nightmare exploit. Are we now putting our environment at risk again?
Anonymous

2022-05-12T18:22:38.06+00:00

Hey Lamar,

Good question which is why I added the scheduled task to run after. This scheduled task should be added to the GPO and it will re enable the exploit so you are protected. Basically the reg key makes it able for the user to install the printer when that action is taken and renables the security to protect against the printer nightmare.

Scheduled Task will toggle admin creds required after printer install from print server; run as a cmd
/c reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" /v RestrictDriverInstallationToAdministrators /t REG_DWORD /d 1 /f

41 answers

CharlesFraser-7567 11 Reputation points

2021-09-23T14:53:28.413+00:00
The "Manage new Point and Print default driver installation behavior" basically boils down to three options, as posted in this Microsoft support article - https://support.microsoft.com/en-us/topic/kb5005652-manage-new-point-and-print-default-driver-installation-behavior-cve-2021-34481-873642bf-2634-49c5-a23b-6d8e9a302872

If you set "RestrictDriverInstallationToAdministrators" as not defined or to 1, depending on your environment, users must use one of the following methods to install printers:

- Provide an administrator username and password when prompted for credentials when attempting to install a printer driver.
- Include the necessary printer drivers in the OS image.
- Use Microsoft System Center, Microsoft Endpoint Configuration Manager, or an equivalent tool to remotely install printer drivers.
- Temporarily set RestrictDriverInstallationToAdministrators to 0 to install printer drivers.

Granting administrator permissions to a standard user or setting the "RestrictDriverInstallationToAdministrators" registry key to "0" are not the most secure options to protect your user community, and not everyone has access to Microsoft System Center, Endpoint Configuration Manager, or an equivalent tool, so that just leaves "including the necessary printer drivers in the OS image".

Windows has a built in tool (since Vista) to help install printer drivers to the local Windows Driver Store called "PRNDRVR.VBS" - you can find information on how to use it here: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc754632(v=ws.11)

I used a batch file to install printer drivers on a user's system so that when they map a network printer (by GPO or through the add printer wizard) they won't be prompted for administrator credentials because the driver will already exist in the local Windows Driver Store. The batch file looks like this:

@Echo off
rem Canon imagePROGRAF 605
c:\windows\system32\cscript.exe %windir%\system32\printing_admin_scripts\en-us\prndrvr.vbs -a -m "Canon iPF605" -v 3 -e "Windows x64" -h "[UNC path to the driver folder]" -i "[UNC path to the INF file inside the driver folder]"

There are 3 caveats though:
1. The driver name used in the -m command of the batch file has to match the name listed in the driver INF file
2. The driver you install has to exactly match the driver used by the print queue
3. The batch file needs to be run as the local System account (or some other elevated account)
The problem, where I'm hoping all you smart people can help me out, is that I've run into a print queue that won't install without elevated credentials, even though the driver already exists in the local Windows Driver Store (because I installed it using the batch file). I've confirmed that the driver I'm installing via the batch file is the same driver currently used by the print queue (same driver name, version number, driver date, provider, etc) but no matter how I map this printer (add printer wizard, GPO, using \servername in Windows Explorer and then double-clicking on the shared printer) I am still prompted for administrator credentials to install the driver.

Does anyone have any suggestions on how to get past this?
Was this answer helpful?
Akin Utku 1 Reputation point

2021-09-30T12:15:38.653+00:00

I'm in the same boat as you, nothing works on the YSoft Printer that has to be a share. Direct IP printers you can get around with specifying the driver through PowerShell "add-printer" command. When it's a shared queue it always wants to use the driver on the server, I have no idea how to override this through any command in PowerShell or vbs. Also not sure how you got this to work by deploying the driver to windows driver store as you did, I've had no luck with that at all.

Does anyone know how can you override what driver is used for a shared printer (e.g. \server\printer) preferably within powershell? Basically instead of grabbing the driver from the share, use the designated driver within the windows driver store instead.
The add-printer command does allow you to specify a driver when adding an IP printer, but no such luck with the shared queue which uses the keyword "add-printer -connectioname"

Also is there any way within Intune to deploy a powershell script that runs as the user but with admin privileges? If you could do that, problem solved I guess.

CharlesFraser-7567 11 Reputation points

2021-10-15T15:51:29.393+00:00

I have an update:

According to Microsoft, when a user prints to a network print queue Windows compares the driver it has to the print server driver, updating the local driver if the server driver is newer. it's not actually comparing drivers in the driver store, it's comparing the information under "c:\Windows\System32\Spool\Drivers\x64\3" The same location is compared between local system and print server, and if the print server has a new (not on the client) or newer (modified date is newer on server) driver file than the local (users) system then Windows prompts to install the driver.

What I've been testing, as a workaround, is running Robocopy to copy anything new or newer from the server to the users local system and that seems to work about 60% of the time.

Here's the command I'm using:
robocopy "\print_server\c$\windows\system32\spool\drivers\x64\3" "\user_computer\c$\windows\system32\spool\drivers\x64\3" /e /xo /r:5 /w:5 /njh /njs /np

I've only been able to get this to work when logged into the print server as a domain admin and manually running the command from an elevated command prompt.

CharlesFraser-7567 11 Reputation points

2021-10-15T16:03:51.457+00:00

They limit how many characters you have in a reply.

I read a forum post this morning where someone suggested that all you need to do to resolve this is the following:

use c:\windows\system32\pnputil /add-driver "\server_name\share_where_the_printer_driver_files_exist\*.INF /subdirs to install the device drivers on the users local system, which you can either manually run (yuck!) or push out to your users using a deployment tool (like Ivanti Management Console - aka: LANDesk, or Microsoft SCCM, or anything that allows you to remotely execute a command on a users system)

The caveat to this solution is that if the driver currently installed on your print server doesn't match the driver you're installing for the user you will need to update the driver in Print Management to the new driver.

The issue with that again comes down to the \Spool\Drivers\x64\3 folder comparison. They found that even with the exact same driver that they found that files on the server were showing a newer Date Modified date than on the users system (even though the users originally installed the driver from the server prior to the new restrictions). Their solution was to delete the queue and remove the installed driver from Print Management, then create a new queue using the same driver already pushed to the users, and they claimed that solved the problem.

I haven't tested this yet but I will. I'll update this thread with my results.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

How can we allow the installation or update of the printer drivers with Group Policy Objects without the user being administrator after updating kb5005033?

41 answers

Your answer