4 Windows NT/2000/XP/2003 Overview Pretty Much Everything You Need to Know about Windows to Follow the Rest of This Book

Sure, the Almighty could create the world in six days. He didn’t have to deal with any legacy infrastructure!

—A common lament from system developers trying to support backward compatibility

Introduction

It’s about 3:30 Sunday morning, and you can’t sleep. You wander out to the living room and turn on the television, flipping through the channels looking for something to watch in the hopes that it’ll make you drowsy. As you skip past the infomercials and the pundits discussing whatever pundits discuss this early in the morning, you happen across an old black-and-white Western. The movie has arrived at the critical scene: The legendary gunslinger, who has sworn to give up his past for the woman he loves, has been “called out” by some young upstart looking to make a name for himself. Once again, over the fervent pleadings of his favorite gal, the gunslinger is strapping on his shootin’ irons and preparing to meet his destiny on the dusty street at high noon.

Just like an Old West gunslinger, an operating system’s “target-ability” is, in essence, directly tied to its popularity and reputation. Like the hero of our early-morning movie, if you’re well known, there is always someone waiting for you around the next corner who wants to prove something. If you happen to be the most widely used operating system platform on the planet, you’ve got a target painted on your back a mile wide.

In the last chapter, we gave you a quick overview of Linux and UNIX and told you that a working knowledge of their internals was necessary because of their popularity as platforms on the Internet. Although Linux and UNIX are indeed popular platforms, from the perspective of sheer numbers, the operating systems from a little company in Redmond, Washington, truly have no match. Love it or hate it, you cannot dispute that the number of Microsoft Windows machines in use today is staggering. As of May 2005, it was estimated that there are 390 million installations of Windows operating systems worldwide, with over half of those being some form of Windows XP. With such an overwhelming installed base, Windows operating systems are an obvious target, and it is important that you have a working knowledge of Windows to understand much of what we cover in the chapters to come.

In this chapter, we take a look at the different Windows operating systems to see how security is structured and to analyze the specific security mechanisms they offer. We start by discussing the history of the various Windows NT core operating systems. Then, we turn our attention to fundamental concepts, various architectural components, and security options found in the different versions of these operating systems. Additionally, we closely examine the latest versions of Windows (Windows 2000, XP, and Server 2003) to determine the changes that have occurred in these newest releases of the Windows NT family and their impact on security.

A Brief History of Time

Time, from a modern Windows security perspective, began in April 1993 with the first release of an operating system based on the Windows NT (“New Technology”) core. Although there were other Microsoft products bearing the name “Windows” prior to that time, they simply cannot be discussed from security perspective (setting aside the question of whether they could actually qualify as true operating systems) because they lacked even the most fundamental aspects of security. Windows 3.0, 95, 98, and Me were seriously deficient from a security perspective, lacking even the fundamental controls associated with isolating programs, authenticating users, and logging events. Because of this, and their significant decrease in popularity today, this book does not address these ancient Windows operating systems. We focus instead on so-called modern Windows machines, starting with Windows NT and growing through Windows 2000, XP, and Server 2003.

Windows NT was based, in large part, on technical concepts pioneered by Digital Equipment Corporation (DEC) in their VMS operating system. In August 1988, Microsoft hired David N. Cutler from DEC’s recently canceled next-generation operating system dubbed Mica, to head Redmond’s development effort on an operating system designed to challenge the UNIX domination of the server market. While at DEC, Cutler was the project leader and one of the major architects of VMS, DEC’s enterprise class operating system, and when he agreed to come to work for Microsoft, he did so on the condition that he could bring approximately 20 former DEC employees from the group developing Mica along with him. This group, made up almost exclusively of programmers who developed VMS, was the core of the project team for what would become Windows NT.

Originally, the group was tasked with developing a successor operating system to OS/2 (Microsoft’s joint operating system venture with IBM), and indeed, their project was originally named OS/2 NT. With the overwhelming success of the launch of Windows 3.0 in April 1990, Microsoft’s vision for their UNIX-beating operating system changed: OS/2 and IBM were out, and Windows NT was born. Along with this change, however, came many of the “backward compatibility” issues that plague Windows operating systems even today.

Backward compatibility is a term used to describe the ability of new and improved versions of a product to continue to work with older, less capable versions. In the world of operating systems, this means being able to run software designed for older operating systems, network with older operating systems, and read the various storage methods used by older operating systems. As the quote at the beginning of this chapter laments, time and again, the requirement for backward compatibility has caused design difficulties and required that compromises be made that eventually weaken new products. As we delve into the security aspects of Windows operating systems, we will find this theme is repeated time and again. However, as we lament the security issues resulting from backward compatibility, we likewise complain when a vendor (whether Microsoft or another) breaks backward compatibility for our favorite applications or features. So, the vendors are damned if they do and damned if they don’t from a backward compatibility perspective. It almost makes you feel sorry for them ... almost.

Following the successful launch of Windows NT in 1993, Microsoft released Windows NT 3.1, then 3.5, 3.51, and 4.0. After a major overhaul to the user interface and many delays, Microsoft released Windows 2000 (which is actually Windows NT 5.0) in February 2000, following up with Windows XP (could that be NT 5.1?) in October 2001. Interestingly, in some of its internals, Windows XP actually refers to itself as Windows 2002. Windows Server 2003 (which is, in essence, the server version of Windows XP) was released early in 2003 (thus, its name).

With the release of Windows XP (“eXPerience”), Microsoft finally managed to mend the self-imposed split in its operating system lines. From 1993 until 2001, Microsoft marketed two distinct operating system families: Operating systems that evolved from the original Windows 3.0 (Windows 3.1, Windows 95, 98, and Me) were targeted toward the home desktop user, whereas Windows NT core operating systems (NT 3.1, 3.5, 3.51, 4.0, and Windows 2000) were targeted toward the business, professional, and server market. Windows XP is an offspring of Windows 2000, evolving from the earlier “professional grade” operating system with the addition of many features aimed at the home user. Although this reintegration of Microsoft’s products is a good thing for the home user, giving them increased security and stability (in the form of reliable memory protection and a security-aware file system), in many ways it introduced other backward compatibility issues that are only now beginning to surface.

Whenever we speak generically of Windows, this chapter focuses on Windows XP, the most widely deployed Windows version in history, except where other versions are explicitly mentioned.

The BAD (Before Active Directory) Old Days

With the advent of Windows 2000, Microsoft introduced a new method of organizing networks called Active Directory services. With the birth of Active Directory, Microsoft dramatically shifted the security architecture of its entire operating system line. Later in this chapter we examine Active Directory in detail, but for now we need to touch on one aspect as an introduction to what follows. Active Directory is a kind of all-in-one service that allows (or disallows) users and programs to find the “stuff” they need within the hodgepodge of interconnected layers in the average modern organization. That “stuff” might be something as simple as sending a document to the printer in the next cubicle, or something as complex as changing the password policy for a group of 500 machines at a branch office in Singapore. What matters most, however, to the discussion at hand is that Active Directory is designed to be used in two different ways. Active Directory can be used in what is known as native mode, where all of the important machines on the network are running Active Directory, as well as in mixed mode, where there is a mixture of both old (pre-Windows 2000) and new machines running. Earlier, we described the average corporate environment as a “hodgepodge of interconnected layers.” Which way do you believe most Active Directory installations run? Because of the realities of finances, software compatibility issues, and just plain inertia, most Active Directory installations still run in mixed mode and carry with them many of the legacy issues of the older, pre-Windows 2000 systems. It is therefore important that you understand not only how Active Directory works, but also that you understand what came before and how this backward compatibility affects even the most up-to-date technologies. Additionally, many of the concepts central to Active Directory had their genesis in the fundamental concepts first introduced by Microsoft when Windows NT was brand new.

Fundamental Concepts from BAD, or “This Stuff Still Matters, So Pay Attention”

Windows Domains: Grouping Machines Together

The concept of the Windows domain was central to Windows networking prior to the arrival of Active Directory, and even though it is currently deprecated, it is still an important concept when discussing Windows networking. A domain is simply a group of one or more networked Windows machines that share an authentication database. An authentication database is a single collection of usernames and password representations that allows a user with the correct credentials to access the resources within that domain. The advantage for users is that they can log on to the domain to access resources and services on various machines within the domain, rather than having to log on individually to each server.

The domain concept presupposes some sort of centralized controlling authority, and indeed, for a domain to exist, you must have at least one special type of server called a domain controller. In a real-life setting, however, domains usually have more than one domain controller. Although domain controllers serve numerous purposes, their most important raison d’être is to authenticate users who are attempting to log on to the domain.

The most important single server in a domain, the first one you install when you set up a domain, is called, unsurprisingly, the Primary Domain Controller (PDC). The PDC keeps and updates the master copy of the domain authentication database, which is sometimes called the SAM database, because it is stored in a file that is named for the Security Accounts Manager, one of the subsystems in Windows. It contains all of the information about user accounts, such as user IDs and password hashes. Prior to the advent of Active Directory, PDCs were the sole guardians of the SAM database, and the other domain controllers on the network behaved differently. These secondary domain controllers were called Backup Domain Controllers (BDCs), and although they also contained a copy of this database, it was the PDC that updated and distributed any changes over the network. If the PDC ever crashed or became dysfunctional, a system administrator could temporarily promote a BDC to serve the function of a PDC until the PDC could be repaired and resume its function.

Under Active Directory, all domain controllers are authoritative and so there is no longer a distinction between primary and backup domain controllers—every one is a domain controller. Changes made to any domain controller are propagated to all domain controllers. This is good news from a robustness perspective—your domain is no longer reliant on a single point of failure. From a security perspective, however, it provides an attacker with several high-value targets where before there was only one.

Domains can also provide a common mechanism to set many critical variables such as minimum password length, password expiration, policies that restrict what users can do, and so forth, across an entire group of systems. Often, small office or home networks will be configured as workgroups, an alternative to organizing servers into domains. These configurations do not provide any common control mechanism. Worse yet, workgroups do not support certain types of critical control mechanisms such as privilege control, which we discuss later in this chapter. A workgroups is, in essence, a single, closed peer-to-peer file sharing system.

Shares: Accessing Resources Across the Network

From a user perspective, shares are the single most important functions of a Windows network, whether in a workgroup, regular domain, or Active Directory environment. A share is a connection (usually remote) to a particular network device such as a hard drive. Shares are very similar in concept to Network File System mounts in Linux and UNIX, although the underlying protocols and mechanisms differ significantly. Most often, users connect to a share by using Windows Explorer’s My Network Places category, then finding the icon with the appropriate location and double-clicking it. Alternatively, users can use the command prompt to enter this to mount a share:

C:> net use \[IP address or hostname][share name] [password] /user:[username]

Once they are connected to a share, users can access objects (e.g., files, directories, etc.), depending, of course, on the particular permissions that apply to these objects. Shares are good from a user standpoint because they provide a convenient and reasonably efficient way to reach objects across the network.

The Underlying Windows Operating System Architecture

Figure 4.1 provides a high-level depiction of the current architecture of operating systems based on the original Windows NT core (that is, Windows NT, 2000, XP, and 2003). Although there have been some very significant changes to the functionality of Windows since NT was originally released, with only a few exceptions, the overall architecture has remained the same. Like most modern operating systems, Windows is designed as a series of layers, with each higher level layer communicating only with the layers above and below it. This layered architecture is important from a security perspective because it can be used to tightly control what is and is not allowed to happen on a machine. Security issues are nearly always a result of some sort of compromise of this layering.

Figure 4.1 A high-level depiction of the Windows NT core architecture.

Fundamentally, the Windows architecture is made up of two modes, user mode and kernel mode. To understand what is happening behind the scenes in Windows, let’s explore these two modes in more detail.

User Mode

As its name implies, user mode includes those portions of the operating system that provide support for user interaction. User mode’s various parts, or subsystems, each play a different role and provide different services to the end user. Because software running in user mode cannot access the hardware of the system directly, user mode services act as a “go between” with kernel mode (which can access hardware) through a strict set of communication guidelines known as Application Program Interfaces (APIs). Within user mode itself, there is a split between two different types of services: those offered natively within Windows itself, called Integral subsystems and those offered in support of other operating systems, called Environment services.

Within the Environment services, there are several individual subsystems that each provide an API that is specific to applications for a particular alternate operating system type. Natively, Windows provides support for POSIX (a standardized, committee-driven UNIX-like environment), OS/2 (that old IBM system we discussed earlier), and Win32 (named for the 32-bit address space it includes for memory referencing) subsystems. One benefit of designing the Environment services in this way is that it is possible to add support for applications for other operating systems by simply writing a new subsystem and plugging it into the existing architecture.

The Integral subsystems are services that provide the APIs that Win32 applications call to perform important operating system functions, such as creating windows on the screen and opening files. Integral subsystem functions include process management (creating, tracking, and terminating process threads), Virtual Memory Management (VMM) functions (allocating, sharing, and protecting process memory), input and output (I/O) functions (to the network, printers, drives, serial ports, parallel ports, etc.), and security functions including portions of Active Directory. Applications running in user mode cannot place calls directly to the Win32 kernel functions themselves, but rather, they interact through subsystem Dynamic Link Libraries (DLLs). These subsystem DLL files translate the documented Win32 system API calls into undocumented Windows system service calls into the kernel itself. In this way, these user mode subsystems are tied into their kernel mode counterparts in the kernel Executive subsystem.

Security Functionality in User Mode: LSASS

Security-related functions are handled by the Security subsystem, also known as the Local Security Authority Subsystem Service (LSASS), which plays a critical role in Windows security. Simply put, this user mode subsystem determines whether logon attempts are valid. When a user enters his or her username and password during the logon process, the Security subsystem sends these entries to a facility called the SAM. The SAM has an authentication database, which we discussed earlier, colloquially called (not surprisingly) the SAM database. Normally, on a default install of Windows, there are two password entries in the SAM database for every user account.

“Two password entries?” you might be thinking. “Why two?”

Remember our earlier admonition about the evils of backward compatibility? Get ready for a prime example.

One entry in the SAM database is called the NT hash, which holds a cryptographic hash of the password used for compatibility with Windows systems based on the NT core. The other entry (called the LM password representation) contains a representation of the user’s password for purposes of backward compatibility with older or less sophisticated Microsoft products, such as LanMan (that’s where the LM comes from), Windows 95, 98, and Windows for Workgroups.

Therefore, by default, the SAM database contains two representations of each password (the LM representation and the NT hash). Additional, optional entries can also be made after the NT hash. Figure 4.2 provides an example of entries for four accounts in the SAM database.

Figure 4.2. Entries in the SAM database.

Note that each line in Figure 4.2 consists of a set of entries: the account name, a unique number identifying each user account known as the Relative ID, the LM password representation, the NT hash, and several optional fields. Each of these fields is separated by a colon. Also, whereas UNIX systems store their passwords in plain-text ASCII files, you won’t be able to find a file on your Windows system that contains lines like those in the entries just listed. On Windows, the SAM database is actually stored in binary form. So where did those password lines come from? You can use a specialized tool to extract the SAM database information into a readable form. By dumping the password hashes in a format that can be read by certain password cracking programs, network administrators can audit the strength of passwords chosen by their users. A program that can be used to dump Windows passwords into a human-readable form is pwdump3. Alternatively, the Cain password cracking tool we’ll discuss in Chapter 7, Phase 3: Gaining Access Using Application and Operating System Attacks, is capable of extracting this information from the SAM database.

For more information about extracting Windows password representations and cracking them, please refer to the Chapter 7 section titled “Retrieving the Password Representations from Windows.”

How Windows Password Representations Are Derived

The LM and NT password representations for each account in Windows are derived in two fundamentally different ways.

The LM representation is derived by adjusting passwords shorter than 15 characters in length to exactly 14 characters, by padding the password with blank characters. In Windows 2000 and later, if a password is 15 or more characters in length, no LM representation is stored for that password. Instead, only the NT hash is created and stored in the SAM. But, for the vast majority of passwords, which are less than 15 characters, an LM representation is created. After padding, the resulting padded password string is then divided into two equal parts, each seven characters in length. One character of parity (needed for Data Encryption Standard [DES] encryption) is added to each part, and each part is used as a key for DES encryption of a hexadecimal number. The LM representation is incredibly weak. Splitting the string into two seven-character parts to form the LM representation allows an attacker to guess pieces of the password independently of one another, speeding up the process of password cracking. It’s a lot easier to guess two seven-character passwords than it is to guess one 14-character password. To get a feel for why, suppose I told you I was thinking of two numbers between one and 10 million (that’s 10⁷), which might be the case if I used only numeric digits in my password (kind of a dumb password restriction, but it helps make this point). Alternatively, what if I told you I was thinking of a number between one and 100 trillion (i.e., 10¹⁴)? Start guessing now. Clearly, you’ll likely guess the two numbers less than 10 million first, unless you were extremely lucky or cheating. That’s why the LM representation’s splitting of the password into two pieces is so weak from a security perspective. It’s like they went out of their way to design it to be weak.

Additionally, if a mixed-case password is used, as is often suggested as a means of making passwords more difficult to guess, the LM representation is calculated only after all characters have been converted to uppercase, dramatically decreasing the number of possible character combinations. Thus, an attacker could guess any mixture of case for a target password and still get access to the system even if the case is wrong (provided that the letters, numbers, and special characters themselves are correct).

The NT password hashes are far stronger, but not unassailable. For the NT representation of the password, the MD-4 (Message Digest, version 4) hashing algorithm is used three times to produce a hash of the password. Note that the LM representation is neither a hash nor an encrypted password. It is really nothing more than an encrypted, fixed hexadecimal number in which the password was used as a key. The NT representation, in contrast, is a hashed password because a hashing algorithm was used to derive it.

There is a flaw in the algorithms used to produce Windows password representations, both of the LM and NT variety. The password representations are not salted. Salting means that one of a large number of permutations of the encryption algorithm is randomly chosen, then used to craft the password representation. Salting makes password cracking via dictionary-based tools much harder because these tools have to determine the salt, and then apply it in the password generation algorithm. Because Windows passwords are not salted, dictionary-based password crackers need to try only one encryption or hashing for each candidate password, speeding up the process of cracking considerably. UNIX systems use salts to make password cracking far more difficult.

For details about cracking passwords very quickly by taking advantage of saltless Windows machines, refer to the Chapter 7 section titled “Configuring Cain.”

As we said earlier, by default, Windows stores both the LM and NT password representations for each user. Because the LM passwords are far more easily cracked, in situations where they are not necessary (on a network where there are no Windows 95 or 98 machines, for instance), it is strongly suggested that they be disabled. This is possible only for Windows 2000, Windows XP, and Windows 2003, and information on how it can be accomplished can be found at support.microsoft.com/default.aspx?scid=kb;EN-US;q299656.

Just how much easier are LM passwords to crack than their NT counterparts? All things being equal, an eight-character LM password representation is about 890 times easier to crack than its NT hash counterparts should be, and a 14-character LM representation is about 450 trillion times easier to crack than its NT hash counterpart.

Kernel Mode

Although both user and kernel modes have built-in security, kernel mode, which is reserved for fundamental operating system functionality (including access to both memory and hardware), is the more secure of the two. Several of the important subsystems within kernel mode are collectively called the Executive subsystems. These include the Input/Output Manager, Security Reference Monitor, Process Manager, Memory Manager, and Graphics Driver Interface subsystems.

Of all the Executive subsystems, the Security Reference Monitor is the most important from a security perspective, as you’d no doubt expect given its none-too-subtle name. By checking and then approving or rejecting each attempt to access kernel mode, the Security Reference Monitor serves as a kind of “master guardian” of kernel mode. The Security Reference Monitor also serves a parallel function for initial user- or program-based attempts to access objects such as files and directories. It checks to make sure users and programs have appropriate permissions before access is allowed. Finally, it defines how audit settings translate into the actual capture of events by the Event Log.

Much Windows functionality (including security-related functionality) is predicated on the operation of the Object Manager, a critical subsystem that manages information about objects within the system. Objects include files, directories, named pipes,¹ devices such as printers, plotters, CD-ROMs, and others. The Object Manager assigns an Object Identifier (OID) to each object when the object is first created. This OID persists for the life of the object and is used by the system to refer to the object. Whenever an object is deleted (e.g., when a user drags the icon for a file to the Recycle Bin, then empties it), the Object Manager deletes the OID for that object.

Windows is, in a very limited sense, a type of object-oriented operating system in that it allows for hierarchical relationships between some types of objects. Folders (which are actually representations of directories) can contain other folders as well as files, for example. The Object Manager is aware of these relationships and their impact on the inheritance of ownership, file, and directory permissions. Creating a file within a folder, for example, will result in the ownership and permissions of the directory being assigned by default to that file.

In addition to managing objects and security, the kernel also performs all of the “normal” underlying operating system functions such as controlling the scheduling of processes and input/output operations.

Finally, kernel mode also includes something called the Hardware Abstraction Layer (HAL). This is a layer of software that is designed specifically to deal with the underlying hardware, but in a high-level manner. The actual specifics of dealing with the hardware at a low level are left to numerous device drivers. This “chain of command” makes it far easier for Windows to support a wide variety of hardware by requiring hardware manufacturers to provide drivers that allow their products to work with Windows. As Windows has evolved from NT to XP and 2003, problems with substandard drivers have become a major headache. Because drivers run deep within the heart of kernel mode, a buggy driver can easily crash the whole operating system. With the advent of Windows XP, Microsoft began a certification program for device drivers in an attempt to increase the stability of the operating system as a whole.

The other main advantage of abstracting hardware access through the HAL is that the original Windows NT supported several different types of hardware platforms, including x86, MIPS, and ALPHA processors. Much of the “higher level” functionality of the operating system was able to remain static over these different hardware layers, while all the mucking about with different architectures was being taken care of by a combination of the HAL and appropriate device drivers. Unfortunately, as Windows has evolved, Microsoft has discontinued support for all non-x86 hardware.

From Service Packs and Hotfixes to Windows Update and Beyond

As vulnerabilities are continuously discovered, every operating system vendor releases upgrades and fixes for their product; Microsoft is by no means the exception to this rule. Fixes and upgrades to Windows used to come in two flavors—Service Packs (SPs) and hotfixes. Hotfixes deal with one specific problem, whereas SPs are, in effect, a tightly bundled set of fixes. One cannot, for example, choose to install all but one feature for a given SP.

Although the designation of “Service Packs” still exists, as Microsoft remarketed the NT core toward consumers, the term hotfix has fallen by the wayside. Understanding that its new consumer market wasn’t going to test each and every new fix or function carefully, Microsoft initiated its Windows Update service, and, with the advent of Service Pack 2 (SP2) for Windows XP, made the activation of this feature nearly mandatory. Windows Update essentially takes care of applying “patches” (the current parlance for hotfix) automatically by default. Users can opt out of automatic patches, but most consumers utilize the service.

Unlike SPs, individual patches are designed to address a very specific problem such as a programming flaw that allows an attacker to crash systems remotely or execute code of the attacker’s choosing. Vast groups of patches are incorporated in SPs, but not immediately. Usually, after a reasonable amount of time has gone by since the previous SP was released (e.g., six months to a year), the most recent sets of patches are rolled into an SP and released.

In companies with a large deployed base of Windows machines, patching, no matter how automated the process, can cause considerable pain and suffering. In response to customer requests to make the update process more predictable, in 2004, Microsoft began issuing all but the most critical updates on a scheduled basis on the second Tuesday of every month (now known in many Windows shops as Black Tuesday). Some Black Tuesdays are quiet events, with a few routine fixes applied at a leisurely pace. Others (quite a few, in fact) are intense onslaughts of work, requiring huge effort, careful concentration, and thorough gnashing of teeth to test and apply the fixes before the release of a seriously nasty worm.

Additionally, in response to criticism, Microsoft has upgraded the Windows Update service to patch not only the operating system itself, but other Microsoft products as well, such as Microsoft Office, as patches become available. Also, if you are supporting a large number of Windows machines, Microsoft has software available called Windows Server Update Services (WSUS), which allows you to create, in essence, your own local Windows Update server. With WSUS, enterprise administrators can download patches from Microsoft to a centralized repository, test them carefully in a quality assurance environment, and then push the fixes to all of their internal Windows machines in a highly controlled fashion.

Accounts and Groups

Accounts and groups are central to the security of every operating system, and Windows is no exception. Improperly set up accounts, inappropriate group access, and related problems can provide easy avenues of access and privilege escalation for attackers. This section explores security considerations related to accounts and groups.

Accounts

In Windows there are two types of accounts: default accounts and accounts that are created by administrators. Let’s explore each type of account in more detail.

Default Accounts

In a Windows domain (and on individual machines), two accounts, Administrator and Guest, are automatically created when the first domain controller is installed. The default Administrator account has the highest level of privileges of any logon account, rather like the root account in UNIX.

One interesting property of the default Administrator account is that it, by default, cannot be locked out no matter how many bad passwords an attacker guesses for this account.² Additionally, this account can never be deleted, although it can be renamed. Also, it can be disabled only if another, nondisabled account with administrator privileges exists. Although there are undeniably logical reasons behind these restrictions on the Administrator account, it is important that you know the restrictions exist. Creating more than one Administrator account is therefore an essential step in hardening any Windows system; if only the default account exists, unlimited password guessing (“brute force”) attacks against this account can occur. Creating one user (unprivileged) account and one Administrator account for each administrator is an even better security practice in that it allows for individual accountability concerning administrator actions. Each administrator should use his or her own unprivileged account for standard system access and his or her own Administrator account only when super-user privileges are required. Many sites attempt to use an alternative method, a shared Administrator account, to limit the number of accounts with Administrator privileges. This is a bad idea, because in such an environment, although logs might record Administrator actions, one can never be sure which person, using the single Administrator account, did what. Of course, make sure all administrator-level accounts have difficult-to-guess passwords, or else you’ll be providing additional infiltration possibilities for the bad guys.

The second default account is the Guest account. If enabled, this account can provide an easy target for attackers. Anyone can log on to an active Guest account, and although the Guest account itself is very limited in the types of actions that it can perform, its existence reduces the challenge for an attacker from breaking in to privilege escalation. Fortunately, in all modern versions of Windows, the Guest account is disabled by default. Also, like the default Administrator account, the Guest account cannot be deleted, but again it can be renamed. For security reasons, you should definitely leave the Guest account disabled.

Other Accounts

Additional accounts, such as user accounts or accounts for specific services or applications, can be created by administrators as needed. Many applications also create their own, single-purpose accounts during installation. Although the default Administrator and Guest accounts described in the previous section have many restrictions, any additional accounts can be disabled or deleted without these restrictions.

Securing Accounts: Some Strategies

A few relatively simple measures can go a long way in securing accounts. First, and most important, rename the default Administrator account to a neutral name such as “extra.” You could even use a fictitious username. The idea here is to help make this account less visible to potential attackers (of course, an attacker can quickly determine the name of an administrator account by scanning the system with a vulnerability scanner). Remember, if you change the name of the Administrator account, it is a good idea to change the account description. Otherwise, someone who is able to read the description for this account will probably notice the phrase, “Built-in account for administering the computer or domain,” and be wise to your name change. (Don’t laugh, we’ve seen it happen.) Any additional accounts with Administrator privileges should also be given names that do not advertise their super-user capabilities.

To see how an attacker can use a vulnerability scanner to grab information about a target system, refer to the Chapter 6 section titled “Vulnerability-Scanning Tools.”

Another sound measure is to create an additional nonprivileged account with the name Administrator to act as a decoy account. Attackers might go after this account, which should have a difficult-to-guess password and extremely limited access privileges. With such a bogus Administrator account, it is possible to examine event logs to determine whether someone is trying to attack the Administrator account, possibly triggering a more detailed investigation.

As described earlier, leaving the default Guest account disabled is a very important step in securing Windows. Following the “belt and suspenders” principle, applying a difficult-to-guess password to the Guest account just in case someone re-enables it (either purposely or by accident) is also a good idea.

Groups

In most Windows deployments, groups are used to control access and privileges, not individual user accounts. Why? If there are a relatively small number of users within a domain, a user-by-user access control scheme could certainly be employed. However, a user-by-user scheme becomes incredibly unwieldy when the number of users becomes bigger than, say, 50 or 60. Most Windows domains have considerably more than 50 or 60 users, often ranging into the hundreds or many thousands. Assigning privileges to such large numbers of users individually is difficult if not impossible. By aggregating users into groups, administrators can more easily manage privileges and permissions. This exact rationale applies to Linux and UNIX groups.

Prior to Windows 2000 and Active Directory, there were only two types of groups available: global groups and local groups (with the advent of Windows 2000, we now have new rules and new groups, which we discuss in more detail when we talk about Active Directory). Membership in a global group doesn’t directly provide any access to any resources because only local groups can grant resource access, and only on the server or workstation on which they have been created. In Windows, the way that users normally obtain access to resources is through being included in global groups that are then included in local groups. When a global group is included in a local group, the list of accounts that have access to the local resources is now made up of both the list of accounts in the local group and the list of accounts in the global group. Note that global groups cannot be included in global groups, nor can local groups be included in local groups.

Why do things this way? Because by including the global group in several local groups, an administrator can change access to the resources on numerous local machines by making changes to the global group (say, when a new hire is added) without having to make configuration changes to the individual local machines. (Read through it again; it really does make sense.)

Default Groups

A number of default groups are created when the first domain controller is installed. Some of these are local groups, whereas others are global. These groups are listed in Table 4.1. Most of the groups have self-explanatory names, with the exception of the Replicator group, which controls the Windows replicator function used in fault-tolerant installations, and the Power Users group, which can perform any task except those reserved for Administrators (i.e., functions that could directly affect the operating system or risk security).

Table 4.1 Default Windows Groups

Beyond these default groups, there are also special groups intended for controlling certain types of system functionality. You cannot add or delete users from special groups; that’s why they’re special. You can, however, change the rights and privileges for these groups (often with disastrous consequences—be careful!). These groups are always internal to any particular host and are thus local groups. The EVERYONE group is one of these special local groups. It is really intended for providing access to certain objects by unprivileged system processes, although it can be used to assign access to just about anything.

SYSTEM is the “holy grail” special group—nothing in Windows has a higher level of privileges than SYSTEM. However, SYSTEM is not a logon ID; no one can log on to a machine as a part of the SYSTEM group. Only various local processes run with SYSTEM privileges, and it is by compromising one of these processes that an attacker can gain SYSTEM privileges and completely “own” a machine. Using a buffer overflow or related exploit, as we discuss in Chapter 7, an attacker can target a SYSTEM-level process and get a remote command shell with SYSTEM privileges.

Other special groups include INTERACTIVE (a volatile group consisting of current users who are logged on locally) and NETWORK (another volatile group consisting of users who have network logon sessions). There is a final special group with the confusing name CREATOR OWNER, which contains the owner of a given object, even if the owner has not created the object.

Other Groups

Additional global and local groups can be created and deleted as necessary. As described previously, access to resources is normally granted by including users in global groups, then including these global groups in local groups on various servers throughout a domain. Each group can be assigned needed levels of privileges and access by adding the appropriate rights and access permissions to the group definition.

Privilege Control

In Windows, the capacity to access and manipulate things, collectively known as privileges, is broken down into two areas: rights and abilities. Rights are things users can do. Rights can be added to or revoked from user accounts and groups (with a few exceptions). Abilities, on the other hand, cannot be added or revoked at all; they are built-in capabilities of the various groups that cannot be altered. The previously discussed default groups all come with their own particular set of rights and abilities.

As far as privileges of logged-on users go, Administrator privileges are the highest level for any logon ID in Windows, acting somewhat like the root account in Linux and UNIX. Users in the various Operators groups get bits and pieces of Administrator privileges, although if you add up all the privileges of all Operator groups, they do not add up to the full set of Administrator privileges. Account Operators can administer nonprivileged accounts. Server Operators can tune servers, set up shares, and so forth. As you might expect, Backup Operators can make backups. Print Operators can perform tasks such as setting up print shares and installing and maintaining print drivers.

After Administrator privileges, Power User privileges are the next highest privilege level, followed by User-level privileges and then Guest privileges. Of course, any “made up,” nondefault group can be assigned rights (but not abilities) as desired.

Special or advanced rights control internal functions within Windows systems. An example is “Act as Part of the Operating System.” This enables whoever has this right to reach subsystems and components within kernel mode directly, potentially altering the system in fundamental ways and accessing all kinds of information that should always be protected.

As with everything in Windows, there are a few quirks when it comes to rights assignment. To view these rights, as shown in Figure 4.3, you can run the security policy management console, by going to Start Run ... and typing secpol.msc. Browse to Security Settings Local Policies User Rights Assignment. When you access a domain controller and give a right to a user, that right applies to all domain controllers in the domain. However, this is not true on servers or workstations in the domain. Therefore, it is important to carefully plan how rights will be assigned to avoid the dreaded runaway escalation of rights. Additionally, because abilities cannot be assigned or revoked, sometimes it is not possible to create exactly the “custom” group that has the types of privileges that you want.

Figure 4.3 User rights assignment.

As always, the venerable principle of least privilege dictates that only the rights needed to do one’s job are assigned to each group or user. Putting this privilege into practice is one of the most fundamental steps in making Windows (or any other operating system, for that matter) more secure. You should avoid assigning special or advanced rights except when absolutely necessary, given the incredible power and significance associated with these rights.

Policies

In Windows, a system administrator can implement a variety of policies that affect security. Each policy is a collection of configuration settings that can be applied either to the local machine or to the domain as a whole. Using these settings, system administrators can create restrictive policies that can elevate security. If they are installed on a domain controller, policy settings can, among other things, restrict the particular programs that users or groups can access. Let’s explore some of the policy options offered by Windows in more detail.

Account Policy

The most basic type of policy in Windows is the Account Policy, which applies to all accounts within a given domain. Establishing appropriate Account Policy settings can thus tighten Windows security considerably, although some of these settings are more useful than others.

The particular Account Policy settings used should depend on each organization’s security policy and requirements. As shown in Figure 4.4, Account Policy parameters include keeping a history of used passwords to prevent reuse, requiring a maximum password age and a minimum password age, setting a minimum password length, and enforcing complexity of passwords. Account Lockout Policy parameters as shown in Figure 4.5 include lockout duration, lockout threshold (i.e., lockout after X bad logon attempts), and control over how accounts are reset after lockout.

Figure 4.4 Account policies: Passwords.

The Reset Account Lockout value goes hand-in-hand with the Lockout Duration. Five bad logons in eight hours means that someone could have four bad logons in seven hours and 59 minutes, but the account won’t be locked. And one successful logon after anything less than five bad logons will clear the count (i.e., as if no bad logon had ever occurred). In general, it is prudent to set the lockout duration to be fairly high (perhaps in domains with sensitive information even to “Forever”) to prevent an attacker from trying a few password guesses, then waiting, then trying a few more, then waiting, without the account ever being permanently locked. Such a configuration will force users with locked out accounts to call a help desk or system administrator to request manual unlocking, a reasonable requirement for highly sensitive environments, but a costly alternative in terms of human resources in less-sensitive organizations.

Figure 4.5 Account policies: Account lockout.

User Properties Settings

Although User Properties are not properly called “policies” in Windows, they serve virtually the same function for security. They are similar in principle to Account Policy settings, except that they can be set differently for every user account. You can look at local user properties by invoking the local user manager Microsoft control, going to Start Run... and typing lusrmgr.msc. The name lusrmgr stands for Local User Manager, but, given the lusr spelling, it is often pronounced “loser manager.” Within this GUI, click Users, and then right-click on any account to view its properties. As shown in Figure 4.6, User Property settings include User Must Change Password at Next Logon, User Cannot Change Password, Password Never Expires, and Account Disabled. Some of these settings (e.g., User Must Change Password at Next Logon, which keeps system administrators from being aware of user passwords, and Account Disabled, which helps protect dormant accounts) can be very useful for security in many operational settings. Others, such as User Cannot Change Password, are likely to create more work on the part of system administrators than they are worth. Password Never Expires is hardly good for security, yet it might be a necessary setting for accounts created by applications and through which they log on or through which updated software is installed. Changing passwords in these cases could cause an application or installation failure.

Figure 4.6 User Properties settings are configured for each user.

Trust

Trust in Windows extends the single-domain logon model to other domains, which can be a real convenience for users who need access to resources within those domains. Users within the trusted domain can simply double-click the name of a drive to connect to these resources on the trusting domain. No additional entry of a username and password is required once users have been authenticated to their own domain if a trust relationship between the domains exists.

If set up properly, Windows domain-based trust relationships can be relatively secure because system administrators have control over the exact level of access that trust affords. After configuring trust on both the trusted and trusting machines, trusted access cannot actually occur until at least one global group in a trusted domain is included in at least one local group in a trusting domain. Members of the global group obtain only the level of privileges and access that the local group does. Someone who is worried about possible runaway access or privileges due to trust relationships can always reduce the level of privileges and access in the local group to the point where trust does not really make very much difference at all.

There are four possible trust models that can be implemented in Windows, as follows:

• No trust. This is not really a trust model per se; it is simply a “no trust” model. No trust is the most secure, but it is also the most inconvenient for users, because they cannot easily access other domains.
• Complete trust. This model means that every domain trusts every other domain. It is the worst for security because it involves helter-skelter trust that goes everywhere, implementing a kind of “peer-to-peer” trust. This model should be avoided altogether if possible. It allows an attacker who breaks into one trusted domain to gain access quickly to the trusting domains.
• Master domain. This model is well suited to security because user accounts are set up in a central accounts domain where they can be carefully managed, while resources (such as files, shares, printers, and such) are placed in resource domains. Users obtain access to resources in resource domains via trust relationships. This gives a kind of central control capability for mapping users (through groups) to resources.
• Multiple master domain. This model is similar to the master domain model, except that user accounts are distributed among two or more account domains. Although the multiple master domain model involves less central control over user accounts than the master domain model, it still is far superior to the complete trust model.

Windows trust, because it is based on a challenge-response mechanism (and on Kerberos authentication under Active Directory—more on this later) is by default fundamentally more secure than trust in many other operating systems. In particular, Windows trust is not based on the incredibly weak IP address scheme that Linux and UNIX r-commands utilize, a problem for UNIX we discuss in detail in Chapter 8, Phase 3: Gaining Access Using Network Attacks.

Despite these strengths of the Windows trust relationships, it is still important to observe some basic principles if trust is to be as secure as possible. First, there are some operational contexts that require such high levels of security that trust should be avoided altogether. Also, you should periodically check trust relationships to determine which ones exist, because attackers might create unauthorized trust relationships as backdoor mechanisms. Also, this periodic audit of trust relationships will give you a chance to decide if a specific trust relationship is still necessary from a business perspective and disable those that have outlived their usefulness.

Auditing

Windows offers three types of logging: System logging, Security logging (also sometimes simply called auditing), and Application logging. Security logging is configurable and yields at least a moderate amount of data about events such as logons and logoffs, file and object access, user and group management, use of user rights, and so forth.

By default, detailed auditing is disabled under all Windows operating systems (and is completely unavailable with Windows XP Home Edition). Although it can easily be enabled through the Audit Policy in the Security Settings Manager (the secpol.msc tool) choosing exactly what to audit is a more challenging task. In Windows NT there are seven audit event categories: Logons/Logoffs; File and Object Access; Use of User Rights; User and Group Management; Security Policy Changes; Restart, Shutdown, and System; and Process Tracking. As shown in Figure 4.7, under the newer Windows versions (2000 and XP Professional) there are nine audit event categories: Account Logon Events, Account Management Events, Directory Service Access, Logon Events, Object Access, Policy Changes, Privilege Use, Process Tracking, and System Events. Deciding not only which event categories to audit, but also whether to capture successes, failures, or both for each event category constitute a further level of complication.

Figure 4.7 Audit policy settings within the Security Settings Manager.

Unfortunately for system administrators and security personnel, standard Windows Security logging misses some very basic types of data (e.g., source IP addresses of packets on the network, whether a system reinstallation has occurred, and other kinds of data). Because of these limitations, many organizations employ third-party commercial logging tools on sensitive Windows systems.

Turning on Logon/Logoff Success and Failure on all servers (but not workstations) provides a reasonable baseline of logging capability. This level of logging enables system and security administrators to answer some basic questions and do some kinds of simple tracing if an incident occurs. If more auditing is necessary, balancing costs versus benefits is imperative. Too much auditing can cripple system performance and fill up hard drives or overwrite older data too quickly. Of all event categories, Object Access takes the worst toll on system performance, but gives the most detailed view of what an attacker or aberrant user does.

To see how an attacker can alter the event logs on a Windows system, please refer to the Chapter 11 section titled “Attacking Event Logs in Windows.”

Object Access Control and Permissions

A number of built-in mechanisms control access to objects such as files and printers in Windows. Let’s look at these control mechanisms in more detail.

Ownership

In Windows, every object has an owner (called the CREATOR OWNER). Even if permissions deny the owner access to an object, the owner can always change these permissions, and then do anything with it (e.g., read, write, delete, etc.). In Windows, ownership of an object means everything.

NTFS and Its Permissions

Windows supports a variety of file systems, most notably the old File Allocation Table (FAT) file systems for backward compatibility with older versions of Windows, and the newer NTFS file system for increased robustness and security. It is very important to remember this: FAT partitions offer no access control and should always be avoided in situations that require any degree of security. This is the single most important reason why all of the operating systems that evolved from the original Windows line (Windows 95, 98, and Me) cannot be considered secure: They were all based on a file system that offered no access control.

NTFS, originally included in Windows NT and then carried forward into Windows 2000, XP, and 2003, is a more sophisticated file system that was designed to provide good performance while delivering recoverability in case something goes wrong during a write to media. It offers a 64-bit addressing scheme, a 255-character naming convention, a Master File Table that keeps a record of stored files, and, most important from a security perspective, it has a reasonably granular set of access permissions.

If you come from a background other than Windows, the sheer number and types of permissions within NTFS is bewildering. Compared to other file systems, NTFS offers a more sophisticated range of choices with respect to access control. NTFS, although not perfect, is in fact one of the most effective parts of security for modern Windows systems.

Standard NTFS permissions that can be applied to file or directories include the following:

• No Access, which is pretty intuitive; the user cannot read, write, alter, execute, or interact with the object in any way.
• Read, which really gives read and execute capabilities to a user for an object. Remember, the standard Read permission also includes the ability to execute.
• Change, which gives a user read, execute, write, and delete capabilities for an object.
• Full Control, which includes everything in Change plus the ability to change permissions and Take Ownership of an object. Taking ownership allows a person with this permission to become the CREATOR OWNER of an object such as a file, directory, or printer.

These standard permissions are really just combinations of more granular permission capabilities offered by Windows, or predefined permission sets, if you will. Beyond these four standard sets, more fine-grained special permissions include No Access, Read (i.e., true Read—Read only, but not Execute), Execute, Write, Delete, Change Permissions, and Take Ownership. In most cases, users base access control on the standard permission sets, and not on the special permissions. However, for very specific access control needs, the more granular special permissions are helpful.

Boosting File and Directory Security

Following several simple, practical steps can help in achieving better object access security in Windows. If you need to give someone a great deal of access to a particular object or set of objects, it is not necessary to give them Full Control. Remember, Full Control allows someone to take ownership of an object, and if you own an object in Windows you can change all permissions or even destroy the object. It is a wise strategy to be very stingy with Full Control permissions.

Speaking of taking ownership, it is especially important to be careful when granting the Take Ownership right. It is always best to use the principle of least privileges when assigning access permissions—allow only the level of access that each user needs to do his or her job-related responsibilities and nothing more. Being as stingy as possible in assigning not only Full Control, but also Change (which also allows someone to Delete) and Change Permissions (which allows someone to change other users’ and groups’ permissions) is in accordance with this principle.

Finally, it is important to limit the kinds of access the EVERYONE group gets. Using the EVERYONE group for the purpose of granting access to every user is absolutely not a good idea. You need to remember that by default, the EVERYONE group even includes unknown users and guests. If you need to grant additional rights to all users, then use Authenticated Users (who have valid, authenticated logons) or Domain Users as a universal group instead of EVERYONE.

Share Permissions

Beyond individual object permissions, Windows also allows users to configure the permissions on the various components of the file system that they intend to share with others. On a shared folder, a user can right-click and select Properties to view these details on the Sharing tab. As shown in Figure 4.8, share permissions include Read, Change, and Full Control. Whether or not remote access is possible to a share depends on both the NTFS and the share permissions, which work together in accordance with a least access rule. For any particular user’s access to an object, whatever is the least access between the cumulative NTFS permissions and the share permissions for a particular object is the type of access that the user gets. So if, for example, object X has NTFS permissions for a user set to Read and the share permissions for that same user are set to Full Control, the user will only have Read access when connecting to the share.

Figure 4.8 Windows XP share permissions: Local access.

Users with the Logon Locally right can log on while at the physical console of a server or workstation where they have that right. Keep in mind that local logons are a potential security problem; to a local user, resources within a local server are protected only by NTFS permissions, not share permissions as stated earlier. The user is sitting at the console (or logged in using a remote GUI control tool, like VNC), and not logging in across the network to access shares, so the share permissions do not apply. Worse still, if the partition where the share is located is not an NTFS partition (i.e., a FAT partition), all bets are off and the user has full access.

Weak Default Permissions and Hardening Guides

Even if a partition uses NTFS, many of the Windows default permissions for system directories and files can charitably be described as “faulty.” For example, the default permissions for the Windows (or winnt on older systems) directory allow Modify, Read & Execute, List Folder Contents, Read, and Write to Power Users. Leaving this default would allow such users to read or completely replace the repair directory, which is created to hold backup information needed to repair the system in the event of a catastrophic problem. The repair directory (Windows epair on Windows XP) holds several security-related files and other important information. A spare copy of the SAM database is included in the repair directory, which can be stolen somewhat easily if these default permissions are left in place. The SAM database file can then be fed into a password-cracking tool, as described in Chapter 7, at the attacker’s leisure. Additionally, the default permission for the Windowssystem32 directory in Windows XP also grants widespread access to Power Users. With this default, an attacker could cause havoc with any number of critical system files by compromising an account in the Power Users group.

The topic of system hardening is so broad that entire books have been written on the subject, so it is certainly beyond the scope of this book to attempt to deliver an in-depth “how-to” guide for hardening a system. Locking down a system is something that can only be done by someone who has both a good understanding of what the system itself needs to do as well as an understanding of the consequences that the various changes made to the system will have. System hardening is a difficult task, and if anyone tells you differently, they’re trying to sell something. Some good starting points for finding system hardening “how-to” guides are the Center for Internet Security (www.cisecurity.org), the SANS Institute (www.sans.org) or the Information Security Forum (www.securityforum.org).

Network Security

So far, this chapter has concentrated on system-related considerations for security. Because nearly all useful Windows systems are connected to a network, we must explore in more detail the security implications of Windows networking. A number of basic network security mechanisms are built into Windows. For example, in Windows NT, the basic authentication package supports a challenge-response mechanism that not only helps guard against bogus clients being able to authenticate to a domain controller, but also helps keep clear-text passwords from going across networks. In Windows 2000 and beyond, Kerberos, a protocol that provides strong network authentication, is used to identify users.

To see how an attacker can capture a Windows challenge and response from the network and conduct a password cracking attack against them, please refer to the Chapter 7 section titled “Using Cain’s Integrated Sniffer.”

To see how an attacker undermines a VPN that uses static Windows passwords for authentication, please refer to the Chapter 12 section titled “Scenario 2: Death of a Telecommuter.”

Limitations in Basic Network Protocols and APIs

Unfortunately, despite the presence of numerous features and capabilities designed to boost network security, the Windows network environment is based on a large number of protocols and APIs, each with its own particular security-related limitations.

SMB/CIFS

Share access is based on an implementation of the Server Message Block (SMB) protocol that Microsoft calls the Common Internet File System (CIFS; note the interesting use of the words Common and Internet in a Microsoft product!). All current versions of the Windows operating system are capable of encapsulating SMB/CIFS in TCP.

Unfortunately, this protocol sets up a session between the client and server that has weak authentication mechanisms by default, as well as loopholes in backward compatibility mechanisms. These weaknesses can allow a bogus client to connect to a share, an attacker to conduct a person-in-the-middle attack between a legitimate client and the server, a malicious user to “tailgate” into a share session that appears to have ended, and so on. Additionally, by default, Windows systems also allow null sessions, remote SMB sessions set up independently of any username or password entry. Null sessions can be used to extract an enormous amount of information from a Windows system using tools such as Jordan Ritter’s “enum” and WinFingerprint, written by Vacuum.

NetBEUI and NetBIOS

The SMB/CIFS implementation isn’t the only security-related network problem in Windows, however. The older (and now deprecated) Windows network environment is based on many protocols such as Network Basic Extended User Interface (NetBEUI) and APIs such as Network Basic Input/Output System (NetBIOS) that have long outlived their usefulness in today’s world of networking. The potential for exploitation, both in terms of creating denial-of-service attacks and gaining unauthorized access to resources, is high. Luckily, with the advent of current Windows versions, the NetBEUI protocol isn’t installed by default.

For a discussion of a vulnerability-scanning tool that checks for weaknesses in the configuration of Windows networking, including SMB, NetBEUI, NetBIOS, null sessions, and others, please refer to the Chapter 6 section titled “Nessus.”

Microsoft’s Internet Information Service (IIS)

Windows supports a large number of network services. Most notable from a security perspective is Microsoft’s Internet Information Service (IIS), the built-in Web server that comes with Windows servers. IIS uses a virtual directory system in which each virtual directory accessible through the Web interface refers to an actual directory on the Web server’s file system. In IIS, features such as IP address-based filtering of connections and logging can be enabled for additional security. Over the years, a large number of security problems have been discovered with the IIS Web server, making it a popular target for attacks. One might go so far as to say that attackers love to target IIS, given its historic security vulnerabilities and the slowness with which security patches are applied by system administrators. Therefore, actively applying every IIS patch is essential to maintaining a secure IIS environment. Of course, you needn’t even deploy the IIS Web server; other Web servers, such as the free open source Apache and the commercial Zeus Web servers, are popular alternatives in the Windows arena. However, each Web server has its own particular set of security-related weaknesses.

For a description of a scanning tool that can help find vulnerable materials on an IIS server and other Web servers, please refer to the Chapter 6 section titled “Nikto: A CGI Scanner That’s Good at IDS Evasion.”

Just as with scanning for weak network configurations, an attacker can use the vulnerability-scanning tool Nessus to detect numerous security weaknesses in IIS, as described in the Chapter 6 section titled “Nessus.”

Windows 2000 and Beyond: Welcome to the New Millennium

The first portion of this chapter served as a grounding in the basic functionality of Windows networking. As we went along, we attempted to differentiate, at several points, where older Windows-NT-based security and networking differed from Microsoft’s more current offerings. Despite what the pundits might say, Windows NT, with all of its quirks and issues, isn’t dead yet, and like any evolving technology, understanding where we are now depends a great deal on understanding where we’ve been. This axiom is especially true in Windows, with its careful adherence to backward compatibility.

So now that we have a basic grounding in the security and networking basics of Windows in general, let’s turn our attention to the specifics of the more recent editions of Windows, namely Windows 2000, XP, and Server 2003. As we said at the beginning of this chapter, Windows 2000 is really just Windows NT 5.0.

Despite its new name, many of the underlying functionality, protocols, and mechanisms are the same as in Windows NT 4.0. Windows XP is the evolutionary offspring of Windows 2000, with the addition of many features aimed at home users. At the same time, however, these new versions of Windows, in many ways, represent a big leap forward in terms of functionality, including many new, security-related options. This portion of this chapter explores some of the major security-related considerations of the current versions of Windows. To avoid awkwardness in nomenclature in referring to these multiple post-NT operating systems, we refer to these newer versions of Windows as Windows 2000+.

What Windows 2000+ Has to Offer

Windows 2000+ offers a multitude of features and represents a huge increase in the growth of operating system size, resource consumption, and complexity we’ve witnessed in this decade. Some of the spiffier features of Windows 2000+ include the following:

• Power management
• Built-in terminal services
• The Microsoft Management Console
• The Microsoft Recovery Console
• Plug-and-Play (sometimes derisively called Plug-and-Pray)

Although these general features are potentially very interesting, Microsoft has added gobs of new security-specific features to Windows 2000+ that are of more interest to us, including the following:

• A Microsoft implementation of Kerberos, a protocol that provides strong network authentication to identify users.
• The SSPI, a package that supports a variety of different authentication mechanisms.
• Microsoft’s implementation of Internet Protocol Security (IPSec), which extends IP to provide system authentication, packet integrity checks, and confidentiality services at the network level, as described in Chapter 2.
• The Layer Two Tunneling Protocol (L2TP), which provides encrypted network transmissions, helping protect the privacy of the contents of traffic.
• Active Directory, the Windows 2000+ directory services that act as the central nervous system of all Windows 2000+ functionality, including all security-related capabilities.
• An architecture that provides strong support for smart cards, allowing them to be used in authentication, certificate issuance, and other contexts.
• The Encrypting File System (EFS), which provides for encryption of stored files, helping protect the contents from unauthorized access.

Native versus Mixed Mode

Modern Windows servers can run in two modes: native mode and mixed mode. In native mode, all domain controllers run Windows 2000 or newer operating systems. In mixed mode, the environment includes both current and older Windows NT domain controllers. To support this backward compatibility, mixed mode results in the same security features and weaknesses as in the Windows NT 4.0 domains that we described in the first part of this chapter. Native mode is better for security, not only because it precludes having to deal with the many weaknesses inherent in legacy Windows NT networks, but also because it allows users to take better advantage of the more current Windows security features. Because all of the security issues discussed so far in this chapter apply to mixed mode, the remainder of this chapter discusses considerations relevant only to native mode.

Deemphasizing Domains

Although domains remain important in Windows 2000+, they are less important than in Windows NT. As Windows networks began to evolve, administrators found that domains, in many respects, got in the way of users and functionality by serving as a boundary between network resources and services (and also the ability to locate them). Worse yet, Windows NT browsing services were at best flimsy mechanisms that expended enormous amounts of bandwidth and processing power simply to maintain the information that allowed users to locate network hosts, resources, and services. In Windows 2000+, domains play a secondary role to a set of services that far supersede those of the old Windows NT browser services, namely the Windows 2000+ directory services, known as Active Directory. At the beginning of this chapter, we hinted at some of the improved functionality that Active Directory had to offer. By fundamentally changing the way that networks are organized and deemphasizing domains, Active Directory actually simplified the mechanisms for finding network resources and administering them.

A domain in Windows 2000+ isn’t so much about network organization as it is about a common set of policy settings. The actual structure of a network has a more naturalistic flavor. For the nature lovers out there, domains can be deployed in either a tree or forest structure. A tree is a linking of domains via trust in a manner that results in a continuous namespace to support locating resources more easily using Active Directory. This means that as one starts at the topmost domain (or root domain) in the tree structure and goes down, the domain name of the domain immediately below starts with the name of the parent domain immediately above, as shown in Figure 4.9. Alternatively, a forest produces a noncontiguous namespace by cross-linking domains via trust. In a forest, there is no structured namespace, and consequently, resource location again becomes a difficult proposition.

Figure 4.9 Depiction of a Windows Active Directory tree.

As we stated earlier in this chapter, in what is perhaps its greatest deviation from its predecessors, Windows 2000+ does not have any PDCs or BDCs. All Windows 2000+ domain controllers are authoritative; they can enter and then propagate changes (e.g., user password changes) to all other domain controllers. As we said earlier, this is a good-news, bad-news situation: The good news is that Windows 2000 is not as reliant on one server as was Windows NT with its PDC. The bad news is that if an attacker breaks into any one domain controller, the results are potentially catastrophic to the domain and possibly to an entire tree or forest, as the attacker can alter user account information or gain access across the entire network. Because each of the domain controllers is an equally high-value target, it is imperative that they all be hardened and monitored for potential problems.

Active Directory: Putting All Your Eggs in One Huge Basket

Based on the Lightweight Directory Access Protocol (LDAP), Active Directory services take a lot of the sting out of finding where resources and services reside on the network, a major advantage to both users and programs in today’s far-flung network environments. Active Directory is, in fact, the most important single addition to Windows 2000+. And, as far as security goes, nothing in Windows 2000+ is as important as Active Directory.

Active Directory is a kind of all-in-one service. Using DNS, Active Directory disseminates appropriate information to other hosts. Active Directory’s health depends on whether DNS is running properly. Dynamic DNS (DDNS) provides Active Directory with dynamic updates, such as when a new site (a host or set of hosts running Active Directory) connects to the network. Active Directory not only helps users and programs find resources and services, but it also serves as a massive data repository, storing information about accounts, organizational units (OUs), security policies, files, directories, printers, services, domains, inheritance rules, and Active Directory itself (whew!). It stores user password hashes in a file named ntds.nit. Attackers can use tools to extract these password representations and recover user passwords using standard Windows password cracking tools.

For more information about how an attacker uses Cain, Pwdump3, and other techniques for grabbing password representations on Windows 2000+ systems, please refer to the Chapter 7 section titled “Cain and Abel: Cracking Windows (and Other) Passwords with a Beautiful GUI.”

Security Considerations in Windows 2000+

With the great increase in complexity represented in Windows 2000+, careful configuration is more important now than ever. Thus, we now explore the security issues associated with several of the features offered by Windows 2000+.

Protecting Active Directory

Think of all the ways a perpetrator might try to attack Active Directory. Privilege escalation provides the best opportunity. Because administrators can do virtually anything to Active Directory, if too many people have full Administrator privileges, the likelihood of an attacker breaking into an account with Administrator-level privileges increases considerably. Setting appropriate permissions on Active Directory objects is also extremely critical. In mixed mode, attackers can also obtain access to Active Directory information via trusted access from an older, more vulnerable Windows NT domain. Attackers might be able to use a compromised user account from a legacy Windows NT server to gain access to Active Directory and exploit the entire network.

Installing Active Directory in the main Windows or winnt directory of your server is not a good idea as far as security is concerned. It puts Active Directory on the same partition as the boot sector, system files, and the ever-dangerous IIS (which is automatically installed in Windows 2000 and is installed by default on Server 2003). Active Directory, furthermore, has very large disk space requirements and can create significant I/O overhead at times; it thus deserves its own partition. A good way (at least for security) to divide partitions on servers, therefore, is as follows:

C: Boot and system files
D: Active Directory
E: User files and applications

Physical Security Considerations

Physical security is always important, whether you’re running the latest Server 2003 machine, or an ancient Windows 98 desktop (Heaven help you ... it’s time to upgrade, my friend!). An attacker who can physically access a system can simply steal the hard drive or otherwise manipulate the raw bits on it. In Windows 2000+, the Kerberos authentication service in particular requires strong physical security. One of the easiest ways to compromise Kerberos is to physically access a Kerberos server (called a Key Distribution Center [KDC]) to gain access to Kerberos credentials (tickets) that reside therein. Physical security in clients is also an important security consideration. Kerberos credentials are, for example, stored in workstation caches. Ensuring that workstations have at least a baseline level of security is thus a sound move for security. Microsoft offers several applications to assess the security posture of both servers and workstations. One such tool, the Microsoft Baseline Security Analyzer (MBSA), available at www.microsoft.com/technet/security/tools/mbsahome.mspx, can assist administrators in assessing their servers and workstations for security issues.

Finally, it is important to remember that anyone with physical access to a Windows server or workstation can potentially use a Linux boot disk to gain unauthorized access to any file.

A description of how an attacker with physical access could use a Linux boot disk to retrieve or alter passwords is described in the Chapter 7 section titled “Retrieving the Password Representations from Windows.”

Templates

The Windows 2000+ Security Configuration Tools include templates and wizards that can be used in securing just about everything that is important to security in Windows 2000+. In addition to manipulating security settings via the GUI, the command-line tool secedit can be used to analyze or configure the security of the machine. A successful Windows 2000+ security strategy will almost inevitably call for the use of templates because they take a lot of the work out of setting the myriad security-related parameters appropriately. By default, nine templates (stored in \%systemroot%security emplates) are available to set the security of various system types (workstation or domain controller) to Highly Secure, Secure, or Compatibility. These templates contain prepackaged, Microsoft-recommended settings for various environments. Beyond these common Microsoft templates, custom templates can also easily be developed and deployed. The Center for Internet Security has formulated several security templates for Windows NT, 2000, XP, and 2003 systems, based on a consensus of security needs for dozens of organizations. These free templates are available at www.cisecurity.org.

Architecture: Some Refinements over Windows NT

The Windows 2000+ architecture, like Windows NT, is divided into user mode and kernel mode. Kernel mode in Windows 2000+ includes some additional components, including the Plug and Play Manager, Power Manager, and Window Manager, among other components.

Accounts and Groups

As in Windows NT, securing accounts and groups is fundamental in the effort to secure Windows 2000+ systems. Default accounts in Windows 2000+ include Administrator and Guest, the latter of which is disabled by default. The same steps used in securing accounts in Windows NT also apply to Windows 2000+.

The default groups in Windows 2000+ are almost identical to the default groups in Windows NT. One of the most significant changes is the addition of the Power Users group, a privileged group (although not as powerful as Administrators) built into Windows NT workstations, that is now a default group in Windows 2000+ client and server platforms. Although it is possible to edit the access available to this group, taking away access from Power Users is likely to result in application breakage and other problems. This constitutes a potential problem in securing Windows 2000+ systems.

Windows 2000+ includes three kinds of security groups: domain local (for access to resources only within the same local domain), global (which can only be assigned access to resources in the domain where they are defined), and universal (which can contain users and groups from every domain within any forest, thus cutting across domain and tree boundaries). Global groups can be included in domain local groups. In a native mode domain, global groups can even be made members of other global groups, unlike in standard Windows NT.

Organizational Units (OUs)

OUs in Windows 2000+ allow hierarchical arrangement of groups of users who can inherit properties and rights within a domain. They are very flexible, and can be used to control a number of security-related properties such as privileges.

OUs constitute a potentially big advantage in Windows 2000+ because they support delegation of privileges. Each OU can be assigned a particular level of privileges. Children OUs below the parent can never be given more rights than the parent has. This provides an excellent scheme for rights management, particularly in helping ensure that “runaway privileges” are not a problem within any domain. Note that in Figure 4.10, the root OU has two children OUs below it. The root domain’s rights will always be greater than or equal to the rights assigned to these second-tier OUs.

Figure 4.10 Depiction of OUs within a domain.

There are, however, several downsides to OUs. In particular, OUs are not recognized outside the particular domain in which they have been created. Additionally, for all practical purposes, three levels of OUs should be the maximum; too many levels interfere with system performance.

Privilege Control

Windows 2000+ includes many significant alterations to the way privileges are handled. We next analyze some of the changes to privilege control in Windows 2000+.

The Nature of Rights in Windows 2000+

As shown in Figure 4.11, rights in Windows 2000+ include Change System Time, Debug Programs, Log On Locally, Replace a Process Level Token, and many others. They are considerably more granular than in Windows NT. Furthermore, Windows 2000+ (in contrast to Windows NT) has no built-in “abilities,” something that further interfered with privilege granularity in Windows NT. Another big change is inheritance of rights, as mentioned earlier. There is also no distinction between standard and special rights in Windows 2000+, but rather more or less just a big set of rights, some of which are extremely powerful, others of which are not.

Figure 4.11 Rights in Windows 2000+.

There are usually multiple ways to set up a rights assignment scheme in Windows 2000+. Suppose someone needs only to create and delete accounts. One way to achieve that would be to include that person’s account in the Account Operator group. Alternatively, the appropriate rights can be assigned directly to the individual user. OUs, however, potentially provide the most suitable way to assign rights because delegation of rights is possible. The administrator could create a special OU that is assigned sufficient rights to do this function. Remember, each lower-tier OU receives the same set as or a lesser set of rights than the parent OU, thereby helping guard against runaway rights.

RunAs

RunAs provides the ability to launch processes with a different user context. As shown in Figure 4.12, someone who has already logged on to one account can use a command line to bring up the RunAs command. The major advantage is to allow privileged users to execute programs in a nonprivileged context, thereby helping to control against the dangers of privilege escalation. This capability is therefore roughly analogous to the UNIX sudo application.

Figure 4.12 The RunAs command in Windows 2000+.

In addition to the command-line RunAs tool, Windows 2000+ also sports a GUI-based RunAs. Simply holding down the Shift key and right-clicking an executable program displays a little menu showing the RunAs option. The user can then select the appropriate account from a list of users, or type in a username to run the program as.

Policies

Group Policy Objects

The major change in Windows 2000+ policies is the introduction of Group Policy Objects (GPOs). GPOs allow different policies (e.g., password policies, IPSec policies, Kerberos policies, etc.) to be applied to different users, OUs, computers, or even entire domains. The point here is that GPOs offer incredible granularity and flexibility. To look at Group Policy settings for a local system, go to Start Run... and type mmc to bring up the Microsoft Management Console screen. Then, go to Console Add/Remove Snap-in and click Add. Choose Group Policy, click Add, and then click Finish when you see the Local Computer GPO. You can now expand the GPO for the local machine to see all of the possible settings for the computer and for users, as shown in Figure 4.13. Enormous numbers of options can be configured at a tiny granularity or across huge user bases, ranging from the desktop appearance to configuration options in Microsoft Internet Explorer. Also, because they are built into Windows 2000+ itself instead of being some kind of add-on, these policies are more difficult to defeat or bypass.

Figure 4.13 Browsing the local GPO.

Other Policies

GPOs are only one way to set policies; many other types of policies can also be individually set (as opposed to making them part of a GPO) in Windows 2000+. For example, there are Local Security Policies (such as the Password and Lockout Policies, similar to the Account Policies in Windows NT), Registry-based policies, and others. They can also be set and changed via a variety of methods, including the Microsoft Management Console, templates, and others.

Windows 2000+ Trust

Windows 2000+ trust is based on Kerberos. Windows NT trust, in contrast, is based on a Microsoft-specific challenge-response mechanism. Another big difference between the Windows 2000+ trust model and Windows NT trust is that once you plug a domain into a tree or forest, that domain automatically trusts all other domains and is trusted by all other domains within that tree or forest.

Additionally, trust can occur outside of the context of trees and forests. Any domain can potentially trust any other domain. Obviously, if such a trust model is not structured properly (through carefully designed trees or forests as well as use of the principle of least privileges), trust can present many serious problems in Windows 2000+ operating systems. An attacker gaining privileged access in one domain could easily attack other domains in the same tree or forest. Runaway trust relationships should be avoided at all cost. In an environment with runaway trust, so many domains trust each other that system administrators often do not really know why trust exists or what the consequences of that trust might be. Another potential hazard is “orphan domains,” domains that were used at one time, but fell into disuse because of a business mode change. These unused domains (and the trust relationships that go with them) are often forgotten or ignored by system administrators, but, because they are part of the known network, they are trusted by other domains within a tree or forest. Attackers like to go after orphan domains, because their neglected state makes them more vulnerable, while offering access through trust to other domains.

Auditing

The Windows 2000+ Event Logger produces the same basic kinds of log output as in Windows NT. The main differences are that the Security Log now has nine (Account Logon Events, Account Management, Directory Service Access, Logon Events, Object Access, Policy Change, Privilege Use, Process Tracking, and System Events) instead of seven event categories. Additionally, the Windows 2000+ Event Logger captures a wider range of events within each category.

Object Access Control

Now we look into the Windows 2000+ object access control scheme, which applies to files, directories, and shares. This scheme is very similar to the one found in Windows NT, although it has been extended with additional capabilities.

NTFS-5

The most important change in Windows 2000 and later as far as object access control goes is the switch from the older NTFS-4 to the more sophisticated NTFS-5. Running at least SP 5 on older Windows NT machines ensures at least some level of compatibility between these two different versions of the file system. The standard permissions that can be assigned to files in NTFS-5 include the following:

• Full Control
• Modify
• Read and Execute
• Read
• Write

Just as in Windows NT, these standard permissions sets are actually combinations of more finely grained, special permissions. Individual permissions in NTFS-5 include (brace yourself!) the following:

• Traverse Folder/Execute File
• List Folder/Read Data
• Read Attributes
• Read Extended Attributes (which include compression and encryption)
• Create Files/Write Data
• Create Folders/Append Data
• Write Attributes
• Write Extended Attributes
• Read Permissions
• Change Permissions
• Delete Subfolders and Files
• Delete
• Take Ownership
• Synchronize (i.e., make the contents of one file identical with the contents of another)

The combined permissions sets are far easier to manage than the individual permissions, but they are less granular.

The Encrypting File System (EFS)

Windows 2000+ offers users the ability to store files transparently that have been encrypted for information security purposes. EFS automatically and transparently encrypts any stored files using DES encryption in Windows 2000. Windows 2003 and XP SP1 and later support DES, 3DES, and the even stronger AES algorithm. Although EFS potentially provides a reasonably strong mechanism for protecting the secrecy of stored files, several inherent limitations diminish its value. EFS does not encrypt files that are transmitted over the network. The fact that EFS only works if there is one, and only one, user per file is also a significant limitation. Furthermore, EFS does slow system performance somewhat. Still, if your laptop ever gets stolen, you’ll rest a little more easily if your files are encrypted. However, if you use EFS, it’s really important to get a backup of your encryption key on a USB token or CD-ROM. Otherwise, if your key gets corrupted, you’ll lose your protected data entirely, likely the most valuable data you have (otherwise, you wouldn’t have encrypted it!). For directions on how to back up this crucial crypto key, check out Microsoft’s Web site at http://support.microsoft.com/?kbid=241201.

Conclusion

This chapter has provided a look at Windows NT, 2000, XP, and Server 2003 security. It should now be apparent that securing these environments is anything but a simple matter. Windows provides a target-rich environment for attackers. Security in legacy Windows NT installations is particularly difficult because so many default settings are weak from a security perspective, and also because of the many older protocols and backward compatibility mechanisms that have little if any built-in security. Windows 2000+ operating systems represent a definite improvement as far as security goes; the major challenge in securing these new operating systems is their sheer complexity. Both Windows NT and Windows 2000+ can be made considerably more secure, but quite a bit of effort is required to do so.

Now that we have a basic understanding of TCP/IP networking, Linux/UNIX, and Windows, we turn our attention to the heart of this book: a step-by-step description of how attackers undermine the security of our computer systems.

Summary

Microsoft’s Windows operating system is very popular as a target for attackers. As of this writing, the most widely deployed version is Windows XP, but within the server arena, Windows 2003, Windows 2000, and even Windows NT still have a strong representation.

Domains are used to group Windows machines together with a shared authentication database. Within a domain, users can authenticate to a domain controller and access objects (directories, files, etc.) in the domain. The PDC holds and maintains the main authentication database for the domain, called the SAM database. BDCs contain copies of this database, but cannot update it. In native mode Windows 2000+ networks, the concept of PDCs and BDCs has been eliminated and all domain controllers are authoritative.

Microsoft releases fixes for Windows in the form of SPs and monthly patches. Patches apply to a specific problem, whereas SPs are more general updates of the system.

The Windows NT core architecture is divided into user mode and kernel mode. User mode supports user interaction, including subsystems to verify whether logon attempts are valid.

The SAM database contains representations of each user’s password. In many installations, two types of password representations are stored: the LM password representation and the NT hash. The LM representation is very weak and is included for backward compatibility with Windows for Workgroups and Windows 95 and 98 systems. The NT hash is far more secure, and is used to authenticate users with Windows NT and 2000+ systems. Neither the LM representation nor the NT hashes are salted, making them easier to crack.

Kernel mode includes the Security Reference Monitor, which enforces access control on objects when users or programs try to access them. The Security Reference Monitor compares the permissions assigned to an object with the characteristics of the user or program trying to access it to determine whether access should be allowed or denied.

Windows supports accounts for users, services, and applications. Several default accounts are included, such as the Administrator account and the Guest account. The Administrator account is analogous to the root account in UNIX, and is often given another name. The Guest account is disabled by default across all versions of Windows.

Groups are used to aggregate users to simplify the assignment of privileges and permissions. Global groups can allow access to any resource in a domain, whereas local groups allow access on a particular server or workstation. Global groups can be included in local groups to allow users across a domain to access local resources on a single machine. In Windows NT, local groups cannot be included in global groups, nor can global groups be included in other global groups.

Windows also includes certain special groups. In particular, the EVERYONE group includes all users and processes, even unknown users and guests.

To manipulate the configuration of the system or access various settings, users and groups can be given various rights. Whereas rights can be assigned and revoked, abilities are inherent to various predefined groups and therefore cannot be changed.

Administrators can configure Windows domains to trust other domains, giving users transparent access to resources across domain boundaries. Windows trust is not transitive. Also, Windows trust does not rely solely on IP addresses for authentication, unlike UNIX trust relationships implemented with the r-commands.

Windows supports logging system, security, and application events.

Every object has an owner, called the CREATER OWNER. The NTFS file system offers access control capabilities on individual objects. Standard NTFS permissions include No Access, Read, Change, and Full Control. These standard permissions are combinations of more granular permissions. The older FAT file system, although still supported, does not offer any type of access control.

In addition to the individual directory and file permissions, Windows shares can have their own sets of permissions. These permissions settings include Read, Change, and Full Control. When both share permissions and NTFS permissions are present for a given file or directory, a user accessing the share will be given the more restrictive access of the two. However, when a user accesses the file or directory by logging in locally at the system console, only NTFS permissions apply (not share permissions).

Windows network security is based on a variety of options and protocols. Among these, the basic authentication protocol supports a challenge-response mechanism that does not require clear-text transmission of passwords. Windows networking also supports packet filtering and network-level encryption using Microsoft’s implementation of the Point-to-Point Tunneling Protocol (PPTP).

Older Windows NT networking utilizes the SMB, NetBEUI, and NetBIOS protocols, each of which has a variety of common configuration errors and vulnerabilities.

Microsoft’s IIS offers Web and FTP servers within the Windows environment. Numerous security vulnerabilities have been discovered in the IIS Web server, making it a popular target for attackers.

Windows 2000/XP and Windows 2003 Server offer numerous new features. From a security perspective, the biggest changes are Kerberos, the SSPI, IPSec, Active Directory, smart card support, and EFS.

Windows 2000+ can be deployed in two modes. In native mode environments, only Windows 2000+ servers are deployed. In mixed mode, both Windows NT and Windows 2000 servers are included in the environment. Mixed mode environments include all Windows NT security features and their associated vulnerabilities.

Domains are less important in Windows 2000+, because Active Directory is the primary mechanism for interaction between systems. Domains can be deployed in tree or forest structures. Trees have a continuous namespace, and are ordered as a top-down hierarchy. Forests involve cross-linking domains and do not have continuous namespace.

Active Directory helps users and programs find resources and services. It also acts as a massive database storing information about accounts, OUs, security policies, password representations, and so on.

The Windows 2000+ Security Configuration Tools provide a graphical interface for viewing and configuring security options throughout Windows 2000+. The command-line tool secedit provides similar functions. Windows 2000+ also offers prepackaged and customizable templates for security configuration.

Windows 2000+ adds the Power Users group by default.

Windows 2000+ supports three types of security groups: domain local, global, and universal. Additionally, OUs allow for the hierarchical arrangements of groups, and the delegation of privileges. OUs are only recognized in the domain in which they were created.

Rights in Windows 2000+ are more granular than in Windows NT. Unlike Windows NT, there are no immutable “abilities” assigned to groups. Instead, a big set of individual rights can be assigned to users, groups, or OUs. The Windows 2000+ RunAs command allows a user to execute a command in the context of another user. GPOs in Windows 2000+ allow different policies to be applied to different users, OUs, computers, or domains.

Windows 2000+ trust is based on Kerberos. By adding a domain into a tree or forest, that domain automatically trusts and is trusted by all other domains in the tree or forest. Therefore, it is important to guard against runaway trust and orphaned domains.

Auditing in Windows 2000+ is very similar to auditing in Windows NT, but with more event categories available to log.

NTFS-5 is the file system used by default in Windows 2000+. The successor to the Windows NT NTFS-4 file system, NTFS-5 offers a dizzying array of more granular individual permissions. These granular permissions are lumped together in a smaller series of combined permissions for files (Full Control, Modify, Read and Execute, Read, and Write).

EFS encrypts local files for access by one user. Based on the DES encryption algorithm (although 3DES and AES are available for Windows 2003 and XP SP1 and later), EFS does not encrypt files that are transmitted across the network. Back up your EFS keys to a USB token or CD-ROM, or you’ll be courting trouble, losing your protected files if your key gets corrupted.