Objective 1.3: Analyzing Technical Constraints when Designing Security


While we d all like to design a security system using all of the latest and greatest technology, budgetary constraints can often limit the scope of a network security design. Perhaps an organization supports satellite offices with down-level operating systems and they have not allocated funds to upgrade the hardware to be able to support the latest Windows operating system. Your design will need to provide the highest level of security possible, based on the technology that you have to work with. This might include designing a security structure that will interoperate with older Microsoft operating systems like Windows NT 4.0, or with third-party services such as UNIX DNS, MIT Kerberos, and other types of clients and servers. In preparing for the 70-298 exam as well as in dealing with real-world situations, you will achieve much success in understanding how Windows Server 2003 operates in a heterogeneous environment and not just a network that uses exclusively Windows Server 2003 software and services.

Recognizing Capabilities of the Existing Infrastructure

Before you can begin planning a Windows Server 2003 implementation, you need to determine if your existing computer and networking hardware will support this new technology. If an organization requires the security options offered by Windows Server 2003 but their current hardware will not support it, they will either need to allocate funds for upgrades or else obtain new hardware altogether. (On the other side of the equation, certain higher-end hardware and software functions will only run on the Advanced and Datacenter editions of 2003 ”the Standard Edition is not a one- size -fits-all option.) As you can see in the review in Table 1.1, there are many options for deploying Windows Server 2003, each with slightly different hardware requirements.

Table 1.1: Hardware Requirements for Windows Server 2003

Requirement

Standard
Edition

Enterprise Edition

Datacenter Edition

Web Edition

Minimum CPU 133 MHz speed

133 MHz

133 MHz for x86-based computers; 733 MHz for Itanium-based computers

400 MHz for x86-based computers; 733 MHz for Itanium-based computers

133 MHz

Recommended CPU speed

550 MHz

733 MHz

733 MHz

550 MHz

Minimum RAM

128MB

128MB

512MB

128MB

Recommended minimum RAM

256MB

256MB

1GB

256MB

Maximum RAM

4GB

32GB for x86-based computers; 64GB for Itanium-based computers

64GB for x86-based computers; 512GB for Itanium-based computers

2GB

Multiprocessor support

Up to 4

Up to 8

Minimum 8 required; Maximum 64

Up to 2

Disk space for setup

1.5GB

1.5GB for x86-based computers; 2.0GB for Itanium-based computers

1.5GB for x86-based computers; 2.0GB for Itanium-based computers

1.5GB

Exam Warning  

While some of the information in this section might seem like a review of earlier MCSE exams, any Windows Server 2003 topic is really fair game on the 70-298 exam. Don t be tripped up by thinking you can skip things you ve already been tested on!

Bandwidth requirements are not quite as critical from a security standpoint, since security settings will be propagated to all clients and servers regardless of the speed of their connection. (Remember that Microsoft considers a slow link to be less than 500Kbps by default, and that certain nonsecurity elements of Group Policy like Folder Redirection and Software installation will not be deployed over slow links.) However, if a company has a satellite office that is connecting via a 56K dial-up connection, for example, you can use Windows Server 2003 security features to improve their performance by creating an Internet-based VPN. However, in a case like that, you would need to be aware of the operating systems in use at the branch office, and what type of security and encryption they would be able to support. (We ll discuss VPNs and remote access in Chapters 7 and 10.) Before creating a network security design that calls for specific technologies, be sure to ascertain that the client s infrastructure can support the specifics of that design. Otherwise, a plan that looks good on paper will not be one that you will be able to successfully implement for your client.

Objective 1.3.2: Identifying Technology Limitations

Windows Server 2003 maintains a high level of backward compatibility with Windows 2000 and Windows NT 4.0 computing environments, but it s important to keep in mind that these earlier versions ( especially NT4) will not be able to take advantage of all of the security enhancements available to Windows Server 2003. For example, the default network protocol for Windows NT 4.0 is NTLM, or NTLMv2 if you ve installed the NT4 Active Directory client. Using these protocols, your NT4 workstations and servers will be able to participate in a Windows Server 2003 domain. If your security design insists on Kerberos authentication as a security standard, however, NT4 machines will need to be upgraded or replaced , since NT cannot participate in Windows Kerberos authentication.

Test Day Tip  

Remember that Windows 2000 Professional, Windows 2000 Server, and Windows XP Professional can all use Kerberos authentication to log onto a Windows Server 2003 network.

Windows NT 4 machines also require special consideration when securing network traffic. While NT4 natively supports the PPTP VPN protocol, a special add-on is required to use L2TP or IPSec in a VPN scenario. Further, NT4 cannot use IPSec or understand IPSec policies as they relate to securing LAN traffic ”non-VPN network communications with NT4 machines will only be able to encrypt authentication traffic using NTLM or NTLMv2.

This is a critical piece to keep in mind if you are requiring IPSec-signed traffic with a specific server on your network, since NT4 machines will not be able to communicate under those conditions.

Finally, remember that Windows NT4 still relies heavily on NetBIOS and WINS to communicate between machines on a network, rather than using DNS as is becoming the Microsoft standard. The NetBIOS ports (TCP 135, 137, 138, 139 and 445) are a well-known point of attack, and should be protected by a firewall or router so that an external attacker cannot use them to damage NetBIOS-based systems. (We ll discuss securing network traffic and protocols further in Chapter 5.)

Objective 1.3.3: Analyzing Interoperability Constraints

In a large enterprise environment, Windows administrators often need to be able to integrate Microsoft technologies with server and client products from third-party vendors . The introduction of other operating systems and services, such as UNIX

DNS and MIT Kerberos, presents unique challenges when creating your security design. Finally, when supporting non-Microsoft clients such as Macintosh, you need to ensure that the clients have a common protocol installed so that they can communicate with the Windows network, and that that protocol meets your organization s security requirements.

Interoperability with MIT Kerberos

A Windows Server 2003 domain controller can function as the Key Distribution Center (KDC) for MIT Kerberos clients and hosts , allowing UNIX clients to use their own Kerberos utilities to authenticate to a Windows Server 2003 domain. Likewise, Microsoft clients can be configured to point to an MIT Kerberos KDC for authentication. A number of command-line utilities on the Windows Server 2003 CD help with configuring clients to authenticate against an MIT Kerberos KDC, including:

  • ksetup Configures Kerberos realms, Key Distribution Centers, and Kerberos Password (Kpasswd) servers.

  • ktpass Sets the password, account name mappings, and other information for Kerberos services that use the Windows 2000 Kerberos KDC.

These utilities and others are available in the Windows Server 2003 Support Tools. For UNIX hosts that are authenticating against a Windows Server 2003 KDC, you ll use these utilities, along with the familiar Windows MMCs to configure account and logon information. Table 1.2 illustrates the ksetup command-line options for both of these utilities, while Figure 1.5 illustrates the command-line options for the ktpass utility.

Table 1.2: ksetup Parameters for UNIX Kerberos Integration

Parameter

Description

/SetRealm <DnsDomainName>

Makes this computer a member of an RFC1510 Kerberos Realm.

/MapUser <Principal> [Account]

Maps a Kerberos Principal ( ˜* = any principal) to an account ( ˜* = an account by same name); If account name is omitted, mapping is deleted for the specified principal.

/AddKdc <RealmName> [KdcName]

Defines a KDC entry for the given realm. If KdcName omitted, DNS can be used to locate KDCs.

/DelKdc <RealmName> [KdcName]

Deletes a KDC entry for the realm. If KdcName omitted, the realm entry itself is deleted.

/AddKpasswd <Realmname> <KpasswdName>

Add Kpasswd server address for a realm.

/DelKpasswd <Realmname> <KpasswdName>

Delete Kpasswd server address for a realm.

/Server <Servername>

Specify name of a Windows machine to target the changes.

/SetComputerPassword <Password>

Sets the password for the computer s domain account (or host principal).

/RemoveRealm <RealmName>

Delete all information for this realm from the Registry.

/Domain [DomainName]

Use this domain (if DomainName is unspecified, detect it).

/ChangePassword <OldPasswd> <NewPasswd>

Use Kpasswd to change the logged-on user s password. Use ˜* to be prompted for passwords.

/ListRealmFlags (no args)

Lists the available Realm flags that ksetup knows .

/SetRealmFlags <realm> <flag> [flag] [flag][...]

Sets RealmFlags for a specific realm.

/AddRealmFlags <realm> <flag> [flag] [flag][...]

Adds additional RealmFlags to a realm.

/DelRealmFlags <realm> <flag> [flag] [flag][...]

Deletes RealmFlags from a realm.

/DumpState (no args)

Analyze the Kerberos configuration on the given machine.

click to expand
Figure 1.5: ktpass Command-Line Descriptions

Integrating UNIX DNS with Windows Server 2003

The Microsoft DNS service has been designed in compliance with most industry standards for the DNS protocol. This means that you have the option to operate DNS using only Windows Server 2003, or integrating your name resolution services with any new or existing third-party DNS solutions. The most common of these is the UNIX Berkeley Internet Name Domain (BIND) DNS implementation. Windows Server 2003 DNS has been tested against the following versions of BIND with varying degrees of interoperability:

  • BIND 4.9.7

  • BIND 8.1.2

  • BIND 8.2

  • BIND 9.1.0

When dealing with a mixed DNS solution, your primary security concern is in the area of zone transfers and record updates. With Windows Server 2003 DNS, both of these tasks are controlled and regulated using built-in Windows security. If your DNS data will be transferred to a BIND server, you need to take precautions to ensure that the UNIX server has been secured against potential attacks against DNS name resolution. This can include restricting the servers that a BIND server is permitted to send a zone transfer to, and ensuring that the actual data transmission to and from the BIND server is encrypted. While the 70-298 exam won t expect you to be able to configure or secure a BIND DNS server, you should be aware that third-party DNS servers are subject to the same kinds of security risks as Microsoft DNS, and you need to take measures to secure them accordingly .




MCSE Designing Security for a Windows Server 2003 Network. Exam 70-298
MCSE Designing Security for a Windows Server 2003 Network: Exam 70-298
ISBN: 1932266550
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net