Wireless Deployment Recommendations and Best Practices

Article
09/11/2009

This article describes recommendations and best practices for deploying a protected Institute of Electrical and Electronic Engineers (IEEE) 802.11-based wireless network in a medium to large organization when using IEEE 802.1X authentication and Microsoft® Windows®-based wireless clients and authentication servers.

This article assumes background knowledge in IEEE 802.11 wireless LAN and associated security technologies and the components of a Windows-based authentication infrastructure. For background information, see Wireless LAN Technologies and Microsoft Windows. For detailed information about a Windows-based authentication infrastructure, see Wireless Deployment Technology and Component Overview. For detailed information about how to deploy a wireless LAN using IEEE 802.1X authentication, see Deployment of Protected 802.11 Networks Using Microsoft Windows.

Security Recommendations

IEEE 802.11 wireless LANs have the historical reputation of being unsafe. While that may have been true for the original 802.11 standard, the latest developments in wireless standards such as IEEE 802.1X, Wi-Fi Protected Access™ (WPA™), and Wi-Fi Protected Access 2™ (WPA2™) provide strong protection for wireless traffic in the most rigorous security environments. If you deploy the latest set of wireless standards with a strong authentication method, there are substantial cryptographic barriers to unauthorized wireless clients and passive attackers.

There is a lot of information in the industry about the various wireless security technologies and options for 802.11 wireless networking. This section describes recommendations for security on Microsoft Windows-based 802.11 wireless networks.

Microsoft recommends that you do not use the following:

Service Set Identifier (SSID) suppression

The SSID (also known as a wireless network name) is by default included in the Beacon frames sent by wireless access points (APs). Configuring your wireless APs to suppress the advertising of the SSID information element in Beacon frames does prevent the casual wireless client from discovering your wireless network. However, SSID suppression does not prevent the most unsophisticated hacker from capturing other types of wireless management frames sent by your wireless AP and determining your SSID.

If you want to use SSID suppression, you should understand that Windows XP Wireless Auto Configuration will connect to the first preferred wireless network that is advertising its SSID, even though it is lower in the preferred networks list than a wireless network that is present but is not advertising its SSID. This behavior can produce confusing results when you introduce a Windows-based wireless client using Wireless Auto Configuration into a wireless environment in which some wireless networks are advertising their SSID and some are not.

For more information, see Non-broadcast Wireless Networks with Microsoft Windows.
Media access control (MAC) address filtering

MAC address filtering allows you to configure your wireless APs with the set of MAC addresses for allowed wireless clients. MAC address filtering adds administrative overhead to keep the list of allowed MAC addresses current and does not prevent a hacker from spoofing an allowed MAC address.
Static WEP or shared key authentication

Static Wired Equivalent Privacy (WEP)—in which the WEP key is manually configured and does not change on a per-client or per-authentication basis—is strongly discouraged due to well-documented security weaknesses. The use of shared key authentication is strongly discouraged because it makes a static WEP encryption key much easier to determine.
VPN connections

Some industry sources recommend that to overcome WEP's weaknesses, you should use a virtual private network (VPN) connection to secure wireless frames sent over a private wireless network. With the proper use of modern 802.11 security standards such as WPA or WPA2, VPN connections are not needed to secure wireless frames. Using VPN connections to secure wireless networks add complexity and can cause problems for roving wireless users.

Recommended Security Configurations

Microsoft recommends that you use one of the following combinations of security technologies (in order of most to least secure):

WPA2 with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication and both user and computer certificates

EAP-TLS is the strongest 802.1X authentication method supported by Windows-based wireless clients. EAP-TLS uses digital certificates to provide mutual authentication, in which the wireless client authenticates itself to the authentication server and vice versa. EAP-TLS authentication requires a public key infrastructure (PKI) to issue certificates and keep them current. For the highest security, configure your PKI to issue both user and computer certificates for wireless access.
WPA2 with Protected EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2) authentication and require strong user passwords

If a PKI deployment is not possible or feasible, you can use PEAP-MS-CHAP v2. PEAP is a one-way authentication scheme using TLS to create an encrypted channel over which the wireless client sends its user or computer credentials using MS-CHAP v2. MS-CHAP v2 is an authentication protocol that was originally developed for dial-up and VPN remote access connections and like EAP-TLS performs mutual authentication. PEAP-MS-CHAP v2 can be used to provide strong password-based authentication of wireless clients, but only when used in conjunction with strong user password requirements on your network.
WPA with EAP-TLS authentication and both user and computer certificates

If your wireless equipment does not yet support WPA2, use WPA with EAP-TLS.
WPA with PEAP-MS-CHAP v2 authentication and require strong user passwords

If your wireless equipment does not yet support WPA2 and a PKI deployment is not possible or feasible, use WPA with PEAP-MS-CHAP v2.

The following combinations of security technologies (in order of most to least secure) are discouraged except if used temporarily when transitioning to a WPA2 or WPA-based security configuration:

WEP with 802.1X authentication, EAP-TLS with both user and computer certificates, and periodic reauthentication

If your wireless equipment does not support WPA2 or WPA, you can use the combination of dynamic WEP (WEP with 802.1X authentication) and EAP-TLS with both user and computer certificates. To change the per-client WEP encryption key for a wireless client session, force your wireless clients to periodically reauthenticate by configuring your wireless APs or Remote Authentication Dial-In User Service (RADIUS)-based authentication servers.
WEP with 802.1X authentication, PEAP-MS-CHAP v2, periodic reauthentication, and require strong user passwords

If your wireless equipment does not support WPA2 or WPA and you are not deploying a PKI, you can use the combination of dynamic WEP and PEAP-MS-CHAP v2. However, you must also require strong user passwords and force your wireless clients to periodically reauthenticate.

Preventing Rogue Wireless APs

The deployment of a secure wireless infrastructure only prevents unauthorized access to your wireless network through managed wireless APs. A secure wireless infrastructure does not prevent an employee from plugging an unmanaged or rogue wireless AP with an unsecured configuration into your intranet. Once plugged into your intranet, any wireless client that can connect to the rogue wireless AP can connect to your intranet.

To combat this problem, you should inform your employees of the security risks and consequences of plugging rogue wireless APs into an intranet network tap. To detect rogue wireless APs, some types of network switches allow you to scan for the manufacturer ID portion of the six-byte MAC addresses of known wireless AP vendors. When the switch detects a rogue wireless AP, it can shut down the switch port and send a notification. Alternately, you can install wireless LAN scanning equipment to listen for rogue wireless APs.

Wireless Network Infrastructure Recommendations and Best Practices

The following sections provide recommendations and best practices for the following elements of wireless network infrastructure:

Wireless clients
Wireless APs
Internet Authentication Service (IAS) servers
Active Directory
PKI

Wireless Clients

Use the following operating systems for Windows-based wireless clients:

Windows Vista™ Contains the latest wireless client software for Microsoft Windows, including WPA2, WPA, and enhanced Group Policy and command-line configuration support.
Windows XP with Service Pack 2 (SP2) Contains all the latest wireless fixes and built-in support for WPA. WPA2 support is available for Windows XP SP2 with the Wireless Client Update for Windows XP with Service Pack 2.

If you must use Windows XP with Service Pack 1, install the Wireless Update Rollup Package for Windows XP for WPA support. The use of Windows XP with no service packs installed is not recommended.
Windows Server® 2003 with Service Pack 2 Contains built-in support for WPA, WPA2, and non-broadcast wireless networks.

For WPA2 deployments:

If your wireless APs and switch infrastructure support opportunistic pairwise master key (PMK) caching, no changes need to be made to the computers running Windows Vista or Windows XP with SP2.
If your wireless APs support preauthentication, you must change the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EAPOL\Parameters\General\Global\PreAuthMode registry value to 1 on your wireless clients running Windows XP with SP2. For WPA2 preauthentication, Microsoft recommends that you leave the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EAPOL\Parameters\General\Global\PreAuthThrottle registry value set to its default value.

For more information about opportunistic PMK caching and preauthentication, see Wi-Fi Protected Access 2 (WPA2) Overview. For more information about registry values that modify preauthentication behavior, see Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) Update for Windows XP with Service Pack 2.

When choosing wireless network adapters for Windows-based wireless clients, use the following best practices:

Choose wireless network adapters whose drivers are designed for Windows Vista or Windows XP and support WPA2, WPA, or both as needed.
If you are using dynamic WEP during your transition to WPA or WPA2, choose wireless network adapters that support Windows Vista or Windows XP, WEP encryption with 128-bit keys, and IEEE 802.1X authentication.
For easier deployment, use wireless network adapters that have Plug and Play drivers already included with Windows Vista or Windows XP or are available through Windows Update.
Avoid installing wireless configuration tools that are provided with the wireless network adapter and use Windows Wireless Auto Configuration.

Wireless APs

For a WPA2-based wireless network, choose wireless APs that support WPA2 when used in conjunction with wireless network adapters and their drivers that also support WPA2. To reduce authentication delays when wireless clients roam from one wireless AP to another, choose switched wireless AP configurations that support opportunistic PMK caching and preauthentication or wireless APs that support preauthentication.

For a WPA-based wireless network, choose wireless APs that support WPA when used in conjunction with wireless network adapters and their drivers that also support WPA. If you are using dynamic WEP during your transition to WPA or WPA2, choose wireless APs that support WEP encryption with 128-bit keys and 802.1X authentication.

When you install your wireless APs, immediately change the default settings for the SSID, administrator passwords used to configure the device and, if supported and needed, the Simple Network Management Protocol (SNMP) community name. If possible, use wireless APs that support SNMPv2.

If also supported by your RADIUS servers, choose wireless APs that use Internet Protocol security (IPsec) and Encapsulating Security Payload (ESP) with encryption to provide data confidentiality for RADIUS traffic sent between wireless APs and RADIUS servers. Use Triple Data Encryption Standard (3DES) encryption and, if possible, certificates for Internet Key Exchange (IKE) main mode authentication. IAS servers support IPsec.

If you are installing wireless APs in the plenum area—the space between the ceiling tiles and the ceiling—you must obtain plenum-rated wireless APs to comply with fire safety codes.

When designing wireless AP placement for performance, use the following best practices:

Do not overload your wireless APs with too many connected wireless clients. Although most wireless APs can support hundreds of wireless connections, the practical limit is 20-25 connected clients. An average of 2-4 users per wireless AP is a good average to maximize the performance while still effectively utilizing the wireless LAN.
For higher density situations, lower the signal strength of the wireless APs to reduce the coverage area, thereby allowing more wireless APs to fit in a specific space and more wireless bandwidth to be distributed to more wireless clients.

IAS Servers

When deploying your IAS servers for your RADIUS infrastructure, use the following best practices:

Install at least two IAS RADIUS servers

At a minimum, you must install two IAS RADIUS servers, a primary and a secondary. You can configure the primary IAS RADIUS server and then copy its configuration to the secondary IAS RADIUS server. To balance the authentication load, configure your wireless APs so that roughly half of them use the primary IAS RADIUS server as their preferred RADIUS server and the other half use the secondary IAS RADIUS server as their preferred RADIUS server.
For best performance, install IAS on domain controllers

To provide authentication and authorization of wireless connection attempts, an IAS RADIUS server must contact a domain controller to verify authentication credentials and obtain the properties of user and computer accounts. By installing IAS on a domain controller computer, you eliminate the delay associated with exchanging network traffic with a remote domain controller.
Use strong RADIUS shared secrets

To help protect RADIUS traffic, choose RADIUS shared secrets that are random sequences of upper and lowercase letters, numbers, and punctuation at least 22 keyboard characters long. If possible, use a random character generation program to determine RADIUS shared secrets.
Use as many different RADIUS shared secrets as possible

The actual number of RADIUS shared secrets depends on configuration constraints and management considerations. For example, IAS allows the configuration of RADIUS shared secrets on a per-client or per-server basis. However, many wireless APs only allow for the configuration of a single RADIUS shared secret for both preferred and alternate RADIUS servers. In this case, a single RADIUS shared secret must be used for two different RADIUS client-RADIUS server pairs: the wireless AP with its preferred RADIUS server and the wireless AP with its alternate RADIUS server. Additionally, if you are copying the configuration of one IAS server (the primary) to another (the secondary), the RADIUS shared secret for each wireless AP/preferred IAS server pair must be the same as the RADIUS shared secret for each wireless AP/alternate IAS server pair.

Because IAS in Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, allows you to configure a range of Internet Protocol (IP) addresses to define a single RADIUS client (for example, when placing all the wireless APs on a single subnet for a single building), all the wireless AP/IAS server pairs defined by the IAS RADIUS client are configured with the same RADIUS shared secret.
Use IAS RADIUS proxies for separate account databases

When there are separate account databases, such as different Active Directory® directory service forests or domains that do not have two-way trusts, you must use a RADIUS proxy between the wireless APs and the RADIUS servers providing the authentication and authorization processing. IAS in Windows Server 2003 supports RADIUS proxy functionality and can forward connection requests to different sets of RADIUS servers (for example, in different Active Directory forests) based on the user or computer name in the connection request.

For information about configuring IAS as a RADIUS proxy, see Deployment of Secure 802.11 Networks Using Microsoft Windows.
Use IAS RADIUS proxies to scale authentication traffic

For a large amount of authentication traffic within an Active Directory forest, use a layer of RADIUS proxies between the wireless APs and the RADIUS servers. By default, a Windows Server 2003 IAS RADIUS proxy balances the load of RADIUS traffic across all its configured RADIUS servers on a per-authentication basis and uses failover and failback mechanisms. You can also configure priority and weight settings so that an IAS RADIUS proxy favors specific RADIUS servers.
Use IPsec to protect RADIUS traffic

If also supported by your wireless APs, use IPsec and ESP to encrypt RADIUS traffic between the wireless AP and the IAS servers and between IAS servers. Use 3DES encryption and, if possible, certificates for IKE main mode authentication. IPsec settings for RADIUS traffic sent between IAS servers can be configured using Group Policy and assigned at the Active Directory system container level. For more information about IPsec, see the Microsoft IPsec Web site.

Active Directory

When configuring Active Directory for wireless access, use the following best practices:

If you have a native-mode domain, use universal groups and global groups to organize your wireless computer and user accounts into a single group. For example, create a group named AuthorizedWirelessAccounts that contains all of the user and computer accounts that are allowed to create wireless connections. Using a single group can greatly simplify the configuration of IAS servers for wireless connections and the ongoing management of wireless access authorization.
Set the remote access permission on computer and user accounts to Control access through Remote Access Policy.
Use settings in the Wireless Network (IEEE 802.11) Policies Group Policy extension to automatically configure wireless clients running Windows XP and Windows Server 2003 with your SSID and security configuration. Settings in the Wireless Network (IEEE 802.11) Policies Group Policy extension simplify and centralize the configuration of all wireless clients that are members of your Active Directory domain.

If you are using WPA, install a domain controller running Windows Server 2003 with Service Pack 2 or Windows Server 2003 with Service Pack 1 to configure WPA encryption and authentication settings with Wireless Network (IEEE 802.11) Policies Group Policy extension.

To configure WPA2 authentication settings for wireless clients running Windows XP with SP2 using the Wireless Network (IEEE 802.11) Policies Group Policy extension, the client computers must be members of a Windows Server 2003 Active Directory domain and have the Wireless Client Update for Windows XP with Service Pack 2 installed. The WPA2 authentication settings in the Wireless Network (IEEE 802.11) Policies Group Policy extension must be configured from the Group Policy Object Editor snap-in running on a computer running Windows Vista.

PKI

When deploying a new PKI or leveraging an existing PKI for EAP-TLS authentication of wireless connections, do the following:

Use autoenrollment for computer certificates

If you are using a Windows 2000 or Windows Server 2003 Certificate Services server as an enterprise certification authority (CA) at the issuer CA level, configure autoenrollment of computer certificates to automatically install a computer certificate on all the wireless client computers and the IAS servers.

Once configured, wireless client computers that are members of the domain or become members of the domain are automatically issued new and renewed computer certificates.
Use autoenrollment for user certificates

If you are using a Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, Certificate Services server as an enterprise CA at the issuer CA level, configure autoenrollment of user certificates to automatically install a user certificate on all the wireless client computers.

Once configured, all users that log on to the domain are automatically issued new and renewed user certificates.
Because certificate revocation checking can prevent wireless access due to the unavailability or expiration of certificate revocation lists (CRLs), design your PKI for high availability of CRLs. For instance, configure multiple CRL distribution points for each CA in the certificate hierarchy and configure publication schedules so that the most current CRL is always available.

For additional information about best practices and recommendations for a Windows-based PKI, see the Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure TechNet article.

For More Information

For more information about deploying protected 802.11 wireless networks, consult the following resources: