Jump to content

Recommended Posts

Posted

Spent all day Thursday wondering why our logons suddenly became so slow and it's all to do with the printer issue :(

 

How vulnerable are we if we change the REG key to allow non-admins to install printer drivers?

An attacker would have to be on your network to run any malicious code? - ie it would have to be a pupil/staff member if you don't have any means of getting on your network from the outside?

Posted

So there is adding the drivers to the File Repository - Use pnputil

Then there is adding them to the Spooler. I can't remember where I posted this but this should work.

 

The mapping needs to occur in the user context. GPP Should work or Printer Connections in a GPO and be quicker as the drivers are pushed out via SCCM/MECM.

 

Start-Process -Wait "C:\Windows\System32\pnputil.exe" -ArgumentList "/add-driver `"$PSScriptRoot\HP Universal Print Driver\pcl6-x64-7.0.0.24832\hpcu250u.inf`""
Add-PrinterDriver "HP Universal Printing PCL 6" -Verbose 

 

You can use PowerShell to add in the user context as a logon script. Ideally signed.

 

Add-PrinterPort 192.168.1.123
Add-Printer -Name "HP Printer" -DriverName "HP Universal Printing PCL 6" -PortName 192.168.1.123

 

I would not reverse the secure default in the registry given the amount of Ransomware attacks education has had in the last 18 months.

Posted

Has anyone got this to work when connecting to the Shared Windows Printer rather than direct to the print device? @Mustang reported they can only get it to work for Type 4 drivers - unfortunately we only have type 3 in play :(

 

To be clear what we are looking for is a way to connect to a shared Windows Printer without the client trying to download and install (therefore demanding administrator credentials) the drivers from the server.

Posted (edited)
Has anyone got this to work when connecting to the Shared Windows Printer rather than direct to the print device? @Mustang reported they can only get it to work for Type 4 drivers - unfortunately we only have type 3 in play :(

 

To be clear what we are looking for is a way to connect to a shared Windows Printer without the client trying to download and install (therefore demanding administrator credentials) the drivers from the server.

 

Not yet - very annoying! I've tried preloading drivers but it seems to make no difference, I've just been reading this:

which might explain why it's not working... I'm not sure. Still fighting to get this working with shared printers, I think i'm going slightly mad

Edited by ThomL
Posted (edited)

Hang on. Something just came back to me from NT/95 days. Lets add some PowerShell to it and see what happens...

 

 

On the client computer:

 

Having already added the printer driver and knowing its "name"

 

add-printerport -name "\\fqdn of your print server\printersharename"

 

Add-Printer -Name "ShareName" -DriverName "DriverName" -PortName "\\fqdn of your print server\printersharename"

 

 

 

Basically we are creating the printer on the client as though it was a local printer, but using the network share on the server as the "local" port. This bypasses point and print. If memory serves this is how we had to do it in days before point and print.

 

I've done it against a couple of different printers / print devices and it seems to work, Papercut also picks up the job and logs it correctly.

Edited by psydii
  • Thanks 2
Posted
Hang on. Something just came back to me from NT/95 days. Lets add some PowerShell to it and see what happens...

 

 

On the client computer:

 

Having already added the printer driver and knowing its "name"

 

add-printerport -name "\\fqdn of your print server\printersharename"

 

Add-Printer -Name "ShareName" -DriverName "DriverName" -PortName "\\fqdn of your print server\printersharename"

 

 

 

Basically we are creating the printer on the client as though it was a local printer, but using the network share on the server as the "local" port. This bypasses point and print. If memory serves this is how we had to do it in days before point and print.

 

I've done it against a couple of different printers / print devices and it seems to work, Papercut also picks up the job and logs it correctly.

I'll try this - does mean I'm going to need to code something to deploy printers to users, or rather allow staff to deploy printers as standard users; staff roam all over site with their laptops, previously Point and Print allowed them to add printers as they needed based on their physical location. Follow me printing would be much easier than this...

Posted (edited)

Unless someone comes up with something better, this really feels like its going to be a complete rebuild of the print system here :(

 

Hoping Papercut universal driver will save us some of the pain, but the transition from GPP deployed and self-service point and print printers to a scripted deployment is going to be rough. Particularly if we need to change drivers...

 

UPDATE:

the add-printerport command is superfluous, the add-printer command creates the local port if it doesn't already exist.

 

also I've had trouble tidying up afterwards. After the printer is removed, the spooler seems to requrie restarting before the port can be removed. Guess we'll have to do that with a gpo loopback / machine script triggered at logoff.

Edited by psydii
Posted

I didn't test on a domain device.

You may be able to map at computer level for desktops.

 

As long as the drivers are install or users have a way of installing them (available package in SCCM) mapping will still work.

 

You never know this might trigger a paperless strategy :D .

Posted (edited)
Thanks all. Very surprised by this change, I'd imagine there's a high proportion of enterprise using point and print?

 

I've put the 0 reg key in place for now, but I hate putting workarounds in place which are against advice.

 

I already have PaperCut Print Deploy on my to-do list, looks like it just moved up higher!

 

 

So, how do you do it?

Can you provide the steps

Edited by chipax
Posted
Currently deploying printers through powershell script.

Just wondering if editing the registry off and on during deployment work?

 

I doubt it.

 

 

I'm just going to TCIP the printers on a computer policy for now and walk away. It's taken too much time and effort that I can't be bothered with it anymore.

  • Thanks 1
Posted
Currently deploying printers through powershell script.

Just wondering if editing the registry off and on during deployment work?

 

I am working on other things so haven't looked into it, but restarting spooler after updating the reg key might help.

Posted
For those people using PaperCut, is using Print Deploy (or even Mobility Print) an option? Seems to allow for GPO deployment and automatic install of printers.
Posted
For those people using PaperCut, is using Print Deploy (or even Mobility Print) an option? Seems to allow for GPO deployment and automatic install of printers.

 

It's very barebones in it's free version. We deemed it not suitable as there was no way to limit printers to certain rooms (Unless you had each room on certain IP range). It would be fine for our follow me spools, rubbish for everything else.

  • Thanks 1
Posted
It's very barebones in it's free version. We deemed it not suitable as there was no way to limit printers to certain rooms (Unless you had each room on certain IP range). It would be fine for our follow me spools, rubbish for everything else.

 

Okay thanks. Will look at the TCP/IP route instead.

Posted

So Kyocera have Type 4 drivers that get around this issue - However I can't seem to use them with a followme queue on papercut.

 

Papercut state that all the printers involved in the followme need to be either type 3 or type 4, so I made an entirely new followme queue & printer - Jobs can go directly to the printer fine, but if I go via the followme queue, they don't appear on the release screen on the MFD - Annoying! (One for support)

 

For now I've put the bypass registry key in, I don't want to do this long term tho.

Posted (edited)

If you made a separate follow me queue using an existing device from your type 3 queue, you may need to adjust the settings for the release on the Devices section of Papercut to include both virtual queues. I also set "jobs will be directed to" setting to "This device (multiple queues to support different operating systems)" (step 3 of https://www.papercut.com/support/resources/manuals/ng-mf/applicationserver/topics/device-mf-copier-integration-release-multiple-operating-systems.html). Once I was done testing, I reverted the settings back to a single virtual queue for those devices, changed the virtual queue driver to the Kyocera v4 (after clearing all pending print jobs from the queue), then changed the individual printers to the v4 driver (all driver changes from printmanagement.msc on the server).

 

I've had a couple laptops so far that did not "update" the information from the print server and still were trying to use the v3 driver, but most automatically picked up the change. To avoid this issue, you may want to rename the find me queue if you push it by GPO (removing the old one from the policy and adding the new one, which would force the clients to query the server about the "new" queue and use the right driver). If users manually add/remove the printer, deleting and re-adding the printer fixes any that didn't update.

 

 

Also, regarding Papercut Print Deploy, I have not used that (just GPO deployed printers and AD-published printers for Windows, and Mobility Print for Chrome/iOS), but the Known issues section of their help site (PD-1112 under https://www.papercut.com/support/known-issues/#mf ) mentions the windows update causes the admin prompts when using Print Deploy (unless you set the registry key to the insecure setting), so that does not appear to be a working alternative (They suggest Mobility print at the bottom).

Edited by mari0bros
correct section, add print deploy info
Posted (edited)
So Kyocera have Type 4 drivers that get around this issue - However I can't seem to use them with a followme queue on papercut.

 

Papercut state that all the printers involved in the followme need to be either type 3 or type 4, so I made an entirely new followme queue & printer - Jobs can go directly to the printer fine, but if I go via the followme queue, they don't appear on the release screen on the MFD - Annoying! (One for support)

 

For now I've put the bypass registry key in, I don't want to do this long term tho.

 

Probably not related, as this has fallen at a time when I've migrated our print server from 2012R2 to 2019 with PaperCut had the same issue where certain MFDs just would not work with the follow me queue using the latest drivers from Konica. Jobs would go to the queue, show up in the release window on the MFD but just would not print - just disappear. I found switching to their Universal Drivers seem to resolve the issue. Had me pulling my hair out. It may not be related to all this, but give it a go?

 

Pete

Edited by FragglePete
Posted

Also, regarding Papercut Print Deploy, I have not used that (just GPO deployed printers and AD-published printers for Windows, and Mobility Print for Chrome/iOS), but the Known issues section of their help site (PD-1112 under https://www.papercut.com/support/known-issues/#mf ) mentions the windows update causes the admin prompts when using Print Deploy (unless you set the registry key to the insecure setting), so that does not appear to be a working alternative (They suggest Mobility print at the bottom).

 

Thank you for this, saves me troubleshooting Print Deploy. We already have the Mobility Print client deployed to all computers (or at least laptops from memory) so will test this on Monday.

Posted

I don't understand why all the reports of prompts to trust the driver / printer server. Isn't the driver already installed?

I've only deployed the update to a few test VMs and will be pushing it to a few production machines tomorrow. I sent an email to staff giving them a heads up.

 

In my testing with the VM GPP in users preferences worked as long as the run in user context was not checked.

 

I also preload the drivers with these commands. I do this in my deployment task sequence and it appears to work via PDQ. I'm sure a startup script or other tool will work too.

 

rundll32 printui.dll PrintUIEntry /in /n"\\printserver\printer" /q

rundll32 printui.dll PrintUIEntry /dn /n"\\printserver\printer" /q

Posted
If you made a separate follow me queue using an existing device from your type 3 queue, you may need to adjust the settings for the release on the Devices section of Papercut to include both virtual queues

 

ahhh that'll be it, thank you. I always had it in my head that the devices bit was only about the "on device" stuff so didn't think the hold queues would be there as well. Thanks, that'll help me get rid of the bypass fix on 99% of our machines (And manually install the user mode 3 drivers on the 2 repro PCs that need them!)

Posted
I wouldn't fallback to the registry setting as you will be vulnerable to the latest CVEs.

 

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36958

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34483

 

The print nightmare could go on for quite some time.

 

Ok after much pain. Tried on a standalone VM with the latest patches. Years ago I did this to improve GPP mapping of printers.

This can be contained in a SCCM package.

 

$drivers = Get-ChildItem '$PSScriptRoot\HP Universal Print Driver' -Recurse *.inf | Select-Object -ExpandProperty FullName
foreach ($driver in $drivers){
Start-Process -Wait "C:\Windows\System32\pnputil.exe" -ArgumentList "/add-driver `"$driver`" /install /subdirs" -NoNewWindow
Add-PrinterDriver "HP Universal Printing PCL 6" -Verbose}

 

Package contents would be

 

Script - deploy.ps1

Directory - "HP Universal Print Driver"

 

Then Create a package in sccm with command line

 

powershell.exe -ExecutionPolicy Bypass deploy.ps1

 

The default for Driver Isolation is Shared so all users should be able to use the driver. It may not be necessary to go through every inf file. The HP Universal Driver is a type 3 so not sure where the type 4 requirement has come from.

 

1. Add to driver store using pnptuil.

2. Add as a Printer Driver using Add-PrinterDriver

 

Was battling with this last week and trying to keep up with the updated updated guidance (which still seems to come down to "don't touch the reg keys") - this looks to be the neatest option I've seen.

 

Anyone had any further flashes of inspiration since? Been off the last few days so just catching up.

Posted

Okay so just having a play with this now - I can install the driver on the client machine, (based on the script by @free780, thanks!) verify that's its there in the local print management, however the printer still fails to map - with the same "specified driver was not found..." error. Have I missed something? Point and Print is disabled so shouldn't be affecting things...

 

Cheers,

Stephen

Posted

On the CVE for PrintNightmare it states about the fix prior to them releasing the Update. On the fix it lists 2 workarounds prior to the update to protect against the vulnerability:

Option 1 - Disable the Print Spooler service - Obviously not an option if you want to print!

Option 2 - Disable inbound remote printing through Group Policy: Computer Configuration / Administrative Templates / Printers - Disable the “Allow Print Spooler to accept client connections:” policy to block remote attacks.

 

So if I am thinking correctly, by disabling the GPO option, then you could apply the RestrictDriverInstallationToAdministrators to 0 and although it opens the vulnerability you are also protected as you have applied the GPO to disable client connections?

 

Or are we concerned that users may install a rogue printer driver from the server/a server? But hopefully this is very unlikely if the existing point and print restrictions to limit which servers are trusted is in place?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...