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?
Dave McGill 51 Reputation points

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.
Erik Calzada 11 Reputation points

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 186 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?
Erik Calzada 11 Reputation points

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

PaulB 11 Reputation points

2021-08-13T14:17:43.393+00:00

This is a nightmare. We have a Farm of 9 servers and 300+ users. Only printers we can get working correctly are Konica using their universal driver.
We have several overseas offices that just cannot print. We don't use point and print . Xerox, Canon, Epson printers all jacked up after the latest update
Please sign in to rate this answer.

1 person found this answer helpful.
Sandrine Marquis 151 Reputation points

2021-08-13T14:41:53.833+00:00

The last version of the universal konica minolta drivers works for me too.

I know it's not a permanent fix. but if you add manually the drivers to the remote computers locally it will work without prompting the user.

I also discovered, some drivers, if you erase the old version of the drivers from the remote computers, it will install the newer version without prompting the user also.

PaulB 11 Reputation points

2021-08-13T15:27:46.073+00:00

We have several Xerox machines. T got the latest Global driver and installed everywhere, no luck with that on yet. Same issue. Keeps asking for credentials. Havent even got to Canon printers yet

Sandrine Marquis 151 Reputation points

2021-08-13T15:44:48.87+00:00

Sorry to read this. I have issues with lexmark also. no drivers seem to work.,

PaulB 11 Reputation points

2021-08-13T16:16:43.437+00:00

I'm going to roll back the updates for now. This one has caused a total cluster *
Sign in to comment
MichaelCMetal 21 Reputation points

2021-08-13T18:41:29.467+00:00

I read through all of this and tried a lot of different ideas. Then v4 drivers were mentioned as being a fix. I can confirm now, for both our Konica Minolta BizHubs, and our Kyocera EcoSys and KX series copiers that this is a working fix. Keeping the restrictions on for security, as well as still getting GPO printers pushed without issue.
Please sign in to rate this answer.

1 person found this answer helpful.

0 comments No comments
Sign in to comment
PaulB 11 Reputation points

2021-08-16T12:12:22.63+00:00

Curious. What Build of Server is everyone on? I'm Server 2016 1607
Please sign in to rate this answer.

1 person found this answer helpful.
MichaelCMetal 21 Reputation points

2021-08-16T13:27:36.747+00:00

My primary print server is 2012R2. Most of the site DCs are also 2012R2. There are a few which are 2019. This is happening across the board.

GonEdw90_IT 2021 51 Reputation points

2021-08-16T15:44:58.217+00:00

We're on Windows Server Standard 2016
Sign in to comment
Sandrine Marquis 151 Reputation points

2021-08-12T12:02:35.123+00:00

You're probably right. I was thinking people were complaining after the update and other were not because the update wasn't applied yet. It's probably the driver. Now the problem is who to fixed this when the problem comes from différents drivers... if this is the latest version of those specific drivers.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
Sandrine Marquis 151 Reputation points

2021-08-13T12:35:50.117+00:00

I've been doing some testing using a desktop computer and a brand new AD user...
I discover something else.
I have two print server.
I have two printer using the same driver on two different server and one works and the other doesn't.
both are shared and list on AD. both using version 3.8.0.0 of the konica minolta universal driver.
If I open the windows explorer and type \server1 and right click the printer "A" and choose connect, it's installing no problem. and if I try another one of the printers it might not work.
If I open the windows explorer and type \server2 and right click the printer "B" and choose connect, it's prompting me for user and password and if I try another one of the printers it might work.
I can't find the correlation between does who are working and those who are not.

If I can't install them manually, my GPOs won't work for sure.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment