Windows Server 2003 Security Cookbook

BUY THIS BOOK

Print Book $49.95

PDF $39.99

Safari Books Online

What is this?

Print Book £35.50

What is this?

Looking to Reprint or License this content?

Tell a friend

Windows Server 2003 Security Cookbook Security Solutions and Scripts for System Administrators

By Mike Danseglio, Robbie Allen
Book Price: $49.95 USD
£35.50 GBP
PDF Price: $39.99

Cover | Table of Contents

Chapter 1: Getting Started

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To have a meaningful discussion of security in Windows Server 2003, we should first establish what security is. A dictionary definition might refer to security as "measures adopted to provide safety." For the purposes of this book, that definition will work very well.

Computer security is not normally defined as a state of complete safety. Rather, it is defined as the collection of protective measures (including technology-based and nontechnology-based measures) that provide a defined level of safety. When security is mentioned throughout the book, you should keep this definition in mind. Security is neither a single protective measure nor complete protection against all attacks. It is a set of measures that provide the desired level of protection.

Many readers might say "I want complete security for my data against all attacks. Tell me how to do that." The only solution that provides complete security is to put that data on a hard drive, incinerate the drive until it is completely turned to vapor, and then randomly mix the hard drive vapor with outside air until completely dissipated. Anything less is a compromise of security in the interest of another business factor such as usability, cost, or feasibility. The need for such compromises is a common theme throughout all computer security topics and is discussed in every chapter of this book.

The operating systems in the Windows NT line, which include Windows 2000 and Windows Server 2003, and even Windows XP, were designed from inception to facilitate security. All enforce user logon and ensure that all software runs within the context of an account, which can be restricted or permitted appropriately. Windows security is not limited to user logon-based security, but extends to all objects within the operating system. Files on the hard drive, entries in the registry, software components—all these elements have a security aspect based on the identity of the user or process accessing them. Operating system components can access objects only with the appropriate permissions and credentials. This can be both a benefit and a detriment.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

What Is Security?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Approach to the Book

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you are familiar with the O'Reilly Cookbook format that is used in other popular books, such as the Active Directory Cookbook, Windows Server Cookbook, and Exchange Server Cookbook, then the layout of this book will not be anything new to you. The book is composed of 21 chapters, each containing 10–30 recipes for performing a specific security task. Within each recipe are four sections: Problem, Solution, Discussion, and See Also. The Problem section briefly describes the task the recipe focuses on. The Solution section contains step-by-step instructions on how to accomplish the task. The Discussion section contains detailed information about the problem or solution. The See Also section contains references to additional sources of information that can be useful if you still need more information after reading the discussion. The See Also section may reference other recipes, Microsoft Knowledge Base (MS KB) articles (http://support.microsoft.com/), Microsoft Developer Network (MSDN ) documentation (http://msdn.microsoft.com), or the Windows Server 2003 product documentation.

The O'Reilly Cookbooks embrace the notion that there are usually many approaches to accomplish any given task. You may be familiar with the famous Perl motto: There Is More Than One Way To Do It. With security tasks, there are often several different ways to do it. You can perform a task with a graphical user interface (GUI), such as MMC snap-ins and specialty management applications; you can use a command-line interface (CLI), such as certutil, net, netdom, or ldifde; you can configure settings directly in the Registry; you can use Group Policy to distribute and manage configuration changes; and, finally, you can perform the same task using a scripting language, such as VBScript or Perl. Whew!

Since people prefer different methods, and no one method is necessarily better than another, we decided to write solutions to the recipes using as many of these ways as possible. That means instead of just a single solution per recipe, we include several solutions. That said, some recipes cannot be accomplished with one of the methods or it is very difficult to do so. In that case, only the applicable methods are covered.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Where to Find the Tools

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For the GUI and CLI solutions to mean much to you, you need access to the tools that are used in the examples. For this reason, in the majority of cases and unless otherwise noted, we only used tools that are part of the default operating system or available in the Resource Kit or Support Tools . The Windows 2000 Server Resource Kit and Windows Server 2003 Resource Kit are invaluable sources of information, along with providing numerous tools that aid administrators in their daily tasks. More information on the Resource Kits can be found at http://www.microsoft.com/windows/reskits/. The Microsoft Installer (MSI) for the Windows Support Tools can be found on a Windows 2000 Server or Windows Server 2003 CD in the \support\tools directory.

Security tools are often produced as single purpose tools that meet a specific need. This is usually the result of an individual getting upset that there is no built-in tool to perform the task. But frequently these single purpose tools are the result of shortcomings in the operating system, such as the account lockout tools we describe in Chapter 9. Whenever we use a one-off or specialty tool, the recipe will describe exactly where you can obtain it. We have intentionally limited the recipes to only use free tools (at the time of this writing). The exception to this is Windows itself—as of this writing, Windows is not free.

Once you have the tools at your disposal, there are a couple other issues to be aware of while trying to apply the solutions in your environment, which we'll describe next.

We strongly believe in supporting the principle of least privilege, which is the security tenet that a logged in user should only have permissions to do the required task at hand. In the Windows world, this means that everyone should log in using a regular user account and then use a separate administrator account that you grant elevated privileges only when necessary. This is beneficial because an administrator who wants to use elevated privileges has to log on with his administrative account explicitly instead of having the rights implicitly, which could lead to accidental changes in your environment. Assuming you employ this method, then you must provide alternate credentials when using administrative tools unless you log on to a computer, such as a domain controller, with the administrative credentials.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Group Policy Notes

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For all Group Policy solutions we use the standard Group Policy Editor (GPE ) found in Windows Server 2003. The policies are shown in a table format listing the location in GPE, the policy name, the setting, and, if applicable, where in your hierarchy you need to apply the policy (for example, at the domain level). Most of the policies here can be implemented as local policy simply by targeting the Group Policy Editor at the local computer instead of the domain.

We wrote the recipes assuming you've installed the Group Policy Management Console (GPMC). GPMC is a free add-on for Windows Server 2003 that simplifies Group Policy management in numerous ways. For example, GPMC allows you to list all policies in your domain in one location instead of hunting through sites, domains, and OUs for the policies. You can also create generic policies without linking them to any part of the hierarchy so you don't affect users before you decide to implement them.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Programming Notes

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

With the VBScript solutions, our intention is to provide the answer in as few lines of code as is reasonable. Since this book is not a pure programming book, we did not want to overshadow the graphical and command-line solutions by providing pages of code or detailed explanations on how to use WSH, WMI, or ADSI. If you are looking for that, we recommend Part 3 of Active Directory, Second Edition (O'Reilly, 2003) or Windows 2000 Scripting Guide (Microsoft, 2003). The code in this book is meant to show you the basics for how a task can be automated and let you run with it. Most examples will take only some minor tweaking to make them do something useful in your environment.

To make the code as simple as possible, we had to remove error checking and other features that are standard scripting best practices. Next, we'll describe how to incorporate these things into your own scripts so that you can quickly turn any code in this book into a robust script with all the trimmings.

Just as you might need to run the graphical and command-line tools with alternate credentials , you may also need to run your scripts and programs with alternate credentials. One way is to use the runas utility when you invoke a script from the command line, or even use runas to open an administrative command prompt and launch other applications from there. Another option is to use the Scheduled Tasks service to run the script under credentials you specify when creating the scheduled task. And yet another option is to hardcode the credentials in the script. Obviously, the latter approach is not very appealing in many scenarios because you do not want the username and password contained in the script to be easily viewable by others. In addition to being insecure, it's also a maintenance nightmare when those user credentials change. Nevertheless, at times it is a necessary evil, especially when working against multiple servers, and we'll describe how it can be done with WMI, ADSI, and ADO.

WMI

Here is example WMI code that prints the list of disk drives on a system:

    strComputer = "."  ' localhost
    set objWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
    set objDisks = objWMI.InstancesOf("Win32_LogicalDisk")
    for each objDisk in objDisks
        Wscript.Echo "DeviceID: " &  objDisk.DeviceID
        Wscript.Echo "FileSystem: " &  objDisk.FileSystem
        Wscript.Echo "FreeSpace: " & objDisk.FreeSpace
        Wscript.Echo "Size: " & objDisk.Size
        WScript.Echo ""
    next

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Replaceable Text

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This book is filled with examples. Every recipe consists of one or more examples that show how to accomplish a task. Most CLI- and VBScript-based solutions use parameters that are based on the computer, domain, forest, OU, user, etc., that is being added, modified, queried, and so on. Instead of using fictitious names, in most cases, we use replaceable text. This text should be easily recognizable because it is in italics and surrounded by angle brackets (<>). Instead of describing what each replaceable element represents every time we use it, we've included a list of some of the commonly used ones here:

<DomainDN>: Distinguished name of domain (e.g., dc=amer,dc=rallencorp,dc=com)
<DomainName>: Fully qualified DNS name of domain (e.g., amer.rallencorp.com)
<UserName>: SAM-style name for a user account (e.g., Administrator)
<UserDN>: Distinguished name of user (e.g., cn=administrator,cn=users,dc=rallencorp,dc=com)
<ComputerName>: Single label DNS hostname of computer (e.g., rallen-xp)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Reporting Security Issues to Microsoft

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Microsoft wants to hear about your security issues. Specifically, they want to know if you've identified new vulnerabilities or issues with Windows products. Microsoft learns of new problems often from customers reporting issues. This gives Microsoft the opportunity to address them via patches, service packs, etc. before an attacker learns of that vulnerability.

The Microsoft Security Response Center (MSRC) was set up specifically to deal with such issues. The center maintains an open line of communications to listen for new security issues. If you feel you've found such an issue, you can contact the center directly at secure@microsoft.com. The MSRC also maintains a web site at http://www.microsoft.com/security/msrc that describes how it works and what you can expect when you contact it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Where to Find More Information

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We hope that this book covers as many security recipes as you'll need to get your job done. But security is nearly boundless. So many components have security integration that, in actuality, we'd have to provide a recipe for nearly every task in Windows to cover all the security-related tasks you can perform. In this book, we focused on the main Windows Server 2003 security topics and on security-sensitive technologies, such as Active Directory, DNS, and DHCP. Luckily, because Windows has been around so long and security is such a hot topic, there are plenty of other sources of information besides this book. This section contains some of the resources we use for security information.

If you have any questions about the complete syntax or usage information for any of the command-line tools we use, you should first take a look at the help information for the tools. The vast majority of CLI tools provide syntax information by simply passing /? as a parameter. For example:

    > dsquery /?

The Microsoft Support web site is a great source of information and is home of the Microsoft Knowledge Base (MS KB ) articles. Throughout this book, we include references to pertinent MS KB articles where you can find more information on the topic. You can find the complete text for a KB article by searching on the KB number at the following web site: http://support.microsoft.com/. You can also append the KB article number to the end of the following URL to go directly to the article: http://support.microsoft.com/?kbid=.

Technet is the best resource for IT professionals that use Microsoft products in their environment. It contains a plethora of great security information as well as planning, deployment, and operations information for virtually every Microsoft product. Technet is available by subscription on CD or on the web at http://technet.microsoft.com/.

MSDN contains a ton of information on the programmatic interfaces to Windows Server 2003. We sometimes reference MSDN pages in recipes. Unfortunately, there is no easy way to reference the exact page we're talking about unless we provided the URL or navigation to the page, which would more than likely change by the time the book was printed. Instead we provide the name of the title of the page, which you can use to search on via the following website:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: System Preparation and Administration

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A system that starts secure can stay secure. The initial installation and configuration of the computer is important to its long-term security. Without a known secure state to start (a security baseline ), it's almost impossible to guarantee a known secure state in the future.

Most companies today use some type of standardized build procedure to install and configure software on their new and repurposed computers. Those procedures have been created to ensure a consistent, repeatable process with a known desired end state (for example, a known good server configuration). There are many reasons to implement such a procedure, such as ensuring that when an IT administrator leaves the organization, the existing configuration and administration procedures can be repeated by the administrator's replacement. One reason that's often overlooked, however, is improved security.

Knowing that a computer is not infected with viruses or malware at its installation is often called a clean start . The clean start gives an administrator the opportunity to protect the system proactively. Most purist security administrators consider any system that becomes compromised as untrustworthy and must be completely rebuilt. So if the build process itself is compromised, all computers based on that process are also compromised. The result could be an entire organization of computers that are not only untrustworthy but cannot be made trustworthy without taking drastic measures. The clean start must also include appropriate initial configuration to help ensure that the computer is not compromised the moment it connects to the network.

There are many solutions available to help make the build and configuration process more efficient. Disk imaging software like Ghost and ImageCast have been around for years and are very good at storing images for a variety of computer roles and then quickly distributing them to target computers. Microsoft ships Remote Installation Service (RIS) and Automated Deployment Services (ADS) that do much the same thing, albeit in a different and less streamlined manner.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Creating a Reference Installation

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to create a clean installation image for consistent and secure deployment of Windows Server 2003 computers.

Using a graphical user interface

Assemble the computer per the manufacturer's instructions.
Do not attach any network cables to the computer. If the computer has wireless network hardware, disable it or continue the steps in a shielded environment.
Install Windows Server 2003 from an original CD.
Download all applicable security updates and patches from the Internet on another computer, and burn these files to a CD. These should usually contain the latest service pack and any critical updates available.
Scan the CD for viruses using a current virus definition file from a known safe source, such as a bootable CD.
Insert the CD in the new computer.
Install all updates.
Install all approved applications from their original CDs or from known good copies. This should usually include a virus scanner. These applications should also be patched with known good patches from read-only media.
Use your image software to create an image of this computer's state.
Store this image in a secure location that cannot be modified before or during server deployments.

A computer that does not start secure can never be secure. Once an attacker has control of a computer, anything that happens on the computer is under the attacker's control and can be monitored and intercepted. For this reason, many attackers attempt to compromise the computer as it's being built. If the computer has malicious code or vulnerabilities built into it during installation, the attacker essentially owns the computer until it is completely erased and rebuilt.

It is critical to install each computer's operating system and software in a secure manner. This recipe provides an outline for preparing a known good installation image (the reference installation image). You can then use this image to load the operating system and appropriate software onto all new computers. This doesn't just apply to servers or domain controllers; most corporations have several sets of images for different computer roles and configurations, including client computers. Usually, any computer set that's not a one-off installation should have an image. For example, a typical organization that frequently deploys both server and client computers might have different images prepared for the following roles:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Renaming the Domain Administrator Account

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to rename the built-in Administrator account in your Active Directory domain to help prevent attacks that use this account.

Using a graphical user interface

Log in as a domain administrator, but not with the built-in domain Administrator account.
Open the Active Directory Users and Computers snap-in (dsa.msc).
In the left pane, expand your domain name, and then click Users.
In the right pane, right-click Administrator, pause, and then click Administrator again.
Type a new name for the account.
Provide the new account name in the User logon name and User logon name (pre-Windows 2000) boxes.
Click OK.

Using a command-line interface

The following command renames the user Administrator to Mike in the domain Contoso:

    > renuser Administrator Mike Contoso

This recipe uses the renuser tool, available from http://www.loa.espci.fr/winnt/renuser/renuser.htm.You can also use the built-in dsmove tool to rename an account, as shown in this example:

    > dsmove CN=Administrator,CN=Users,DC=Contoso,DC=com -newname Mike

This example uses the same variable names as the renuser example. The tool requires you to provide the distinguished name of the user in Active Directory as the first parameter. The -newname option specifies the new name for the user object.

Using VBScript

    ' This code renames the domain administrator account.
    ' ------ SCRIPT CONFIGURATION ------
    strParentDN    = "<ParentDN>"    ' e.g. cn=Users,dc=rallenc    orp,dc=com
    strUserOldName = "<OldUserName>" ' e.g. administrator
    strUserNewName = "<NewUserName>" ' e.g. mike
    ' ------ END CONFIGURATION ---------
     
    set objCont = GetObject("LDAP://" & strParentDN)
    objCont.MoveHere "LDAP://cn=" & strUserOldName & "," & strParentDN, _
                     "cn=" & strUserNewName
    set objUser = GetObject("LDAP://cn=" & strUserNewName & "," & strParentDN)
    objUser.Put "sAMAccountName", strUserNewName
    objUser.SetInfo
    WScript.Echo "Rename successful"

The Administrator account is a well-known account in all versions of Windows NT, Windows 2000, Windows XP, and Windows Server 2003. It is created by default both in the local security accounts manager database and in the domain account database. This account has full access to all available resources. On a local computer, that means that this account can do anything on the computer. In a domain environment, this effect is amplified because the domain Administrator has access to all resources on all computers in that domain by default.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Renaming the Local Administrator Accounts

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to rename the built-in Administrator accounts on the computers in your domain to help prevent attacks that use this account. You do not want to perform this task on each computer if you can avoid it; you want to do this to a group of computers or all computers in your domain.

Both the GUI and CLI solutions require you to manually make the change on each computer. The Group Policy solution allows you to fully address the problem by performing this task in a centralized and managed fashion.

Using a graphical user interface

Log in as a local administrator.
Click Start → All Programs → Administrative Tools → Computer Management.
Double-click Local Users and Groups → Users.
In the right pane, right-click Administrator and click Rename.
Choose a new name for the Administrator account, and then press Enter.

Using a command-line interface

The following command renames the user Administrator to Mike:

    > renuser Administrator Mike

This recipe uses the renuser tool, available from http://www.loa.espci.fr/winnt/renuser/renuser.htm.

Using Group Policy

Table 2-1 shows the Group Policy settings you use to rename the local Administrator account.

Table 2-1: Renaming the local Administrator accounts with Group Policy
Path	`Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\`
Policy name	Accounts: Rename administrator account
Value	Define this policy setting; <NewAdministratorName>

Using VBScript

    ' This code renames the local administrator account.
    ' ------ SCRIPT CONFIGURATION ------
    strComputer = "."
    strNewName = "<NewUserName>"  ' e.g. mike
    ' ------ END CONFIGURATION ---------
     
    set objComputer = GetObject("WinNT://" & strComputer)
    set objUser = GetObject("WinNT://" & strComputer & _
                            "/Administrator,user")
    set objNewUser = objComputer.MoveHere(objUser.ADsPath,strNewName)
    WScript.Echo "Successfully renamed account to: " & strNewName

This recipe is very similar to Recipe 2.2. The same types of vulnerabilities and countermeasures apply here. However, in this recipe, we are protecting the individual computers in the network. Because each computer in the network has its own Administrator account, each of these can be vulnerable (albeit smaller in scope than the domain Administrator account).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Disabling the Local Administrator Accounts

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to disable the built-in Administrator accounts on the computers in your domain to help prevent attacks that use this account. You do not want to perform this task on each computer if you can avoid it; you want to do this to a group of computers or all computers in your domain.

The GUI solution requires you to manually make the change on each computer. The Group Policy solution allows you to fully address the problem by performing this task in a centralized and managed fashion.

Using a graphical user interface

Log in as a local administrator.
Click Start → All Programs → Administrative Tools → Computer Management.
Double-click Local Users and Groups → Users.
In the right pane, right-click Administrator and then click Properties.
Select the Account is disabled box, and then click OK.

Using Group Policy

Table 2-2 shows the Group Policy settings you use to disable the Administrator account.

Table 2-2: Group Policy to disable the Administrator account
Path	`Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\`
Policy name	Accounts: Administrator account status
Value	Define this policy setting; Enabled

Using VBScript

    ' This code disables the local administrator account.
    ' ------ SCRIPT CONFIGURATION ------
    strComputer = "."
    strAdminName = "<NewAdminName>"  ' e.g. mike
    ' ------ END CONFIGURATION ---------
     
    set objComputer = GetObject("WinNT://" & strComputer)
    set objUser = GetObject("WinNT://" & strComputer & _
                            "/" & strAdminName & ",user")
    objUser.AccountDisabled = TRUE
    objUser.SetInfo
    WScript.Echo "Successfully disabled account: " & strAdminName

As discussed in Recipes 2.2 and 2.3, the Administrator account is a common target of attack. Those recipes helped increase security by renaming the account. However, you can also disable the account. This stops the account from working entirely.

If you do not plan to use the Administrator account on local computers, you should disable and rename the account. Disabling the account hinders all types of attacks against the account, including SID-based attacks, and not just attacks that use the account name. A disabled account simply cannot be used. Because the application attempting to use the disabled credentials is usually unable to tell the difference between reasons for a failed logon, most attacks will continue in vain against the disabled Administrator account, filling event logs with failed logon attempts. This makes it highly likely that you'll identify and mitigate the attack because it generates such a high profile.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Renaming the Guest Account

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to ensure that an attacker cannot use the built-in Guest account to mount an attack on your resources.

Using a graphical user interface

Log in as a domain administrator, but not with the built-in domain Administrator account.
Open the Active Directory Users and Computers snap-in (Dsa.msc).
In the left pane, expand your domain name, and then click Users.
In the right pane, right-click Guest, and then click Rename.
Type a new name for the account.
Right-click the new name and click Properties.
Click the Account tab.
Provide the new account name in the User logon name and User logon name (pre-Windows 2000) boxes.
Click OK.

Using a command-line interface

The following command renames the user Guest to the name Fred in the domain Contoso:

    > renuser Guest Fred Contoso

This recipe uses the renuser tool, available from www.ntfaq.com. You can also use the built-in dsutil tool to rename an account, as shown in this example:

    > dsmove CN=Guest,CN=Users,DC=Contoso,DC=com -newname Fred

This example uses the same variable names as the renuser example. The tool requires you to provide CN= options to define the object name and location, and DC= options to define the domain name. The -newname option specifies the new name for the user object.

Using VBScript

    ' This code renames the domain guest account.
    ' ------ SCRIPT CONFIGURATION ------
    strParentDN    = "<ParentDN>"    ' e.g. cn=Users,dc=rallenc    orp,dc=com
    strUserOldName = "<OldUserName>" ' e.g. guest
    strUserNewName = "<NewUserName>" ' e.g. fred
    ' ------ END CONFIGURATION ---------
    set objCont = GetObject("LDAP://" & strParentDN)
    objCont.MoveHere "LDAP://cn=" & strUserOldName & "," & strParentDN, _
                     "cn=" & strUserNewName
    set objUser = GetObject("LDAP://cn=" & strUserNewName & "," & strParentDN)
    objUser.Put "sAMAccountName", strUserNewName
    objUser.SetInfo
    WScript.Echo "Rename successful"

As discussed in previous recipes in this chapter, any known account is a security vulnerability. Attackers that know that an account exists have a starting place for their attacks. This means that you should always attempt to eliminate any known footholds to make their attacks less successful.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Logging in as a Non-Administrator

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to log in to Windows as an administrator, but realize that this is not a secure practice. So you really need to log in as a normal user but still perform administrative tasks by running specific applications in an administrator account's context.

Using a graphical user interface

Log in to Windows as a normal user by supplying a username and password or smart card and PIN.
Click Start → All Programs, right-click the desired application, and select Run as.
Click The following user and supply the desired administrative username and password.

Using a command-line interface

The following command runs the MMC application as user DomainAdmin from the Contoso Active Directory domain. The user will be prompted to provide the password for Contoso\DomainAdmin before MMC is started.

    > runas /user:Contoso\DomainAdmin mmc.exe

In this example, the /user switch indicates the identity of the user in domain\username format.

The following command will use the credentials on a smart card to launch a command prompt, after prompting the user for the smart card PIN:

    > runas /smartcard cmd.exe

One of the most common (and commonsense) concepts in computer security is POLP, the principle of least privilege. It simply states that users should have access to only the resources they need to perform their day-to-day tasks. POLP also applies to non-computer security, although most people don't think of it that way. It is a very similar concept to the idea of need-to-know security.

In the world of computer security, POLP is most often applied to administrators. Although administrators have job tasks that require a great deal of privilege over computer systems, they're also regular users who check email, work with Microsoft Word, and surf the Internet. POLP means that administrators should have a regular user account that doesn't have administrative privileges and that they should use this account when they're performing regular, day-to-day tasks. A second computer account might belong to the Domain Admins group, and administrators would log on with that account to perform administrative tasks.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring Internet Explorer Enhanced Security Configuration

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to enable the strongest possible Internet Explorer security on particularly sensitive Windows Server 2003 computers to prevent any attacks that might come through active code or other Internet Explorer-based vulnerabilities.

Using a graphical user interface

Open Control Panel → Add or Remove Programs → Add/Remove Windows Components.
Select Internet Explorer Enhanced Security Configuration, and then click Details.
Select For administrator groups and For all other user groups.
Click OK, Next, and OK.

Using a command-line interface

You cannot add or remove Windows components from the command line.

Security vulnerabilities often arise from a user browsing web sites. It's not uncommon for even reputable web sites to use adware installation scripts to track users and increase their profit. They very often install long-term cookies on every browser that touches their web site. Some of the more questionable web sites allow third parties to attempt to install ActiveX controls or applications that can be spyware, adware, or other forms of malware.

It is not uncommon for someone to access the Internet from Windows Server 2003 computers. The user isn't usually doing anything intentionally dangerous, but doesn't realize the severity of the actions they are taking. Any infection or installed software on the server can have a far reaching impact, because all connections and resources provided by that server are potentially compromised. Having a file server infected with a network-sniffing spyware application that reports its data to an external server, for example, could compromise a great deal of your network data. And that will ruin your day.

To combat this type of vulnerability, Microsoft made a decision during the development of Windows Server 2003—Internet Explorer should be very secure by default. So secure, in fact, that only static HTML is displayed. No other content is rendered and any attempt to do anything else in Internet Explorer will display an error. This means that most web sites will not display. Although the usability for this type of configuration is very limited, the security improvement is more than worth the trade-off. This aggressive lockdown of settings is known as the Internet Explorer Enhanced Security Configuration.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Preventing Automatic Installation of New Hardware Drivers

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to block a user from installing new hardware drivers . Only existing installed hardware should work with Windows.

Using Group Policy

Table 2-3 shows the Group Policy settings you use to configure this option.

Table 2-3: New hardware driver installation settings in Group Policy
Path	`Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\`
Policy name	Load and unload device drivers
Value	<GroupList>

The value <GroupList> is a list of all users and groups that can load and unload device drivers. You can add or remove any user or group.

There has been a massive proliferation of portable, easily installed consumer computer hardware over the last few years. MP3 players, thumb drives, flash memory, cameras, and other hardware can all store data. This data can be anything. While normally there's a specific type of data intended for each device, these devices can often store any type of data you choose. For example, Apple's iPod is really just a small hard drive with a GUI that plays music. You can store any data you like on that hard drive. The GUI simply ignores the nonmusic content.

This proliferation of simple storage hardware is a nightmare for security administrators. How do you stop data from leaving computers in your organization? Even worse, how do you prevent malicious data (such as viruses) from entering your network? Previously, the only concerns were floppy disks and CD-ROMs, both of which could either be removed from the computer or disabled through an easy configuration change in Group Policy. But now, USB and FireWire ports are considered security vulnerabilities, because a user can attach a storage device to these ports. Windows, being the device-friendly operating system that most users want, will attempt to install and configure a device driver and make that device available automatically. In Windows XP and Windows Server 2003, the operating system even comes with a large library of device drivers that it attempts to use to configure new hardware.

This behavior is undesirable for most server configurations. You should implement this recipe to help stop users from unauthorized data transfer on server computers. When implemented, only an administrator can install a new device driver. The user of the system can use any previously installed device driver, but cannot add a new one. They receive a notice that an administrator must log in to complete the device installation.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Protecting Against Modified Device Drivers

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to stop Windows from loading unsigned or potentially modified or spoofed device drivers, as the modification of device drivers can allow more malicious code to run in a privileged state.

Using Group Policy

Table 2-4 shows the Group Policy settings you use to configure this option.

Table 2-4: Requiring signed drivers with Group Policy
Path	`Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\`
Policy name	Devices: Unsigned driver installation
Value	Do not allow installation

Most device drivers run in a privileged space within the Windows architecture. They usually have permission to access other devices and sensitive components of Windows. This is why poorly written device drivers often cause blue screens or hard hangs. It is also why we worry about device drivers from a security perspective.

Because device drivers can access many sensitive operating system components, they can compromise virtually any area of the operating system. Device drivers have been written that have intercepted and saved all display information (i.e., recording everything on the screen), intercepted all keyboard input, and monitored disk access for sensitive data and then sent that data to the attacker. These malicious device drivers are similar to malware or viruses, but because of how they are written and implemented, they can often be much more powerful.

Obviously the first line of defense is to not install any device driver unless you know that it is trustworthy. Windows Server 2003 reinforces this defense by making it annoyingly (but beneficially) hard to install any digitally signed device driver that's not built into the operating system. It's even harder to install a driver that hasn't been digitally signed (an unsigned driver) because the authenticity of this driver cannot be determined. Although it's really hard for a user to install an unsigned device driver, it can be done.

This recipe disables this ability entirely. Unsigned drivers are rejected by the operating system without providing the user the ability to override the setting. This recipe may not be appropriate for lightly managed client computers because the support costs increase when the help desk needs to manage device installation for the users. But for server computers, this recipe should always be implemented.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Encrypting the SAM

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to prevent an attacker from obtaining the Security Accounts Manager (SAM) database from a physically compromised computer. This stops the attacker from obtaining sensitive security information such as the user password hashes.

Using a graphical user interface

Click Start → Run, type Syskey and click OK.
Click Update and choose the encryption key storage type as described in the Discussion section.
Click OK and OK.

The SAM is a database maintained by Windows that stores a variety of security-specific information, including usernames and passwords. This data should always be protected. Of course, Windows does provide some basic protection, but the protection provided by default depends on several other layers of protection. Most notably, the built-in protection for SAM data assumes that Windows is the only operating system on the computer. If that's the case, and you're in Windows trying to view the SAM data on the hard drive without proper rights, you will be unsuccessful. But that's a pretty big "If."

A simple SAM attack has the user boot into another operating system. This can involve simply inserting a floppy disk and booting the computer, or can be more complex, such as moving the hard drive to an existing computer running another operating system. Regardless, once a separate operating system is implemented, the SAM can easily be read. It's a file stored in your %windir%\system32\config directory with the rest of your Registry data. An attacker can copy that information to another operating system and begin their attack.

To combat this type of offline attack, syskey encrypts the SAM. The encryption key can be stored in the Registry, on floppy disk, or derived from a supplied password . This helps thwart attackers because the SAM is no longer in cleartext. A successful attack now becomes a matter of breaking the Syskey encryption before any other attacks can be attempted. This is a very effective countermeasure to such an offline SAM attack.

The three options in the syskey tool allow you to configure where the key is stored and how it is protected. They are:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Locking the Console

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to lock your current logon session without logging completely out to prevent someone from walking up and using your computer.

Using a graphical user interface

Press Ctrl − Alt − Delete.
Press L.
Alternately, if your keyboard has a Windows key, you can press Windows − L.

Attacks on unlocked computers are quite common. We've personally been at both ends of these attacks—both as the attacker and the victim. Walking up to an unlocked computer is akin to walking in a residential neighborhood and seeing a wide open front door with no cars in the garage. You don't know when the owners are coming back, but it'll only take you a minute to steal what you want.

These attacks are very easily mitigated. A combination of a password-protecting screensaver (see the next recipe) and manually locking the console before you leave it unattended make this type of no-effort attack highly unlikely to succeed.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Enabling Screensaver Locking

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want your computer's screensavers to lock the computer after five minutes of inactivity. This is desired so that an attacker cannot walk up to an unused computer and begin working without having to provide authentication. For this example, we'll use the blank screensaver that engages after five minutes of inactivity.

Using a graphical user interface

Open Control Panel.
Double-click Display.
Click Screen Saver.
Select On resume, password protect.
Click the Screen saver drop-down and choose Blank.
Type a value of 5 for Wait.
Click OK.

Using Group Policy

The following Group Policy setting configures this option:

Path	`Computer Configuration\Administrative Templates \Display`
Policy name	`Password protect the screen saver`
Value	`Enabled`
Policy name	`Screen Saver timeout`
Value	`300 seconds`
Policy name	`Screen Saver executable name`
Value	`Scrnsave.scr`

Table of Contents

WMI

Using a graphical user interface

Using a graphical user interface

Using a command-line interface

Using VBScript

Using a graphical user interface

Using a command-line interface

Using Group Policy

Using VBScript

Using a graphical user interface

Using Group Policy

Using VBScript

Using a graphical user interface

Using a command-line interface

Using VBScript

Using a graphical user interface

Using a command-line interface

Using a graphical user interface

Using a command-line interface

Using Group Policy

Using Group Policy

Using a graphical user interface

Using a graphical user interface

Using a graphical user interface

Using Group Policy

Using the Registry