Windows Vista Power Users

The Power Users group has always been an attempt by Microsoft to provide a group that wasn't quite as powerful as the Administrators group, as but more powerful than the Users group. That need, as you probably know, grew out of the fact that the permissions and rights that you get from being a member of the Users group just aren't sufficient to allow you to run many applications. Many of us administrators know that we need to wean users away from having local administration accounts, but need to give them more power so that they can run applications. For some folks, the Power Users group was the answer.

Unfortunately, it wasn't a very good answer. Because Power Users have the ability to write to ntoskrnl.exe, the basic Windows program, then an evil (and, of necessity, very smart) Power User could modify that file, giving themselves more powers and escalating their privileges. They also have the ability to modify at least one system service that runs as the LocalSystem account, which would let a crafty Power User log onto the system as the LocalSystem account.

Power Users was created as a Band-Aid to help solve the overall problem of application compatibility because many applications won't work when run from a so-called standard user account.

Tip

Jargon alert: "standard user" is a relatively new Microsoft phrase that you'll hear more and more as you start using Vista. It means "a user who's basically just a member of the local Users group on a machine," with no special administrative powers at all. You'll see this appear in phrases like "once you have all of your users running as standard users…."

The idea with Power Users was to create a group that had just enough administrative powers to allow users to run those troublesome "gotta be an admin to run me" applications. In other words, Microsoft created Power Users to work around the fact that many Windows developers did a lousy job of testing their applications. (And, unfortunately, some of those developers work for Microsoft.) That has led to a world where millions of users are logged into their systems all day as administrators or power users, with the result that the millions of machines that they're working on are prone to security problems.

The alternative solution to the problem of applications that require administrator-level power-chivvying developers into writing software that works properly when run by a standard user-seemed too highly priced before we all starting facing the worms and spyware du jour, but Microsoft has apparently decided that the time has come to ask those developers to pitch in and help solve the security problem.

As a result, Microsoft has essentially eliminated the Power Users group. It's still present in case you've got some resource that has a permission that refers to the Power Users group, but it's "Power" Users in name only, as it basically has the same power as the Users group. To see this change, try creating a member of the Power Users group on an XP system and then use the whoami.exe application found in various versions of Support Tools and the Resource Kit (or built into the OS, in the case of XP x64 and Vista) to find out what privileges that user has. Run whoami /priv and you'll get this list:

SeChangeNotifyPrivilege

SeShutdownPrivilege

SeUndockPrivilege

SeSystemtimePrivilege

SeProfileSingleProcessPrivilege

SeCreateGlobalPrivilege

Do the same thing with a Power User member on a Vista system, open up a command prompt and run whoami /priv and you'll see this:

SeChangeNotifyPrivilege

SeShutdownPrivilege

SeUndockPrivilege

SeTimeZonePrivilege

SeIncreaseWorkingSetPrivilege

Let's make that a bit more understandable by looking first at the things that old and new Power Users have in common and which things they see differently. Both groups have SeChangeNotifyPrivilege, which you may know better as "bypass traverse checking." It means that if a user has NTFS permissions to access a particular folder, but the folder is nested inside folders that the user is denied access, then the user can get to the folder that they do have permission to. (Users have had this permission since NT 3.1.) The other two rights that both XP and Vista Power Users have are SeShutdownPrivilege and SeUndockPrivilege, which mean pretty much what they sound like: the power to shut a system down or to undock a laptop from a docking station.

Both XP and Vista users have the right to modify system time, but in different ways. XP Power Users could change time, date, and time zone. Vista users and Power Users have been granted an altogether new right: the ability to change just the time zone, something that Microsoft added in response to customer demand. You see, regular users don't have the right to change workstation times because Microsoft's always seen that as a security issue. (Certainly it might make Kerberos unhappy in a domain, as domain authentication breaks down if a client's clock is more than five minutes different from a domain controller's clock.) But, people argued, they had regular old users who traveled with laptops and crossed time zones. Admins wanted the itinerant laptop users to be able to change their clock's time zone, but not the time. So Vista has the new "change time zone" right, and Power Users (and Users) have it, but Power Users no longer have the right to change workstation time.

XP Power Users had two rights that Vista Power Users don't have: "profile single process" (SeProfileSingleProcessPrivilege) and "create global objects" (SeCreateGlobalPrivilege). The first was scary because it allows one user to examine a process being run by another user. The idea is this: suppose I wanted to run Performance Monitor and monitor processes that other users are running. That would require the OS to give me the right to gather statistical information about other users' processes. The power is normally used to allow someone to run a program like Performance Monitor to watch things that the system is doing but in theory could be used to spy on someone or even on the system.

The second is a right that controls whether or not users can create something called "file mapping objects in the global namespace." And no, that wasn't an English sentence, but I'll translate. When programs need to read or write disk files and folders, or talk to and from other programs, or control an I/O device like a printer or a serial port, there are often several ways to do that, coding-wise. But one way that's been around for a long time is to treat all of those kinds of I/O as being particular kinds of disk file reads and writes; so, for example, to let one program talk to another program, a programmer could do a lot of complicated coding, or she could have the two programs that she wants to communicate create a sort of imaginary file. Then, when the two programs needed to talk between themselves, they just read or write from or to that imaginary file. Where does security come in here? Well, if I'm just a regular old user and I want to run program A, which talks to program B, then those programs-which logged on as me, because I started them-will need the ability to create these imaginary files, these "file mapping objects." Clearly even the lowliest of users should be able to create one of these; no security worries there. Ah, but now let's add in Terminal Services, and we get a problem. More than one user may have a TS session running on the same system, and each user may run programs that use these file mapping objects. What if they collide, what if User 1 runs a program that creates a file mapping object named "Wally," and User 2 runs a program that tries to do the same thing? That'd be a problem, except for the fact that every user session gets its own separate area or "namespace." Each user in a Terminal Server session, then, has his own "local namespace" in which he can create file mapping objects. But Terminal Services has a way for one user's session to interact with another user's session, through a global namespace for file mapping objects. Being able to monkey around with the global namespace could enable a bad guy to affect other TS users' sessions, so Microsoft removed that ability from Power Users in Vista. Offhand I do not know of any applications that this change would break if you take this right from a user, but it's possible. In that case, just add the right to a particular group and put the user in that group because, again, Vista Power Users (and standard users) lack SeProfileSingleProcessPrivilege and SeCreateGlobalPrivilege.

The Vista Power User has one right that the XP Power User didn't-the right to bump up the amount of memory that a given application uses, the "working set" of that app. Apparently Microsoft needed to create that specific new right for some reason and needed regular users to have it.

Once you've seen the privileges and group memberships of a Vista Power User, try creating a normal user account in Vista and run whoami /priv on it for comparison: you'll see that members of the Users group have the exact same rights as members of Vista's Power Users group.

So Power Users are much less powerful rights-wise. How about Power Users' NTFS permissions, though? Yup, they've been circumscribed. Even my up-to-date, SP2-equipped copy of XP x64 edition that I'm writing this on gives vast powers over the System32 folder to Power Users, vast when compared to what little a member of Users can do…but there's nary a special-to-Power-User permission on any folder of a Vista system that I can find.

*.* Source of Information : Administering Windows Vista Security: The Big Surprises