Windows Server 2008 R2 Unleashed (76 page)

9. In the DHCP Split-Scope Configuration Wizard, click Next on the Introduction to

DHCP Split-Scope page to continue.

10. On the Additional DHCP Server page, type in the name of the secondary DHCP

server (for this example, Server60), and click Next to continue.

11. On the Percentage of Split page, the wizard will default to the 80/20 split, which will

configure the primary server with 80% of the addresses for lease and exclude the

remaining 20%. The secondary server will be configured with 20% of the addresses

available for lease and the other 80% will be excluded. Accept the defaults or move

the slider to the desired percentage split, and click Next to continue, as shown in

Figure 11.12.

ptg

FIGURE 11.12

Defining the percentage split of addresses.

12. On the Delay in DHCP Offer page, define the delay in milliseconds on the secondary

server to ensure that the bulk of clients will be serviced by the primary server, and

click Next to continue.

NOTE

Determining how long to delay the secondary DHCP server must be concluded by per-

forming tests on the actual network that will serve the DHCP clients. It is key that the

primary server is given ample time to respond and the delay on the secondary is short

enough that when the primary server is down, DHCP clients will be acknowledged and

serviced by the secondary DHCP server. For our test network, 100 milliseconds was

suitable, but on some larger networks, this number might need to be increased.

13. On the Summary of Split-Scope Configuration page, review the chosen settings and

click Finish to configure both of the DHCP servers.

Implementing Redundant DHCP Services

357

14. Once the process completes, the status of the configuration changes on both servers

is displayed in the window. Review the results and click Close to close the wizard.

11

15. Once the wizard is closed, in the tree pane, select and expand the secondary server

to expose the IPv4 node.

16. Expand the IPv4 node to reveal the new scope. Review the scope settings, and if

things look good, right-click the scope and click Activate to finalize the split-scope

configuration, as shown in Figure 11.13.

ptg

FIGURE 11.13

Activating the new split scope on the secondary DHCP server.

Both the primary and secondary DHCP servers configured in a split-scope configuration

will honor client scope address reservations, even if the reservation IP address falls within

the excluded IP address range. For this to be 100% effective, the reservation will need to

be defined on both servers, and the wizard will copy any existing reservations defined on

the primary server. Link Layer Filter lists will not be copied over, and any new reserva-

tions created on the primary server will need to be manually created on the secondary

server scope.

Clustering DHCP Servers

The final redundancy option, and frankly the easiest to configure and maintain, if

resources allow, is to deploy a clustered DHCP service. In this configuration, if a single

server goes down, the second server in a cluster will take over DHCP operations. This

option requires a greater investment in hardware and should be considered only in

specific cases in which it is necessary. The biggest benefit for this configuration is that all

358

CHAPTER 11

DHCP/WINS/Domain Controllers

leases, Link Layer Filter lists, and reservations will be contained with the configuration of

the single clustered DHCP server. For more information on clustering servers, see Chapter

29, “System-Level Fault Tolerance (Clustering/Network Load Balancing).”

Exploring Advanced DHCP Concepts

DHCP has been an unassuming network service as of late. The simplicity of the protocol is

another reason for its success because it is not cursed by a high degree of administrative

complexity. However, greater control over a DHCP environment can be achieved through

the understanding of some advanced concepts regarding its use. Some of these concepts

are new to Windows Server 2008 R2, and some were introduced in Windows 2000 Server,

Windows Server 2003, and Windows Server 2008. These improvements can help you gain

control over a DHCP environment and provide for more security and ease of use.

Understanding DHCP Superscopes

A DHCP superscope is used for environments in which multiple network subnets encom-

pass a single scope environment. In these cases, a superscope can be created to contain

multiple scopes. The individual scopes are subsequently dependent on the master super-

scope. If it is turned off, they will also be deactivated.

ptg

Examining DHCP Multicast Scopes

A multicast scope is created to allow clients to be assigned multicast IP addresses. A multi-

cast IP address is one in which destination hosts can each have the same IP address, which

is useful in one-to-many forms of communications, such as webcasts and videoconferenc-

ing sessions.

Delegating Administration of DHCP

It is never wise to hand over full administrative privileges to individuals who need to

perform only a specific network function. If a small group of administrators needs control

over the DHCP environment, Windows Server 2008 R2 makes it easy to delegate adminis-

trative capabilities to them through the inclusion of a group called DHCP Administrators.

Adding users or, preferably, groups to this security group will enable those users to admin-

ister the DHCP servers in an environment. If the DHCP server is a member server, this will

be a local security group. If DHCP is deployed on a domain controller, this will be a

domain security group and membership in this group will apply to all DHCP servers in

the domain that are running on domain controllers. There is also another group named

DHCP Users that can be used to grant read-only view rights to the DHCP system. This is a

good group for desktop or Network Operations Center administrators to be members of.

Using the Netsh Command-Line Utility

Windows Server 2008 R2 has made great strides in allowing virtually all administrative

functions to be performed through the command line. This not only helps those users

who are used to command-line administration, such as that in UNIX operating systems,

Securing DHCP

359

but also allows for the execution of scripts and batch files, which can automate adminis-

trative processes. The Netsh command-line utility is one such utility that effectively allows

11

administrators to accomplish virtually all DHCP tasks that can be run through the MMC

GUI interface. For a full listing of potential functions with Netsh, run netsh /? from the

command line, as illustrated in Figure 11.14.

ptg

FIGURE 11.14

Netsh command-line options.

Securing DHCP

The DHCP protocol is effectively insecure. There is no way to determine if a request from

a client is legitimate or is malicious. Users who have evil intentions can conduct denial-of-

service attacks against the DHCP server by simply requesting all available IP addresses in a

range, effectively disallowing legitimate users from being granted IP addresses. For this and

other reasons, it is important to keep wired security as a high priority. Although this point

might seem obvious, keeping potential intruders physically off a network is a must, not

only for DHCP but for other network services prone to denial-of-service attacks. This

includes auditing the security of wireless networks, such as 802.11b, which can (and often

do) provide unrestricted access to malicious users.

When securing DHCP services is required, link layer filtering should be enabled for both

Allow and Deny lists. This will ensure that only the desired and approved clients can

receive an IP address and all others will be ignored. Also, deploying a Network Policy

Server (NPS) and configuring an appropriate health policy can be performed, and the

DHCP server can be configured to check a client’s health information with the NPS server

360

CHAPTER 11

DHCP/WINS/Domain Controllers

and deny a lease if the system does not meet the health policy. More information on

Network Policy Servers can be found in Chapter 15.

Examining DHCP Authorization

DHCP is an unauthenticated service, which means that anyone can deploy a DHCP server

on a network and start to accept clients and assign them erroneous addresses or redirect

them for malicious purposes. Consequently, since Windows 2000, it has become necessary

to authorize a DHCP server that is running in an Active Directory domain. After the

DHCP server is authorized by the proper domain administrative authority, that server can

then accept client leases.

The downside to this approach is that a Windows NT 4.0 or Linux server could still be

added, unauthenticated, to a network. In this situation, it would become necessary to use

a network analyzer to determine the location of rogue DHCP servers.

Authorization of a Windows Server 2008 R2 DHCP server is straightforward, as long as the

server is a member of an AD DS domain and the logged-on user has proper DHCP privi-

leges in the domain. Normally authorization occurs during the installation of the DHCP

Server role. However, a domain DHCP server that has been unauthorized or a workgroup

DHCP server that is joined to the domain will need to be authorized. This can be accom-

plished by following these steps:

ptg

1. Open the DHCP console (Start, All Programs, Administrative Tools, DHCP).

2. Right-click DHCP in the console tree, and then click Manage Authorized Servers to

display the Manage Authorized Servers dialog box.

3. In the Manage Authorized Servers dialog box, click the Authorize button, as shown

in Figure 11.15.

FIGURE 11.15

Authorizing a DHCP server.

4. When prompted, type the IP address or name of the DHCP server to be authorized,

and then click OK.

5. Confirm the DHCP server to be authorized in the Confirm Authorization dialog box,

and then click OK. In a few minutes, the DHCP should be authorized, and the

scopes can be activated. Click OK to close any remaining dialog boxes.

Reviewing the Windows Internet Naming Service (WINS)

361

Understanding DHCP and Domain Controller Security

11

If at all possible, the DHCP service should not be run on an Active Directory domain

controller because the security of the SRV records generated is lost. The reasons for this are