Keep It Simple

Single Sign On is the ability to use a centralized database of user names and passwords, such as Active Directory, to authenticate and authorize users and/or computers for different services on an enterprise network. When Single Sign On is implemented, users have to remember only one user name and password, and (in theory) enter logon credentials only once to access all resources for which they are authorized.

Windows Vista includes new Group Policy settings that improve the Single Sign On experience for end users, when authentication is required before access to a wireless network is granted. Single Sign On can be used in conjunction with 802.1x and wired networks; with wireless clients, the new settings are designed primarily to improve the experience for authenticating against a wireless AP (Access Point) and Windows domain simultaneously.

Before discussing the problems that are addressed by Vista’s Single Sign On features, let’s look briefly at the technologies used on enterprise wireless networks.

RADIUS, 802.1x and PEAP

RADIUS (Remote Authentication Dial In User Service) servers allow the implementation of single sign-on solutions, by acting as a gateway between directory services, such as Active Directory, and other devices that require authorization and authentication services. Rather than duplicate or maintain a separate database of user names and passwords on a wireless access point, the AP can communicate with a RADIUS server, which in turn verifies credentials against a centralized database, such as Active Directory.

802.1x is an authentication standard for enterprise networks, preventing clients from sending and receiving packets on the physical network (wired or wireless data link layer) until they have successfully authenticated. In conjunction with WPA- (Wi-Fi Protected Access) and WPA2-Enterprise and a RADIUS server, a Windows client can be authenticated against Active Directory using computer and/or user credentials. RADIUS is known as IAS (Internet Authentication Service) in Windows Server 2003 and NPS (Network Policy Server) in Server 2008.

Also, 802.1x supports certificate-based and password-based authentication, such as:

• Configuring wireless clients to authenticate with smart cards or certificates.
  This is the strongest authentication method but also the most expensive to deploy. It is sometimes known as PEAP (Protected Extensible Authentication Protocol) with EAP-TLS (Transport Layer Security).
• Configuring wireless clients to use secure password authentication.
  Sometimes known as PEAP with EAP-MS-CHAPv2, secure password authentication uses TLS to create an encrypted connection before transmitting credentials.
  
  When P-EAP-MS-CHAPv2 is used, you don’t need to deploy certificates to wireless clients, but a certificate should be installed on the RADIUS server, so its identity can be verified by the client. However, wireless clients will need to have the root CA (certification authority) certificates installed for the issuer of the RADIUS server’s certificate.
  
  If the RADIUS server’s certificate was issued by a Windows Server CA that’s integrated with Active Directory, any domain-joined client will have the appropriate root CA certificates installed by default. In this scenario, to ensure successful authentication, a wireless client must be joined to the domain on a wired network before it can successfully authenticate on the wireless network.
  
  Although the wireless AP is essentially the middleman in the authentication process, the wireless client sends its credentials directly to the RADIUS server, hence the need for the root CA certificates on the wireless client. If the wireless client is authenticated, an encrypted key is sent to the wireless AP, which in turn uses the key to send authentication keys to the wireless client.

Figure 1 Figure 2 Figure 3 Figure 4

Authentication mode	Result
User re-authentication	First, computer authentication is performed, and then user authentication. This is the default and recommended option.
User authentication	Computer-based authentication is performed, and user authentication only if the user travels to a different wireless access point.
Computer authentication	Only computer authentication is performed.
Guest authentication	Restrictions that are applied to the Guest user account are enforced.

Table 1 – Wireless security authentication modes

Single Sign On in Windows Vista

Vista’s new Single Sign On feature allows wireless clients to authenticate to enterprise wireless networks using 802.1x, along with WPA for encryption, before users log on; integrating wireless authentication with Windows logon to give end users a seamless experience when connecting to a domain.

In practice, this means that 802.1x (wireless network) authentication with computer credentials, if configured, is performed before the Windows logon screen is displayed, and 802.1x authentication with user credentials is performed after the Windows logon screen is displayed but before domain logon is processed.

There are several scenarios where domain logon on pre-Vista wireless clients can be problematic:

• When different virtual LANs (VLANs) are used for wireless clients that are configured for user- or computer-based 802.1x authentication;
  Vista’s Single Sign On can be configured to renew the Dynamic Host Configuration Protocol (DHCP) address of the wireless adapter after 802.1x user authentication, if different VLANs are used for user- and computer-authenticated clients.
• When different domain and 802.1x user-logon credentials are required, prompting for two sets of credentials at different times;
  Vista collects all the required credentials on the Windows logon screen when different user credentials are required for domain and wireless network logon.
• When a user logs on to a domain-joined computer for the first time and user-based 802.1x logon credentials are required.
  Vista’s Single Sign On can be configured to perform wireless authentication before domain logon is processed.

Let’s look at a pre-Vista logon problem where Single Sign On is not available. You can assume that the computer is already joined to the domain, and as a result is able to verify the certificate of the RADIUS server, which was provided by a Windows Server Certification Authority integrated with Active Directory. 

As a user tries to log on to a computer for the first time, user-based authentication is required by the 802.1x-enabled wireless network. In this situation, the computer has no cached domain logon credentials for the user, so a connection must be made to a domain controller to authenticate the user. The user won’t be able to log on to the domain because user-based 802.1x authentication to the wireless network has not yet occurred, preventing connection to a domain controller.

In Vista, if Single Sign On is configured, the credentials used to authenticate against the domain and 802.1x are the same, and entered only once. Then 802.1x authentication is performed first, enabling communication with a domain controller for Active Directory logon.

If clients are configured to use computer authentication only, a successful connection is made to the wireless network before the logon screen is displayed, and the user will be able to enter their domain credentials and logon. In Windows XP, if user credentials were also required for access to the wireless network, user-based authentication to the wireless network was not performed until after domain logon, causing failed domain logons and prompting for credentials more than once under certain conditions.

Configuring Vista’s Single Sign On

Vista Group Policy allows you to configure wireless profiles (collections of settings that include the network’s service set identifier, or SSID, Single Sign On settings and other parameters) and push them to Vista clients for use by the wireless LAN AutoConfig service.

On a Windows Server 2008 domain controller, open GPMC (Group Policy Management Console) from Start, Administrative Tools. In GPMC, expand your forest, domain and then right click Group Policy Objects. Select New from the menu. Give the policy a name and then click OK.

The new policy will appear under Group Policy Objects. Right click the policy and click Edit. The Group Policy Management Editor window will open in a separate console. Under Computer Configuration, expand Windows Settings, Security Settings. Right click Wireless Network (IEEE 802.11) Policies and click Create a New Windows Vista Policy. The policy properties will be displayed in a new dialog box. Give the policy a name and description (Figure 1), click Add at the bottom of the dialog and select Infrastructure from the menu.

This is where we start to configure a wireless profile, with Single Sign On enabled, to push to our Vista clients. On the Connection tab, give the profile a name and then type the WLAN’s SSID (in this case, HQWLAN) and click Add as shown in Figure 2. Select the Security tab. Here it’s possible to change settings appropriate for your wireless network and set the authentication mode (see Table 1). Click Advanced.

Under Single Sign On, check Enable Single Sign On for this network and then select Perform immediately before User Logon (Figure 3). Here it’s also possible to initiate a transition to a different VLAN after 802.1x user authentication, if your network separates traffic (to e-mail or Intranet servers for example) from clients that only have computer authentication. Check “this network uses different VLAN for authentication with machine and user credentials” to enable this functionality if required.

Press OK and then OK again on the New Profile properties. Before completing the procedure, at this point it’s possible to export the configuration of a selected wireless profile as an XML profile. This file can then be used to import a wireless profile on a Vista wireless client instead of via Group Policy if required (Figure 4). Click OK to complete the configuration of the new policy. In the Group Policy Management Editor window, you’ll see the new policy in the right-hand pane (Figure 5).

Figure 5

To deploy the new wireless profile to Vista clients, link the new GPO (Group Policy Object) as required in GPMC. If you exported the wireless profile (hq.xml in this example) as described above, you can deploy it using a script or from the command line, with the following command:

netsh wlan add profile filename=”c:\hq.xml”

To verify that the new wireless profile has been added, whether via Group Policy or the netsh command, you can run the following command on Vista:

netsh wlan show profiles