Consider the following scenario.

• You are running a Windows Vista-based computer.
• You use a wireless access point that is configured to use Wireless Encryption Protocol (WEP) and shared-mode network authentication.
• In the properties of the wireless network connection, you click View Wireless Networks, and then you click Choose a wireless network.

When you double-click the WEP-shared mode access point in this scenario, you cannot connect to the access point. Instead, you receive the following error message:

Windows cannot connect to access_point.

On a Windows Vista-based client computer, you access an online document that is on a site that uses Windows Live ID (WLID) authentication. Then, you are prompted for user credentials two times. However, you expect to be prompted for user credentials only one time.

You are connected to a remote network over a virtual private network (VPN) connection from Windows Vista. However, every time that you try to access a local resource on another computer, you are prompted for authentication. You expect that stored credentials for the resource that you are trying to access will be used for local access.

On a computer that is running Windows Vista, you try to establish a dial-up virtual private network (VPN) connection that uses Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) for authentication.

If there are no user certificates on the computer, you may receive the following error message:

Error: 0×80420100: There was an unknown error.

When the Network Access Protection Agent service is disabled on a Windows Vista-based computer, the Transport Layer Security (TLS) session cookie is not updated. Also, the cookie will be reused when the Network Access Protection Agent service is enabled. This lets successful authentications occur even though the authentications do not participate in Network Access Protection (NAP).

When you configure a Windows Vista-based computer to use machine authentication and to validate the RADIUS server certificate, the computer may be unable to connect to the network.

This problem occurs when the following conditions are true:

• When you configure the network authentication method, you click to select the following check boxes:
  • Validate Server Certificate
  • Connect to these servers
• You do not enter any server name in the text box under the Connect to these servers check box.

When you use the Group Policy Management Console to configure a Group Policy object for wireless access, you experience the following symptom.

When you click Microsoft: Protected EAP (PEAP) in the Select a network authentication method list, and then click Properties, the Select Authentication Method list appears in the Protected EAP Properties dialog box as expected. However, Secured password (EAP-MSCHAP v2) is the only item that is displayed in this list. When you click the drop-down arrow to expand the list, no other authentication methods are displayed. Therefore, you cannot select an alternative authentication method.

You experience this issue when you use the Group Policy Management Console in Windows Server 2008 or in Windows Vista.

Note: For more information about how to view the Select Authentication Method list, see the “More Information” section.

When a user belongs to many groups, that user may have problems with authentication or with Group Policy settings. The following Microsoft Knowledge Base articles describe these symptoms in more detail:

269643 Internet Explorer Kerberos authentication does not work because of an insufficient buffer connecting to IIS
280380 Buffer overflow exploit possible with extended stored procedures
The existing resolution that is described in these articles instructs you to modify the MaxTokenSize registry value. An improvement has been made to this resolution. If you use the hotfix that is described in this article, you may not have to edit the default MaxTokenSize value.

The hotfix that is described in this article supersedes the hotfixes that are described in Microsoft Knowledge Base articles that are listed in this section.

You use the netsh advfirewall consec command together with the auth1 or auth2 authentication parameters to create a connection security rule that will work together with authentication methods that are specified on a Windows Vista-based computer. After you do this, the order of the values that you specify for the auth1 or auth2 parameters is not preserved in the connection security rule. Regardless of the order in which you specify the values for the auth1 and auth2 parameters, the connection security rule is created together with authentication parameters that are specified in the following order:

Auth1: ComputerKerb, ComputerCert, ComputerPSK, ComputerNTLM, Anonymous

Auth2: ComputerCert, UserKerb, UserCert, UserNTLM, Anonymous

For example, the following command creates a connection security rule that lists the ComputerKerb authentication method before the ComputerNTLM authentication method in the first authentication set:

netsh advfirewall consec add name=�Authentication Test� endpoint1=any endpoint2=any action=requestinrequestout auth1=computerntlm,computerkerb

Note: The netsh advfirewall consec set command also displays the same behavior when you use the auth1 or auth2 parameter with it.

Consider the following scenario:

• On a Windows Vista-based computer, you map a drive to a Web Distributed Authoring and Versioning (WebDav) shared file that is located on an Internet Information Services (IIS) 6.0 server. To map the drive, you use the following command:
  

  NET USE X: HTTPS://SERVERNAME/SHARENAME

  Note: The X placeholder represents the letter of the drive that you want to map to the shared resource. The SERVERNAME placeholder represents the server on which the shared file is located. The SHARENAME placeholder represents the shared file to which you want to map the drive.

• You select a certificate when you are prompted, and you click OK to confirm.

In this scenario, you receive an error message that resembles the following:

System error 1397 has occurred. Mutual Authentication failed. The server’s password is out of date at the domain controller.

This problem may also occur when you use the HTTPS protocol to try to access a WebDav shared file on a Java-based WebDav Server.

Notes:

• This problem occurs if mutual authentication is enabled on the server that is running IIS 6.0 server.
• If you use the HTTP protocol instead of the HTTPS protocol to access the WebDav shared file, this problem does not occur.
• After the dialog box appears, if you do not click OK to confirm the selection of the certificate within 10 seconds, this problem does not occur.