You Can’t Fake It ‘Til You Make It with Standard Users

I’ve never had a particular interest in being an actor, but if I ever did end up acting for whatever reason, I have a strategy which I’m pretty sure is going to work: I’m going to be Samuel L. Jackson instead of Chris Jackson. Now, I’m not going to do any mad scientist genetic experiments or anything, I’m just going to say I’m Samuel L. Jackson, and then start making movies.

It’s this very strategy which I see some enterprise customers doing.

Today (yes, it’s Saturday – surprise, I’m a geek on weekends too) I had an email dialog that went something like this:

Hey, app compat guy, I’m trying to write an MSI file to Program Files from a standard user account. Can I do that just by changing the ACL?

Well, from the perspective of the operating system, an MSI is just a file, so yes – if you give yourself permission to do a particular task, you are indeed able to begin doing that task. That’s what we call a tautology.

Ah, fantastic. Because they really think it’s inconvenient in general that standard users can’t write to program files, so changing the ACLs sounds like the ticket. Oh, also, how do standard users then go about running those MSIs?

Wait … what?

Yes, I should always think to ask the intent rather than answering the specific question, because the customer was on a trajectory to open up ACLs across Program Files and was then seeking to figure out how to run MSIs as well.

So, basically the customer wanted to have their users be Local Administrators, but they wanted to call them Standard Users.

Another example: I had a customer who was using the Power Users group. They wanted to get rid of Power Users, but because they didn’t want to address their application compatibility issues, they were going to have to give Standard Users all of the same permissions that Power Users once had.

Again – an example where you want to have users have elevated permissions, but pretend that it’s OK because it has a better name.

The fact that the highest privilege group you belong to happens to be called Users (and have the well-known SID S-1-5-32-545) does not matter at all if you give that group the same permissions that local administrators or power users used to have. Calling the group Users does not give you any of the security benefits of running with true standard user permissions. Calling the group Users does not give you the cost savings of running with true standard user permissions. In fact, it’s precisely the opposite. Because you are, in essence, lying about the true nature of your users, not only do you not get these benefits, you THINK that you do because of the name, and then you don’t fix it! And then people get all kinds of confused when they don’t realize any of the benefits of the security posture they think they have.

I advocate moving a significant percentage of users in the typical enterprise to true standard users. There are all kinds of tools which are new to Windows 7 since Windows XP, which means you don’t need all of the XP tricks of opening ACLs (which makes you not quite a true standard user) any longer. But I also appreciate that, because resolving those issues does take time and expertise, you may have to get there gradually rather than in one big bang. But my recommendation, if you can’t get there completely, is to just be honest about what your users truly are. If some still need administrator rights for a while, that’s OK – but then I would just call them that. Don’t call them standard users, but then give standard users all of the power normally reserved for administrators.

Just having the right name is not enough. For, even if I call myself Samuel L. Jackson, people won’t come to the theater to watch me. They won’t buy my DVDs. And I will never, ever sound cool when I say, “Enough is enough. I have had it with these motherf* snakes on this motherf* plane!”

Comments (0)

Skip to main content