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.
Prev. page
[1]
2
next page 
