Just thought I’d throw this up there. Turns out, MS made some interesting choices closing the PrintNightmare (CVE-2021-34527, CVE-2021-1675) hole. We found one of those interesting choices earlier this week when a print server was just slammed at 100% CPU all day. For those that don’t know, I work in higher ed. And much to our dismay, we have a lot of print servers (currently over 20, when it should be like, 3?). Since PrintNightmare, you have to have a list of allowed print servers that computers are allowed to use. Great. So, we have a GPO that does this. What happens is computer is told to map a printer, and if the print server is on the list, it’s mapped, and if it isn’t, it isn’t. Simple, yea? Well here’s the rub: it checks the list AFTER it connects to the print server. Some may see where this is going…
Long ago, we realized GPOs to map printers are inconsistent. Especially on lab machines with lots of turnover. So, we moved to using a login script to do the work. So user logs in, script runs to map printer, if it can’t map the printer, it tries again (just to account for network issues, server outage, etc). This week, that resulted in a DDoS of the print server because someone changed the GPO to not include the print server in the GPO allowed list… and because MS made an odd choice.
Best I can tell, here’s what happens
- Computer gets told to map printer on print server
- Computer connects to print server to check for printer
- Computer checks approved list of print servers and either maps printer, or rejects
So, if you ask me, steps 2 and 3 are wrong. They should be reversed and the computer should check the approved list before it auths to the print server. In our case, with 800+ computers all hitting the print server over and over again, lsass VERY quickly was overwhelmed with auth requests and the print server would start alerting about CPU/memory.
Maybe I’m daft and MS had a reason for doing it this way, but damn does it just seem backward to me.