The print queue is required, and must contain letters.
An infosec firm accidentally published a proof-of-concept exploit for a critical Windows print spooler vulnerability that can be abused by rogue users to compromise Active Directory domain controllers. How this happened is a little messy. Rewind to June 8's Patch Tuesday, and Microsoft issued a fix for CVE-2021-1675, which was …
"people need to prioritize disabling the print spooler service on domain controllers and mission critical servers "
What the hell is the print spooler doing enabled on a domain controller ? Since when do you print from a domain controller ?
I wager this situation would never happen on a Linux server, because Linux admins only enable what is needed on the server. Windows admins, on the other hand, just install Windows and let it run.
I never print from my main PC, because the printer is on the other side of the office and the USB cord is not long enough. Do you really think I have the print spooler service enabled on my main PC ? Of course not.
If you're running in a SOHO environment, it's not inconceivable that the admin and cost of separating functions into separate VMs/systems is unwanted. Having multiple Windows installations to host all the necessary domain services has been the recommendation for a very long time but that doesn't mean people listen.
Microsoft offer their 365 services for companies that don't want to host it themselves, but who knows what rationale people have for odd configurations.
"...but who knows what rationale people have for odd configurations"
When small company IT are over ruled by PhDs who know nothing about real world IT, but whenever they are given reasons why they can't do something in the way they want (such as "explicitly prohibited by the licence conditions") suddenly become "IT experts", scweam and shout and stamp their little feet until they get their way. And they never "lower themselves" to say "thank you".
More like, what the frak is a print spooler doing accepting "drivers" from network clients?
Or, what the frak is a printer doing requiring a 'driver' running with system priveleges?
i.e. Why the ducking fuck are printer drivers not standardised, or at least run in unpriveleged userspace?
Typically, these days, printers are attached to a generic interface (USB or network) that already has a driver and the printer driver is no more than a filter that could run perfectly well in user space. There's no specific technical reason why such a filter couldn't be installed by an unprivileged user for their own use.
It's just that we're not starting from here.
There's always one.
Look, you may know how to configure Windows, this forum is for Linux users who last touched Windows a decade ago to complain about "Windows issues" without fear of contradiction.
Then you come along with some actual Windows knowledge and try and ruin it all!!!
We don't want the truth, we want to carry on slagging off Windows like we've been doing for the past twenty years.
Yes exactly if only Windows supported libusb properly then you wouldn't need kernel drivers for most things.
But anyone who has tried using libusb-win32 has encountered a world of pain, because windows sucks. so there :P
Someone (me) who has a small network (my home net) is quite unlikely to go to the trouble of using group policy to allow Self Propelled Agents of Mass Destruction (teenagers) to install anything whatsoever. Past experience suggests to letting them install even seemingly innocuous items results in mass mayhem and someone (me) having to spend hours fixing the results. Nah, I just use admin privs… and don’t give them the admin account name, much less an admin password.
Fortunately the youngest is due to go to uni (in Indiana! Hoo-rah!) in late August to September, assuming that it won’t be remote classes. Unfortunately the eldest, no longer a teenager but still a SPAMD, is working from home and will be for a while.
"You can use group policy to allow non admins to install print drivers."
That's an administrator pre-approving the equivalent of a function-limited SUDO. Admin still got involved.
Now, please remember that I'm one of the rare Windows non-basher here on this forum.
I came to post the same first two paragraphs. Downvoted for the pointless dumping on winbloze admins.
I get what some are saying about those with limited resources. Security is not free. Sorry, but I'm still going to go ballistic on you. This is not the '80s. Running a print spooler on a domain controller is at the same level as running sendmail as root. Fix your problem.
You print from a domain controller when it's a home or small company domain. At home I have a domain controller which doubles as several other roles because, well, I only have four server systems, as it's a _home network_. Printing is live on the DC because on several occasions I needed to print something out while configuring either other servers or clients.
My printers are all network printers, not USB. I have them in locations convenient to me, rather than close to a computer, whether server or client. I tend to print to the grayscale laser on average of once every few days; it's a Brother HL-2070, and has been in service since 2005, and currently is just short of 20,000 pages printed. It's on its third drum. I suspect that when that drum dies I'll just get a new printer. I tend to print to the colour inkjet about once a week. It's an Epson WF-3530, currently using non-Epson ink and being Epson-like about it. When I replace the Brother I will probably get a Brother colour laser and dump the Epson, too.
People still use printers. (And even fax machines; the Epson has fax capability, last used last month. I had to send something to the county government, they insist on faxes, email and texts don't cut it. I may keep the Epson around just for faxing.) People need to print from all kinds of machines. Including Linux servers. I have Linux servers at the office, and used to have one at home. And, yes, printing was turned on.
You shouldn't really be putting Azure AD Connect (or anything really, but especially AD Connect) on a DC.
We have turned everything possible into a core server, even including the on prem Exchange box we have to keep around to manage O365 synched identities. Microsoft have got much better at allowing most stuff to run without the GUI, but there are still a few idiocies like ADFS not being supported on core.
We do still actually have one DC hanging around running the GUI. It is a heavily protected physical server that we would use to bring the virtual estate back online in the event of a full power out disaster. Means we at least have a directory and the means to manage it if everything else goes black. Hasn't happened yet and hopefully never will. A lot would have to go wrong across two datacentres to leave us in that situation, but we have planned and practiced the scenario. Should really turn this into a core server as well and manage it with a laptop with RSAT.
Yeah opinion of someone who can't work out how to network print on windows (you have had nigh on 30 years to wrap head around netbios and samba) is deff into troll territory, usb too short my arse...
Anyway dc's are worrying, would be more concerned with it running on a cert authority, or web server and yeah lots of crm/erp business critical systems need the spooler enabled for pdf generation as its less brain damaging to write a print css file than to try and code for page wrapping and overflow in a pdf lib
The DC thing is a distraction. That is, it's a real issue for some people, but not having any DCs running the Print Spooler service does not make this a non-issue. Print Spooler runs by default on Windows desktop systems, and a LOCAL_SYSTEM + Interact service with an RCE is very, very bad.
Attackers penetrate, elevate, and pivot. A workstation exploit might not get them Domain Admin immediately, but they'll get there eventually.
Innit. What is it with Windows and printers? Win 10's had more than its fair share of printer issues, too.
If MS suddenly come out with some "revolutionary" paper-free workplace "solution" nail-gunned onto the side of Office 351 I may begin to suspect that this stuff has been not entirely accidental.
You don't mention which printer but assuming this is a non-GDI device then it is quite possible that Samsung haven't bothered to release a driver for linux. MS released GDI printing (using OS software rather than printer hardware to deal with the problem of printer incompatability so what you are complaining about is not a linux problem but a printer problem.
When I started in computing you either wrote your own printer driver or used text only output and this never really changed even with MS dominating business computing because both MS and the printer makers kept moving the goal posts and refusals on both side to make changes after one or the other changed their specifications. Even the the likes of HP I would end up using MS own drivers for the manufactorers previous models to get their latest product working in the hope that they would eventually release a working driver.
I will tell you what I told all those people whom I supported with this problem, make certain that your printer works with your OS before you buy or accept that you are going to write your own driver or pay someone to do it for you and in my experience windows was too often no different.
I still remember having to try and force a 16-bit unsigned ASPI driver to load, behind the already ancient TWAIN32, behind a proprietary 32-bit unsigned interface, all designed for Windows 95, on a Windows 10 workstation, because they pulled a $10k old scanner out of storage and were too cheap to get another one or buy a 95 license to install in a VM or something. I never could get it to work.
This post has been deleted by a moderator
"Martin Lee, technical lead at Cisco Talos, said: "Exploits such as this underline how important it is to both securely authenticate users and be in a position to identify unusual network activity."
Which is of course true.
It also costs a tidy sum and I can imagine a firm like Talos or its Daddy Cisco would be able to sell me something that does these things...
As opposed to having a separate server for each role and / or using Server Core for DC workloads which is a more powerful mitigation IMHO.
Side note: An often overlooked downside of cloud is that IT is under direct pressure to reduce VM footprint as you're paying for each VM by the minute. Even the lowest of the low on prem server gives you headroom for running a DC and a file/print server roles as two separate VM's and a Win Standard licence let's you run two VM guests.
> Putting a printer on a Windows Server is SO 1990s.
Obviously you have no idea how printing works then.
Our cloud printing solution that prints, to the cloud, has a service running on a server which requires the print spooler.
Otherwise no users can print to the networked printers. This service will eventually be rolled out to our other sites.
Your "solution" only works for a small installation where one person prints at a time and doesnt authenticate on the printer. Thats quite 90's, we had to run like that recently when the printers failed to authenticate staff. It was a mess, with everyone's jobs getting mixed up.
running quickbooks required the printer service to be running (I just tested it). it had a very unusual crash when the print spooler was disabled and kept wanting to send some failure code someplace. This was on a Windows 7 workstation. I put the spooler in 'manual' startup mode after, will start to run things that need it, then stop again. Irritating,yeah.
I have to wonder if there's some easier way to prevent network access to a 7 workstation from exploiting this... (and don't say "Install WIn-10-nic" because THAT isn't happening)
Also since the article said Windows 7 was vulnerable, even when it is NOT a domain controller, what is the extent of this vulnerability on 7 as a workstation?
Wow, Microsoft needs to fix this ASAP. I hate to tell you guys this, but about every small business running a server does this. That server will be the DC, and the File and Print server. It will likely be an application server too. If they are lucky, they will have enough money for a second DC for redundancy. And BTW, GPO is set to allow users to install printers. Why they hell does a Domain admin need to add printers for each user? Scream, blame, laugh all you want. Most small businesses with Domains are running off one or two servers. There's no full time admin. That's it. No Mo' money .... Remember SBS?. It would do ALL roles including Exchange on one box. Just sayin' ...... And now they want us to just turn off print services? Oh, that will go over well ...... Not gonna happen. M$, where's the fix?
"An unprivileged user uploading a new printer driver to the print server isn't an everyday occurrence and should raise suspicions.""
It's not users installing print drivers on their local machines, it's regular (non-admin) users installing print drivers on domain controllers!
Biting the hand that feeds IT © 1998–2021