New Event Viewer

Changes in Security Options

If you've got any security-related responsibilities are all, chances are good that at some point you've opened up the Group Policy Editor either on the local group policy object or on a domain group policy object and navigated to Computer Configuration Windows Settings Security Settings Local Policies Security Options. That folder contains a grab bag of options that let you dial your security up or down. Turn 'em all off, and you're basically running a NT network, circa 1993 security-wise: loose and easily hacked, but compatible with ancient software and operating systems. Turn 'em all on and you'll need to be running only XP, 2003, and Vista systems and new applications.

But most of these security settings are just on/off ones, and they've got to have some default, out-of-the-box value. Microsoft's got to pick those defaults, and it's a tough job. They've been slowly tightening security not just with every version of Windows but often with every service pack, so it should be no surprise that Vista not only continues to offer the same security options as XP SP2 did, but more options, as well, and tighter settings on some existing options. In this section, I'll enumerate which security options settings have changed, and how that may affect your job of fitting Vista systems into your existing network.

Tip 

But don't panic: yes, Vista tightens some security settings that have been left loose for a long time, but remember, these are settings in the local group policy object and can be easily rolled back if necessary. Furthermore, if you're connected to a domain, and that domain has a domain-based group policy object that specifies values in the Security Options folder, then those settings will override the local settings on a Vista system. The only real downside you might experience if you monkey with the security settings a lot would be a little heartburn from Vista when you try to initially join a Vista box to an existing Active Directory domain, but I'll discuss that later.

Note 

A note before we get started: when I say that something has "changed from XP" or "changed from Server 2003," I am referring to the 32-bit versions of XP and 2003. I mention this because as I look at the default settings in the local group policy object of my x64 workstation I note that some of the "new Vista settings" are actually already included in the x64 versions of XP and Server 2003.

Changes to Named Pipe Access

Named pipes are a way for programs to communicate among themselves. Years ago, most named pipes created by the OS were poorly secured or not secured at all. Many hackers successfully attacked Windows systems through poorly secured named pipes. One of the easiest avenues for these sort of attacks was by connecting as an "anonymous" user. This is a once-obscure but sadly now well-known way to connect to many Microsoft protocols and, as its name suggests, you needn't use a username and password to log in; you can, instead, remain anonymous. While allowing anonymous users any access to a Microsoft network resource isn't a very good idea, the fact is that for backward compatibility purposes Windows still uses some anonymous connections. Microsoft's been slowly removing the anonymous user-if I recall right, the first code to reduce the power of "anonymous" was as far back as 1998 with NT 4.0 SP3-but it's still around, and Vista takes up cudgels to reduce its power-and threat-a bit further, in these changes in how named pipes handle anonymous users.

Windows has, since XP at least, had a Security Options setting "Network access: Named Pipes that can be accessed anonymously." It lists a subset of the system's named pipes that you need the anonymous user to be able to access, and by default the group policy setting has included a bunch of stuff that doesn't really make sense:

• COMNAP and COMNODE only appear on a server running Microsoft's gateway software for talking to an IBM mainframe, their "Host Integration Server" (HIS). To the best of my knowledge, it's not possible to run HIS on any of Microsoft's desktop OSes.

• SQL\QUERY would appear on a system running Microsoft SQL Server or its equivalent. It's possible that a Vista system might be running SQL Server Express 2005-although not possible, I am told, to run its predecessor, Microsoft Desktop Engine (MSDE)-but not likely.

• LLSRPC appears only on servers running the Licensing Service. Why Microsoft would want anonymous people accessing the Licensing Service is a puzzle, and in no case would it appear on a desktop OS.

• BROWSER allows a system to act as either a master browser or backup browser on a subnet; this pipe is how the master and backup browsers talk. If the backup and master browser on a given subnet are not members of the same forest, then they need to be able to anonymously access the BROWSER named pipe so that the master browser can send the backup browser a copy of the segment's browse list. Microsoft has kept BROWSER in the list of named pipes that can be accessed anonymously because of that case where a workgroup might have backup and master browsers. In any case, the chances that it's a desktop OS are small, but not impossible; one could imagine a small home workgroup built entirely of Vista systems. But in that case we'd probably be talking about a single segment, where broadcasts could handle any name resolution needs.

Vista's default setting for "Network access: Named Pipes that can be accessed anonymously" removes all of those named pipes, leaving just one: SPOOLSS. That works with the print spooler, and that's a server role that is quite common for desktop OSes.

Why did Microsoft have so many silly named pipes in XP's default set of group policy settings? They were just saving themselves a little trouble by creating a set of defaults that they could apply both to server OSes and workstation OSes. With Vista, it looks as though that's no longer true, and the desktop has gotten its own set of settings.

Changes to Share and Registry Access

Criminals wanting to penetrate a system anonymously have avenues other than named pipes. Windows systems also feature a variety of built-in shares, and some can be accessed anonymously-or could be, before Vista. By default, XP allows two shares to be accessed anonymously. They are named in a Security Option setting named "Network access: shares that can be accessed anonymously." The two named on XP are COMCFG, which is related to the Host Integration System, and DFS$, which is necessary for a server hosting a Distributed File System root. Since Vista can't host HIS or a DFS root, they're both gone in Vista, and "Network access: shares that can be accessed anonymously" features an empty box.

Another avenue for bad guys is to read parts of the Registry remotely, as it reveals inner details about the system. Some Registry paths clearly must be accessible over a network for networking and remote administration to function, and those are named in the Security Option setting "Network access: remotely accessible registry paths." Where it names nine paths in XP, there are only three in Vista.

LM Deemphasized, NTLMv2 Emphasized

Vista changes two items in Security Options in a way that I personally like a lot, but I want you to understand what they might do to your network compatibility. The two settings are

• "Network security: Do not store LAN Manager hash value on next password change" is now enabled, even though it had been disabled by default until now.

• "Network security: LAN Manager authentication level" changes from "Send LM and NTLM" to "Send NTLMv2 response only."

First, a little background. It's nice that we've got machines called domain controllers (DCs) that centrally store usernames and passwords so that every machine doesn't have to carry around a complete list of all usernames and passwords. But having central logon services means that you've got to figure out how to use those services safely. I say that because if I'm sitting a Workstation A and offer it my domain name and password, then how's Workstation A going to ask Domain Controller B to verify it? It's not a very good idea to ask across the network "hey, Domain Controller B, I've got a guy here who says he's a guy named Mark with password ‘swordfish,' does that sound right?" It'd be a bad idea because people can easily listen in on network traffic.

So, instead of making DCs and workstations reveal secrets across the wire, Microsoft and other vendors do something a bit more crafty. When the workstation says to the DC, "I want to log Mark in, can you verify that this is indeed Mark talking to me," the DC replies "okay, I know Mark's password, and you've got the password that the would-be Mark offers. So here's a big random number. Take it and encrypt it, using the password that this might-be-Mark guy offered. Then send the encrypted result back to me." The workstation takes the random number (which is called the challenge), encrypts it with offered password, and sends that encrypted number (which is called the response) to the DC. Meanwhile, the DC also encrypts the challenge, using the password that it has on file for Mark. If the response from the workstation matches the encrypted challenge, then the DC knows that the password typed in to the workstation is indeed the correct one, without the workstation having to transmit the proffered password.

Now, that's just the broad outline of how this kind of authentication method, called a "challenge-response mechanism," works. The devil's in the details: complex encryption's hard to crack (and that's good) but requires more CPU power, long keys are harder to crack but also require more CPU power and make logons slower (and that's bad), so the OS vendor has to weigh its choice of encryption methods and key lengths carefully. As time has gone on, Microsoft has created three different challenge-response mechanisms: the late 1980s offered "LM," short for "LAN Manager," which was replaced in the early 1990s with "NTLM," the NT version of the LAN Manager logon protocol, and in the late 1990s Microsoft created a far better challenge-response mechanism called "NTLMv2." There's also Kerberos, an authentication method used most in the time in Active Directory, and that appeared with Windows 2000 in early 2000. But even a network with the most state-of-the-art stuff will sometimes fall back from Kerberos to either LM, NTLM, or NTLMv2. That's not really a wonderful thing, as Kerberos is considerably more secure than the other three, but there is no way to banish the "LM family" altogether. But if you want to keep your network secure, then it'd be best to ensure that if

Kerberos isn't available then your systems should use NTLMv2 rather than the older, less secure challenge-response mechanisms.

If NTLMv2's been around for nearly 10 years, why aren't we all using it now? Why hasn't LM and NTLM been banished for years? It's the same story as before: compatibility. If you've got some older computers in your network (Windows 9x, for example), then it's some work getting them to talk NTLMv2; MS-DOS systems and Windows for Workgroup systems will never talk NTLMv2. Alternatively, if you've got third-party network-attached devices like some of the Network Attached Storage (NAS) boxes like, for example, an old Quantum Snap Server, then a device like that might not understand NTLMv2.

Every modern copy of Windows knows how to log on using either the LM, NTLM, or NTLMv2 challenge-response methods, but which of those methods does it choose? You configure that with a setting in Security Options, "Network security: LAN Manager authentication level." By default an XP box will, when offered a logon challenge, compute two responses: the LM and NTLM response. As both of those responses are encrypted with an encryption algorithm that has been cracked in the past and gets easier to crack with every passing year as CPUs get faster, automatically responding LM and NTLM responses becomes less and less ideal all the time. Vista's default is different, and by default it offers the NTLMv2 response.

Will this new default cause you trouble? Well, any 2000, XP, 2003, or Vista system acting as a server can understand and use an NTLMv2 response, so if your Vista clients always produce NTLMv2 responses then you'll probably be okay. But, again, check your network-attached devices, like those convenient little print server things the size of a deck of cards that will let you put a printer anywhere and make it available on the network. As with all hardening processes, testing is important.

Vista also hardens systems a bit by keeping your systems from creating something called "LM hashes." Whenever you type a password into your computer, the computer doesn't store your password anywhere. Instead, it takes you password and subjects it to a mathematical function called a "hashing function" that reduces the password, no matter what length, to a 128-bit number. That's what gets stored on your computer and on your domain controllers, not your password; instead, the "password hash" is stored. Why do that? Because if someone gets your hash, then reversing the hash process and figuring out your password just by looking at the hash should be nearly impossible, if the system's designed right. Microsoft first started doing this back in the LAN Manager days of the late 1980s, and the hashes created and stored by LAN Manager are known as the "LM hashes." In designing the method of storing LM hashes, Microsoft built a fairly good hashing system given the power of computers at the time, but they made one serious error. By looking at the LM hash of someone's password, anyone can instantly determine whether the password that resulted in the hash was fewer than eight characters. Being able to instantly be certain that a particular password was seven characters or fewer is a powerful tool in the hands of bad guys.

With the advent of NT 3.1 in 1993, Microsoft used a different and more secure method of hashing. But Microsoft needed to worry about backward compatibility, and so whenever you changed your password, then NT created and stored two hashes: the LM hash and an "NT hash." Remember, if a bad guy gets your hashes, then he doesn't need to crack them both-cracking the LM hash will give him your password without any need of help from the NT hash. Storing LM hashes is potentially security nitroglycerine, but Windows XP and 2003 still create LM hashes by default. There's been a setting in Security Options, "Network security: Do not store LAN Manager hash value on next password change" in Windows for years, but Microsoft's disabled it by default because, again, older operating systems and network-attached devices may fail if they can't get LM hashes. That changes with Vista.

Personally, I shut LM hashes off my network in 2002 and haven't missed them, and I think that if you can tell your systems to stop creating LM hashes, then you should jump on it-but, again, I would strongly suggest doing some testing first. Vista, however, takes a stronger position and is the first version of Windows to shut off LM hashes right out of the box.

No More Unsigned Driver Warnings

Just about anyone who's ever worked with 2000, XP, or 2003 for any time at all has had to load a driver for a new piece of hardware, or perhaps had to update a driver on an existing piece of hardware. A good portion of the time, trying to install that driver meets with a dialog box containing a dire-sounding message to the effect that you are trying to install a driver that has not been signed by Microsoft's Windows Hardware Quality Labs (WHQL, pronounced "whickel" so as to rhyme with "nickel."). This, the message seems to intone, is a perilously foolish idea but, hey, it's a free country and you are certainly welcome to destroy your operating system; just don't say we didn't warn you, it seems to say.

No, that's not the exact text of the dialog box, but it's the spirit. You see, Microsoft's WHQL labs offer a set of rules to follow when writing a driver or for that matter anything that contains low-level, "kernel mode" code. If you follow those rules to write the driver, and then buy a digital certificate to sign the driver, then you can submit it to Microsoft's WHQL labs to be tested for compatibility. (As of August 2006, the test costs $250 per driver per operating system; "XP" covers all varieties of XP, so submitting a driver for signing for both XP and 2003 would cost $500, according to "Global WHQL Policies Document," found at http://www.microsoft.com/whdc/whql/policies/default.mspx.) If the driver passes, then WHQL signs your driver with Microsoft's certificate. If Windows sees that signature when you try to install a driver, then you don't get the baleful-sounding warning message.

Most hardware vendors don't particularly want to have to pay Microsoft $250 every time the hardware vendor updates a driver, and so they don't bother, kicking off the warning message. I honestly don't know enough about how thorough the WHQL guys are to intelligently comment about whether or not this whole WHQL signing thing is just a revenue stream for Microsoft, or a seriously good idea. In any case, the only reason that you ever see the warning is because of a Security Options setting "Devices: Unsigned driver installation behavior." On 2000, XP, and 2003, it's got three options: "Do not allow installation," "Warn but allow installation," or "Silently succeed." The default was "Warn but allow installation." But if you look for "Devices: Unsigned driver installation behavior" in Security Options on a Vista system, you'll find that it's gone altogether. That's because Microsoft decided to take a hard line on drivers for the 64-bit version of Vista, and require that all 64-bit drivers for Vista be signed by WHQL. That's a pretty stringent requirement in my opinion, and that's not just a bystander's point of view-remember, I'm a 64-bit kinda guy, and that driver thing is in my top five reasons why I might not be able to roll out Vista as quickly as I'd like. In any case, you can read more about this 64-bit driver issue in detail in Chapter 6.

But wait a minute; the Security Options item goes away, and 64-bit Vista requires signing; what about 32-bit? Well, inasmuch as 32-bit Vista is, according to Microsoft, the last 32-bit operating system that they'll ever create, I guess they decided not to worry quite as much about security (which is the supposed reason for driver signing) and just tell 32-bit Vista to allow unsigned driver installs to silently succeed. It's a good change in my opinion, as I have never, ever seen anyone not load a driver because of the dialog box's message, and I have seen the "are you sure?" dialog get in the way of some unattended installs.