The Cable Guy Wireless Single Sign-On

Joseph Davies

Wireless connections that are established and then have to authenticate with a private network can add an extra layer of challenge for user and administrator alike. A Windows-based wireless client that is a member of an Active Directory domain must perform an IEEE 802.1X-based authentication to obtain a protected

wireless connection and a domain logon. Because authentication can involve either user or computer credentials and because domain logons are dependent on network connectivity, issues arise when configuring the order in which the authentications will be performed and when specifying which credentials to use. All this can impact domain logons and cause a user to be prompted for credentials multiple times.

Fortunately, Wireless Single Sign-On in Windows Vista® lets you specify that IEEE 802.1X authentication for Wi-Fi Protected Access 2 (WPA2)-Enterprise, WPA-Enterprise, and 802.1X authentication with Wireless Equivalency Privacy (WEP) occur before the user logon process. This allows you to solve domain logon issues in specific configurations. Wireless Single Sign-On also seamlessly integrates wireless authentication with the Windows® logon experience, resulting in happier users overall. For these reasons, I want to take a look this month at the features of Wireless Single Sign-On, how to configure it, and how it works during the user logon process.

Single Sign-On Essentials

A Windows wireless client can perform authentication to the wireless network using only computer or user credentials, or a combination of both. When using only computer credentials, Windows performs 802.1X authentication before displaying the Windows logon screen. This gives the wireless client computer early access to networking resources such as Active Directory® domain controllers.

When using only user credentials, Windows without Single Sign-On performs 802.1X authentication after the user logon process has completed. Figure 1 shows the startup and logon timeline for this scenario.

Figure 1 Timeline when using only user credentials for wireless authentication

Figure 1 Timeline when using only user credentials for wireless authentication (Click the image for a larger view)

The consequences of using only user credentials for wireless authentication are that a user cannot do an initial domain logon to a computer because there are no locally cached credentials for his or her user account and there is no connectivity to the domain controller to authenticate new logon credentials. Moreover, some domain logon operations will fail because there is no connectivity to the domain controllers of the Active Directory domain at this time. Logon scripts, Group Policy updates, and user profile updates fail, resulting in Windows event log errors.

When using a combination of user and computer credentials, Windows performs an 802.1X authentication with computer credentials before displaying the Windows logon screen. After the user has logged on, Windows performs another 802.1X authentication with user credentials. Some network infrastructures use different virtual LANs (VLANs) for computers that have authenticated with computer credentials and those that have used user credentials. If the authentication to the wireless network using user credentials and the switch to the user-authenticated VLAN occur after the user logon process, the Windows wireless client will not have access to networking resources on the user-authenticated VLAN, such as Active Directory domain controllers, during the user logon process. Once again, this leads to failed domain logon operations.

Another problem occurs when the wireless authentication with user credentials uses a different set of security credentials than the user logon credentials. For such configurations, Windows prompts for additional user credentials when wireless authentication begins, which can be confusing.

The Single Sign-On feature in Windows Vista was developed to address the issues of domain logons, separate computer- and user-authenticated VLANs, and prompting the user for different credentials at different times. With Single Sign-On, network administrators can specify that wireless authentication with user credentials occur before the user logon process. When the user credentials needed for user logon and for wireless authentication are different, all of the required credentials are requested and collected on the Windows logon screen.

With Single Sign-On, a Windows Vista wireless client can be configured to perform wireless network authentication with user credentials before the user logon process. Figure 2 shows the new startup and logon timeline.

Figure 2 Timeline when wireless network authentication with user credentials occurs before user logon

Figure 2 Timeline when wireless network authentication with user credentials occurs before user logon (Click the image for a larger view)

This allows for configurations that use only user credentials or a combination of user and computer credentials with separate VLANs with no loss of functionality. Because the wireless client has network connectivity or connectivity to the user-authenticated VLAN before the user logon process starts, domain logon operations can complete successfully. For an example, see "Joining a Windows Vista Wireless Client to a Domain" at microsoft.com/technet/network/wifi/vista_bootstrap_wireless.mspx.

Based on the configuration of the wireless profile, Single Sign-On consolidates the input fields for the user credentials for wireless authentication and adds them to the Windows logon screen. Therefore, all of the user credentials for user logon and wireless authentication using user credentials are supplied by the user at the same time.

Extensible Authentication Protocol (EAP) methods written for the new EAPHost architecture in Windows Vista can use the EAP Pre-Logon Authentication Provider (PLAP) Support API to include input fields needed for authentication on the Windows logon screen. For more information, see the SSO and PLAP API at msdn2.microsoft.com/bb530584.

As an example of a Single Sign-On session, consider a Windows Vista wireless client that is configured to perform authentication using only user credentials and a user name and password for both domain logon and 802.1X authentication. When the user presses Ctrl+Alt+Del at the initial Windows Vista screen, Single Sign-On determines that the 802.1X authentication must occur prior to the user logon. When the user types his or her user name and password, Single Sign-On performs user-based wireless network authentication first and displays a message indicating that it is connecting to the wireless network by its name. After wireless authentication, Windows Vista performs user logon and displays the user's desktop.

Configuring Single Sign-On

Behind the Scenes

To add to your understanding of the wireless authentication process, let's take a more detailed look at what happens when the user actively tries to log on. When a user hits Ctrl+Alt+Del for user logon on a wireless client running Windows Vista, the following steps are executed:

  1. Wireless Auto Configuration determines the wireless network profile to use. If the wireless client has already successfully performed authentication with computer credentials, the currently connected wireless network profile is used. If the determined wireless profile is configured to perform authentication with only computer credentials, no additional wireless authentication with user credentials is needed. Steps 2 through 6 assume that the selected wireless profile is configured to perform authentication with user credentials, has Single Sign-On enabled, and the setting Perform immediately before User Logon is selected.
  2. The user types his or her credentials for user logon and wireless authentication (if needed) and initiates the user logon.
  3. Windows displays a message to the user that it is attempting to connect to the wireless network name.
  4. Windows attempts to perform a wireless network authentication with user credentials. If the Allow additional dialogs to be displayed during Single Sign-On setting is enabled and the EAP type needs to display additional dialog boxes to the user, Windows displays the dialog boxes. If wireless authentication does not successfully occur within the Max delay for connectivity (in seconds), wireless authentication is abandoned. If the setting This network uses different VLAN for authentication with machine and user credentials is selected, Windows performs a DHCP renewal of the IP address configuration of the wireless network adapter when the wireless authentication is successful.
  5. Windows performs the user logon process.
  6. Windows displays the desktop.

If the Perform immediately after User Logon setting is selected, Windows performs the steps in the following order: 1, 2, 5, 3, 4, 6.

To enable and configure Single Sign-On, you can use the Wireless Network (IEEE 802.11) Policies Group Policy extension and configure the advanced security settings for a wireless profile of a Windows Vista policy. For more information on this, see "Wireless Group Policy Settings for Windows Vista" at technetmagazine.com/issues/2007/04/CableGuy.

On the Advanced security settings dialog box, select Enable Single Sign-On for this network and configure Single Sign-On options as needed. Figure 3 shows an example of Single Sign-On enabled with the default settings.

Figure 3 Default Single Sign-On settings

Figure 3 Default Single Sign-On settings

There are Single Sign-On settings to perform 802.1X wireless authentication immediately before or after the user logon process and to specify the time delay for 802.1X authentication to complete before starting the user logon process. You can also indicate whether to display dialog boxes beyond the consolidation of input fields on the Windows logon screen. For example, if an EAP type wants the user to confirm the certificate sent from the Remote Authentication Dial-in User Service (RADIUS) server during authentication, the EAP type can display the dialog box.

You can also specify that the wireless client should initiate a Dynamic Host Configuration Protocol (DHCP) renewal of the TCP/IP configuration of the wireless adapter after performing user-based authentication. Select this option if there are separate VLANs for computer- and user-based authenticated wireless clients and those VLANs are different IPv4 or IPv6 subnets.

After you create the wireless profile containing the Single Sign-On settings within the policy, you can also configure Windows Vista wireless clients by exporting the profile as an XML file and then importing the XML profile on Windows Vista wireless clients.

To create a Single Sign-On XML wireless profile, create a wireless profile with the appropriate Single Sign-On settings. On the General tab of the Windows Vista wireless policy, click the wireless profile with the Single Sign-On settings, and then click Export. When prompted, specify the profile XML file name and its location.

To use the Single Sign-On XML profile to configure another Windows Vista wireless client, import the XML profile with the command:

netsh wlan add profile filename=
    "[FileName].xml"

To determine if a wireless profile has Single Sign-On enabled, use:

netsh wlan show profile=[ProfileName] 

Single Sign-On settings are listed in the "Security settings" section of the netsh wlan show profile command display and in the text of wireless connection events in the Windows event log. You can also use the Event Viewer snap-in to view the events in the Microsoft\Windows\WLAN-AutoConfig folder of the Applications and Services logs with the source of "WLAN-AutoConfig" and event IDs 13001, 13002, 13003, and 13004.

You'll find more information at the Wireless Networking Web page at microsoft.com/wifi. And see the "Behind the Scenes" sidebar for more details on the Single Sign-On process.

Joseph Davies is a technical writer with Microsoft and has been teaching and writing about Windows networking topics since 1992. He has written eight books for Microsoft Press and is the author of the monthly TechNet Magazine Cable Guy column.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.