Using Certificates to Secure Your WLAN

Without 802.1x, trying to set up and maintain a secure wireless LAN (WLAN) is a nightmare because of vulnerabilities in the Wired Equivalent Privacy (WEP) standard, especially poor key-management techniques such as manual key distribution. Although 802.1x addresses WEP's major vulnerabilities, you must configure each component to use 802.1x, including workstations, wireless Access Points (APs), and a Remote Authentication Dial-In User Service (RADIUS) server. In addition, the RADIUS server needs a credentials database that it can use to authenticate wireless clients, and you need a Certificate Authority (CA) to grant the RADIUS server a certificate for authenticating itself to wireless clients.

However, Microsoft has leveraged Active Directory (AD) and Group Policy to the point that you can completely insulate the user from the 802.1x implementation process. When your WLAN and clients are properly set up, an authorized workstation that's brought within range of your WLAN automatically authenticates and connects to the WLAN without any action by the user. Unauthorized workstations are blocked from connecting to the WLAN or snooping on its traffic. With 802.1x, there are no WEP keys to manually distribute to APs and workstations, and no lists of media access control (MAC) addresses of authorized workstations on each AP. An 802.1x WLAN first requires wireless clients to authenticate through the AP to a RADIUS server, then lets the AP and wireless client negotiate dynamic encryption keys instead of using the much weaker static keys that most WEP networks use.

I'm pretty blown away by what a good job Microsoft has done integrating 802.1x support into the Windows environment--how easy it is to set up and how well it works. I'm going to show you the simplest way to implement 802.1x and certification-based authentication on a typical network of Windows XP and Windows 2000 computers and a Win2K AD domain. Alternatively, you can use passwords for WLAN authentication. In this case, you can configure workstations so that when they come within range of your WLAN, they either use the username and password that the user specified when logging on to the workstation or prompt the user to manually enter new credentials. Password-based authentication is simpler to roll out than certificates because you don't have to create the certificates, but password authentication requires more action from the user to get on the network, and it's less secure. Password-based authentication leaves your network vulnerable to anyone who can guess an authorized user's password--and we all know how weak user passwords tend to be. Certificate-based authentication lets only users who have a computer with an authorized certificate and private key (or can steal such a computer) on the network. For in-depth coverage of setting up a password-based 802.1x WLAN, see the Windows & .NET Magazine article "A Secure Wireless Network Is Possible," May 2004, InstantDoc ID 42273.

Although Windows supports the most recent wireless security standard--Wi-Fi Protected Access (WPA), which uses 802.1x and addresses WEP's vulnerabilities--I don't use WPA in this article for several reasons. First, as I write this article, you can't use Group Policy to roll out the WPA update automatically to all your workstations--a major drawback if you have many workstations. Second, WPA is actually an interim standard adopted by the wireless industry until the official 802.11i is ratified, which means that if you implement WPA now, you'll need to roll out another update relatively soon. Third, WPA requires device driver or firmware updates for your many wireless NICs and firmware updates for your APs. When you look at all the work required to implement WPA and the little extra protection WPA provides compared with how easily you can implement 802.1x and how much protection 802.1x provides, WPA just doesn't seem worth the trouble. If Microsoft provides a way to update systems and NICs automatically to 802.11i when it comes out, I think 802.11i will be a worthwhile investment.

Adding X
To set up 802.1x on a WLAN, the first thing you need to do is make sure your network supports 802.1x. Windows Server 2003 comes with 802.1x built in, and Microsoft has added 802.1x support to XP with Service Pack 1 (SP1) and to Win2K with the Microsoft 802.1x Authentication Client available at http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/8021xclient.asp. (You can even obtain 802.1x authentication clients for Windows NT and Windows 9x if you have a Premier or Alliance support contract with Microsoft, but you won't be able to use Group Policy to push out a centrally configured wireless networking policy to those computers.)

Next, make sure that any APs you currently have or plan to purchase support 802.1x. Typically, 802.1x-compliant APs have an 802.1x configuration page that you can find when you log on to the AP through your Web browser.

Finally, you must set up one Windows 2003 server and install Internet Authentication Service (IAS) on it. IAS provides the RADIUS server necessary on an 802.1x WLAN. When a wireless client tries to connect to an AP, the AP contacts the RADIUS server to try to authenticate and authorize the client. The RADIUS server checks the client's credentials against AD and lets the AP know whether to let the wireless client connect. You need to use Windows 2003's IAS instead of Win2K Server's IAS because only Windows 2003's IAS supports 802.1x authentication services. Make sure that the Windows 2003 computer that will serve as the IAS server is a member of the domain but not a domain controller (DC). Then open the Control Panel Add/Remove Programs applet, select Add/Remove Components, and install Internet Authentication Service.

Certificate Services
The IAS server needs a certificate to authenticate itself to the wireless clients, so you need a CA server running either Windows 2003 or Win2K Certificate Services. The CA server will also provide certificates for all your wireless clients for authentication to the IAS server. If your AD domain is still running on Win2K DCs and you don't already have an enterprise CA, I suggest that you install Certificate Services on an existing Win2K server as an Enterprise Root CA instead of installing Certificate Services on your Windows 2003 IAS server. For more information about Windows 2003 versus Win2K Certificate Services, see the sidebar "Windows Server 2003 Certificate Services."

When you install Certificate Services, you're basically setting up a public key infrastructure (PKI). For a large enterprise PKI, you should set up one root CA that you then use to certify other subordinate CAs. You keep the root CA off the network to ensure that it's never compromised, and you issue certificates from the subordinate CAs. If a subordinate CA is ever compromised, you can revoke its certificate from the root CA and publish a new certificate revocation list (CRL) to your network. A multilevel CA hierarchy saves you from rebuilding your entire PKI if a CA is compromised. However, it can be overkill for smaller networks. For the sake of simplicity, we'll just set up one Enterprise Root CA on an existing Win2K server and issue certificates directly from it.

Open the Add/Remove Programs applet, then select Add/Remove Components. Before installing Certificate Services, you must install Microsoft IIS because Certificate Services uses IIS for administration and certificate requests. When you install IIS from Control Panel, be sure to enable Active Server Pages (ASP) so that the Certificate Services pages will work. After installing IIS, you can install Certificate Services. When prompted for what type of CA to install, select Enterprise Root CA. "Enterprise" means that CS will automatically integrate with AD, letting you enroll users and computers automatically. Next, you're prompted for identifying information for the CA. I use the name STO CA in this article. After you set up the Enterprise Root CA, all the computers in your domain will automatically trust certificates issued by that CA. Why? When the computers see that a new enterprise CA is published in AD, the computers automatically add that CA's certificate to their Trusted Root Certification Authorities store, which you can view with the Microsoft Management Console (MMC) Certificates snap-in.

Obtaining Certificates
Now that you have a CA, you need to obtain a certificate for your IAS server. Open the Certificates snap-in on the IAS server. When prompted to choose a user, service, or computer account, select computer; when prompted to choose between a remote computer or the local computer, choose the local computer. Then in the main Certificates snap-in window, right-click the PersonalCertificates folder and select All Tasks, Request New Certificate. Click Next on the first page of the Certificate Request Wizard. On the next page, select Computer as the certificate template type, and click Next. Enter WLAN Authentication as the friendly name, click Next, then click Finish. A dialog box will tell you that the certificate request was successful; then, you should see the new certificate in the PersonalCertificates folder.

Now you need to obtain certificates for all your wireless client computers. The easiest way to do so is to create a certificate request in a Group Policy Object (GPO) that will be applied to all your computers that need WLAN access. Either create a new GPO that's linked to an appropriate organizational unit (OU) or edit the Default Domain Policy GPO that's linked to the root of the domain (in most environments, there's no harm in giving each computer in the domain a Computer certificate). In Group Policy Object Editor, navigate to the GPO's Computer ConfigurationWindows SettingsSecurity SettingsPublic Key PoliciesAutomatic Certificate Request Settings node. Right-click in the details pane and select New, Automatic Certificate Request. Click Next on the first page of the wizard. On the next page, select the Computer template, click Next, then click Finish. You should now see a request for a Computer certificate in the Automatic Certificate Request Settings folder. The next time each computer applies this GPO, the computer will request a Computer certificate from your CA and store it in the computer's personal certificate store.

Wireless Client Network Settings
The next step involves configuring the wireless network settings on all your wireless client computers. Again, you'll use Group Policy to automate the process. Using the same GPO as before, navigate to Computer ConfigurationWindows SettingsSecurity SettingsWireless Network (IEEE 802.1x) Policies. Right-click in the details pane and select Create Wireless Network Policy. Click Next on the first page of the Wireless Network Policy Wizard, and enter 802.1x Computer Certificate WLAN Policy as the name of the policy. Click Next, select Edit policies, and click Finish.

In the 802.1x Computer Certificate WLAN Policy Properties dialog box, go to the Preferred Networks tab, where you'll enter the Service Set Identifier (SSID) of your WLAN and configure its authentication settings. Click Add, and enter AcmeSecureWLAN as the network name (SSID). Now navigate to the IEEE 802.1x tab. Select Smart Card or other certificate as the Extensible Authentication Protocol (EAP) type and Computer only as the computer authentication type. Next, you need to configure the certificate settings, so click Settings.

In the Smart Card or other Certificate Properties dialog box, select Use a certificate on this computer and Use simple certificate selection (Recommended), which Figure 1 shows. These two settings cause wireless clients to select an appropriate certificate (the one we just deployed) from their personal store and use the certificate to authenticate to the IAS server. To make sure the clients authenticate to the real WLAN and not some impostor WLAN set up by an attacker, select Validate server certificate in the same dialog box--otherwise, your wireless clients will trust any WLAN that claims to be AcmeSecureWLAN. Then, select the box next to the CA that issued your IAS server a certificate--in this case, STO CA. Click OK three times to close all the dialog boxes. Now, the next time each computer applies this GPO, the computer will configure its wireless network settings as we just defined.

Configure IAS and the APs
Now that you've configured your wireless clients, you're ready to configure your IAS server and APs. On the IAS server, you need to define a remote access policy that links WLAN authentication requests to a requirement for certificate-based 802.1x authentication. You also need to create RADIUS client records for each of the APs on your WLAN. To create the remote access policy, open the MMC Internet Authentication Service snap-in and select the Remote Access Policies folder. Right-click in the details pane and select New Remote Access Policy. 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 WLAN Access for Domain Computers as the name of the remote access policy, and click Next. On the Access Method page, select Wireless to set up the remote access policy with the necessary RADIUS criteria to recognize WLAN authentication requests and apply this policy to those requests. Click Next.

On the User or Group Access page, you define which computers can connect to the WLAN. Select Group and add the STODomain Computers group. STODomain Computers includes all computers in the domain. You could use a less inclusive group, but don't forget that you're also going to add a certificate requirement, so when you're finished, only computers that are a member of STODomain Computers and have a certificate trusted by the IAS server will be able to connect. Click Next. At the Authentication Methods page, you can choose from Protected EAP (PEAP) or Smart Card or other certificate; select the latter and click Configure. In the Smart Card or other Certificate Properties dialog box, you can choose which certificate the IAS server will use to authenticate itself to the client. Select the certificate that your CA issued to the IAS server, and click OK. Back in the wizard, click Next, which brings you to a page that summarizes the remote access policy's details, as Figure 2 shows. Click Finish.

Next you need to configure the RADIUS client records for your APs so that IAS will recognize them. Still in the Internet Authentication Service snap-in, right-click RADIUS Clients and select New, RADIUS Client. In the New RADIUS Client wizard, enter a friendly name for one of your APs and its IP or DNS address. For this example, I'll call the AP First Floor East and give it the IP address 192.168.100.3. Click Next. On the Additional Information page, select RADIUS Standard as the Client-Vendor. The other information you need to enter on this page is a secret to be shared by the IAS server and the AP. Using this secret, the two systems will be able to authenticate to each other and encrypt data sent between them. Enter the same long, complex string of characters in both the Shared secret and Confirm shared secret fields, and remember or write down the secret for when you configure the AP. Select the Request must contain the Message Authenticator attribute, which causes the IAS server to require the AP to use the shared secret, and click Finish. Repeat this process (with different friendly names and addresses) for the other APs.

The final setup step is to configure your APs to communicate with IAS via RADIUS and to require 802.1x authentication from wireless clients. Most AP vendors provide a tiny Web server on their APs so that you can configure them from a Web browser on your workstation. Each AP's configuration pages will look a little different, but they all require the same basic settings for enabling 802.1x. On your AP, find the page that lets you enable 802.1x authentication. Next, enter the IP address of your IAS server and the shared secret. If the AP asks for a port number, enter 1812. Your AP might also let you enter a second RADIUS server, if available, for fault-tolerance purposes. Finally, configure the AP with the appropriate SSID.

Test Case
Now that everything is set up, it's time to test. First, test WLAN connectivity using a legitimate client--a computer that has the appropriate wireless network policy and a computer certificate from the CA. The computer should connect to the WLAN automatically, and a balloon should appear in the lower right corner of the desktop to indicate a wireless connection. Next, try connecting to the WLAN with an unauthorized client. Make sure the WLAN blocks it. You could also obtain a WLAN sniffer and confirm that your WLAN traffic is indeed encrypted.

If you run into any problems, you can diagnose them from the wireless client, the AP, or the IAS server. On the client, check the System and Security logs for certificate-related error messages. Most APs have a logging feature that you can use for tracking down authentication problems between the client and IAS or RADIUS problems between the AP and IAS. On the IAS server, you can look for errors in the System log as well as in the IAS log at C:windowssystem32logfiles. The IAS log isn't very readable, but Iasparse does a great job of producing readable reports from the IAS log. To find out more about IAS logging and Iasparse, see "Activating the IAS Log," December 2003, InstantDoc 40571.