Troubleshooting Windows XP IEEE 802.11 Wireless Access

Operating System

Microsoft Corporation Published: June 2002

Abstract

This article describes the tools used to troubleshoot a Windows XP wireless client, a wireless access point (AP), and Internet Authentication Service (IAS) and how each tool is used to gather troubleshooting information. This article also describes the most common problems with IAS authentication and authorization, certificate properties, and the process of certificate validation for both the wireless client certificates and IAS server certificates. Microsoft® Windows® XP Technical Article

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2002 Microsoft Corporation. All rights reserved. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Microsoft® Windows® XP Technical Article

Contents

Windows XP Troubleshooting Tools...... 1 Network Connections Folder...... 1 Tracing...... 2 Server Names...... 2 Wireless AP Troubleshooting Tools...... 4 IAS Troubleshooting Tools...... 5 IAS Event Logging and Event Viewer...... 5 Network Monitor...... 5 Tracing...... 5 Enabling Tracing with Netsh...... 6 Enabling Tracing through the Registry...... 6 SNMP Service...... 7 System Monitor Counters...... 8 Troubleshooting IAS Authentication and Authorization...... 9 Validating the Wireless Client’s Certificate...... 10 Validating the Wireless Client’s MS-CHAP v2 Credentials...... 11 Validating the IAS Server’s Certificate...... 12 Summary...... 13 Related Links...... 14 Microsoft® Windows® XP Technical Article

Windows XP Troubleshooting Tools

The tools for troubleshooting wireless connections in Windows XP are the Network Connections folder and tracing.

Network Connections Folder The Network Connections folder and the Windows XP notification icons provide information about the state of the authentication. If an authentication requires additional information from the user, such as selecting one of multiple user certificates, a text balloon appears instructing the user. Within the Network Connections folder, the text under the name of the connection corresponding to the wireless network adapter describes the state of the authentication. Figure 1 shows the information available for a wireless connection in the Windows XP Network Connections folder.

Figure 1 A wireless network connection in Network Connections

Additionally, when you obtain status on the connection, you can view the signal strength on the General tab and the IP address configuration on the Support tab. If the wireless adapter has an Automatic Private IP Addressing (APIPA) address (169.254.0.0/16) or the configured alternate IP address, then authentication has failed and the Windows XP wireless client is still associated with the wireless AP. If the authentication fails and the association is still in place, the wireless adapter is enabled and TCP/IP performs its normal

Troubleshooting Windows XP IEEE 802.11 Wireless Access 1 Microsoft® Windows® XP Technical Article configuration process. If a DHCP server is not found, it automatically configures an APIPA or alternate address.

Tracing To obtain detailed information about the EAP authentication process for Windows XP, you must enable tracing for the EAPOL and RASTLS components using the following commands at a command prompt: netsh ras set tracing eapol enabled netsh ras set tracing rastls enabled After these commands are issued, try the authentication process again and view the Eapol.log and Rastls.log files in the SystemRoot\Tracing folder. For more information about tracing, see “IAS Troubleshooting Tools” in this article. For Windows 2000, you can enable tracing for the RASTLS component.

Server Names If the wireless client is validating the server certificate (enabled by default) and the Connect if the server name ends with string is not correct, authentication will fail. Verify that this string is correct from the properties of the Smart Card and Other Certificate EAP type on the Authentication tab from the properties of the network connection that corresponds to the wireless LAN network adapter. Figure 2 shows the default properties of the Smart Card and Other Certificate EAP type for Windows XP (prior to Service Pack 1 [SP1]) and Windows 2000.

Figure 2 The properties of the Smart Card and Other Certificate EAP type

For Windows XP SP1, you can specify the names of the servers that must authenticate the wireless client in Connect to these servers, from the properties of the Smart Card or other Certificate EAP type. The names of the servers must match the names of the authenticating servers or authentication will fail. Figure 3 shows the default properties of the Smart Card and Other Certificate EAP type for Windows XP SP1.

Troubleshooting Windows XP IEEE 802.11 Wireless Access 2 Microsoft® Windows® XP Technical Article

Figure 3 The properties of the Smart Card and Other Certificate EAP type for Windows XP SP1 and later

For general troubleshooting of Windows XP wireless client issues, see Microsoft Knowledgebase article Q313242, “How to Troubleshoot Wireless Network Connections in Windows XP” at http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q313242&LN=EN- US&rnk=1&SD=gn&FR=1&qry=Q313242&src=DHCS_MSPSS_gn_SRCH&SPR=CHS&.

Wireless AP Troubleshooting Tools

The tools for troubleshooting a wireless AP depends on the tool set and management software provided with the wireless AP. For example:

 Some wireless APs provide signal strength analysis tools that you can use to troubleshoot low signal strength and coverage area issues.

 A wireless AP might also provide a PING facility to check for the reachability of the wireless AP using standard or proprietary wireless protocols.

 A wireless AP might also support Simple Network Management Protocol (SNMP) and the 802.11 Management Information Base (MIB). See the documentation provided with the wireless AP for more information about wireless APs troubleshooting tools and techniques.

IAS Troubleshooting Tools

To help you gather information to troubleshoot problems with IAS, the following troubleshooting tools are available:

 IAS event logging and Event Viewer  Network Monitor  Tracing  SNMP Service  System Monitor counters

IAS Event Logging and Event Viewer To troubleshoot IAS authentication attempts in the system event log, ensure that enable event logging is enabled for all types of IAS events (rejected, discarded, and successful authentication events). This is enabled by default on the Service tab for the properties of an IAS server in the Internet Authentication Service snap-in. Here is an example of the description for a successful authentication event (Source: IAS, Event ID: 1): User [email protected] was granted access. Fully-Qualified-User-Name = example.com/Users/Client NAS-IP-Address = 10.7.0.4 NAS-Identifier = Client-Friendly-Name = Building 7 Wireless AP Client-IP-Address = 10.7.0.4 NAS-Port-Type = Wireless-IEEE 802.11 NAS-Port = 6 Policy-Name = Wireless Remote Access Policy Authentication-Type = EAP EAP-Type = Smart Card or other Certificate

Failed authentication events are Source: IAS, Event ID: 2. Viewing the authentication attempts in this log is useful in troubleshooting remote access policies. When you have multiple remote access policies configured, you can use the system event log to determine the name of the remote access policy that either accepted or rejected the connection attempt (see Policy- Name in the event description). Enabling IAS event logging and reading the text of IAS authentication events in the system event log is the most useful tool for troubleshooting failed IAS authentications.

Network Monitor You can use Network Monitor, available in the Microsoft Systems Management Server or the Windows 2000 Server and Windows .NET Server 2003 families, or a commercial packet analyzer (also known as a network sniffer), to capture and view RADIUS authentication and accounting messages that are sent to and from the IAS server. Network Monitor includes a RADIUS parser, which you can use to view the attributes of a RADIUS message and troubleshoot connection issues.

Tracing Windows 2000 has an extensive tracing capability that you can use to troubleshoot complex problems for specific components. You can enable the components in Windows 2000 Server to log tracing information to files using the Netsh command or through the registry.

Enabling Tracing with Netsh You can use the Netsh command to enable and disable tracing for specific components or for all components. To enable and disable tracing for a specific component, use the following syntax: netsh ras set tracing Component enabled|disabled where Component is a component in the list of components found in the Windows 2000 registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing. For example, to enable tracing for the IASRAD component, the command is: netsh ras set tracing iasrad enabled To enable tracing for all components, use the following command: netsh ras set tracing * enabled The most useful components to enable for tracing of EAP-TLS authentications are the following:

 IASHLPR (the Iashlpr.log file in the SystemRoot\tracing folder)  IASPIPE (the Iaspipe.log file in the SystemRoot\tracing folder)  IASRAD (the Iasrad.log file in the SystemRoot\tracing folder)  IASSAM (the Iassam.log file in the SystemRoot\tracing folder)  IASSDO (the Iassdo.log file in the SystemRoot\tracing folder)  IASUSERR (the Iasuserr.log file in the SystemRoot\tracing folder)  RASTLS (the Rastls.log file in the SystemRoot\tracing folder) The corresponding netsh commands are: netsh ras set tracing iashlpr enabled netsh ras set tracing iaspipe enabled netsh ras set tracing iasrad enabled netsh ras set tracing iassam enabled netsh ras set tracing iassdo enabled netsh ras set tracing iasuserr enabled netsh ras set tracing rastls enabled

Enabling Tracing through the Registry You can also enable the tracing function by changing settings in the Windows 2000 registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing.

You can enable tracing for each component by setting the registry values described later. You can enable and disable tracing for components while the Routing and Remote Access service is running. Each component is capable of tracing and appears as a subkey under the preceding registry key. To enable tracing for each component, you can configure the following registry value entries for each protocol key: EnableFileTracing REG_DWORD Flag You can enable logging tracing information to a file by setting EnableFileTracing to 1. The default value is 0. FileDirectory REG_EXPAND_SZ Path You can change the default location of the tracing files by setting Path to the path you want. The file name for the log file is the name of the component for which tracing is enabled. By default, log files are placed in the SystemRoot\Tracing folder. FileTracingMask REG_DWORD LevelOfTracingInformationLogged FileTracingMask determines how much tracing information is logged to the file. The default value is the maximum mask of 0xFFFF0000. MaxFileSize REG_DWORD SizeOfLogFile You can change the maximum size of the log file by setting different values for MaxFileSize. The default value is 0x10000 (64K). Tracing consumes system resources and should be used sparingly to help identify network problems. After the trace is captured or the problem is identified, you should immediately disable tracing. Do not leave tracing enabled on multiprocessor computers.

SNMP Service You can use the Simple Network Management Protocol (SNMP) Service to monitor status information for your IAS server. IAS supports the RADIUS Authentication Server MIB (RFC 2619) and the RADIUS Accounting Server MIB (RFC 2621).

System Monitor Counters You can use System Monitor to monitor the resource use of specific components and program processes. With System Monitor, you can use charts and reports to determine how efficiently your server uses IAS and both identify and troubleshoot potential problems. You can use System Monitor to monitor the following IAS-related performance objects:

 IAS Accounting Client  IAS Accounting Server  IAS Authentication Client  IAS Authentication Server

Troubleshooting IAS Authentication and Authorization

To troubleshoot the most common issues with IAS authentication and authorization, verify the following:

 The wireless AP can reach the IAS servers. To test this, try to ping the IP address of the wireless AP’s uncontrolled port from the IAS servers. Additionally, ensure that IPSec policies, IP packet filters, and other mechanisms that restrict network traffic are not preventing the exchange of RADIUS messages (UDP ports 1812 and 1813) between the wireless AP and its configured IAS servers.

 Each IAS server/wireless AP pair is configured with a common shared secret.  The IAS servers can reach a Global Catalog server and an Active Directory domain controller.  The computer accounts of the IAS servers are members of the RAS and IAS Servers group for the appropriate domains.

 The user or computer account is not locked out, expired, disabled, or that the time the connection is being made corresponds to the permitted logon hours.

 The user account has not been locked out by remote access account lockout. Remote access account lockout is an authentication counting and lockout mechanism designed to prevent an online dictionary attack against a user's password. For more information, see "Remote Access Account Lockout" in the "Internet Authentication Service for Windows 2000" white paper at http://www.microsoft.com/windows2000/techinfo/howitworks/communications/remoteaccess/ias.asp.

 The connection is authorized. For authorization, the parameters of the connection attempt must:  Match all of the conditions of at least one remote access policy.  Be granted remote access permission through the user account (set to Allow access), or if the user account has the Control access through Remote Access Policy option selected, the remote access permission of the first matching remote access policy must have the Grant remote access permission option selected.

 Match all the settings of the profile.  Match all the settings of the dial-in properties of the user or computer account. To obtain the name of the remote access policy that rejected the connection attempt, ensure that IAS event logging is enabled and look for events that have IAS as the source with the Event ID set to 2. In the text of the event message, look for the remote access policy name next to the Policy-Name field.

 If you have just changed your Active Directory domain from mixed-mode to native-mode, IAS servers can no longer authenticate valid connection requests. You must restart every domain controller in the domain in order for the change to replicate.

Validating the Wireless Client’s Certificate In order for the IAS server to validate the certificate of the wireless client, the following must be true for each certificate in the certificate chain sent by the wireless client:

 The current date must be within the validity dates of the certificate. When certificates are issued, they are issued with a range of valid dates, before which they cannot be used and after which they are considered expired.

 The certificate has not have been revoked. Issued certificates can be revoked at any time. Each issuing CA maintains a list of certificates that should no longer be considered valid by publishing an up-to-date certificate revocation list (CRL). By default, the IAS server checks all the certificates in the wireless client’s certificate chain (the series of certificates from the wireless client certificate to the root CA) for revocation. If any of the certificates in the chain have been revoked, certificate validation fails. This behavior can be modified with registry settings described later in this topic. To view the CRL distribution points for a certificate in the Certificates snap-in, obtain the certificate properties, click the Details tab, and then click the CRL Distribution Points field. The certificate revocation validation only works as well as the CRL publishing and distribution system. If the CRL in a certificate is not updated often, a certificate that has been revoked can still be used and considered valid because the published CRL that the IAS server is checking is out of date.

 The certificate has a valid digital signature. CAs digitally sign certificates they issue. The IAS server verifies the digital signature of each certificate in the chain, with the exception of the root CA certificate, by obtaining the public key from the certificate’s issuing CA and mathematically validating the digital signature. The wireless client certificate must also have the Client Authentication certificate purpose (also known as Enhanced Key Usage [EKU]) (OID 1.3.6.1.5.5.7.3.2) and must either contain a UPN of a valid user account or FQDN of valid computer account for the Subject Alternative Name property of the certificate. To view the EKU for a certificate in the Certificates snap-in (for Windows XP and Windows 2000), double- click the certificate in the contents pane, click the Details tab, and then click the Enhanced Key Usage field. To view the subject alternative name property for a certificate in the Certificates snap-in, double-click the certificate in the contents pane, click the Details tab, and then click the Subject Alternative Name field. Finally, to trust the certificate chain offered by the wireless client, the IAS server must have the root CA certificate of the issuing CA of the wireless client certificate installed in its Trusted Root Certification Authorities store. Additionally, the IAS server verifies that the identity sent in the EAP-Response/Identity message is the same as the name in the Subject Alternative Name property of the certificate. This prevents a malicious user from masquerading as a different user from that specified in the EAP-Response/Identity message. The following registry settings in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 on the IAS server can modify the behavior of the EAP-TLS when performing certificate revocation:

 IgnoreNoRevocationCheck

When set to 1, IAS allows EAP-TLS clients to connect even when it does not perform or cannot complete a revocation check of the client's certificate chain (excluding the root certificate). Typically, revocation checks fail because the certificate doesn't include CRL information. IgnoreNoRevocationCheck is set to 0 (disabled) by default. An EAP-TLS client cannot connect unless the server completes a revocation check of the client's certificate chain (including the root certificate) and verifies that none of the certificates have been revoked. You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as those from third parties.

 IgnoreRevocationOffline When set to 1, IAS allows EAP-TLS clients to connect even when a server that stores a CRL is not available on the network. IgnoreRevocationOffline is set to 0 by default. IAS does not allow clients to connect unless it can complete a revocation check of their certificate chain and verify that none of the certificates has been revoked. When it cannot connect to a server that stores a revocation list, EAP-TLS considers the certificate to have failed the revocation check. Setting IgnoreRevocationOffline to 1 prevents certificate validation failure because poor network conditions prevented their revocation check from completing successfully.

 NoRevocationCheck When set to 1, IAS prevents EAP-TLS from performing a revocation check of the wireless client's certificate. The revocation check verifies that the wireless client’s certificate and the certificates in its certificate chain have not been revoked. NoRevocationCheck is set to 0 by default.

 NoRootRevocationCheck When set to 1, IAS prevents EAP-TLS from performing a revocation check of the wireless client's root CA certificate. NoRootRevocationCheck is set to 0 by default. This entry only eliminates the revocation check of the client's root CA certificate. A revocation check is still performed on the remainder of the wireless client's certificate chain. You can use this entry to authenticate clients when the certificate does not include CRL distribution points, such as those from third parties. Also, this entry can prevent certification-related delays that occur when a certificate revocation list is offline or is expired. All of these registry settings must be added as a DWORD type and have the valid values of 0 or 1. The wireless client does not use these settings.

Validating the Wireless Client’s MS-CHAP v2 Credentials When you are using PEAP/MS-CHAP v2 for authentication, rather than EAP-TLS, the user name and password as sent by the wireless client must match the credentials of a valid user account. The successful validation of the MS-CHAP v2 credentials by the IAS server depends on the following:

 The domain portion of the user name corresponds to a domain that is either the domain of the IAS server or a domain that has a two-way trust with the domain of the IAS server.

 The account name portion of the user name corresponds to a valid account in the domain.  The password is the correct password for the account.

To verify the credentials, have the user of the wireless client log on to their domain using a computer that is already connected to the network, such as with an Ethernet connection (if possible).

Validating the IAS Server’s Certificate In order for the wireless client to validate the certificate of the IAS server for either EAP-TLS or PEAP/MS- CHAP v2 authentication, the following must be true for each certificate in the certificate chain sent by the IAS server:

 The current date must be within the validity dates of the certificate. When certificates are issued, they are issued with a range of valid dates, before which they cannot be used and after which they are considered expired.

 The certificate has a valid digital signature. CAs digitally sign certificates they issue. The wireless client verifies the digital signature of each certificate in the chain, with the exception of the root CA certificate, by obtaining the public key from the certificate’s issuing CA and mathematically validating the digital signature. Additionally, the IAS server computer certificate must have the Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1). To view the EKU for a certificate in the Certificates snap-in, double-click the certificate in the contents pane, click the Details tab, and then click the Enhanced Key Usage field. Finally, to trust the certificate chain offered by the IAS server, the wireless client must have the root CA certificate of the issuing CA of the IAS server certificate installed in its Trusted Root Certification Authorities store. Notice that the wireless client does not perform certificate revocation checking for the certificates in the certificate chain of the IAS server’s computer certificate. The assumption is that the wireless client does not yet have a physical connection to the network, and therefore cannot access a Web page or other resource in order to check for certificate revocation.

Summary

This article describes the various tools and techniques to troubleshoot IEEE 802.11b wireless connections. For Windows XP, use the information in Network Connections and the tracing facility. For wireless APs, use the troubleshooting facilities of the AP. For IAS, use event logging, accounting logging, Network Monitor, and the tracing facility. To troubleshoot IAS validation and the validation of certificates, use the lists and information provided in the article.