Wireless security is an ever-increasing headache for enterprises of all sizes. The problem has gone beyond simply ensuring that end users don't use default settings, using passwords to restrict unauthorized access to Access Points (APs), and encrypting traffic to foil eavesdroppers. If you still use Wired Equivalent Privacy (WEP) technology to secure your wireless networks, be aware that it has serious flaws that under certain circumstances could permit malicious hackers to penetrate your network defenses. The Wi-Fi Protected Access (WPA) standard, and subsequent WPA2 standard, overcome these flaws by adding stronger authentication and encryption and should be used whenever possible in preference to WEP. The downside of using WPA and WPA2 is the extra complexity involved in setting up your wireless network infrastructure. However, even for a small network, the increased security may be worth the effort, so let me walk you through the steps of deploying a WPA or WPA2-based solution and configuring your Windows XP-based clients to support it.
Planning Your WPA and WPA2 Infrastructure
You can use WPA or WPA2 in one of two ways to secure your wireless networks. You can set up WPA and WPA2 to use Pre-Shared Key (PSK) authentication (called WPA-PSK or WPA2-PSK), which is an ideal solution for smaller organizations that don't have an enterprise authentication server. With PSK authentication, both the client and the server must know a shared secret or key. (You can find out more about using WPA-PSK and WPA2-PSK technology in the Web-exclusive sidebar "Securing Networks with WPA-PSK and WPA2-PSK" at http://www.windowsitpro.com/windowssecurity, InstantDoc ID 50106.) You can also set up your WPA or WPA2 implementation to use 802.1x technology, which is what I discuss in this article. You can learn more about PSK and 802.1x technologies and some basic wireless security information in "SecureYourWireless Networks," November 2005, InstantDoc ID 47860.
When you use WPA or WPA2 with 802.1x, you need to decide how users will authenticate to the network. Windows supports two options: client certificates (which use Extensible Authentication Protocol-Transport Layer Security—EAP-TLS—authentication) and Protected Extensible Authentication Protocol (PEAP) with Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAP v2). Using certificates is considered more secure than using PEAP, but it requires a Public Key Infrastructure (PKI), whereas PEAP doesn't. If you have a strong password policy and require users to change their passwords frequently, PEAP can be an ideal option for small-to-midsized business (SMBs) and is the method we'll use to secure our wireless network. If you want to use certificates to authenticate users, I recommend you read "Using Certificates to Secure Your WLAN," October 2004, InstantDoc ID 43086.
When you use PEAP authentication, the wireless AP uses Remote Authentication Dial In User Services (RADIUS) to authenticate and authorize the wireless client, passing the authentication packets from the client to a RADIUS server. Figure 1 shows the components of a RADIUS authentication infrastructure. RADIUS servers must have access to a directory (e.g., Active Directory—AD) that contains the user information needed to authenticate users. To authorize a client, the RADIUS server examines policy that the administrator has defned. Policy can be user specific or general to all users or groups of users. Some implementations of RADIUS, including Microsoft Internet Authentication Service (IAS), are able to query a directory for user-specific policy.
Configuring RADIUS
To prepare your wireless network to use PEAP, you first need to install one or more RADIUS servers on your network. Although any Windows Server 2003 or Windows 2000 Server system can function as a RADIUS server, Microsoft recommends that for the best performance, you install RADIUS on a domain controller (DC). Also, whenever possible, you should have more than one RADIUS server in your network for fault-tolerance purposes. In this example, we'll use IAS as the RADIUS implementation. To install IAS, open the Add/Remove Programs Control Panel applet and select Add/Remove Windows Components. In the Windows Components Wizard, select Networking Services and click Details. In the Networking Services dialog box, select Internet Authentication Service, and click OK.
Activate RADIUS. After you install IAS on the RADIUS server, you'll need to activate the RADIUS server by registering it in AD. To do so, launch the Microsoft Management Console (MMC) Internet Authentication Service snap-in from the Start, Administrative Tools menu. Select Register Service in Active Directory from the Action menu. Click OK to confirm that you want IAS to be able to read dialin properties of users. Next, you'll be prompted to add the server to the RAS and IAS Servers group in other domains that will use your RADIUS server to authenticate users.
Obtain certificates for RADIUS servers. After installing your RADIUS servers, you need to obtain a certificate for each. You can install an enterprise Certification Authority (CA)—for example, Microsoft Certificate Services, which ships with Windows 2003 and Win2K—and configure autoenrollment to obtain the necessary certificates. You can find information about installing an enterprise CA in the articles "CA Trust Relationships in Windows Server 2003 PKI," May 2004, InstantDoc ID 42444 and "User-Side PKI Trust Management," June 2004, InstantDoc ID 42809. As an alternative to installing and managing a CA, you can purchase certificates for your RADIUS servers from a third party such as Verisign.
Define remote access policy. Next, you need to define the policy that permits the RADIUS server to authenticate and authorize wireless network clients. Open the MMC Internet Authentication Service snap-in (Start, Administrative Tools, Internet Authentication Service). Right-click Remote Access Policies and select New Remote Access Policy to launch the New Remote Access Policy Wizard. Click Next to start entering policy details. On the Policy Configuration Method page, you'll see two options: Use the wizard to set up a typical policy for a common scenario and Set up a common policy. Select the first option to configure a typical policy, then enter a policy name (e.g., Wireless LAN policy), and click Next. You'll see four Access Method options. Select Wireless and click Next. This page lets you configure the policy for a user or group. Select Group and click Add to specify which groups of users have access. You can name groups that contain only the users who have wireless access (which I recommend), or you can choose a broad group such as Domain Users. After you add your groups, click Next.
Configure the authentication method and policy. The default authentication method is PEAP, which lets users authenticate using their credentials. (You can configure a different authentication method by clicking the Configure button.) The certificate issued to your RADIUS server by the enterprise CA or purchased from a third-party CA should be displayed in the Certificate Issued field, and Secured Password (EAP MSCHAPv2) should be displayed in the list of EAP Types. If the RADIUS server certificate isn't specified, select it from the drop-down list. If the certificate isn't available, check that it was installed correctly before proceeding.
When you use PEAP as the authentication method, you can change the number of times users can enter their credentials during each authentication attempt before they're disconnected, and you can choose whether to permit them to change their password after it expires. Make sure the Enable Fast Reconnect option is selected. Click Next to see a summary of settings and click Finish to save your policy.
After you save the policy, you need to make a couple of changes to it. Double-click the saved policy in the IAS snap-in to open the Properties dialog box. Click Edit Profile to open the Edit Dial-in Profile screen. Click the Dial-in Constraints tab and select the Minutes clients can be connected (i.e., Session-Timeout value) check box. The Session-Timeout value ensures that a client can't remain connected for long periods after its account has been disabled. Clients will be forced to authenticate again after they've been connected for the specified number of minutes. For WPA orWPA2 environments, Microsoft suggests 600 minutes as a suitable value. Next, select the Advanced tab and click Add. Select Ignore-User-Dialin-Properties from the list in the Add Attribute dialog box and click Add. In the Boolean Attribute Information dialog box that appears, ensure that the setting is set to True, then Click OK. Click Close to dismiss the Add Attribute dialog box, then click OK to save your policy changes. These settings ensure that user properties designed for use with dial-in users don't cause problems with your APs, which expect only wireless properties.
Setting Up APs
Next, you need to configure IAS to communicate with your RADIUS clients (i.e., your APs). In the IAS snapin, right-click RADIUS Clients and select New RADIUS Client from the drop-down list. Enter a friendly name for the RADIUS client and its hostname or IP address. Click Next.
In the Client-Vendor field, select RADIUS Standard. In the Shared secret and Confirm shared secret fields, enter a strong secret. You'll share this secret with the AP, and it will be used to authenticate and encrypt traffic between the AP and RADIUS servers. Next, select the Request must contain the Message Authenticator attribute, which causes the RADIUS server to require the AP to use the shared secret. Repeat these steps to configure each of your RADIUS servers.
Finally, configure your AP according to the manufacturer's instructions. At a minimum, you'll need to enter the AP's Service Set Identifier (SSID), configure it to use WPA with 802.1x or WPA2 with 802.1x (not PSK) authentication, and select TKIP (for WPA) or AES (for WPA2) as appropriate, then enter the RADIUS server information and the shared key.
Testing and Troubleshooting WLAN Connectivity
After you configure your RADIUS servers and APs, you need to test connectivity and troubleshoot any problems. To test for connectivity, disable all but one AP (alternatively, test connectivity after installing your first RADIUS server and AP). On your wireless client, right-click the wireless NIC and select Properties. If you're not logged on as a member of the local Administrators group, you'll receive a warning about disabled controls. Ignore the message and click OK to dismiss it. In the Wireless Network Connection Properties dialog box, select the Wireless Networks tab. Under Preferred Networks, click Add to open the Wireless Network Properties. Enter the SSID of your wireless LAN in the Network name (SSID) field; select WPA or WPA2, as appropriate, from the Network Authentication drop-down list; then select TKIP or AES from the Data Encryption drop-down list. Click the Authentication tab and from the EAP type drop-down list, select Protected EAP (PEAP), and Click OK. Click View Wireless Networks in the Wireless Network Connection Properties screen, select the SSID for the network you just added, then click Connect. You should now be connected to your WLAN. (You won't have to repeat these steps each time you want to connect; the network is now configured to connect you automatically.)
If you're unable to connect to your WLAN, multiple sources of diagnostic information are available. Most APs maintain activity logs that show whether connectivity problems with RADIUS servers are preventing wireless clients from authenticating. IAS also maintains logs in the %systemroot%\system32\logfiles folder, which you can use to check for authentication and authorization failures. And IAS writes events to the System log that you can use to debug connectivity problems.
Using Group Policy to Distribute Wireless Settings
If you're using WPA, you can use Group Policy to distribute settings to wireless clients, saving you from having to configure each client manually. (Currently, Group Policy doesn't support WPA2.) If you're running a Win2K-based AD, you'll need to install a Windows 2003 DC to update your AD schema and run Group Policy Editor (GPE) on that DC to leverage support for wireless networks.
To use Group Policy to configure access to a wireless network, log on to a DC and run the MMC Active Directory Users and Computers snap-in. I recommend that you create an organizational unit (OU) and place the computer accounts of your wireless network clients into it. Then you can apply a Group Policy Object (GPO) specific for wireless settings to the OU without affecting other systems in your forest. Launch GPE, and navigate to the Wireless Network (IEEE 802.11) Policies, which are stored under Computer Configuration, Windows Settings, Security Settings. Right-click in the MMC's right pane and select Create Wireless Network Policy to launch the Wireless Network Policy Wizard. Enter a name for the policy and a description. When you click Finish, the wizard asks whether you want to go back and edit the policy. Select Yes.
From the New Network Policy Properties dialog box, select the General tab, which displays the policy name and description. On this page, you configure the amount of time that clients should wait before they check for a policy update (180 minutes by default) and specify the networks to access. Under Networks to access, you'll see a drop-down list containing three options: Any available network (access point preferred), Access point (infrastructure) networks only, and Computer-to-computer (ad hoc) networks only. I recommend that you select Access point ( infrastructure) networks only. This prevents your wireless clients from attempting to connect to other wireless clients that might be broadcasting the same SSID as one of your wireless networks—a common trick employed by hackers to try to capture data. There are two other policy settings you need to configure here. The first setting—Use Windows to configure wireless network settings for clients—stipulates that you can't use third-party software (e.g., manufacturers' utilities) to configure wireless NICs. You should select this option. The second setting—Automatically connect to non-preferred networks—determines whether clients to which the policy is applied can connect to wireless networks other than the ones listed on the Preferred Networks tab. I recommend that you don't select this option, which will prevent clients from connecting to unknown networks when they can't find a preferred network.
Next, select the Preferred Networks tab to specify the networks to which you want your clients to be able to connect. To add a network, click Add, which opens the New Preferred Setting Properties dialog box. Select the Network Properties tab and enter the network's SSID and description. You'll also see two drop-down lists. Select WPA from the Network Authentication drop-down list and TKIP or AES from the Data Encryption drop-down list. Next, open the IEEE 802.1x tab and select Protected EAP (PEAP) from the EAP Type dropdown list. Click Settings and select from the list of CAs only those you trust. Trusted CAs are those that issue certificates to your RADIUS servers. Next, select Secured Password (EAPMSCHAP v2) from the list under Select Authentication Method. Select Enable Fast Reconnect, and click OK to save the policy.
To verify the new policy, open a command line on a wireless client, and run
gpupdate /target:computer /force
This command fetches the new policy and applies it to the wireless client. After applying the policy, you should see the wireless networks configured in your GPO listed in the Wireless Networks tab of the Wireless Network Connection Properties dialog box.
Other Options, Other Resources
If you're still using WEP to secure your wireless networks, it's time to upgrade to a more secure environment. Using 802.1x technology and PEAP authentication with WPA or WPA2 can provide a strong security infrastructure, and I hope I've simplified the configuration process for you a bit. However, there are alternatives you might want to consider for building a secure wireless network. You can check out some other options on Microsoft's site dedicated to Wi-Fi and security at http://www.microsoft.com/wifi, and find detailed guidance for securing WLANS at http://www.microsoft.com/technet/security/topics/
NetworkSecurity.mspx. Another good wireless security resource is "A Secure Wireless Network is Possible," May 2004, InstantDoc ID 42273. With all these resources available and new wireless security developments appearing all the time, securing your wireless network is a goal within reach.
