Implementing a WLAN Test Environment

Before embarking on a full-scale WLAN deployment on your enterprise network, perform a trial deployment on a WLAN test network in your lab to familiarize yourself with how the technology works and resolve any issues that arise before deploying the enterprise WLAN. After setting up your WLAN test environment, perform a limited test to ensure that all components are working together under a simplified certificate infrastructure. Then expand the test environment, testing your Group Policy design and a three-tier CA infrastructure. Figure 11.7 shows the process for implementing a WLAN test environment.

Figure 11.7: Implementing Your WLAN Test Environment

Setting Up Your WLAN Test Environment

Keep your initial WLAN test deployment simple so that you can focus on successfully installing and configuring the essential components. To simplify your initial test:

• Test a basic, single-tier PKI.

  When you deploy your enterprise WLAN, it is recommended that you provide the extra security of a three-tiered certificate infrastructure in which the root CA is offline. For guidelines for designing a certificate infrastructure, see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services.

• Omit using Group Policy in your initial test.

  In your production deployment, you will want to use Group Policy to preconfigure and control the following Wireless Network (IEEE 802.11) Policies settings for Windows XP (SP1 and later) and Windows Server 2003 wireless clients:

  • Types of networks that users can access

    For example, you might restrict users' access to an AP (infrastructure) network only, or to a computer-to-computer (ad hoc) network only.

  • Network name (SSID)

  • Wireless network key (WEP) settings

  • Enabling of network access control using IEEE 802.1X

  • Authentication methods and settings

In your initial test deployment, install and configure the following components and services:

• Wireless APs

• Active Directory

• DNS and DHCP

• A single-tier PKI

• At least one RADIUS server (IAS)

• Wireless clients

After successfully deploying your initial WLAN test environment, add the use of Group Policy and deploy a WLAN with a three-tier PKI in your lab, and confirm that your WLAN still functions properly, to prepare for a successful production deployment.

Configuring Wireless APs

Configure your wireless APs according to the manufacturer's specifications.

To provide secure wireless connectivity, the APs must support WEP and 802.1X authentication.

Because your WLAN uses 802.1X and RADIUS, you do not need to manually enter the WEP keys: They are generated automatically during the EAP-TLS and PEAP-MS-CHAP v2 authentication process. (Most APs include the option for manually entering the WEP keys on the AP, which you can do if needed for the test deployment.)

In configuring the AP, you enter a value for the RADIUS shared secret, which you will later enter on the IAS server when you add the AP as a RADIUS client on the IAS server.

Configuring Active Directory for the WLAN

Your test deployment must include at least one Active Directory-based domain controller.

Perform the following configuration tasks in Active Directory:

• Configure the remote access permission on wireless user and computer accounts.

• Create a group for wireless user and computer accounts. You will create a remote access policy for the group.

• Register the IAS server in Active Directory.

Configuring the Remote Access Permission

To grant wireless user accounts and wireless computer accounts permission to access the network remotely, set the remote access permission in the computer and user accounts.

• To configure the remote access permission on wireless user and computer accounts

  1. On a domain controller (or on a member server on which the Active Directory snap-ins are installed), open Active Directory Users and Computers.

  2. To configure each wireless user account with the permission to access the network remotely, right-click the user object in the Users folder, click Properties, click the Dial-in tab, and then under Remote Access Permission (Dial-in or VPN), select either Control access through Remote Access Policy (for native-mode domains) or Allow access (for mixed-mode domains).

  3. To configure each computer account with the permission to create wireless connections, right-click the computer object in the Computers folder, click Properties, click the Dial-in tab, and then under Remote Access Permission (Dial-in or VPN), select either Control access through Remote Access Policy (for native-mode domains) or Allow access (for mixed-mode domains).

Create a Group for Wireless Users and Computers

Create an Active Directory group to contain wireless users and computers. Later in the test deployment, you will create a group-based remote access policy for wireless connections and specify the group.

• To create a group for wireless users and computers

  1. Open Active Directory Users and Computers.

  2. Create a group for wireless users. For the test deployment, accept the default group scope — that is, create a global group.

     For information about how to add a group, see "Creating user and group accounts" in Help and Support Center for Windows Server 2003.

  3. Add each user account for wireless users and each computer account to be used for wireless access as a group member.

     For information about how to add a member to a group, see "Changing group memberships" in Help and Support Center for Windows Server 2003.

     Tip

     If you are unable to add computer objects when adding members to a group, use the Object Types button in the Select Users, Contacts, Computers, or Groups dialog box to add computers to the types of objects that you can add to a group.

Register the IAS Server in Active Directory

The next step in setting up your WLAN test environment is to use the IAS snap-in to register the IAS server in Active Directory. The following procedure registers the IAS server by using the Internet Authentication snap-in.

• To register the IAS server in Active Directory

  1. Open the Internet Authentication Service snap-in on the IAS computer.

  2. Right-click Internet Authentication Service (Local) for the IAS server, and then click Register Server in Active Directory.

  3. When asked if you want to authorize this computer to read users' dial-in properties for this domain, click OK.

     Note

     This procedure registers the IAS server only in its member domain, which is all that you need for your test deployment. For your production deployment, you will need to register the IAS server in its member domain, trusted domains, and so on. For information, see "Enable the IAS server to read user accounts in Active Directory" in Help and Support Center for Windows Server 2003.

Configuring DNS and DHCP

To support wireless computers in your test lab, your test deployment must include one or more servers running the DNS and DHCP services.

Configure the DNS and DHCP services as follows:

1. On the DNS server:

   1. Ensure that the DNS zone in which the wireless computers will register DNS address records is configured for dynamic updates.

   2. Optionally, specify that the DNS zone is an Active Directory-integrated zone, which provides secured updates, and that the DNS zone is to be updated by DHCP.

2. On the DHCP server, configure a separate scope and lease duration for your wireless client computers.

   The DHCP scope should not include the static IP addresses of your APs or any of your servers.

   For more information about configuring DHCP for your wireless deployment, see "Adapting the Network Infrastructure for a WLAN" earlier in this chapter. For information about configuring scopes and lease durations on a DHCP server, see "Deploying DHCP" in this book.

Deploying a Certificate Infrastructure

For your initial test lab deployment, use a simple certificate infrastructure. To be able to integrate the certificate services with Active Directory in your test environment (and, later, to use Group Policy to provide easier management of wireless clients), you must install the CA as an enterprise CA. After installing your enterprise root CA, you can install a computer certificate on the IAS server and install user and computer certificates on your wireless computers.

To set up the certificate infrastructure for your initial test environment, perform the following tasks:

• Install a single-tier CA.

• Install a computer certificate on the IAS server.

• Install user and computer certificates on wireless computers.

Installing a Single-Tier CA

To keep your initial test deployment simple, install a single-tier CA.

• To install a single-tier CA in your test environment

  • Install the enterprise root CA either on the domain controller or on a separate member server in your test environment.

    You must be logged on as a member of both the Enterprise Admins group and the Domain Admins group for the root domain.

    For installation instructions, see "Install an enterprise root certification authority" in Help and Support Center for Windows Server 2003. For your test lab deployment, you do not need to add certificate templates to the CA or configure the CA to allow subjects to request a certificate based on a template.

Installing a Computer Certificate on the IAS Server

On the IAS server, install a computer certificate from the issuing CA, which, in the single-tier CA infrastructure that you will deploy in your WLAN test environment, is the enterprise root CA. For your test lab deployment, use the Certificates Request Wizard located in the Certificates snap-in to obtain a computer certificate.

Start by creating a Certificates console on the IAS server that contains the Certificates - Local Computer snap-in, which you will use to request the computer certificate.

• To install a computer certificate on the IAS Server

  1. Create a Certificates console on your IAS server that contains the Certificates - Local Computer snap-in. For the test lab deployment, name the console Certificates.

     For information about how to add a snap-in to manage certificates, see "Manage certificates for a computer" in Help and Support Center for Windows Server 2003. To perform this task, you must be a member of the Domain Admins group (or a member of the Administrators group on the local computer).

  2. Use the Certificates console to request a computer certificate for the IAS server.

     To install a computer certificate, click Certificates - Local Computer in the console tree, and select Computer as the certificate type (unless your IAS server is also a domain controller, in which case your only option is to select Domain Controller). For more information about how to use the Certificates console to request a certificate, see "Request a certificate" in Help and Support Center for Windows Server 2003.

For more information about using the Certificates Request Wizard for installing computer certificates, in addition to two alternative methods, see "Computer certificates for certificate-based authentication" in Help and Support Center for Windows Server 2003.

Verifying that the computer certificates meet IAS requirements

Each computer certificate installed on an IAS server must meet the following requirements:

• The certificate must be installed in the Local Computer certificate store.

• The cryptographic service provider for the certificate must support the secure channel (Schannel) security package. If not, the IAS server cannot use the certificate, and the certificate is not available for selection in the properties of the Smart Card or other certificate EAP type in the remote access policy.

The computer certificate for the IAS server must meet additional requirements. The following procedure tells how to verify each requirement.

• To verify that the computer certificate for the IAS server meets all requirements

  1. From the Certificates console, double-click the certificate to open it.

  2. On the General tab, confirm that You have a private key that corresponds to this certificate appears.

  3. On the Details tab, under Field, click Enhanced Key Usage, and then confirm that there is an object identifier for Server Authentication (1.3.6.1.5.5.7.3.1).

  4. On the Details tab, under Field, click Subject Alternative Name, and then confirm that the fully qualified domain name (FQDN) of the computer account for the IAS server (for example, DNS Name=IASServerName.TestDomainName.com) appears.

  5. On the Certification Path tab, confirm that a valid certification path appears and that the statement This certificate is OK appears.

Verifying the root CA certificate

The root CA certificate of the CA that will issue the wireless client computer and user certificates must be installed in the Trusted Root Certification Authorities certificate store. The following procedure tells how to verify this.

• To verify that the root CA is in the Trusted Root Certification Authorities store

  1. From the Certificates console, expand Certificates - Local Computer, expand Trusted Root Certification Authorities, and then click Certificates.

  2. In the Details pane, confirm that the name of your test lab enterprise root CA appears in the Issued To list.

     If the root CA is not in the list, you might need to refresh the display. To do this, click Action, and then click Refresh.

Installing User and Computer Certificates on Wireless Clients

When EAP-TLS is in use, as in your test lab deployment, wireless clients should have both a computer certificate and a user certificate in order to be authenticated to the network. When PEAP-MS-CHAP-v2 is in use, the root CA certificates of the issuing CAs for the computer certificates on the RADIUS servers must be installed on the wireless clients. You can do this manually by importing the root CA certificate on each wireless client, or you can publish the root CA certificate using Group Policy.

For your test lab deployment, use the Certificate Request Wizard located in the Certificates snap-in on the wireless client computer to obtain both a computer certificate and a user certificate for each wireless computer in your test lab.

• Before you begin

  • Connect the wireless client directly to the wired network that contains the CA infrastructure.

    The connection is required in the test environment in order for the wireless client to receive computer and user certificates. In your enterprise environment, this step might not be necessary, depending upon how you decide to deploy certificates.

    If you connect the wireless client to the wired network, you can install the user certificate on the wireless client by using the Certificates - Current User snap-in (as described in the procedure), by using autoenrollment, by submitting a certificate request over the Web, or by implementing a CAPICOM program or script. If you prefer not to make a temporary connection between the wireless client and the wired network, you can install the certificate from a floppy disk.

Note

CAPICOM is a COM client, supporting Automation, that performs cryptographic functions (the CryptoAPI) using Microsoft ActiveX controls and COM objects. For information about CAPICOM, see the CAPICOM link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

• To install user and computer certificates on a wireless client

  1. Create a single console that contains two snap-ins, for managing computer certificates and user certificates. For the test deployment, name the console Certificates.

     1. Install the snap-in for computer accounts under the name Certificates - Local Computer.

        For information about how to install a snap-in for managing computer certificates, see "Manage certificates for a computer" in Help and Support Center for Windows Server 2003.

     2. Install the snap-in for user accounts under the name Certificate - Current User.

        For information about how to install a snap-in for managing user certificates, see "Manage certificates for your user account" in Help and Support Center for Windows Server 2003.

     To install both snap-ins, log on under a user account with administrative credentials for the local computer. (You can install the user certificates snap-in but not the computer certificates snap-in if you log on under a user account in the test domain.)

     Note

     For the initial test deployment, to receive computer and user certificates, the wireless client must be connected directly to the wired network that has the CA infrastructure.

  2. Use the Certificates - Local Computer snap-in to request a computer certificate for the wireless client.

     For instructions telling how to use the Certificates console to request a computer certificate, see "Request a certificate" in Help and Support Center for Windows Server 2003.

     The Help topic provides instructions for requesting a user certificate. To request a computer certificate, instead of clicking Certificates - Current User in the console tree, click Certificates - Local Computer. Then, when prompted for a certificate type, select Computer.

  3. Use the Certificates - Current User snap-in to request a user certificate.

     For instructions telling how to use the Certificates console to request a user certificate, see "Request a certificate" in Help and Support Center for Windows Server 2003. When prompted for a certificate type, select User.

Verifying that the certificates meet all requirements

After installing the computer and user certificates, perform the following procedures to verify that the certificates meet all requirements for the client to perform properly over a wireless connection.

• To verify that the computer certificate for the wireless client meets requirements

  1. Verify that the computer certificate is installed in the Local Computer certificate store (required for EAP-TLS authentication).

     After verifying the correct certificate store, verify the certificate configuration.

  2. From the Certificates console, double-click the certificate to open it.

  3. On the General tab, confirm that the statement You have a private key that corresponds to this certificate appears.

  4. On the Details tab, under Field :

     1. Click Enhanced Key Usage, and confirm that the object identifier for Client Authentication is 1.3.6.1.5.5.7.3.2.

     2. Click Subject Alternative Name, and confirm that the FQDN of the wireless computer account (for example, DNS Name=LaptopName.TestDomainName.com) appears.

  5. On the Certification Path tab:

     1. Confirm that a valid certification path appears.

     2. Confirm that the statement This certificate is OK appears.

• To verify that the user certificate for the wireless client meets requirements

  1. Verify that the user certificate is installed in the Current User certificate store (required for EAP-TLS authentication).

  2. From the Certificates console, double-click the certificate to open it

  3. On the General tab, confirm that You have a private key that corresponds to this certificate appears.

  4. On the Details tab, under Field, confirm the following items:

     1. Click Enhanced Key Usage, and confirm that the object identifier for Client Authentication is 1.3.6.1.5.5.7.3.2.

     2. Click Subject Alternative Name, and confirm that the universal principal name (UPN) of the user account (PrincipalName=[e-mail], for example) appears.

  5. On the Certification Path tab:

     1. Confirm that a valid certification path appears.

     2. Confirm that the statement This certificate is OK appears.

Configuring the RADIUS (IAS) Server

Before you configure your RADIUS server, open Active Directory Users and Computers and verify that your IAS server is a member of the RAS and IAS Servers group.

Configure your RADIUS (IAS) server by performing the following tasks:

1. Add each wireless AP to the IAS server as a RADIUS client.

2. Create a remote access policy for wireless clients.

Adding APs as RADIUS Clients

On the IAS server, add each wireless AP as a RADIUS client. You will need to type the RADIUS shared secret that you configured earlier on the wireless AP.

• To add a wireless AP as a RADIUS client on the IAS server

  1. Open the Internet Authentication Service snap-in.

  2. In the console tree, right-click the RADIUS Clients folder, and then click New RADIUS Client.

  3. In the Friendly name field, type a name for the AP.

  4. In the Client address (IP or DNS) field, type the IP address of the wireless AP. Then click Next.

  5. If the remote access policy for wireless users is designed for a specific model of wireless AP (for example, a remote access policy that contains vendor-specific attributes), in the Client Vendor list, select the manufacturer's name.

     If you do not know the manufacturer, accept the default value, RADIUS Standard.

  6. In the Shared secret and Confirm shared secret fields, type the shared secret value that you assigned when you configured the AP.

Creating a Remote Access Policy for Wireless Clients

To give wireless users access to the network, create a remote access policy for wireless clients, and then configure that policy for the highest level of encryption. To use IAS, you must be logged on using an account that has administrative credentials.

• To add a remote access policy for wireless clients

  1. Open the Internet Authentication Service snap-in.

  2. In the console tree, right-click Remote Access Policies, and then click New Remote Access Policy.

  3. Complete the New Remote Access Policy Wizard using the information provided in Table 11.3. Accept default settings when no information is specified.

     Table 11.3: Adding a Remote Access Policy for Wireless Users

     Wizard Page	Action
     Policy Configuration Method	For Policy Name, type an appropriate name, such as WLAN Test Policy.
     Access Method	Select Wireless.
     User or Group Access	Click Group, and then click Add. In the Select Groups dialog box, type the name of the group that you created for wireless users, and then click Check Names to confirm that the name you typed is correct.
     Authentication Methods	Select Smart Card or other certificate.

• To configure encryption for the new remote access policy

  1. In the console tree of the Internet Authentication Service snap-in, right-click the newly created wireless access policy, and then click Properties.

  2. Verify that Grant remote access permission is selected, and then click Edit Profile.

Configuring the Wireless Adapter on Wireless Clients

On each wireless client, you can manually configure the wireless adapter to recognize the wireless network that the client must access in order to gain wireless connectivity. However, this is generally not necessary, because Windows XP will sense the wireless network and prompt the user via the notification bar. Once the user selects the network name, the network is automatically added to the preferred networks list.

• To manually configure the client computer's wireless adapter to recognize the AP

  1. On the wireless computer, log on under a user account with administrative credentials on the local computer, and open Network Connections.

  2. Right-click the wireless adapter icon, and click Properties to display properties for the wireless network adapter.

  3. To configure TCP/IP for the wireless adapter, on the General tab, type the static IP address for your DNS server.

  4. On the Wireless Networks tab, confirm that the name of the wireless network that you added appears in the Available Networks list.

  5. Disable the network adapter that connects the client computer to the wired network, and then disconnect the client computer from the wire that connects it to the network.

Testing Your Limited WLAN Deployment

To test the deployment of your wireless network, roam the entire coverage area for your wireless network, associating with one AP after another. Use your floor plan (with the APs marked on it) to mark the areas that provide adequate coverage and those that require more troubleshooting. You should be able to roam around the building, associating with one AP after another, and test applications.

As you roam through coverage areas, perform the following tests to ensure that your wireless network will provide strong, uninterrupted coverage for wireless clients:

• Use the client software that the adapter manufacturer provided for the wireless device to determine that the wireless client associates with the nearest AP.

  If the wireless client does not readily associate with the closest AP when you move from one AP's coverage area to the next, turn the network adapter's radio off and back on using software provided by the adapter manufacturer. This forces the wireless adapter to find the strongest signal, which usually is the closest AP.

  The wireless client's ability to associate with an AP is determined by the error rate of the data packets and the signal strength. If the coverage from the first AP is still strong, the wireless transceiver receives few bad packets and maintains its association. If the closest AP is failing to associate with the wireless client, restarting the radio of the wireless network adapter forces the wireless adapter to find the strongest signal, which usually is the closest AP.

• Check the statistics for error rates and signal strength to be sure that they are within limits. Check the AP for throughput to determine whether the data transfer rate is adequate.

The following troubleshooting tools also can be useful when testing and deploying your WLAN:

• Use the Wireless Monitor MMC snap-in, included with Windows Server 2003, to gather and view statistical and configuration information for wireless APs and the Windows Server 2003 wireless client.

• Use a spectrum analyzer to determine the location and strength of interfering signals as you move from one signal area to another. A spectrum analyzer measures radio frequency radiation from low to high frequencies across a frequency spectrum. These signals are plotted on a graph that shows their strength and frequency. If necessary, you can shield or move any devices that are causing interference.

• Use a protocol analyzer to document usage intervals and traffic load. You can use Network Monitor or third-party tools to capture 802.11 packets sent between a wireless client and a wireless AP. With a protocol analyzer, you can capture 802.11 packets, but cannot view the contents of the encrypted payloads.

Expanding Your WLAN Test Deployment

After successfully deploying and testing a simple wireless network, you can add more complex features — such as Group Policy settings to more easily deploy and manage wireless clients, and a three-tier CA infrastructure to provide greater security for your enterprise WLAN.

Each time that you add a new component or feature, test your new deployment before expanding your test deployment further.

Configuring Group Policy Settings

For your initial test deployment, you configured your wireless clients without creating the Active Directory-based wireless network policies that enable you to preconfigure and replicate the wireless client configuration to all wireless clients. Wireless network policies are created by configuring Wireless Network (IEEE 802.11) Policies settings in Group Policy.

In addition, you did not use Group Policy to configure autoenrollment, which enables you to install certificates for the wireless clients automatically.

Instead, you manually configured some of the wireless client settings and used the Certificates console on the client computer to request the computer certificate. (Alternatively, you could have used Web enrollment to request the user or computer certificate.)

However, in your production WLAN deployment, you will want to use Group Policy to provide easier deployment and management of wireless clients and to enable autoenrollment for the installation of the certificates. Before embarking on an enterprise deployment of your WLAN, configure and test Group Policy settings to enable these features.

Note

To support automatic computer certificate allocation, the issuing CA must be an enterpise CA server running either Windows 2000 or Windows Server 2003. To support automatic user and computer certificate allocation, the issuing CA must be an enterpise CA server running either Windows Server 2003, Enterprise Edition or Windows Server 2003, Data Center Edition.

When you configure Group Policy settings to support your WLAN, decide whether you want to manage wireless connections through the domain or create a separate organizational unit (OU) for this purpose. Using an OU might be more efficient than entering Group Policy settings for the domain, which includes both wired and wireless clients.

Note

If you need to force a Group Policy update on the wireless client during your testing, you can use Gpupdate command-line tool. For Gpupdate parameters, see "Gpupdate: Command-line reference" in Help and Support Center for Windows Server 2003.

For more information about:

• Designing OUs, see "Designing the Active Directory Logical Structure" in Designing and Deploying Directory and Security Services.

• Designing group policies, see "Designing a Group Policy Infrastructure" in Designing a Managed Environment.

• Deploying autoenrollment, see "Planning for autoenrollment deployment" in Help and Support Center for Windows Server 2003.

• The appropriate way to open Group Policy Object Editor for a specific type of object, see "Ways to open the Group Policy Object Editor" in Help and Support Center for Windows Server 2003. (Click the Index button, and in the keyword box type Group Policy Object Editor; then select opening.)

• Adding and defining wireless network policies, see "Define Active Directory-based wireless network policies" in Help and Support Center for Windows Server 2003.

Installing a Three-Tier CA

When you deploy your enterprise WLAN, it is recommended that you provide the extra security of a three-tier certificate infrastructure in which the root CA is offline. Therefore, after you finish deploying and testing your WLAN test environment with a single-tier CA, and then introducing Group Policies and retesting, it is a good practice to install a test version of the CA infrastructure that you plan to implement in your enterprise environment in your lab before doing so in your production environment.

For information about designing and deploying a certificate infrastructure, see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services.