Chapter One
Administering Vista Security: The Little Surprises
Much of this book shows you how Vista's new big security technologies work, how they'll affect you, and where you can control them. This chapter, however, doesn't hit the big stuff; instead, in this chapter I want to introduce you to a bunch of changes in Vista that are fairly significant, but not obvious ... until you run up against the kind of strange, unexpected, or puzzling behavior that I've come to think of as "Vysteries." Now, you might think "hey, if this is a potpourri of small Vista administration and security surprises, why not put it at the end of the book?" I thought about that but realized that if you did want to fire up a copy of Vista and work through some of the things we cover in the rest of the book, then you might find yourself more aggravated from tripping over the small brambles at your feet than from trying to scale the high towers of User Account Control internals and the like-so the first chapter seemed a practical place to put these items.
But let me stress that these aren't all bad surprises. All I'm trying to do in this chapter is give you a quick heads-up about things that I feel have changed most significantly administration-wise, particularly from a security point of view, with a view to highlighting the not-so-well-publicized changes. That way, you can decide best where to spend your time in Windows new doodads. (In addition, I'm hoping to show you these things before some client mentions it in a meeting. Don't you just hate those kinds of surprises?) These aren't in any particular order; it is, again, a potpourri.
Because, as I mentioned in the Introduction, I'm trying to keep this short and because I'm working from pre-release versions of Vista, I'll assume that you've already figured out how to get Vista up and running in at least a minimal manner on a test system or two. That way, we can move right along to the surprises.
Restoring the Administrator
You go to log onto Vista for the first time, and want to log on as the Administrator, just as you always have. But there's this hitch because, well, there doesn't seem to be an Administrator account anymore. Arrgh.
Actually, the Administrator account's still there and can be logged onto. It's just disabled. So here's how to get it back.
First, log onto the Vista system as a local administrator. If you're on a domain, that means that you'll probably need to log on with a domain administrator account, or, if you're not in charge of your domain, then ask your domain administrator to put your domain account in the Administrators group of your Vista machine. If you're using a computer that's a member of a domain, but you can't do either of those things then you're probably stuck, unless you reinstall the Vista box as a member of a workgroup rather than a domain.
Making Your Own Administrator
If, on the other hand, you're running a Vista box that is not a member of a domain, then Vista will prompt you to create a user account when it first starts up. Vista then automatically puts that account in the Administrators group, just as XP did. It won't force you to give that account a password, but it's a good idea to do it anyway because Vista, like XP and 2003, treats accounts with blank passwords as sort of second-class citizens in that they can't be used over a network.
Because that first account is a local administrator, you may not actually need to revivify the Administrator account.
Activating the Administrator Account
Do you, then, need to activate the Administrator account? Probably not. I figured out how to activate the Administrator account in the early days of Vista, but soon realized that I could accomplish anything with that account that Vista prompted me to create that I could do with the Administrator account. In fact, when testing Vista builds 5472, 5536, and RC1 I never even bothered with activating the Administrator account.
I have heard of people needing the Administrator for application compatibility; as some folks have apps coded to run using the Administrator account (not a good idea, but, again, I've been told that some need it). In any case, if you need the Administrator back, then here's the sequence. First, the Administrator account needs a password, as it's currently blank and, as we all know, having an account on a system named "Administrator" with a blank password and that is a member of the Administrators group is a terribly bad idea.
Also, if your system is a member of a domain that has minimum password requirements installed, then you won't be able to activate an Administrator account with a blank password. (Not that the error message that you get from Windows is crystal clear in explaining why it errors out when you try to activate an Administrator account with a lame password; you tell it to activate the Administrator account and it replies something to the effect that "the password does not meet the minimum requirements of this system." You then scratch your head and say, "I wasn't trying to do anything with a password!")
We'll give the Administrator a good password and activate it at the same time. Here's how.
NOTE
Note that in my instructions, I'm using the "Classic Start menu." You'll see that I also run using the Windows Classic theme, which leads to my Vista desktops looking sort of like Windows 2000. I do that mainly for the sake of better speed and quicker response time.
1. Log onto your Vista system with whatever local administrator account you've wangled.
2. Start up a command prompt: click the Start button (it doesn't say "Start" anymore, but it's in the same place as the old Start button, the lower left-hand corner by default and is a circular representation of the Windows flag). Then click All Programs, and then Accessories.
3. I know, I've lulled you into a false sense of "I know what I'm doing now," and you're about to click the Command Prompt icon. Don't. Instead, right-click the Command Prompt icon and choose "Run as administrator." You will see your desktop go gray and you'll see a dialog box warning you that you're about to do something administrator-like, and did you really mean to do that? You then click either a Continue or Cancel button.
4. This is called the "Consent user interface" because the program that kicks it off is called consent.exe. It's part of User Account Control (UAC), which we'll discuss in Chapter 2. You'll see this dialog box every time you do something that requires even mildly "administrator-ness" to work right. It stays up for two minutes, and if you don't respond in those two minutes, you get a dialog box announcing that Windows won't run the program because "The operation returned because the timeout period expired." In any case, click Continue to get Vista to open a command prompt.
5. Now that you've got the command prompt, set the Administrator's password to something other than blank. (And, if necessary, something that makes your domain's group policies happy.) That command looks like net user administrator newpassword. In my case, I'll type net user administrator swordfish to give it the password "swordfish." As with virtually all Windows command-line commands, case does not matter except in the password itself, and you've got to press the Enter key once done. You should get "The command completed successfully."
TIP
But what if you didn't? If you get "System error 5 has occurred. Access is denied," then you didn't start up the command prompt by right-clicking and choosing "Run as administrator." Yes, I know, you're logged on as an administrator, you should be able to do administrator things ... but it's a longer story having to do with UAC, and we'll cover it later. For now, just please remember to always start your command prompts with "Run as administrator" if you want to do anything administrative.
6. Now we've got an administrator with a good password; finish the job and activate the account. From the command prompt, type net user administrator /active:yes and press Enter.
TIP
I did that as two commands for clarity's sake, but you can do it in one: net user administrator swordfish /active:yes will work as well.
TIP
And no matter which path you took, be sure to clear your screen or prying eyes might see that new password. In fact, closing the command prompt window at that point might be a good idea so that no one can press the Up arrow to see what you typed.
Power Users Are Essentially Gone
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, 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. (See Mark Russinovich's blog entry at http://www.sysinternals .com/blog/2006/05/power-in-power-users.html for a more detailed write-up of how these attacks would be launched.)
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
(If you're wondering what all of that Sesomething stuff means, we'll cover it the next chapter.) 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. (There's an even more intrusive one called SeDebugPrivilege, but we'll meet that next chapter.)
(Continues...)
Excerpted from Administering Windows Vista Securityby Mark Minasi Byron Hynes Copyright © 2007 by John Wiley & Sons, Ltd. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
