Many small-to-midsized businesses (SMBs) struggle to budget for expensive wireless infrastructure equipment that’s traditionally used in large organizations, even though SMB support teams seldom have the technical expertise needed to configure and maintain this complex hardware and software.
Help is available, however: Features in Windows Server 2008 and Windows Server 2003 provide everything you need to implement a secure wireless LAN (WLAN). You need to have three components in place: a compliant Access Point (AP), a compatible WLAN client, and an authentication server. First, let’s examine the IEEE 802.11i standard for wireless security, then focus on the components, especially the authentication server component. I’ll step you through how to install and configure your authentication server and show you how it fits into an 802.11i Robust Security Network (RSN) implementation.
How IEEE 802.11i Works
The IEEE 802.11i amendment to the 802.11 standard specifies security methods that leap far beyond those provided by the Wired Equivalent Privacy (WEP) standard. WEP was the security recommendation that was included in the original 1997 standard, and its weaknesses were quickly revealed. The security methods specified in IEEE 802.11i include the following three:
IEEE 802.1X authentication. The IEEE 802.1X standard specifies methods used to implement port-based authentication. Port-based authentication is an authentication process that allows only credential exchanges to traverse the network until the user or machine connected to the port is authenticated.
The port is called an uncontrolled port during the time in which it allows only credential exchanges. The port is called a controlled port after authentication is completed. This use of terms may seem counterintuitive, but the language is based on the concept of two virtual ports existing within a single physical port, or WLAN association, in the case of a wireless link. Devices compatible with 802.1X use the Extensible Authenticationv Protocol (EAP) for authentication and to move the port from the uncontrolled (unauthorized) to the controlled (authorized) state. The fundamental concept of EAP is that it’s extensible, meaning that authentication can be handled in different ways and there are several different EAP types. To learn more about the various EAP types you should or shouldn’t use, see the sidebar “EAP Types.”
TKIP and AES-CCMP key management. The Temporal Key Integrity Protocol (TKIP) is recommended as a transitional security protocol for older WLANs. So long as client devices support Advanced Encryption Standard (AES) with Cipher Block Chaining Message Authentication Code Protocol (CCMP) for key management, as most new hardware and software does, a newly implemented WLAN will most likely use AES-CCMP. TKIP and AES-CCMP are used to exchange encryption keys in a secure manner. Both group encryption keys, which are used for broadcast and multicast messages, and private encryption keys must be generated and managed.
RC4 and AES encryption. After the authentication is complete and the encryption keys are implemented, those keys are used with either the RC4 (in the case of TKIP) or AES (in the case of CCMP) encryption algorithms. These encryption algorithms protect the data as it travels across the wireless medium.
How Internet Authentication Service and RADIUS Work
Now let’s look at the three components that must be in place for a secure WLAN: a compliant AP, a compatible WLAN client, and an authentication server. Most APs support 802.11i with the use of TKIP at a minimum, and more APs support AES-CCMP than ever before. As for compatible clients, both Windows Vista and Windows XP can function as RSN clients. RSN dynamically negotiates the authentication and encryption algorithms to be used for communications between wireless APs and wireless clients. Lastly, the core of an 802.11i authentication infrastructure is the authentication server, which is often built in to expensive WLAN infrastructure devices such as WLAN controllers.
In most implementations, the authentication server is a Remote Authentication Dial-In User Service (RADIUS) server. Microsoft’s RADIUS server is the Internet Authentication Service (IAS) in Windows 2003 and Windows 2003 R2. Server 2008 introduces Network Policy Server as the replacement for IAS and many other network services.
In 802.1X terminology, the IAS server plays the role of the authentication server. The AP plays the role of authenticator, and the client plays the role of supplicant. Figure 1 shows their relationship. The supplicant requests access to the network, and the authenticator (the AP) responds by requiring authentication. The supplicant provides credentials for the selected EAP type and sends them to the authenticator. The authenticator then forwards the credentials to the authentication server, IAS, which can request additional information from the supplicant. Eventually, the supplicant is either authenticated or rejected.
Installing IAS
IAS isn’t installed by default on Windows 2003 servers. You need to add the service through the Add or Remove Programs Control Panel application. Select the Add/Remove Windows Components button. In the Windows Components Wizard window, select the Networking Services components and click the Details button. From here, select the Internet Authentication Services subcomponent, then click OK. Click Next to continue with the installation, then click Finish to complete the installation. During this process, you might be asked for the installation media. If requested, provide the appropriate Windows 2003 disks.
Additionally, you need an enterprise root certification authority to be able to install and configure IAS properly. If you’ve studied public key infrastructure (PKI) implementations in Windows environments, you’ll know that this constraint imposes the need for a Windows domain. However, if you’re implementing RADIUS through IAS, you're likely to be running a Windows domain and shouldn’t have a problem.
Configuring IAS as a RADIUS Server
Assuming the default logging properties are acceptable to you, the first thing you must do is configure the clients of the RADIUS or IAS server. Although you might typically think of clients as end nodes on your network, RADIUS-based authentication architectures are different. The end nodes connect to the APs as clients, and the APs connect to the RADIUS server as clients. Therefore, the clients you need to configure in the IAS configuration tool are the APs used in your WLAN.
To begin configuring clients of the IAS service, click Start and navigate to Administrative Tools, Internet Authentication Service. After the IAS manager loads, you’ll see a screen like that in Figure 2. Right-click the RADIUS Clients node and select New RADIUS Client. You’ll need to provide the following information:
• friendly name
• client address
• client-vendor
• shared secret
The friendly-name parameter can be any letters or digits you desire; names like WAP1 and WAP2 always work well for me. The client address can be either the DNS name or the IP address. In most cases, you’ll choose to use the IP address since APs are often implemented without names. The client-vendor setting will usually be configured as the default of RADIUS Standard, which is compatible with most RADIUS devices; however, to take advantage of some vendors’ proprietary enhancements, you might need to select the appropriate vendor. Finally, the shared secret is used to secure the communications between the AP and the RADIUS server. Be sure to use a strong passphrase that includes uppercase letters, lowercase letters, and digits, to ensure that the RADIUS communications across the wired side of the network are secure.
After you create the client configuration settings, the next step is to configure a remote-access policy to control the allowed authentication methods. Create this policy by right-clicking Remote Access Policies and selecting New Access Policy. Click Next in the wizard to begin creating the policy. From here, you can either use a wizard to create a standard policy or you can create a custom policy with full control over all EAP and RADIUS messages. The policy should be given a name that reflects its purpose. I often choose names such as EAP-TLS Authentication or EAP-TTLS Authentication.
Configuring the AP
The final step in this process is to configure the AP to use the RADIUS server to authenticate WLAN clients. The procedure will vary according to the AP model and firmware version. However, the processes are similar:
1. Choose the section of the configuration interface that’s related to security.
2. Select WPA-Enterprise or WPA2-Enteprise as the authentication method.
3. Enter the IP address of the IAS server in the RADIUS server attribute field.
4. Enter the shared secret that you created when you created the RADIUS client for the AP in IAS.
After you complete these steps, the AP should be able to forward authentication requests from WLAN clients to the wired-side IAS/RADIUS server. Remember, the supplicant submits requests to the AP, which forwards them to the RADIUS server. Consequently, the AP effectively acts as a mediator between the clients and the RADIUS server, eliminating the need for WLAN clients to be RADIUS-server–aware.
A Commitment to RADIUS Authentication
Server 2008 introduces support for new EAP types, including EAP-Tunneled Transport Layer Security (EAP-TTLS), Light Extensible Authentication Protocol (LEAP), and EAP Flexible Authentication via Secure Tunneling (EAP-FAST, a secure replacement for Cisco’s LEAP). These changes show Microsoft’s commitment to continued support of RADIUS authentication in Windows Server.
Regardless of the RADIUS solution you select, the core of a solid 802.11i implementation is the PKI. The configuration of the infrastructure is fast and easy as long as you have a PKI in place. (For information about installing a PKI, see the Microsoft article “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure." The good news is that implementing PKI in Windows is a simple task; however, it’s one that calls for thorough planning.