I’m sure everyone has heard the phrase, “when you have a hammer, everything looks like a nail”. Sometimes Group Policy can be this way. I’ve been doing Group Policy now, for, well…a long time. Before that, I was an early aficionado of System Policy in NT 4.0 and the erstwhile Zero Admin Toolkit (ZAK). Through 20+ years of working in enterprise IT, I have done my fair share of designs around desktop lockdown. Back in those early days, ZAK was my hammer, and I hammered a lot. Then Group Policy became my tool of choice. The idea of  locking down the desktop seemed compelling–prevent user “futzing”, lower help desk calls, etc. That was the story, and I was sticking to it. Back then it wasn’t so much about security as it was about reducing the knobs and switches that users could get into. As time has gone on, and I’ve worked with more customers in more environments (big and small) I evolved my thinking about the value of technologies like Group Policy and its job of lockdown. These days, when I talk to folks about best practices around Group Policy, I spend most of the time talking about stuff like real security, setting up/configuring the user’s environment (e.g. IE configurations, putting shortcuts on the desktop, etc.) and much less about lockdown.

What is Lockdown?

When I talk about lockdown, I think its important to make some definitions. Group Policy does a lot of stuff, but lockdown, in my definition, is where you obfuscate parts of the user’s experience in order to prevent them from accessing features within the OS or applications. Since Group Policy has been around, this kind of lockdown has primarily been within the realm of Administrative Templates policy, as is exemplified here by the policy that removes the Run dialog from the Start Menu:

Administrative Template Lockdown policy

I contrast this kind of lockdown with “real” OS security. Lockdown, by and large, is not real security, but rather  “security through obscurity”. Real security includes things like User Rights Assignment policy, that lets you control which OS privileges a user has, or minimum password length policy, or file system and registry permissions. These are configurations that are enforced by the Windows kernel, and are at the core of the OS and it’s inherent security model. Barring a vulnerability, they cannot be “worked around”, as many lockdown settings can (a perfect example of this is the Administrative Templates policy to prevent access to the command prompt. As even a mildly intrepid user, there are several ways I can access the command prompt or it’s equivalent even with this policy in place).

That said, sometimes lockdown is helpful to reduce user behaviors that could result in bad things happening in your environment. A perfect example of this is the “Site to Zone assignment” policy in Internet Explorer  Administrative Templates. This policy is designed to control IE’s security posture when visiting certain websites. This doesn’t, in and of itself, protect the OS, but it can protect the user from themselves, which, in a “defense in depth” strategy, can be just as important. We all know these days how many exploits inside organizations arise not from vulnerabilities in software, but vulnerabilities in user behavior, so every little bit helps.

Good Lockdown, Bad Lockdown

As I said earlier, I’ve evolved my thinking around user lockdown over the years. I’ve seen what works and what doesn’t in a variety of situations. And I’ve come to believe that there is bad lockdown and good lockdown. Bad lockdown is easy to identify, if you apply the criteria I mentioned above. Does the lockdown directly help secure the system or the user from the bad guys? If not, then I question it’s value. I’ve turned all the knobs and switches in Group Policy. What have I seen? User confusion, more help desk calls rather than less, and a generally frustrating experience with Windows. The bottom line–don’t use a lockdown setting unless you can explicitly draw the connection between that lockdown and the security of your network and systems (or if your company has specific policies about certain behavior–e.g. preventing access to Solitaire–that has to be considered too). Your users will thank you and, in the end, I think you’ll have less work to do. If you are not sure if a particular setting helps or hurts that goal, then try to consider it from a security angle.  Does removing access to that Explorer menu item or that application context menu keep the user safer, or are you just worried that they might “get confused” if they run it? If the latter is your explanation for a setting, I can almost guarantee it will do you no good.

By contrast, good lockdown are those things that do draw a straight line between user behavior and security, such as the IE Site to Zone Assignment policy I mentioned earlier, or similar kinds of settings. In my experience, there are really very few of those settings in GP, relative to the 1000s of knobs and switches Microsoft provides in the box.

Security, Not Obscurity

I’ll leave you with one last thought about this topic. Often times, I’ve seen folks use lockdown as a replacement for security. It isn’t. If you are not doing the things to secure the core OS, either the user or a bad guy will work around it eventually, and then you’ll be really sorry. Group Policy is a wonderful tool for managing real security configuration in Windows–really the only tool that is free and in the box. If you use it for anything, use it for configuring real OS security and go easy on the lockdown stuff. I guarantee you’ll have less work in the long run, your users will thank you, and you’ll probably be more secure.

Darren