User Account Control (UAC) is a Failure

This is a rant, so I’ll try to keep it fairly short – despite the highly inflammatory title. The problem, however, is that I really do think that User Access Control (UAC) is actually worse than being a mere failure. Specifically, I think it fails to accomplish what it was, apparently, intended to do, and it gets in the way for legitimate end-users and Systems Administrators. In short, I think it was probably designed by lawyers – to help give Microsoft some degree of ‘plausible deniability’ for all of the malware that plagues Windows and which Microsoft seems to take little interest in stopping.

Exhibit A: Malware

Microsoft recently copped to having just a 14% market-share when it comes to all devices and screens being used in today’s computing environment. That’s a significant drop from their vaunted 90% market share of just a few years ago. Obviously, this shift has a lot to do with both the success of iOS and Android as well as Microsoft’s failure to gain significant traction in either the phone or tablet space – but I think it also is partially due to Microsoft’s shameful ability to address malware on Windows PCs. Or, put differently, there’s a definite perception (happily inflamed by Apple commercials of years past) that PCs are just ‘buggy’ and susceptible to malware.

Of course, it’s a bit nebulous to argue something about ‘perceptions’. Only, if you’re anything like me and have non-technical friends and family who turn to you for ‘computer help’, you know that this perception is a full-blown reality and that it’s still insanely easy for end-users to get all sorts of crap-ware (spy-ware, mal-ware, and other ad-ware ‘stuff’) on pretty much any Windows machine – even when Anti-Virus is installed.

In fact, to hammer the point home that UAC is useless, look no further than what happened when HowToGeek installed the top 10 ‘free’ apps from download.com. Anyone with a brain would expect that such an endeavor would end up with a decent amount of ‘spy ware’ and ‘ad-ware’ installed on their machine if they undertook something this dumb, but if you take a second and read through the blow-by-blow of just exactly what did transpire, then it’s clear to see that Windows clearly has a problem. Something that UAC doesn’t protect or even prevent against – simply because all of this software is installed ‘under the covers’ during a ‘legit’ install operation that ends up being ‘trusted’ or approved by end-users when they first get a UAC pop-over when trying to install things. Which, in turn, re-iterates the point that UAC is, at the very least, useless.

Exhibit B: UAC on Windows Server 2012 R2

Given that UAC doesn’t do a very good job of protecting against what it was supposed to do (or at least what we were told it was supposed to do), I’d have to argue that it’s a failure. Sadly, though, I have to argue that it’s MORE than just a failure – because of the headaches and shenanigans it causes for systems administrators when working with Windows Server 2012R2.

Recently I encountered some of these problems first hand. First, there were problems or issues where scripts (.bat and .ps1) failed to copy files as they had done previously on Windows Server 2008 R2. File and folder permissions were all correctly set as needed to let a non-Administrator account access and change files as per the scripts – but the scripts wouldn’t work without throwing permissions errors. Things got even more confusing when I couldn’t even run these scripts myself unless I was either logged in directly as the ‘Administrator’ OR unless I was using an elevated command prompt when logged in as a member of the Administrators Group but no as the actual Administrator.

The problem, though, is that I had already turned off UAC – so the fact that additional ‘escalation’ of privilege was required ‘to get stuff done’ kind of threw me for a loop. What drove me batty, though, was that when I was logged in to these servers as non-Administrator (even though my login was a member of the Administrators Group) I couldn’t create new folders without being thrown a prompt telling me I’d need to ‘get permissions’ to create folders. And, to be clear: I wasn’t trying to create folders in C:Windows or at the root of the C: drive; I was simply trying to create new directories in the D: drive (in a folder owned by ‘Administrator’). That, however, was my clue that UAC was still, somehow, turned on.

Which, in turn, is why I say that UAC is actually more than a failure on Windows Server 2012 R2 – because you can’t simply turn it off from the Control Panel as you used to do. Instead, you actually have to go out and hack the registry to turn it off.

Conclusion

In the end, if UAC can’t protect end-users from the debacle that ‘freeware’ has become, then it’s arguable that it doesn’t serve much of a point. And, if I’m honest, I’ve never been that much of a fan of UAC as a ‘protection’ for typical end-users. Personally, I’m pretty sure that what end-users ‘hear’ or ‘see’ when a UAC prompt pops up is something that asks them the equivalent of “Do you want to keep getting stuff done, or would you like to stop what you’re doing?” – because the actual warning texts are ‘mumbo jumbo’ to typical end users. So, for my own workstation and on servers I manage I’ve always turned it off – in favor or just practicing ‘safe computing’ instead.

The problem, however, is that it looks like Microsoft has ‘upped the ante’ with Windows Server 2012R2 by forcing administrators to jump through additional hoops just to turn this ‘feature’ off. But whenever I’m forced to hack the registry to be able to administer things the way I think I logically should be able to do in the first place, then I’m going to argue that Microsoft is actually doing more harm than good – because pretending that ‘forcing’ users to keep UAC on for non-Administrator accounts is just that much more likely to force users to log in and run everything as ‘Administrator’ instead of trying to branch out and using least privilege. Meaning that UAC has gone from being a nuisance to a potential, and serious, liability. Either way though, it’s clearly a failure at protecting what it was designed to do.