> We reported our findings to Microsoft, but a fix is not planned.
The old Microsoft is back then?
The old Microsoft is back then?
Also, Microsoft is over Windows Server environments. They have gone full cloud and could care less about Windows OSes. They continue to develop them but it's clear it's switched from critical business unit to a side business for them.
That's unfair. I actually don't hate Windows Server in and of itself, but I loathe the way people use it, and I dare say they're encouraged to do so.
I think the worst part is the lack of incentive to actually learn about the OS, or how to use it, let alone holistic best practices for system administration. Why bother expanding your skills, when everything you need is just an RDP and EXE away!
Windows Server is to system administration as WordPress is to software engineering. It's extremely powerful for beginners and it'll _probably_ work for a good chunk of what people want.
Both are often driven by incessant manual tweaking, until one day it finally works, and then hoping no one makes a sudden movement. And good luck consistently replicating any effort from one environment to another in either case.
However easy it might _seem_ easy at first, it's very quickly going to start hurting. And of course there are "correct" ways of doing them both, but: why on Earth would you bother when it's so damn easy to do it the naughty way?
I have been out of Windows systems engineering for a while, but this was certainly not the case say 20 years ago.
The operating systems and best practices were well documented (via official Microsoft Press books) and back then MCSE certification actually let you learn some in depth stuff (if you wanted to).
I'm sure that documentation you describe still exists. The Microsoft docs site is pretty thorough. But every time I have personally found myself involved with windows, things have been an enormous mess of string and bubblegum.
Linux shops are certainly not bastions of consistency, but I've just found better success with git-driven automation in Linux environments than I've ever experienced with my own senses in any Windows shop.
I firmly believe it boils down to the fact that RDP enables laziness out of the box, whereas linux requires clearing a few hurdles to make things quite as easy. So there is a tangible incentive to do things the sustainable, "right way" and not limp along with short-term quick and easy fixes.
> I think the worst part is the lack of incentive to actually learn about the OS, or how to use it, let alone holistic best practices for system administration.
Funnily, this is how I feel about Linux-based OS's. Being that there's only a single "distribution" of Windows I can be confident that time I spend learning about various "contrivances" Microsoft devices (service management, configuration storage, etc) are going to apply to any Windows machine I work on.
OTOH, every Unix and Linux distro has its own set of contrivances for configuration, service management (though systemd being rammed down everybody's throats has in some ways changed this), filesystem hierarchy, etc. I pushed for RHEL for "day job" deployments, for years, because I knew there would be stability in the product that was similar to Windows. (Debian is a close second.) Otherwise, Linux distros feel like the wild west.
Knowledge about the underlying architecture of NT going all the way back to the original 3.1 release still applies. The OS has been updated, for sure, but there's a strong lineage and adherence to design principles going all the way back to the start.
People who use any technology w/o understanding it are infuriating.
> Both are often driven by incessant manual tweaking, until one day it finally works...
Again, that's how I see a lot of Linux shops. I don't think Windows makes it any easier to have immature sysadmin practices.
My Windows environments are deployed from unattended installs, configured by Group Policy, and manual tweaking on individual VMs is highly discouraged. If I were deploying Linux at scale I'd be using configuration management tools there the same way.
The only thing I would challenge is that the pain of inconsistency (from distros to stacks, e.g. systemd, etc.) is exactly what I believe drives people to desire/aspire to automation and strive for the consistency.
That inconsistency, while absolutely frustrating at times, also forces users (often against their will) to understand the core concepts behind the software they're using or managing rather than memorizing GUI workflows.
In my opinion, a number of Windows folks seem to take consistency for granted, and become all too reliant on it. They get comfy and have little clue how to overcome adversity when it rears it's ugly head.
I don't think that sort of laziness is unique to the Windows world, but I do think Windows makes it easier to fail upwards. It's much harder to hide incompetence in a Linux environment, at least in my experience.
In other words: if you'll excuse my reductiveness, what doesn't kill, gives strength. Or at least hardens one's resolve.
Honestly my biggest gripe boils down to how easy RDP makes it to form bad habits, and how there is little (short term) consequence for operating in reactive ways which lack reproducibility because "I'll just pop into the server and click around for a sec"
Windows with RDP is faster, and it is easier. System admin that way (mostly) works. Best of all, for the majority of those who grew up in the PC age, it's familiar.
But I unfortunately don't trust a lot of my colleagues past and present not to abuse it.
curl | bash enters the chat.
Seriously, though, junior sysadmins (or devs pretending to be sysadmins) are gonna do what they do regardless of the underlying substrate. For Windows sysadmins it might be clicking-around doing one-off "fixes". For Linux admins it's shitting-up production boxes with compilers and dev tools or adding sketchy untrustworthy package repos.
> Honestly my biggest gripe boils down to how easy RDP makes it to form bad habits, and how there is little (short term) consequence for operating in reactive ways which lack reproducibility because "I'll just pop into the server and click around for a sec"
> Windows with RDP is faster, and it is easier. System admin that way (mostly) works. Best of all, for the majority of those who grew up in the PC age, it's familiar.
It's the same w/ SSH on Linux machines, though. Junior people think it's easier to make one-off changes. Senior people realize that every one-off change is a gamble with the future. It's part of the culture and maturity of the individual and of the organization they're working in.
My point is that whatever is done over SSH is at the very least repeatable with relative ease even if it's incorrect.
SSH has a command history. RDP means recalling what guis were clicked through and which options were selected. Neither is particularly scalable and both are imperfect but only one of those is faulty by default.
In the case of ssh at least I can copy and paste (then fix) some idiot's commands into a script as a starting point for automation. What are my options after a whackamole RDP session?
But you’re certainly right that doing ad-hoc fixes is a losing battle, regardless of the platform.
Along with setenforce 0.
And these people are telling me about security
Things like „oh this doesn’t work with SELinux enabled, so let’s just disable SELinux“ for example.
I‘ve seen both and I wouldn’t necessarily say I‘ve seen the former more often.
There’s probably as many incompetent Linux admins as there are incompetent Windows admins. At least in my personal experience.
There's no such incentive with windows because it's so "easy" and things like powershell's double hop and other similar quirks can actually make certian things more difficult to automate.
My point is, at least you can easily translate random CLI poking into scripts. more often than not, an RDP session doesn't lend itself to scripting.
So you're saying they do care?
(I'm just giving you a hard time. The correct expression is "could not care less about <x>".)
It's a little disappointing a default configuration results in a less secure deployment (and Microsoft has done a lot to standardize on more secure-by-default configurations) but it's not like this was some great unknown zero-day.
Manually visit every DHCP server in existence and do exactly what listed in mitigations?
>> The TL;DR version is:
Disable DHCP DNS Dynamic Updates if you don't need them
Client records should be safe if you configure a weak user as the DNS credential
Managed records can’t be protected from spoofing with any configuration; use static DNS records for sensitive non-Windows hosts, if possible
Do not use DNSUpdateProxy; use the same DNS credential across all your DHCP servers instead