Adapting the Network Infrastructure for a WLAN

In adapting your network infrastructure for a WLAN, verify you have the required components; eliminate any potential single points of failure; and define IP addressing and subnets needed to support your wireless clients. Figure 11.2 shows the process for adapting your existing network infrastructure for a WLAN.

Figure 11.2: Adapting the Network Infrastructure for a WLAN

Verifying Required Components

To support a secure wireless solution, your existing network infrastructure must include the following components:

• Active Directory, to store account properties and validate password-based credentials.

• DHCP services, to provide automatic IP configuration to wireless clients.

• DNS services, to provide name resolution.

• RADIUS support, to provide centralized connection authentication, authorization, and accounting.

• A certificate infrastructure, also known as a PKI, to issue and validate the certificates required for Extensible Authentication Protocol-Transport Level Security (EAP-TLS) and Protected EAP (PEAP)-TLS authentication. TLS can use either smart cards or registry-based user certificates for authenticating the wireless client.

• For PEAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) authentication, computer certificates for the RADIUS servers and root CA certificates of the issuing CAs on the wireless clients (if needed).

Windows Server 2003 provides all of these components, with some variations in the levels of features supported and capabilities in different editions of the operating system (Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition). For information about differences in these services among the different editions of Windows Server 2003, see Help and Support Center for Windows Server 2003.

After verifying that your existing network infrastructure includes the appropriate components, update the design to support your WLAN.

Active Directory: Planning Groups and Group Policy for Wireless Access

Active Directory contains the user and computer accounts that are used for authentication and authorization of wireless users. It also contains the Group Policy settings that govern wireless connections — for example, information regarding autoenrollment for the user and computer certificates that are installed on wireless clients, and the Wireless Network (IEEE 802.11) Policies settings that specify preferred networks, Wired Equivalent Privacy (WEP) settings, and IEEE 802.1X settings for wireless connections.

To plan for the configuration of Active Directory for your wireless clients, identify the user and computer accounts for wireless users, and add them to a group that will be used in conjunction with a remote access policy to manage wireless access. You must also determine how to set the remote access permission on the user and computer accounts.

Note

For a native-mode domain, you can use universal groups and nested global groups. For example, you might create a universal group named WirelessUsers that contains global groups of wireless user and computer accounts for intranet access.

For information about designing group policies for a WLAN, see "Designing a Group Policy Infrastructure" in Designing a Managed Environment of this kit.

For information about configuring Active Directory for a WLAN, see "Implementing a WLAN Test Environment" later in this chapter. For information about the design and deployment of Active Directory, see "Designing and Deploying Directory Services" in Designing and Deploying Directory and Security Services.

Note

You can configure a computer running Windows Server 2003 or the Microsoft Windows 2000 Server operating system as an Active Directory domain controller. To configure a Windows 2000 Server-based computer as an Active Directory domain controller for wireless access, you must install Service Pack 3 (SP3) or later.

DNS: Identifying Zones Where Wireless Clients Will Register

In DNS, identify the DNS zones where the wireless computers will register DNS address records, and ensure that the zones are configured for dynamic updates. Optionally specify that the DNS zones are Active Directory-integrated zones, which provide secured updates, and that the DNS zones are updated by DHCP. For information about configuring DNS zones, see "Deploying DNS" in this book.

DHCP: Creating Scopes and Leases for Wireless Clients

On the DHCP server, you must configure the scope and lease duration differently for wireless clients than for clients connected to the wired LAN.

A DHCP scope is the full, consecutive range of possible IP addresses for a network, which typically defines a single physical subnet where DHCP services are offered. A DHCP lease duration is the specified time during which the IP addresses within the DHCP scope can be leased.

Define separate scopes for your wired subnets and your wireless subnets, so that you can configure the lease duration differently for the clients requiring DHCP services on your WLAN than for the clients on your wired LAN.

The default lease duration for a DHCP scope is eight days. This might be optimal for clients on your wired network. Because wireless clients do not release their addresses when the wireless user roams to a new subnet, you should decrease the lease duration substantially for wireless clients. By setting a shorter lease duration for wireless clients, you free IP addresses for reuse throughout the day instead of leaving the addresses unavailable for as long as eight days. When determining the optimal lease duration for the wireless clients in your environment, keep in mind the additional processing load that the shorter lease duration places on your DHCP server.

For more information about configuring scopes and lease durations on a DHCP server, see "Deploying DHCP" in this book.

RADIUS: Verifying Support for 802.1X and EAP-TLS

Verify that the RADIUS servers, such as IAS, support EAP-TLS and PEAP-MS-CHAP v2 authentication. Optionally, verify that the RADIUS servers support the use of the NAS-Port-Type attribute in their Access-Request messages. IAS uses the NAS-Port-Type attribute to identify the wireless connection types.

Computers running Windows Server 2003 or Windows 2000 Server IAS can be used for RADIUS support. A Windows 2000 IAS server must have Service Pack 3 (SP3) or later installed.

Note

You can configure IAS in Windows Server 2003, Standard Edition, with a maximum of 50 RADIUS clients and a maximum of 2 remote RADIUS server groups. You can define a RADIUS client by using a fully qualified domain name or an IP address, but you cannot define groups of RADIUS clients by specifying an IP address range. If the fully qualified domain name of a RADIUS client resolves to multiple IP addresses, the IAS server uses the first IP address returned in the DNS query.

With IAS in Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition, you can configure an unlimited number of RADIUS clients and remote RADIUS server groups. In addition, you can configure RADIUS clients by specifying an IP address range.

By using IAS as your RADIUS server and Active Directory as your directory service, you can provide a single sign-on solution. IAS uses Active Directory as its user accounts database. The same set of credentials is used to control network access (authenticating and authorizing access to a network), to log the user on to an Active Directory domain, and to control access to resources in the domain.

The RADIUS server must support the EAP-TLS authentication protocol, which is used in certificate-based security environments. In addition, EAP-TLS is required if you are using smart cards for network access authentication. The RADIUS server also must support the PEAP-MS-CHAP v2 authentication protocol, which is used in password-based security environments.

Certificate Infrastructure: Verifying Support for EAP-TLS and PEAP-MS-CHAP v2

To support EAP-TLS authentication, verify that the certificate infrastructure supports issuing user and computer certificates to wireless client computers and issuing computer certificates to your RADIUS servers.

To support PEAP-MS-CHAP v2 authentication, verify that your RADIUS servers have the appropriate computer certificates installed, and that each wireless client computer has the root certification authority (CA) certificates of the issuers of the computer certificates of the RADIUS servers installed.

You can use a third-party CA to issue certificates for wireless access, as long as the certificates that you install fulfill the requirements for TLS authentication.

For more information about certificate requirements, see the discussion of deploying a certificate infrastructure in "Implementing a WLAN Test Environment" later in this chapter. For information about designing and deploying a certificate infrastructure, see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services.

Eliminating Single Points of Failure

To ensure that wireless clients can continue to be authenticated on the network and can access resources and applications, eliminate single points of failure in your network infrastructure by including:

• Redundant services (such as Active Directory domain controllers) on separate subnets.

• Clustered DHCP services, in the event that one of the cluster nodes fails.

• DNS on all domain controllers, in the event that a DNS server fails.

• Redundant RADIUS servers and proxies, to provide fault tolerance for RADIUS-based authentication.

• Redundant switches and routers, in the event that a switch or router fails.

• Redundant network paths between switches and routers.

Defining IP Addressing and Subnets

Determine how many additional IP addresses your wireless clients will require, and whether or not to define additional subnets.

• To determine the number of additional IP addresses that you will need for wireless access:

  1. Calculate the number of additional IP addresses that wireless users will require:

     1. Determine the average number of wireless clients currently using your corporate network at any given time.

     2. Add to this the estimated number of additional concurrent wireless clients your network will need to support in the future.

  2. Estimate the number of APs (and associated IP addresses) that you will need for wireless network access. For information about how to determine how many wireless APs to deploy, see "Designing Wireless AP Location" later in this chapter.

Based on the number of IP addresses that you will add to accommodate your WLAN, decide whether or not to add additional subnets.

Creating separate subnets for your wireless networking components offers many benefits, including:

• Wired network components do not have to draw from the same pool of existing IP addresses as your wireless clients.

• IP addresses for wireless clients are easier to identify, which assists in easier management and troubleshooting.

• Separate subnets give you increased control over DHCP lease times.

• You can associate each of your physical subnets (both wireless and wired) with sites within Active Directory, which enables you to assign network access policies to the specific subnets.

• If all APs are on the same subnet, you can provide seamless network-layer roaming for the wireless clients. Network-layer roaming allows a wireless client to associate with a new AP within the same subnet, in the same wireless network. When crossing subnets, applications that cannot handle a change of address, such as some e-mail applications, might fail.

Note

Network-layer roaming is to be distinguished from general roaming, which allows a wireless client to associate with a new AP within the same wireless network. In network-layer roaming, the wireless client associates with a new AP on the same subnet, within the same wireless network.

Example: An Enterprise Corporation Designs Subnets and IP Addressing for a WLAN

IEEE 802.11 APs are designed with Ethernet ports and use TCP/IP as a networking protocol. Thus, an enterprise corporation designed their network so that the wireless APs in the building are all attached to the same separate subnet, which is connected to a router.

To avoid using IP addresses from existing subnets, they assigned all of the wireless components to a separate subnet. Because they used a separate subnet for wireless components, the wireless components did not adversely affect the available number of host addresses allocated on previously configured wired subnets.

To keep track of the allocation of IP addresses, they created the IP address numbering scheme shown in Table 11.1. The corporation adopted this numbering convention for all of their buildings that have wireless network connectivity.

Table 11.1: Example IP Address Allocation for IP Subnet 172.16.50.0/24

IP Address	Device
172.16.50.1	Router
172.16.50.2-172.16.50.10	Servers (terminal, proxy, IAS, and so forth)
172.16.50.11-172.16.50.x	Wireless APs
172.16.50.x+1-172.16.50.254	Wireless clients

Under this addressing scheme, addresses were assigned in the following manner:

• Within the IP subnet 172.16.50.0/24, they assigned the router connecting to the rest of the network the first IP address of 172.16.50.1.

• They assigned other devices — such as terminal servers, proxy servers, and IAS servers — addresses from 172.16.50.2 through 172.16.50.10.

• They assigned the wireless APs sequential IP addresses starting with 11. To make it easier to keep track of the wireless APs, they assigned IP addresses that were 10 digits higher than the wireless AP number. For example, Wireless AP 1 was assigned 172.16.50.11, Wireless AP 2 was assigned 172.16.50.12, and so forth.

As is usual practice, they assigned static IP addresses to the APs and any servers on the subnet. To prevent the DHCP server from allocating a static IP address to a wireless client, they created a DHCP scope for the wireless subnet that did not include the assigned servers and APs (the scope range was 172.16.50.x+1 through 172.16.50.254).

They located all APs in a building on the same subnet, which allowed network-layer roaming throughout the building. This also made IP addressing by DHCP servers more manageable. The DHCP server assigned wireless clients dynamic IP addresses.