by Greg Shields

First, a confession. I don’t like UAC all that much. I don’t like its in-your-face interruption with my daily flow of computer interaction. I don’t like its insinuated transfer of security responsibility from the people who know security (we IT professionals) to the people who don’t care about security (our users). I don’t like Microsoft’s ever-shifting justifications as to why it’s a needed security component (it’s for malware protection; it’s not for malware protection). Above all, I particularly don’t like the subtle pressure that it adds onto already overburdened IT administrators by well-meaning security types (“Windows has it; you’re now required to use it!”).

So why was UAC created? Why was it created in such a way to be particularly annoying to both users and administrators alike? I have a theory, one that I cannot substantiate, but one that seems to fit better with any of the other reasons for its being. In my theory, UAC isn’t written for you. It wasn’t directly written for your users or your business either. UAC was, according to my theory, written instead as a direct assault on the vendors that supply you with software.

Allow me to explain this further. Recall that one of the primary reasons for the release (and subsequent application and driver compatibility problems) with Windows Vista was to improve its security model. With Windows Vista, Microsoft made a substantive about-face in terms of security, finally and completely eliminating external driver and application access to the OS kernel. Prior to Windows Vista, your applications and drivers enjoyed comparatively easy access to Microsoft’s kernel. These pieces of code could insert themselves in many ways, primarily in order to provide fantastic levels of compatibility. In the early days of the Windows OS, this compatibility was a good thing.

But no longer. The problem, as we’ve all experienced, is that when software and drivers have that access, so does malware. It is for this reason that the move from Windows XP to Windows Vista substantially improved core OS security. Forcing applications and drivers out of the low-level system kept those system files sacrosanct, protecting Windows like never before.

Yet, at the same time, forcing those applications and drivers out of the kernel also “broke” virtually every application and driver in existence. If you were an early adopter of Vista, only to find that many of your applications simply didn’t function, you know this problem. In the end, Vista’s near-universal negative reviews were an unfortunate fallout of Microsoft making a good decision on security.

The problem with Vista wasn’t Microsoft’s problem—it was the problem of the software vendors that didn’t, wouldn’t, or couldn’t update their code to fit Microsoft’s new security model.

Between the release of Windows Vista and today, most software vendors have since updated their code to fit into that driver model. They’ve had to if they wanted their code to simply function on the new OS. But at the same time, many still don’t write code according to Microsoft’s security best practices. Their code perhaps stored user-specific information in HKEY_LOCAL_COMPUTER, an area that is only accessible to administrators. Maybe it required using, modifying, or otherwise working with a file or folder that only permitted access to administrators. Or perhaps it required the use of some on-system action that Microsoft hard coded to work only with administrative privileges.

All of these coding practices are not considered good because they fly in the face of eliminating administrative privileges. When a regular user application requires some sort of administrator rights to do its job, businesses that use that application are forced to make difficult decisions about expanding their distribution of administrator privileges.

This is, in my theory, the reason UAC was created. You already know that UAC by default is a very noisy thing. It prompts your users, sometimes many times, that an action they’re attempting to accomplish requires elevation. “Hey, are you sure? Hey, are you sure? Hey, are you sure?” It also handles that elevation, but not without an action by the user (at least with its default configuration). This process for many is annoying and a hurdle to efficiency, yet even Microsoft’s recommendation is for you to leave this noisy application set at its defaults.

In my theory, I believe that UAC—consciously or unconsciously—was written to forcibly change the coding behaviors of your software vendors. Call it “Behavior change through shame.” By creating a solution that annoys you when your applications attempt to perform actions that they shouldn’t need to do in the first place, you’re annoyed. You grow to dislike those applications. You notify your vendor that you don’t like this behavior. And, in the end, the software vendors eventually spend the time, effort, and money to fix their code.

Assuming for a minute that my theory is correct, you can see how this behavior-modification system both sucks and is awesome at the same time. It “sucks” because you’re forced to deal with a set of ridiculous prompts for a period of time. But, over time, it’s also “awesome” because its presence drives our entire IT ecosystem towards a future state of greater security.

Now, how can you use a solution like UAC to improve your own posture of eliminating administrator rights? In the next articles, I’ll show you a few ways in which you can.

About the Author

Greg Shields is an independent author, speaker, and IT consultant, as well as a Partner and Principal Technologist with Concentrated Technology. With 15 years in information technology, Greg has developed extensive experience in systems administration, engineering, and architecture specializing in Microsoft OS, remote application, systems management, and virtualization technologies. He is a Contributing Editor and columnist for TechNet Magazine and Redmond Magazine, and serves as the Series Editor for Realtime Publishers, the world’s leading provider of high-quality content for the IT market. Greg is a highly sought-after and top-ranked speaker for both live and recorded events, and is seen regularly at conferences like TechMentor Events, Microsoft Tech Ed, VMworld, and more. He is a multiple recipient of Microsoft “Most Valuable Professional” award.