Executive Summary: Microsoft Windows Vista is an operating system that is both wireless-friendly and secure. Learn how to use Windows Vista’s wireless networking features to enhance wireless security from the client side. Windows Vista’s wireless networking features let users configure more secure wireless networks and achieve better wireless functionality than in previous Windows operating systems.

Almost every time I advise someone to use a wireless rather than wired networking solution for their small office/home office (SOHO) or their home, I get a quizzical look and the inevitable question “Is that secure?” Admittedly, security is a big concern on wireless networks because wireless networks are more open to anonymous access than physical networks are. However, my typical response is that although wireless can be nonsecure, it doesn’t have to be—it all depends on how much you care about security. The reality is that some people simply don’t care about their computer security, perhaps because of lack of knowledge or because they think they have nothing to lose even if someone does break into their network. But if you’re reading Windows IT Pro, you undoubtedly do care about security.

Windows Vista is a very wireless-friendly, as well as a very secure, OS. In this article, I explain how to use Vista’s wireless networking features to enhance wireless security from the client side. These features let users configure more secure wireless networks and achieve better wireless functionality than in previous OSs.

Wireless Administration
In previous versions of Windows, hardware vendors typically provided their own tools for managing wireless networks. This method was challenging for both users and support technicians because users needed to learn how to use different vendor-specific wireless software depending on the type of computer or network adapter they had, and support personnel had to manage these various clients with different tools—mostly in a decentralized manner. Vista includes wireless client software by default. This software is hardware-vendor independent, and the interface for administering wireless networks is the same for both users and administrators. This single point of administration offers a new level of consistency for wireless clients and makes managing wireless security easier than ever before.

For additional functionality, hardware vendors and developers can use Microsoft’s Extensible Authentication Protocol (EAP) architecture, called EAPHost. EAPHost is basically a framework for creating authentication mechanisms that Vista doesn’t support natively. Hardware vendors or developers can use EAPHost to create a plug-in for an existing Vista wireless client, in order to provide additional authentication or encryption functionality, instead of writing a complete software package. This additional authentication functionality is available to users through the Vista wireless client (rather than in a separate application as with previous versions of Windows).

Connecting to Wireless Networks
One of Vista’s most significant improvements to wireless security is that the wireless client discloses much less information about configured wireless networks. In previous versions of Windows, such as Windows XP, the client periodically broadcasts the Service Set Identifier (SSID) names of all the configured wireless networks. Malicious users can take advantage of this behavior by catching these broadcasts, then tricking a client into connecting to a false Access Point (AP), using an SSID name that matches the SSID name of a real wireless network that’s configured on the client, in order to obtain private information such as a username and password for connecting to a real AP.

In Vista, a wireless client doesn’t broadcast all configured SSID names. Instead, the client broadcasts only those SSIDs that are explicitly configured as hidden and preferred networks, and only if necessary (e.g., when a user initiates a connection to configured wireless networks). If a user doesn’t have any hidden networks configured, no broadcasts will occur from the client side, which greatly enhances security. (Note that using hidden SSID networks isn’t a recommended practice because doing so provides only an illusion of security. Even if your AP doesn’t broadcast SSID names, your clients do. Because you have many more clients than APs, and because clients are mobile whereas APs are static, a malicious user will more likely discover a hidden SSID name by sniffing client broadcast traffic rather than obtaining the name from an AP.)

Vista helps users connect to hidden networks by displaying “unnamed networks” in the Connect to a network wizard, which Figure 1 shows. To access this wizard, right-click the taskbar’s network icon and select Connect to a network. If you select Wireless from the drop-down list, you’ll see all the visible, hidden, and configured wireless networks on the machine. If a user attempts to connect to an unnamed (hidden) network, he or she will be prompted for an SSID name before authentication proceeds. Having to manually enter the SSID name every time you want to connect to a hidden network prevents broadcasting SSIDs from the client side when you’re away from the network. You can automate this procedure by configuring Vista to connect automatically to hidden networks, although this approach requires broadcasting SSIDs. A better alternative it to use a semiautomatic approach: Configure the hidden network, deselect the option for automatically connecting to the network, but select the option to connect to the network even if it doesn’t broadcast the SSID. To use this approach, select the Manage Wireless Networks option from Vista’s Control Panel Network and Sharing Center applet, then open the wireless network’s properties. This approach saves the network’s SSID and authentication settings on the computer, but you still have to connect manually.

If you’re wondering how Vista can discover hidden networks, then you should know that AP hardware actually hides SSIDs by sending a frame with the SSID set as NULL. Although XP and Windows Server 2003 can’t display those networks to users, Vista can.

If a user tries to connect to an unsecured network, Vista notifies the user. A network is considered unsecured if it doesn’t use an authentication and encryption protocol (or if it uses a weak protocol). A Vista client will never automatically connect to an unsecured network. You can use Group Policy to configure clients to prevent all unsecured connections. Automatic connections are possible only for secured networks that are configured with network profiles on the client side.

In Vista, creating and connecting to ad-hoc (without AP) networks is enhanced from both a security and a functionality standpoint. A major security feature for ad-hoc networks is implementation of the Wi-Fi Protected Access 2 (WPA2)–Personal security protocol. As Figure 2 shows, this protocol is the default authentication method in the wizard for creating ad-hoc networks. To access this wizard, start the Network and Sharing Center applet and select the Set up a connection or network option. Before Vista, Wi-Fi Protected Access (WPA) was available only on infrastructure wireless networks, and user-to-user networks were left with weak security methods such as static Wired Equivalent Privacy (WEP).

Another useful new feature for connecting Vista to wireless networks is Group Policy’s Enterprise Single Sign-On service. This feature lets users authenticate to wireless networks and domain controllers (DCs) in a single logon procedure. First, the user is authenticated by using an 802.1x-enabled device (by using a certificate or a username and password). If the logon is successful, the computer’s Group Policy is applied, and credentials are passed to the domain logon procedure. Using the Enterprise Single Sign-On feature also lets you join a client to a domain by using only a wireless network, which isn’t possible in XP. In XP, you have to connect the client to a physical network first, and join the client to the domain—then you can start to work on the wireless network.

Available Security Methods
Vista supports many security methods for authentication and encryption, as Figure 3 shows. WEP was the most commonly used security protocol for securing wireless networks in previous Windows versions. Although WEP is simple to implement, it’s no longer considered a viable security method. WEP’s main weakness is that it’s based on a shared key for encryption of traffic (as well as for vector initialization). In addition, WEP uses an inferior encryption algorithm and has weak key management. These weaknesses make WEP an easily breakable solution that’s no longer recommended.

The most commonly used security protocol in Vista is WPA. WPA has a better design, better key management, and a better encryption algorithm than WEP has. But WPA’s major advantage over WEP is the use of Temporal Key Integrity Protocol (TKIP), which dynamically changes encryption keys as traffic goes between two hosts. Rather than WEP’s cyclical redundancy check (CRC), WPA uses a better and more secure method for maintaining message integrity, called Message Authentication Code.

Vista offers two WPA configuration options: personal and enterprise. WPA-Personal is easier to configure because it uses a shared passphrase. This passphrase, which must be known (and configured) to the client and AP, acts as a base for implementing encryption. Although WPA-Personal is much more secure than WEP, sharing a passphrase can still pose a significant risk, so this implementation of WPA is recommended for small offices or home (ad-hoc) networks. WPA-Enterprise is a much more secure protocol, but it requires the implementation of 802.1x devices, the Remote Authentication Dial- In User Service (RADIUS) protocol, and an authentication server. WPA-Enterprise is intended for use in corporate environments. Both WPA-Personal and WPAEnterprise also exist in version 2 (i.e., WPA2). The most important difference in version 2 is the implementation of the Advanced Encryption Standard (AES)–based algorithm, rather than WPA’s RC4. Although WPA2 is recommended for optimal security, you might experience limitations if your AP or client hardware doesn’t support it.

IEEE 802.1x authentication is designed for medium and large wireless LANs with authentication infrastructure consisting of RADIUS servers and account databases such as Active Directory (AD). This authentication method prevents a wireless client from joining a wireless network until it has performed a successful authentication. For authentication of clients, 802.1x uses EAP, with different methods such as those using username and password credentials (Protected Extensible Authentication Protocol–Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2) or a digital certificate and/ or a smart card (Extensible Authentication Protocol– Transport Layer Security—EAP-TLS).

Using Group Policy to Manage Wireless Networks
Having a consistent policy for wireless connectivity in a corporate environment is important for maintaining a secure network. Using Group Policy is the easiest method for enforcing wireless and other policies. You can use Group Policy to block access to nearby wireless networks managed by different organizations, to disable the built-in support for wireless auto configuration, and to configure wireless clients to automatically connect to your organization’s protected wireless networks.

In Windows 2003 and XP, you can use a Group Policy Object (GPO) to configure wireless settings. However, Windows 2003’s GPO wireless options are limited to those available in XP. Vista greatly extends those capabilities, so the GPO now covers all the new features of wireless connections.

To use Group Policy for managing Vista wireless clients on a corporate level, you must first extend Windows 2003’s AD schema with the proper attributes. The Microsoft article “Active Directory Schema Extensions for Windows Vista Wireless and Wired Group Policy Enhancements” (www.microsoft.com/technet/ network/wifi/vista_ad_ext.mspx) includes detailed instructions for this procedure, as well as the required script. After you extend the AD schema, you can use Vista’s Group Policy Management Console (GPMC—connected to the corporate forest) to configure wireless policies. Create a new GPO, then navigate to Computer Configuration, Windows Settings, Security Settings, Wireless Network (IEEE 802.11) Policies. Because Vista has a new set of wireless options, you must create separate policies for XP and Vista. Fortunately, you don’t have to create a separate GPO for each OS and deal with WMI. You can simply right-click the GPO Wireless Network Policies item and create a new XP or Vista policy. If both types of wireless policies are configured, XP wireless clients will use only their own policy settings, and Vista wireless clients will use only their own policy settings. If no Vista policy settings exist, Vista wireless clients will use the XP settings, because they’re a subset of the settings available for Vista. Note that wireless policies intended for Vista, created from Vista’s GPMC and linked somewhere in the domain, aren’t visible from Windows 2003’s GPMC (unlike XP policies). However, this doesn’t mean that the policies won’t be applied.

Wireless policies have many configuration options, such as preventing users from connecting to ad-hoc networks, preventing users from creating new wireless profiles, and enforcing only preconfigured wireless profiles. By using these options in Group Policy, administrators can create wireless profiles for some or all users that contain information about the SSID, authentication and encryption methods, and some advanced 802.1x options. For example, if you want to preconfigure a wireless network profile for a client so that he doesn’t have to enter any settings, open a new policy window, select the General tab, click Add, and select the network type (infrastructure or ad-hoc). Then, enter all the data for the desired wireless network in the new profile properties window that opens (which Figure 4 shows an example of). If you want to restrict users to connect only to networks that you explicitly specify, select the Network Permissions tab rather than the General tab.

Using Group Policy is the only method for configuring Vista’s Enterprise Single Sign-On feature. Enterprise Single Sign-On options in Group Policy let you configure when 802.1x authentication will occur in relation to user logon, as well as let you integrate user logon and 802.1x authentication credentials on the DC. You can choose between performing wireless authentication immediately before or after user logon, and you can specify the number of seconds of delay for connectivity before the process begins. You can also configure options to prompt the user to fill in additional fields if necessary, and you can specify whether your wireless networks will use a different Virtual LAN (VLAN) for computer and user authentication. To configure these options, open a new policy window, select the General tab, click Add, and select Infrastructure. In the new profile properties window that opens, select the Security tab and click Advanced.

If you’re using WPA2-Enterprise authentication, Group Policy offers a set of options for configuring the caching of 802.1x authentication results, as Figure 5 shows. In the Fast Roaming section, you can configure Pairwise Master Key (PMK) caching and preauthentication options. Wireless clients and wireless APs can both cache the results of 802.1x authentications. Caching those results makes subsequent access much faster when a wireless client roams back to a wireless AP to which the client already authenticated. You can configure a maximum time to keep an entry in the PMK cache and the maximum number of entries. With preauthentication, a wireless client can perform an 802.1x authentication with other wireless APs in its range while it’s still connected to its current wireless AP. You can also configure the maximum number of times to attempt preauthentication with a wireless AP.

Wireless Networks and NAP
Network Access Protection (NAP), which is Windows Server 2008’s and Vista’s new feature for controlling network access (from the client health aspect), can also be applied to wireless networks. Vista can declare its health state while trying to connect to 802.1x-enabled wireless networks. For NAP to work on a wireless network, the current domain environment must include Server 2008 Network Policy Server (NPS). On the client side, Vista must be configured with the proper enforcement agent for 802.1x (i.e., the EAP Quarantine Enforcement Client). To configure this enforcement agent, open the NAP Client Configuration console (napclcfg.msc) and go to the Enforcement Agents node. Start the Services applet from the Control Panel’s Administrative Tools, and configure the Network Access Protection service to start automatically.

When a client that doesn’t comply with company security requirements (e.g., doesn’t have all updates installed) tries to connect to the corporate wireless network, NAP will deny access and will place the client in quarantine (on a separate VLAN). The client will be able to access only remediation servers (e.g., Windows Server Update Services— WSUS) that will provide the necessary updates to make the client compliant. For more information about NAP, including configuring NAP with 802.1x (which is beyond the scope of this article), go to technet.microsoft.com/en-us/network/bb545879.aspx.

Unplug Safely
Vista’s new wireless features can help enhance wireless security in both home and corporate environments. Implementing WPA2 in ad-hoc networks can improve home network security. For corporate implementations, Vista can work with the latest security technologies to boost wireless security.