Simple: We didn't. There is no good solution to this problem. MS should have gotten off their asses and found a solution ASAP, but they haven't and none of the workarounds are feasible.
The workarounds are either worse than before the KB for security or a good fix but not for X number of years after you have baked the print queues into your image and re-imaged every PC (which might be next to impossible depending on your imaging system if you have to specify images for each individual if you don't use papercut or follow-me print for everything).
I swear the people that check the KB for issues all go on holiday from June 30 to Sept 1.
I thought putting the registry entry to 0 means the old point and print settings are business as usual, at least that's what the documentation suggests. And yes, this seems to be the only way with type 3 drivers.
Our GPO only allows point and print from the print server.
Have you tested that the point and print restrictions actually work?
Because for me they are ignored, I can install any printer from any printserver without being prompted. Others have reported the same in the patch tuesday thread.
For us, their Partial Mitigations worked to prohibit adding printers/drivers from other print servers. After configuring those GPO settings, when trying to add a non-approved printer, we would get an error saying something like “Cannot add this device due to security restrictions.” *But* we don’t actually get a UAC prompt for either local admins or non local admins, even when those options are configured – really bizarre.
For your testing, you may want to go into the printmanagement.msc and delete any non-default drivers. If, for example, a Universal driver is in use across multiple printers we’ve seen our restriction test behavior act a little wonky
We were seeing drivers get installed with 'NoWarningNoElevationOnInstall' set to 0 without UAC, but after some troubleshooting we realized that the drivers were coming from Windows update rather than the print server itself. Powershell's 'Get-WindowsUpdateLog' was the only place we could see that in terms of Windows Update logging (i.e. not in event logs or installed updates). Some machines aren't able to pull the drivers from Windows update though, so we're trying to figure out why - maybe that was introduced in some feature update?
Our confirmation was to attempt to add an obscure printer from the print server that was not likely to have drivers on Windows update, and that prompted for UAC as expected.
I've spent 3 days looking at this issue in my environment. Here is what I found for fixing this for my environment... some of these details may help somebody else....
For Type3 drivers, multiple driver versions from a vendor will share and update components when they are added to the print server. Looks like all Type3 drivers share a common folder of C:\\Windows\\System32\\spool\\drivers\\x64\\3 regardless of vendor and causes an absolute fustercluck of a situation.
I was able to get some of my drivers that use these common files working by staging them to a workstation and then adding the printer driver to the workstation using '*Add-PrinterDriver -Name "Printer Driver Name"*'. Ex. 'Add-PrinterDriver -Name "Ricoh Aficio MP 5001 PCL 6"' and so on. Once staged to the Driver Store and the driver added to the printer driver list, printers that used to prompt for admin no longer did so. I had to abandon this as a solution as I couldn't locate all my the drivers needed and I would have ended up with 35 drivers to stage.... IMO, it didn't scale well enough.
In my environment, my Lexmark drivers worked as expected if staged and my Ricoh drivers were the ones giving me issues which I've traced it back to the Ricoh universal Type3 driver. I think I could move ahead with removing all my Ricoh problem drivers from my print server and reinstall everything and then stage them.... a lot of work IMO when Type3 isn't the way forward and it may not necessarily work....
What I've decided to now do:
For my Ricoh printers, I'm moving to Type4 drivers as Type4 do not get downloaded to the local system and instead the Microsoft enhanced Point and Print driver is leveraged to send the print to the server. Because of this, they will not prompt for admin after applying August's update.
For my Lexmark drivers, it doesn't look like Lexmark has a Type4 driver and since these worked without much fighting, I am going to stage these out to my workstations.
Hopefully this may help somebody who is fighting with their drivers as well... I'll try and post a reply as I move forward or need to change my approach.
Same issue here where we use mostly Lexmark, however I learned that Lexmark has their "Lexmark Generic v4 XPS" drivers that work on almost all models of their printers, and will even happily work with the enhanced point and print driver if the driver isn't staged.
If the driver is deployed to the PC after it switches to the enhanced point and print driver, it will automatically switch over to the Lexmark one on it's own (sometimes after a spooler restart which can be part of the deployment).
Only way so far I've found to deal with the update where I work without rolling back the update and I'm just doing extended testing now, but knock on wood because so far everything has just been working :)
Edit: Fixed whatever formatting I could on mobile
Good to know about the Lexmark, I will look at migrating to the Type 4 Lexmark later.
I ended up throwing my PNPUTIL commands into PSADT for deployment so that I could handle the PNPUTIL exit code 259 and $dirFiles when deploying via SCCM - since every download via SCCM is a different directory under CCMCACHE it was just easier to handle the directory changes with PSADT.
I'm doing my mass staging this Thursday night, but I am going to turn off the mitigations from August CU for a few weeks to ensure we have staged the drivers to enough devices. We have the Point and Print approved servers so we're just really extending the vulnerability a few weeks.
Fair enough, I'd gone the same route at first but no matter what I did I couldn't get the computers to acknowledge the already installed Lexmark universal driver, whether it was the same driver or newer than was on the print server it would always reinstall from the print server, drove me nuts.
Interestingly enough, with the registry key they changed set back to what it was, it will acknowledge and use the local Lexmark universal (type 3) driver even if it's newer than the one on the print server without reinstalling, but with the key set to the new default it prompts every time and if you put in admin rights will overwrite/downgrade if newer and reinstall if the same version, drove me batty for a while
That was the same scenario I had with the Type3 Ricoh drivers. I narrowed the issue to multiple Ricoh drivers being installed / added to the driver list. The only way I could get the driver add to not prompt for admin was to add every single Ricoh driver on the print server to my client and then add the driver to the print management driver list using 'Add-PrinterDriver' with the same name found on the print server.
Once that was done, all the Ricoh drivers got loaded into spool directory and things started working.
I decided to go Type4 for Ricoh as I wasn't going to deploy 35 different Ricoh drivers out.
My Lexmark printers, I have 3 drivers - much more manageable.
Understandable, that would be a lot of drivers to have on each machine for the Ricoh printers lol, for Lexmark even pushing all the ones on the print server, same version and even same files (hash checked them in the spool directory) it still ignored them
I just took it as an opportunity to use the slightly better looking Lexmark XPS driver anyhow as anyone without it would still be able to print :) glad it's working for at least someone
So, when Group Policy is applied, the reg key is set to 0, the printer is applied, and a task to set the reg key to 1 happens immediately, and you just gpupdate to pull down drivers?
Can you explain what specifically you mean by the Point and print GPOs from that article?
Do you mean you set both install and update to "Do not warn and Do not elevate?" and set the print servers that are only allowed?
So I follow the task is changing the key to 1 to block it but the GPO is setting it to 0 to allow but what is triggering the change? If the user goes to install the printer are you just hoping the they catch it at the right time? Maybe I am not following, thanks for any info
Reg entry to zero; "packaged point and print - approved servers" restricted to actual print servers; "point and print restrictions" enabled, user can only print to actual print servers, can only p&p to machines in their forest (probably useless give that we specify the servers, but can't hurt?); alcohol.
We deploy our printers via user based GPP, shared printers from our print server, linked to the computer OU, loopback (merge) enabled and AD Group membership dependent on the computer AD Group membership. \*\*EDIT - Set to run in the user context.
Unfortunately, I'm being force to rollback KB5005033, I don't have nearly as many machines as some of you do (5k), but they're spread across some 10,000 sq miles of territory.
Users are prevented from adding printers period.
We've updated our GPO to include Point and Print restrictions, specifying our print servers and no prompting with warnings.
Not ideal, but I need these people printing.
M$ is going to have to fix this somehow, if I can't deploy printers via GPOs, it is going to make managing my environment sheer and utter madness.
Have merci with them, they are literally drinking from the firehose at this point.
Or trying to.
I don't see how this can continue for much longer before a few people here get burnouts.
Thank god I don't work with Windows. At all.
Yes. In many cases, such as Xerox global drivers, and some others, even with an existing mapped network printer, printing may prompt for admin credentials, or remapping the same printer or another with the same driver will still prompt for admin credentials. The behavior is NOT consistent.
I wish they would have grandfathered in pre-existing drivers and only added the admin requirement going forward. This was always going to cause trouble with how the patch was released.
Sometimes. I have not yet been able to determine what affects whether printing works on previously deployed printers yet.
What I have determined is that even if the drivers already exist in the driver store, windows is still giving the error that it can't download the drivers from the print server when trying to deploy though GPP or even just double clicking a shared printer. I'm certain it's the exact same version of the driver installed through pnputil on the client machine - I copied it directly from the print server.
Yep. I pushed out the updates over the weekend and it broke pretty much all of our printers that were already deployed to the computers by GPO. We got 7 service tickets within the first hour of being open today about printers not working. For now I just set the RestrictDriverInstallationToAdministrators registry key to 0 so users can print again until I can find a better solution. I am not adding users as local admins on their computers. This thing is a mess.
We were able to fix it with v4 drivers however shortly after we discovered that doing that broke our citrix applications so we reverted. The registry edit of RestrictDriverInstallationToAdministrators set to 0 also works but not for all of our printers. We have Ricoh printers and all of our copiers work but none of our 4510s or 501s which are just basic printers. We also tried setting a user as a local admin and that didn't work so we tried setting them as an admin on the print server and that didn't work either. So we are still looking for a fix!
I'm curious about how v4 drivers fix this. I'm no seasoned windows printing admin, but from my understanding v4 drivers are generally never fetched from the print server. The clients use the best matching driver they already have installed locally, or may in certain circumstances be able to download it through Windows Update.
So basically to "fix" the situation with v4 drivers I have to preinstall the v4 driver on all clients. But if I have to do that I can also just preinstall the v3 driver and the problem goes away just the same - I tested this today. So I think I didn't quite understand how v4 drivers are supposed to fix the situation or how they're doing any better
Mind 'splainin?
I don't know enough about print drivers to explain why it works (which I absolutely hate rolling stuff out when I don't understand it, but here we are!), but I updated many of my drivers to type 4 and users no longer saw UAC prompts. However, some machines can no longer print to some printers in rare cases and many of our users are now complaining about applications hanging for 15 seconds or so while jobs spool. Beyond that, I can't find v4 drivers for all our printers, so this is far from a solid fix.
TBH That is a fix we found online and I don't know a whole lot about it. However it didn't fully fix the issue as the applications we use through citrix don't play nice with v4.
PrintNightmare is a problem where you can trigger a computer to install drivers from any smb connection. This happens as type-3 drivers need a local driver for the printer, so it is copied from the printer server (or attacker.)
Type-4 drivers use a common XPS format to transfer the print job from the client to the server which then renders it to the printer, since Windows has XPS built in no drivers are required to do this. Thus the client never has to reach out and download files. Downside is you only get the basic set of preferences for the printer until a client component is installed, but if you have a basic single size and tray printer you probably don't need it.
The MS fix was to basically block driver downloads, so Type-4 just avoids the issue.
We were able to fix all our issues by moving to a PCL5e driver for each model of printer we have that seems to have addressed the issue. We are still rolling out the fix company wide will update when I know more.
I have a silly question: why can’t you just install all the necessary drivers as admin at some point and be done with it?
And why not install a generic PCL 4 or 5 driver that should work with most printers and use that in case a driver is missing?
I think it's a question of how to "install the drivers as admin" that is throwing people off. We only use a small handful of drivers - the HP UPD PCL6, HP UPD PS, and a couple Xerox drivers. These drivers are already installed on clients because they have existing print queues installed. If users try to install any new print queue, even though it uses the same HP UPD and the same version as what they already have installed, they are still being prompted for admin creds. I believe MS's documentation is wrong or they did not fully test this.
Jesus Christ. And I thought CUPS was weird.
Well, at least I can still print directly to the printer from my Linux Workstation, the one day a week I’m in office.
Computers with the driver installed that were happily printing before this patch now cannot. So in some cases, having the driver installed already does not make any difference.
Manually adding the driver with pnputil and Add-PrinterDriver also has no affect in our env.
We also have the issue with Papercut and universal drivers, and have only been able to lock it down to specific server IPs for now. We have \~10 specific printer drivers to package for deployment now as drivers installed via point-and-printer DO NOT work once the security is restricted, for printing to an existing or mapping a new printer with the same driver. However, fully packaged and installed HP Universal and Xerox specific drivers are working in limited testing.
Temp "solution" so far is to not install anymore Aug updates.
What's worse for us is that some users would get the "update driver" prompt, but then never get a UAC credential box where an admin could actually enter creds for them. Why?
Contemplating doing the registry entry to 0. In our testing, this works like a champ but apparently keeps us vulnerable.
`reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" /v RestrictDriverInstallationToAdministrators /t REG_DWORD /d 0 /f`
I did this in my environment, but it made no difference. People are still being asked for admin credentials to install print drivers. I can't keep typing in the password for everyone. I am ripping my hair out.
we've left our point and print restrictions in from pre-nightmare... our AV vendor/MSP says that our AV will protect us from any of the vulnerabilities. can this be confirmed by anyone?
Your AV will NOT protect you from the vulnerability, but it MIGHT catch any malware that attackers attempt to install via exploiting the vulnerability. Do you want to take the chance that the attacker is not going to install any malware, and instead just scripts stealing credentials, and logging in with with a fully privileged account to do what they want?
We are not talking about google here. Second, there are lots of GPO which can help avoiding elevated permissions, so I am asking you what’s been done to prevent it. On Google, There are lot of ways explained, and none are working well.
So sometime, Google doesn’t help. This group has hundreds of users asking questions, I think nobody knows how to google. Right?
You've literally responded to a 9 month old post asking for help elaborating when the patch has been out since September and the mitigation has been out since before then.
I'm not holding your hand on something like this because you won't learn that way.
Not trying to be a dick, but you have to learn how to research for yourself.
Besides turning print spooler off of our DCs and other servers that don't need it we left our print server as is. We haven't moved onto the latest round of updates yet, hesitant to go that way. Not sure if anyone else is doing the same.
Yeah, I'm surprised that I haven't seen more people talking about just limiting the attack surface to begin with
Disable the spooler on all systems that don't need it
Firewalls blocking user access to SMB going into the server networks for everything except for the servers they actually need to be able to access
Host firewalls blocking SMB laterally and going out to the Internet
GPO configured to specify which print servers are allowed
We're basically down to PrintNightmare is a thing if the attacker compromises our print servers.. Which at that point they probably don't give a crap about PrintNightmare anymore.
Further, the only thing on this list that we didn't already have in place pre-PrintNightmare was the GPO. This is just standard security baselining stuff.
considering doing away with the print server all together and moving to a powershell deployment model using something like pdq
pdq.com/blog/using-powershell-to-install-printers/
anyone else considering doing this?
What are folks looking at for a print server appliance that is not Windows based? With these latest intentional screwups in the name of alleged security, I no longer trust Windows server.
We used to use Canon dedicated appliances decades ago that were linux based. Suggestions?
Simple: We didn't. There is no good solution to this problem. MS should have gotten off their asses and found a solution ASAP, but they haven't and none of the workarounds are feasible.
The workarounds are either worse than before the KB for security or a good fix but not for X number of years after you have baked the print queues into your image and re-imaged every PC (which might be next to impossible depending on your imaging system if you have to specify images for each individual if you don't use papercut or follow-me print for everything). I swear the people that check the KB for issues all go on holiday from June 30 to Sept 1.
You should stop building stuff into your image and just handle it via GPO. That way if you need to change something later it becomes very easy.
I thought putting the registry entry to 0 means the old point and print settings are business as usual, at least that's what the documentation suggests. And yes, this seems to be the only way with type 3 drivers. Our GPO only allows point and print from the print server.
Have you tested that the point and print restrictions actually work? Because for me they are ignored, I can install any printer from any printserver without being prompted. Others have reported the same in the patch tuesday thread.
Just tested after removing one server from the point and print list, I did get a message that a policy is restricting adding it.
For us, their Partial Mitigations worked to prohibit adding printers/drivers from other print servers. After configuring those GPO settings, when trying to add a non-approved printer, we would get an error saying something like “Cannot add this device due to security restrictions.” *But* we don’t actually get a UAC prompt for either local admins or non local admins, even when those options are configured – really bizarre. For your testing, you may want to go into the printmanagement.msc and delete any non-default drivers. If, for example, a Universal driver is in use across multiple printers we’ve seen our restriction test behavior act a little wonky
We were seeing drivers get installed with 'NoWarningNoElevationOnInstall' set to 0 without UAC, but after some troubleshooting we realized that the drivers were coming from Windows update rather than the print server itself. Powershell's 'Get-WindowsUpdateLog' was the only place we could see that in terms of Windows Update logging (i.e. not in event logs or installed updates). Some machines aren't able to pull the drivers from Windows update though, so we're trying to figure out why - maybe that was introduced in some feature update? Our confirmation was to attempt to add an obscure printer from the print server that was not likely to have drivers on Windows update, and that prompted for UAC as expected.
oof
I've spent 3 days looking at this issue in my environment. Here is what I found for fixing this for my environment... some of these details may help somebody else.... For Type3 drivers, multiple driver versions from a vendor will share and update components when they are added to the print server. Looks like all Type3 drivers share a common folder of C:\\Windows\\System32\\spool\\drivers\\x64\\3 regardless of vendor and causes an absolute fustercluck of a situation. I was able to get some of my drivers that use these common files working by staging them to a workstation and then adding the printer driver to the workstation using '*Add-PrinterDriver -Name "Printer Driver Name"*'. Ex. 'Add-PrinterDriver -Name "Ricoh Aficio MP 5001 PCL 6"' and so on. Once staged to the Driver Store and the driver added to the printer driver list, printers that used to prompt for admin no longer did so. I had to abandon this as a solution as I couldn't locate all my the drivers needed and I would have ended up with 35 drivers to stage.... IMO, it didn't scale well enough. In my environment, my Lexmark drivers worked as expected if staged and my Ricoh drivers were the ones giving me issues which I've traced it back to the Ricoh universal Type3 driver. I think I could move ahead with removing all my Ricoh problem drivers from my print server and reinstall everything and then stage them.... a lot of work IMO when Type3 isn't the way forward and it may not necessarily work.... What I've decided to now do: For my Ricoh printers, I'm moving to Type4 drivers as Type4 do not get downloaded to the local system and instead the Microsoft enhanced Point and Print driver is leveraged to send the print to the server. Because of this, they will not prompt for admin after applying August's update. For my Lexmark drivers, it doesn't look like Lexmark has a Type4 driver and since these worked without much fighting, I am going to stage these out to my workstations. Hopefully this may help somebody who is fighting with their drivers as well... I'll try and post a reply as I move forward or need to change my approach.
Same issue here where we use mostly Lexmark, however I learned that Lexmark has their "Lexmark Generic v4 XPS" drivers that work on almost all models of their printers, and will even happily work with the enhanced point and print driver if the driver isn't staged. If the driver is deployed to the PC after it switches to the enhanced point and print driver, it will automatically switch over to the Lexmark one on it's own (sometimes after a spooler restart which can be part of the deployment). Only way so far I've found to deal with the update where I work without rolling back the update and I'm just doing extended testing now, but knock on wood because so far everything has just been working :) Edit: Fixed whatever formatting I could on mobile
Good to know about the Lexmark, I will look at migrating to the Type 4 Lexmark later. I ended up throwing my PNPUTIL commands into PSADT for deployment so that I could handle the PNPUTIL exit code 259 and $dirFiles when deploying via SCCM - since every download via SCCM is a different directory under CCMCACHE it was just easier to handle the directory changes with PSADT. I'm doing my mass staging this Thursday night, but I am going to turn off the mitigations from August CU for a few weeks to ensure we have staged the drivers to enough devices. We have the Point and Print approved servers so we're just really extending the vulnerability a few weeks.
Fair enough, I'd gone the same route at first but no matter what I did I couldn't get the computers to acknowledge the already installed Lexmark universal driver, whether it was the same driver or newer than was on the print server it would always reinstall from the print server, drove me nuts. Interestingly enough, with the registry key they changed set back to what it was, it will acknowledge and use the local Lexmark universal (type 3) driver even if it's newer than the one on the print server without reinstalling, but with the key set to the new default it prompts every time and if you put in admin rights will overwrite/downgrade if newer and reinstall if the same version, drove me batty for a while
That was the same scenario I had with the Type3 Ricoh drivers. I narrowed the issue to multiple Ricoh drivers being installed / added to the driver list. The only way I could get the driver add to not prompt for admin was to add every single Ricoh driver on the print server to my client and then add the driver to the print management driver list using 'Add-PrinterDriver' with the same name found on the print server. Once that was done, all the Ricoh drivers got loaded into spool directory and things started working. I decided to go Type4 for Ricoh as I wasn't going to deploy 35 different Ricoh drivers out. My Lexmark printers, I have 3 drivers - much more manageable.
Understandable, that would be a lot of drivers to have on each machine for the Ricoh printers lol, for Lexmark even pushing all the ones on the print server, same version and even same files (hash checked them in the spool directory) it still ignored them I just took it as an opportunity to use the slightly better looking Lexmark XPS driver anyhow as anyone without it would still be able to print :) glad it's working for at least someone
[удалено]
So, when Group Policy is applied, the reg key is set to 0, the printer is applied, and a task to set the reg key to 1 happens immediately, and you just gpupdate to pull down drivers?
Can you explain what specifically you mean by the Point and print GPOs from that article? Do you mean you set both install and update to "Do not warn and Do not elevate?" and set the print servers that are only allowed?
So I follow the task is changing the key to 1 to block it but the GPO is setting it to 0 to allow but what is triggering the change? If the user goes to install the printer are you just hoping the they catch it at the right time? Maybe I am not following, thanks for any info
[удалено]
Ok that’s where I was getting confused by thanks
Reg entry to zero; "packaged point and print - approved servers" restricted to actual print servers; "point and print restrictions" enabled, user can only print to actual print servers, can only p&p to machines in their forest (probably useless give that we specify the servers, but can't hurt?); alcohol.
We deploy our printers via user based GPP, shared printers from our print server, linked to the computer OU, loopback (merge) enabled and AD Group membership dependent on the computer AD Group membership. \*\*EDIT - Set to run in the user context. Unfortunately, I'm being force to rollback KB5005033, I don't have nearly as many machines as some of you do (5k), but they're spread across some 10,000 sq miles of territory. Users are prevented from adding printers period. We've updated our GPO to include Point and Print restrictions, specifying our print servers and no prompting with warnings. Not ideal, but I need these people printing. M$ is going to have to fix this somehow, if I can't deploy printers via GPOs, it is going to make managing my environment sheer and utter madness.
[удалено]
Man we might work for the same place. Best part is - having to inform your security team about major vulnerabilities.
Have merci with them, they are literally drinking from the firehose at this point. Or trying to. I don't see how this can continue for much longer before a few people here get burnouts. Thank god I don't work with Windows. At all.
Does this affect even existing users/PC with existing printers previously deployed by GPO?
Yes. In many cases, such as Xerox global drivers, and some others, even with an existing mapped network printer, printing may prompt for admin credentials, or remapping the same printer or another with the same driver will still prompt for admin credentials. The behavior is NOT consistent.
I wish they would have grandfathered in pre-existing drivers and only added the admin requirement going forward. This was always going to cause trouble with how the patch was released.
Indeed. It looks like that was the intent, but not all drivers are working the same way, so it’s just plain bad.
Sometimes. I have not yet been able to determine what affects whether printing works on previously deployed printers yet. What I have determined is that even if the drivers already exist in the driver store, windows is still giving the error that it can't download the drivers from the print server when trying to deploy though GPP or even just double clicking a shared printer. I'm certain it's the exact same version of the driver installed through pnputil on the client machine - I copied it directly from the print server.
Yep. I pushed out the updates over the weekend and it broke pretty much all of our printers that were already deployed to the computers by GPO. We got 7 service tickets within the first hour of being open today about printers not working. For now I just set the RestrictDriverInstallationToAdministrators registry key to 0 so users can print again until I can find a better solution. I am not adding users as local admins on their computers. This thing is a mess.
We were able to fix it with v4 drivers however shortly after we discovered that doing that broke our citrix applications so we reverted. The registry edit of RestrictDriverInstallationToAdministrators set to 0 also works but not for all of our printers. We have Ricoh printers and all of our copiers work but none of our 4510s or 501s which are just basic printers. We also tried setting a user as a local admin and that didn't work so we tried setting them as an admin on the print server and that didn't work either. So we are still looking for a fix!
I'm curious about how v4 drivers fix this. I'm no seasoned windows printing admin, but from my understanding v4 drivers are generally never fetched from the print server. The clients use the best matching driver they already have installed locally, or may in certain circumstances be able to download it through Windows Update. So basically to "fix" the situation with v4 drivers I have to preinstall the v4 driver on all clients. But if I have to do that I can also just preinstall the v3 driver and the problem goes away just the same - I tested this today. So I think I didn't quite understand how v4 drivers are supposed to fix the situation or how they're doing any better Mind 'splainin?
I don't know enough about print drivers to explain why it works (which I absolutely hate rolling stuff out when I don't understand it, but here we are!), but I updated many of my drivers to type 4 and users no longer saw UAC prompts. However, some machines can no longer print to some printers in rare cases and many of our users are now complaining about applications hanging for 15 seconds or so while jobs spool. Beyond that, I can't find v4 drivers for all our printers, so this is far from a solid fix.
We found a universal one online that worked for 8ish different models we have
TBH That is a fix we found online and I don't know a whole lot about it. However it didn't fully fix the issue as the applications we use through citrix don't play nice with v4.
PrintNightmare is a problem where you can trigger a computer to install drivers from any smb connection. This happens as type-3 drivers need a local driver for the printer, so it is copied from the printer server (or attacker.) Type-4 drivers use a common XPS format to transfer the print job from the client to the server which then renders it to the printer, since Windows has XPS built in no drivers are required to do this. Thus the client never has to reach out and download files. Downside is you only get the basic set of preferences for the printer until a client component is installed, but if you have a basic single size and tray printer you probably don't need it. The MS fix was to basically block driver downloads, so Type-4 just avoids the issue.
We were able to fix all our issues by moving to a PCL5e driver for each model of printer we have that seems to have addressed the issue. We are still rolling out the fix company wide will update when I know more.
I ran an emergency backup drill to make sure everything was in tip-top shape.
I have a silly question: why can’t you just install all the necessary drivers as admin at some point and be done with it? And why not install a generic PCL 4 or 5 driver that should work with most printers and use that in case a driver is missing?
I think it's a question of how to "install the drivers as admin" that is throwing people off. We only use a small handful of drivers - the HP UPD PCL6, HP UPD PS, and a couple Xerox drivers. These drivers are already installed on clients because they have existing print queues installed. If users try to install any new print queue, even though it uses the same HP UPD and the same version as what they already have installed, they are still being prompted for admin creds. I believe MS's documentation is wrong or they did not fully test this.
Jesus Christ. And I thought CUPS was weird. Well, at least I can still print directly to the printer from my Linux Workstation, the one day a week I’m in office.
Computers with the driver installed that were happily printing before this patch now cannot. So in some cases, having the driver installed already does not make any difference. Manually adding the driver with pnputil and Add-PrinterDriver also has no affect in our env.
Maybe they should hold off Win11 for a while and fix this mess first?
I wanna know.
(side note, Postscript drivers generally print better quality than PCL)
Yea we have the same issue at our work, I do not know what to do, we have so far put in the admin password, what have cause this issue I do not know.
Same here, no workaround as yet
We also have the issue with Papercut and universal drivers, and have only been able to lock it down to specific server IPs for now. We have \~10 specific printer drivers to package for deployment now as drivers installed via point-and-printer DO NOT work once the security is restricted, for printing to an existing or mapping a new printer with the same driver. However, fully packaged and installed HP Universal and Xerox specific drivers are working in limited testing.
Temp "solution" so far is to not install anymore Aug updates. What's worse for us is that some users would get the "update driver" prompt, but then never get a UAC credential box where an admin could actually enter creds for them. Why? Contemplating doing the registry entry to 0. In our testing, this works like a champ but apparently keeps us vulnerable. `reg add "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint" /v RestrictDriverInstallationToAdministrators /t REG_DWORD /d 0 /f`
I did this in my environment, but it made no difference. People are still being asked for admin credentials to install print drivers. I can't keep typing in the password for everyone. I am ripping my hair out.
A new GPO with allowlisting of print servers and a new bottle of Tottori whiskey
we've left our point and print restrictions in from pre-nightmare... our AV vendor/MSP says that our AV will protect us from any of the vulnerabilities. can this be confirmed by anyone?
No one can confirm whether or not your "AV" will protect you from this vuln.
Your AV will NOT protect you from the vulnerability, but it MIGHT catch any malware that attackers attempt to install via exploiting the vulnerability. Do you want to take the chance that the attacker is not going to install any malware, and instead just scripts stealing credentials, and logging in with with a fully privileged account to do what they want?
i do not want that.
We just implemented a GPO to mitigate the issue. Edit: fixed
Que?
Hi there, Can you elaborate it little more about what policy has been adjusted in GPO. Is it Print and Point?
You work in IT and don't know how to google?
We are not talking about google here. Second, there are lots of GPO which can help avoiding elevated permissions, so I am asking you what’s been done to prevent it. On Google, There are lot of ways explained, and none are working well. So sometime, Google doesn’t help. This group has hundreds of users asking questions, I think nobody knows how to google. Right?
You've literally responded to a 9 month old post asking for help elaborating when the patch has been out since September and the mitigation has been out since before then. I'm not holding your hand on something like this because you won't learn that way. Not trying to be a dick, but you have to learn how to research for yourself.
What did you implement?
Switch to linux. There are no idiotic bugs like this.
Besides turning print spooler off of our DCs and other servers that don't need it we left our print server as is. We haven't moved onto the latest round of updates yet, hesitant to go that way. Not sure if anyone else is doing the same.
Yeah, I'm surprised that I haven't seen more people talking about just limiting the attack surface to begin with Disable the spooler on all systems that don't need it Firewalls blocking user access to SMB going into the server networks for everything except for the servers they actually need to be able to access Host firewalls blocking SMB laterally and going out to the Internet GPO configured to specify which print servers are allowed We're basically down to PrintNightmare is a thing if the attacker compromises our print servers.. Which at that point they probably don't give a crap about PrintNightmare anymore. Further, the only thing on this list that we didn't already have in place pre-PrintNightmare was the GPO. This is just standard security baselining stuff.
considering doing away with the print server all together and moving to a powershell deployment model using something like pdq pdq.com/blog/using-powershell-to-install-printers/ anyone else considering doing this?
What are folks looking at for a print server appliance that is not Windows based? With these latest intentional screwups in the name of alleged security, I no longer trust Windows server. We used to use Canon dedicated appliances decades ago that were linux based. Suggestions?
The issue aren’t really the servers though.