How To Install and Configure a DHCP Server in a Workgroup in Windows Server 2003

How to Install the DHCP Service

Before you can configure the DHCP service, you must install it on the server. DHCP is not installed by default during a typical installation of Windows Standard Server 2003 or Windows Enterprise Server 2003. You can install DHCP either during the initial installation of Windows Server 2003 or after the initial installation is completed.

How to Install the DHCP Service on an Existing Server

1. Click Start, point to Control Panel, and then click Add or Remove Programs.
2. In the Add or Remove Programs dialog box, click Add/Remove Windows Components.
3. In the Windows Components Wizard, click Networking Services in the Components list, and then click Details.
4. In the Networking Services dialog box, click to select the Dynamic Host Configuration Protocol (DHCP) check box, and then click OK.
5. In the Windows Components Wizard, click Next to start Setup. Insert the Windows Server 2003 CD-ROM into the computer's CD-ROM or DVD-ROM drive if you are prompted to do so. Setup copies the DHCP server and tool files to your computer.
6. When Setup is completed, click Finish.

How to Configure the DHCP Service

After you have installed the DHCP service and started it, you must create a scope, which is a range of valid IP addresses that are available for lease to the DHCP client computers on the network. Microsoft recommends that each DHCP server in your environment have at least one scope that does not overlap with any other DHCP server scope in your environment. In Windows Server 2003, DHCP servers in an Active Directory-based domain must be authorized to prevent rogue DHCP servers from coming online. Any Windows Server 2003 DHCP Server that determines itself to be unauthorized will not manage clients.

How to Create a New Scope

1. Click Start, point to Programs, point to Administrative Tools, and then click DHCP.
2. In the console tree, right-click the DHCP server on which you want to create the new DHCP scope, and then click New Scope.
3. In the New Scope Wizard, click Next, and then type a name and description for the scope. This can be any name that you want, but it should be descriptive enough so that you can identify the purpose of the scope on your network (for example, you can use a name such as "Administration Building Client Addresses"). Click Next.
4. Type the range of addresses that can be leased as part of this scope (for example, use a range of IP addresses from a starting IP address of 192.168.100.1 to an ending address of 192.168.100.100). Because these addresses are given to clients, they must all be valid addresses for your network and not currently in use. If you want to use a different subnet mask, type the new subnet mask. Click Next.
5. Type any IP addresses that you want to exclude from the range that you entered. This includes any addresses in the range described in step 4 that may have already been statically assigned to various computers in your organization. Typically, domain controllers, Web servers, DHCP servers, Domain Name System (DNS) servers, and other servers, have statically assigned IP addresses. Click Next.
6. Type the number of days, hours, and minutes before an IP address lease from this scope expires. This determines how long a client can hold a leased address without renewing it. Click Next, and then click Yes, I want to configure these options now to extend the wizard to include settings for the most common DHCP options. Click Next.
7. Type the IP address for the default gateway that should be used by clients that obtain an IP address from this scope. Click Add to add the default gateway address in the list, and then click Next.
8. If you are using DNS servers on your network, type your organization's domain name in the Parent domain box. Type the name of your DNS server, and then click Resolve to make sure that your DHCP server can contact the DNS server and determine its address. Click Add to include that server in the list of DNS servers that are assigned to the DHCP clients. Click Next, and then follow the same steps if you are using a Windows Internet Naming Service (WINS) server, by adding its name and IP address. Click Next.
9. Click Yes, I want to activate this scope now to activate the scope and allow clients to obtain leases from it, and then click Next.
10. Click Finish.
11. In the console tree, click the server name, and then click Authorize on the Action menu.

Troubleshooting

The following sections explain how to troubleshoot some of the issues that you may experience when you try to install and configure a Windows Server 2003-based DHCP server in a workgroup.
Clients Cannot Obtain an IP Address
If a DHCP client does not have a configured IP address, this typically indicates that the client was not able to contact a DHCP server. This can be caused by a network problem, or because the DHCP server is unavailable. If the DHCP server started and other clients can obtain valid addresses, verify that the client has a valid network connection and that all the related client hardware devices (including cables and network adapters) are working properly.

The DHCP Server Is Unavailable

If a DHCP server does not provide leased addresses to clients, it is frequently because the DHCP service did not start. If this is the case, the server may not be authorized to operate on the network. If you were previously able to start the DHCP service, but it has since stopped, use Event Viewer to check the System log for any entries that may explain why you cannot start the DHCP service.

To restart the DHCP service:

1. Click Start, and then click Run.
2. Type cmd, and then press ENTER.
3. Type net start dhcpserver, and then press ENTER.

-or-

1. Click Start, point to Control Panel, point to Administrative Tools, and then click Computer Management.
2. Expand Services and Applications, and then click Services.
3. Locate and then double-click DHCP Server.
4. Verify that Startup is set to Automatic and that Service Status is set to Started. If not, click Start.
5. Click OK, and then close the Computer Management window.

Source: http://support.microsoft.com/kb/323416

DHCP Server Security

Although DHCP servers are critical to the operation of most enterprise networks, DHCP server security is often one of the most overlooked areas of network security. One reason for this might be the simplicity of how DHCP works: DHCP clients broadcast discovery messages (DHCPDISCOVER) containing their MAC addresses and DHCP servers respond by offering (DHCPOFFER) to lease an IP address and other TCP/IP settings that the client can use to communicate on the network. The client responds (DHCPREQUEST) to the first lease offer it receives and the server acknowledges (DHCPACK) the request and marks the address as leased in its DHCP database. That's all there is to it—who needs to worry about security?

Attacking DHCP

Unfortunately it's the very simplicity of DHCP that's actually the problem as far as security goes. No authentication or authorization takes place during an exchange between a DHCP server and DCHP client, so the server has no way of knowing if the client requesting the address is a legitimate client on the network, and the client has no way of knowing if the server that assigned the address is a legitimate DHCP server. The possibility of rogue clients and servers on your network can create all kinds of problems.

For example, a rogue DHCP server could provide legitimate clients with bogus TCP/IP information that prevents the clients from communicating on the network. A denial of service (DoS) condition then results, and users are unable to connect to network resources to perform their work. Setting up a rogue DHCP server could be as simple as conducting a social engineering attack to gain physical access to your network and plugging in a laptop configured as a DHCP server.

Another scenario might involve an attacker compromising a client computer on your network and installing software that repeatedly requests new IP addresses using spoofed MAC addresses until the entire pool of addresses in your DHCP server's scope is leased. When this happens, legitimate clients that boot onto the network can't acquire an address and again users are unable to access the network and can't do their work.

A more sinister result happens when an attacker breaches network security and gains control of your own DHCP servers. At that point the attacker might proceed to modify the DHCP server to assign clients an incorrect subnet setting and thus create another DoS condition. Or they might modify the server to assign clients incorrect DNS settings and redirect clients to rogue or hijacked DNS servers, which could then redirect clients to hostile websites where they unknowingly download a trojan.

Worse yet, if you're running your DHCP server on a domain controller then an attacker who compromises your DHCP server gains access to your accounts database and can cause all sorts of further problems. The result is usually your worst nightmare. Fortunately, there are some measures you can take to protect your DHCP servers and avoid many of these scenarios, provided you're also following all the usual best practices for securing Windows-based networks. Let's look at some specific threats to DHCP on your network and the countermeasures you can take to mitigate these different threats.

Threats and Countermeasures

On the face of it, the requirement that Windows 2000 and Windows Server 2003 DHCP servers be authorized in Active Directory before they can start leasing addresses to requesting clients seems to mitigate the threat of rogue DHCP servers on your network. Authorization means that when a Windows 2000 or Windows Server 2003 DHCP server boots onto an Active Directory network it first contacts a domain controller to check if its own IP address is found on the list of authorized DHCP servers maintained by the domain controller. If the DHCP server determines that it is authorized to lease addresses to clients, it begins to do so. If it's not authorized, Windows shuts down the DHCP Server service on the machine so it won't be able to lease addresses.

The real benefit of this is to protect your network against legitimate DHCP servers that are badly configured, though it has the added side effect of guarding against accidental or rogue DHCP servers running Windows 2000 or Windows Server 2003. What happens though if an attacker compromises your network with a rogue DHCP server not running Windows 2000 or Windows Server 2003? In this case authorization won't help because non-Microsoft DHCP servers may not respond the same way as Microsoft ones to the DHCPINFORM messages Windows uses to check if DHCP servers are authorized.

Rogue clients is another problem entirely though, as DHCP is designed to make it easy for clients to obtain IP addresses so they can participate on a network. The obvious way of dealing with the problem of rogue clients would seem at first to be DHCP reservation, though on large networks this entails considerable administrative overhead. A reservation is a predefined setting that maps a MAC address to an IP address so that only a client with a particular MAC address can lease the IP address associated with that reservation. If security is critical an administrator could create reservations for each and every client machine on the network, and if unreserved IP addresses still remain in the DHCP server's cope then these could be reserved using invalid or non-existing MAC addresses. Then when a rogue client tries to boot on the network the result is that the DHCP server has no free addresses to lease and the client can't connect.

If only it were that simple. While this approach might foil a casual attack, sophisticated attackers have ways for circumventing DHCP reservations. The simplest approach is for the attacker to run a program that listens for DHCPDISCOVER broadcasts from clients and harvests their MAC addresses. Then when a legitimate client shuts down the rogue client can reconfigure its MAC address to match that of the legitimate client and hijack the legitimate client's lease or try to disrupt communications for the client. Considering this, security-conscious administrators might consider dropping DHCP entirely in favor of static addressing, but what's to stop an attacker who has physical access to your network from assigning a static address to their own machine and joining the network?

Via:windowsecurity.com/articles/DHCP-Security-Part1.html