Skip navigation

A Secure Wireless Network Is Possible

Lock down connections from your mobile clients

Wireless networks can be secure if you use the right technologies. To add a secure wireless network to an existing Windows network, all you need to do is install one or more 802.1x-compliant wireless Access Points (APs) and one computer running Windows Server 2003. The Windows 2003 server will facilitate 802.1x authentication between your wireless clients and your existing Windows network. Your users will be able to gain access to your wireless network simply by using their existing Windows user accounts.

The Means to Security

To secure the wireless network, we'll use 802.1x and the related Protected Extensible Authentication Protocol (PEAP), which are the wireless networking industry's initial solution to the Wired Equivalent Privacy (WEP) standard's security problems. WEP's main vulnerabilities are poor encryption key handling and a lack of per-user authentication and authorization. The 802.1x standard addresses these problems by implementing better key-management methods and leveraging Remote Authentication Dial-In User Service (RADIUS) servers for authentication, accounting, and authorization.

Wi-Fi Protected Access (WPA) is an even more recent and secure standard that completely replaces WEP, and Microsoft offers Windows updates that support WPA. However, at the time of this writing, you can't use Group Policy to roll out or configure the WPA update; you must do the work manually or purchase some other method of automated software deployment. For more information about WPA, see the sidebar "The WPA Alternative."

The 802.1x standard supports conceivably any authentication protocol through its use of PEAP, a follow-on to Extensible Authentication Protocol (EAP) developed by Microsoft, Cisco Systems, and RSA Security. EAP facilitates choice in authentication methods but doesn't protect them from eavesdropping or modification by attackers. PEAP provides a secure, Secure Sockets Layer (SSL)-based, integrity-checked channel through which client and server can conduct authentication by any means, including certificates, passwords, smart cards, and biometrics. Windows 2003 and Windows XP feature built-in support for certificates, passwords, and smart cards. The Microsoft 802.1x Authentication Client (which I discuss later in the article) gives you the same support for Windows 2000, Windows NT, and Windows 98. All three options provide mutual authentication between the server and client, integrity checking, and encryption to foil eavesdroppers.

You can use either PEAP EAP-Transport Layer Security (TLS) or PEAP EAP-Microsoft Challenge Handshake Authentication Protocol (MSCHAP) v2 for authentication to your wireless LAN (WLAN). EAP-TLS accomplishes authentication by using client certificates, which can be stored on smart cards or the local computer. Smart cards provide the highest level of security for authenticating clients on your wireless network but require an investment in cards and readers and an infrastructure for deployment and support. Client certificates stored on the workstation provide the next highest level of security but require you to take on the maintenance work of deploying client certificates to each client workstation and deploying and managing a public key infrastructure (PKI).

Although Active Directory (AD) and Group Policy's built-in support for certificate management can help you manage certificates, some companies still need an alternative to client certificates for their wireless network—especially smaller companies that want to avoid rolling out a full PKI. That's where EAP-MSCHAP v2 comes in. EAP-MSCHAP v2 uses the familiar, password-based Windows authentication protocol MSCHAP v2 inside PEAP. EAP-MSCHAP v2 lets you leverage existing Windows accounts to control access to the WLAN instead of requiring a full PKI to deploy client certificates to each workstation. However, you should be aware of one limitation when using EAP-MSCHAP v2. Because EAP-MSCHAP v2 is based on the user's password, the user's computer doesn't gain access to the WLAN—or to anything on the network, such as Group Policy Objects (GPOs)—until the user logs on. In this article, I show you how to use EAP-MSCHAP v2 to employ your users' existing Windows account passwords for authentication to your secure 802.1x network. I assume you have a Win2K AD domain, but if not, you can use accounts stored on a Windows 2003 server in a legacy NT domain.

In 802.1x networks, the AP becomes a middleman, simply passing messages between the wireless client and a RADIUS server. The client and RADIUS server authenticate to each other. When authentication is successful, the RADIUS server notifies the AP that the wireless client can join the network. The RADIUS server can also provide the AP with a list of routing restrictions that should apply to the client based on profiles stored on the RADIUS server. This per-client routing control introduces some exciting possibilities, such as the ability to restrict visiting business partners to certain services or areas of your network. For instance, you could configure a profile on the RADIUS server that restricts guests who connect to your network to Internet access only and prevents them from accessing servers on your local network.

XP computers that have Service Pack 1 (SP1) and an 802.11b NIC have built-in support for 802.1x networks, and 802.1x-compliant APs are common. The only other component that needs to support 801.1x is the RADIUS server, support that the Internet Authentication Service (IAS) RADIUS server in Windows 2003 provides. (Win2K Server SP3 provides 802.1x client support but doesn't provide IAS.) Windows 2003 IAS can verify credentials stored in a Windows 2003 or Win2K AD domain, the server's local SAM, or an NT domain. Unless you choose to purchase a third-party certificate for your RADIUS server from a commercial Certificate Authority (CA) or you already have an in-house CA, you need one more component: Microsoft Certificate Services, which you can install on the same Windows 2003 computer that's running IAS. Why do you need a CA in this scenario that uses password-based rather than certificate-based client authentication? Because PEAP requires the RADIUS server to possess a certificate for server-to-client authentication. In this scenario, we'll use Certificate Services to issue one certificate to the IAS server. Figure 1 shows all the components involved in our secure wireless network.

To build our secure wireless network, we install Windows 2003, then install and configure Certificate Services and IAS. Next, we set up the wireless AP and configure it to use RADIUS to contact the IAS server to handle client connection requests. In this particular example, I use D-Link Systems' AirPremier Enterprise DWL-1000AP+ AP, but many other APs from Cisco Systems, Linksys, NETGEAR, and others support 802.1x. Last, we configure a client workstation to authenticate to our wireless network.

Setting Up Windows 2003

After installing Windows 2003 with default settings, you need to make a few adjustments. If you haven't already joined the server to your AD domain during installation, do so now. Next, bear in mind that your APs need to be able to find your IAS RADIUS server, so make sure the server has a static IP address or that its DNS name is being correctly updated in your DNS by pinging the server from some other computer on the network. I prefer a static IP address for crucial servers such as RADIUS servers because failure can affect many users.

Next, install Microsoft IIS, which Certificate Services requires. When you install it, be sure to enable support for Active Server Pages (ASP), which Certificate Services also requires. To install IIS, open the Control Panel Add/Remove Programs applet. At the Add or Remove Programs dialog box, select Add/Remove Windows Components. In the Windows Components Wizard, select Application Server (aka IIA) and click Details. Select Application Server Console and Internet Information Services (IIS), as Figure 2 shows. When you select Internet Information Services (IIS), click Details so that you can select which IIS components to install. In the Internet Information Services (IIS) dialog box, disable everything except Common Files, Internet Information Services Manager, and World Wide Web Service. When you select World Wide Web Service, click Details to specify which components of World Wide Web Service should be installed. At the World Wide Web Service window, select only Active Server Pages and World Wide Web Service. During this process, you'll notice that—in keeping with Microsoft's new emphasis on security—IIS isn't installed automatically, and that when you do install IIS, all dynamic-content components, such as ASP, are disabled. Now click OK in all the dialog boxes and complete the Windows Components Wizard.

Now that IIS is installed, you can install Certificate Services. Start the Windows Components Wizard again and select Certificate Services. Click Details and verify that both Certificate Services CA and Certificate Services Web Enrollment Support are selected. Click OK and complete the wizard. The wizard will ask you what type of CA to configure this computer as. You definitely want an enterprise CA so that it will integrate with AD, but you need to choose between a Root Enterprise CA and a Subordinate Enterprise CA. If you currently have no enterprise CA in your domain, you must make this new enterprise CA a root CA. But if you already have a root enterprise CA, you can make the new CA a subordinate of the existing root. Using root and subordinate CAs facilitates large, maximum-security PKIs that include special measures for protecting CAs from compromise. In this article, we'll keep things simple and make our new CA a root enterprise CA. Continue with the wizard and accept all the default settings proposed for Certificate Services. After your CA is installed, you'd typically need to use a certificate issued by your CA to enroll your IAS server, but because our IAS server is on the same computer as Certificate Services, IAS will be able to use the signed certificate issued by the Certificate Services server to itself.

Installing IAS

Now you're ready to install IAS. Return to the Windows Components Wizard, select Networking Services, and click Details. Enable Internet Authentication Service and complete the wizard. To configure IAS, open the Microsoft Management Console (MMC) Internet Authentication Service snap-in under Administrative Tools. Then, right-click the root of the tree pane and select Register Server in Active Directory.

Next, create a new RADIUS client account for the AP. The AP will use this account to authenticate itself to the IAS server and subsequently request authentication on behalf of wireless clients. Right-click the RADIUS Clients folder in the tree pane and select New RADIUS Client, which displays the first window of the New RADIUS Client Wizard. Enter the "friendly" name you use for the AP as well as its IP address or DNS address and click Next. On the next wizard page, make sure that Client-Vendor is set to RADIUS Standard so that IAS and the AP will successfully communicate. Also, enter a complex string of characters into the two shared-secret fields. Make a note of this secret because you'll need to enter the same information on your AP. Finally, select the Request must contain the Message Authenticator attribute check box to require full authentication from the RADIUS client (for your AP) by using the shared secret. Click Finish.

Your IAS server is now ready to accept RADIUS messages from your AP, except for one thing. IAS's default Remote Access Policy (RAP) automatically rejects any clients that try to connect, even if their authentication credentials are good. Therefore, you need to create a new RAP that grants access to wireless clients that properly authenticate. In the Internet Authentication Service snap-in, right-click Remote Access Policies in the tree pane. Select New Remote Access Policy and click Next on the first page of the New Remote Access Policy Wizard. On the next page, select Use the wizard to set up a typical policy for a common scenario, enter a name such as Allow Domain Users to connect wirelessly for this new RAP, then click Next. The next page asks you to select the access type—select Wireless and click Next.

The wizard then asks which groups the user must belong to in order to gain access through this RAP. You can create a group and populate it with any subset of users to whom you wish to grant wireless access. If you want all users in the domain to have wireless access, add the Domain Users group. Click Next.

The wizard asks which authentication method you want to require for this RAP. Select Protected EAP (PEAP) and click Configure. In the Protected EAP Properties dialog box, you can select which certificate the IAS server should use to authenticate itself to clients and which EAP types should be allowed. Make sure the server's certificate issued by your CA is selected. Also ensure that the only item in the EAP Types list is Secure password (EAP-MSCHAP V2). Click OK in the Protected EAP Properties dialog box, click Next in the wizard, and click Finish to close the wizard.

Configuring the AP

Now you're ready to set up your AP. This step is one of the easiest because the AP has little to do in 802.1x communications—it's just a middleman. The specific steps required to configure an AP differ from product to product, but you configure the same settings regardless of the AP model. You must configure the AP to use 802.1x and provide the IP address of your RADIUS server as well as the shared secret you entered in the AP client account on the RADIUS server. For this example, I perform these steps on a D-Link AirPremier Enterprise DWL-1000AP+.

I'll assume that you've already configured the AP with the same static IP address that you specified when creating the AP client account on the IAS server, a Service Set Identifier (SSID), and an administrator password, and I'll focus on the 802.1x settings. You don't need to configure any actual WEP encryption keys on the AP because WEP is the very problem that 802.1x solves, but you should still configure other AP encryption settings, such as key length and lifetime. After opening my browser and logging on to the AP, I select the Advanced tab, which Figure 3 shows. All I need to do is enter the IP address of my IAS server and the shared secret that I specified when I created this AP's client record in IAS. I leave the port at its default of 1812. Notice that I can specify a second RADIUS (IAS) server. Most APs provide this option so that you can build a fault-tolerant wireless network. For more information about doing so, see the sidebar "Adding Fault Tolerance." Finally, I click Apply to save my changes. After the AP resets itself, it won't let anyone connect to the network unless he or she successfully authenticates to the IAS server.

Before trying to connect to your wireless network from a workstation, first make sure that the AD user account you're going to test is configured to let the IAS server determine the RAP. Open the MMC Active Directory Users and Computers snap-in, find the user account, open its Properties dialog box, and select the Dial-in tab. Verify that Remote Access Permission is set to Control access through Remote Access Policy, as Figure 4 shows. The wireless network would also work fine if you selected Allow access, but Control access through Remote Access Policy provides much more control and eases maintenance. Remote Access Permission governs the various types of remote access (dial-in, VPN, wireless), and you might not want to grant all types of remote access to a user. When you select Control access through Remote Access Policy, you can configure RAPs such as the one we created earlier on the IAS server that control each type of remote access through group memberships and other variables. Then, when a user tries to connect to the wireless network, the AP will query the IAS server. The IAS server will check the user's name and password against AD, verify that the user belongs to the group you specified in your RAP, and reply to the AP. The IAS server will instruct the AP to let the user access the network only if his or her credentials are authentic, he or she matches the criteria for a RAP that allows wireless access, and his or her AD user account doesn't explicitly deny remote access permission.

Configuring a Workstation

To configure a workstation's wireless network connection to authenticate by using 802.1x and PEAP, you need XP with SP1 or you need Win2K with the Microsoft 802.1x Authentication Client for Win2K, which you can download from If you have Microsoft Premier and Alliance Support contracts, you can also obtain 802.1x clients for NT and Win98. The workstation doesn't need to be a member of the domain, although that can simplify the connection process, as I'll explain later.

Open the Control Panel Network Connections applet. Open the wireless network connection's Properties dialog box, and select the Wireless Networks tab. In the drop-down box under Available networks, you should see the SSID from the AP you just set up. Select it and click Configure to open the Wireless network properties dialog box. On the Association tab, select Open for the Network Authentication field and WEP for the Data encryption field, select The key is provided for me automatically (because providing the key is one of 802.1x's main functions), and clear This is a computer-to-computer (ad hoc) network; wireless access points are not used.

Switch to the Authentication tab, which Figure 5 shows. Select Enable IEEE 802.1x authentication for this network, and select Protected EAP (PEAP) as the EAP type. Clear the remaining two check boxes. (The first of these, Authenticate as computer when computer information is available, is applicable only when you're using certificates instead of PEAP.) Click Properties to display the Protected EAP Properties dialog box. You have a choice here. The Validate server certificate check box lets you configure this client so that it will connect to the wireless network only if the IAS server's certificate checks out as valid. This option gives you strong defense against impostor APs that an attacker might set up in your vicinity, but it requires you to import the certificate of your root CA into the workstation's Trusted Root Certification Authorities store, which increases the amount of setup work necessary on each client. Going without the certificate check leaves open the possibility of someone setting up an impostor AP, but MSCHAP v2 does provide mutual authentication (meaning that both the client and the server must prove knowledge of the password). For this example, I cleared the Validate server certificate option.

For the Select Authentication Method drop-down box in the Protected EAP Properties dialog box, select Secured password (MSCHAPv2) and click Configure. You'll see the EAP MSCHAPv2 Properties dialog box. Again, you have an option. The default setting is Automatically use my Windows logon name and password (and domain if any). This setting causes the workstation to use whatever username and password the user entered when he or she logged on to the workstation, as well as the domain name if the user logged on with a domain account. For users who don't have a domain account in the same domain as the IAS server (or a trusted domain), clear this check box. When the box is cleared and the user tries to access the network, the workstation displays a pop-up notification that asks for the user's credentials. Also, remember to clear this option on the computer of a visitor who needs to access your network. You can create a temporary account for the visitor that provides only network access.

Now click OK in all the dialog boxes. Within a few seconds, the workstation should ask you for your credentials. After entering them correctly, you should be able to access the network. If you can't access the network, make sure the workstation has obtained an IP address from your DHCP server. If you receive a message informing you that the logon failed, check the System log on your IAS server for IAS source messages, which are useful for troubleshooting RADIUS problems.

We're done! With one Windows 2003 system, an AP with 802.1x support, your existing AD domain, and XP, Win2K, NT, or Win98 workstations, you can build a secure wireless network. Using PEAP, you can leverage your existing AD user accounts for controlling access to the network and avoid creating redundant credentials for each user or rolling out an extensive PKI. The 802.1x standard takes care of WEP's worst encryption-key-handling problems. After the initial IAS and AP setup, all you have to do is enable 802.1x authentication on your client workstations. Then everyone can enjoy the benefits of wireless networking without losing sleep over security.

TAGS: Security
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.