Troubleshooting IEEE 802.11 Wireless Access with Microsoft Windows
This article describes the tools used to troubleshoot a Microsoft Windows XP or Windows Server 2003-based wireless client, a wireless access point (AP), and the Internet Authentication Service (IAS) when using Institute of Electrical and Electronic Engineers (IEEE) 802.1X authentication for IEEE 802.11-based wireless connections. This article also describes the most common problems with IAS authentication and authorization, certificate properties, and the process of certificate validation for both wireless client and IAS server certificates.
This article assumes background knowledge in IEEE 802.11 wireless LAN and associated security technologies and the components of a Windows-based authentication infrastructure. For background information, see Wireless LAN Technologies and Microsoft Windows. For detailed information about a Windows-based authentication infrastructure, see Wireless Deployment Technology and Component Overview. For detailed information about how to deploy a wireless LAN using IEEE 802.1X authentication, see Deployment of Protected 802.11 Networks Using Microsoft Windows.
For information about how to troubleshoot wireless connectivity on wireless networks that do not use 802.1X authentication, see Troubleshooting Microsoft Windows XP-based Wireless Networks in the Small Office or Home Office.
On This Page
Troubleshooting Tools in Windows
The tools for troubleshooting wireless connections in Windows XP and Windows Server 2003 are the Network Connections folder and tracing.
Network Connections Folder
The Network Connections folder and the notification area 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 indicates the status of the connection.
Figure 1 shows the information available for a wireless connection in the Windows XP Network Connections folder.
In Windows XP Service Pack 2 (SP2) and Windows Server 2003 with Service Pack 1, the Repair capability has been enhanced for wireless connections. You can access the Repair capability through the Repair context menu option of a connection or from the Repair button on the Support tab of the Status dialog box of a connection. When you repair a wireless connection, it is disabled and re-enabled, which clears many error conditions on wireless network adapters.
When a wireless client running Windows XP with SP2 or Windows Server 2003 with Service Pack 1 attempts a wireless connection, it goes through the following authentication states, which are indicated as the status of the wireless connection in the Network Connections folder, and in the new wireless connection Status dialog box, and in the Wireless Network Connection dialog box:
Validating identity Credentials are required for connecting to the wireless network.
Attempting to authenticate Credentials are being exchanged with the wireless network to authenticate a wireless connection.
Authentication did not succeed The credentials for connecting to the wireless network were not valid and authentication has failed.
Connected The credentials for connecting to the wireless network are valid.
Once authentication has succeeded, a wireless client running Windows XP with SP2 or Windows Server 2003 with Service Pack 1 then attempts to obtain a valid IP address configuration and goes through the following states, which are indicated as the status of the wireless connection in the Network Connections folder, and in the new wireless connection Status dialog box, and in the Wireless Network Connection dialog box:
Acquiring network address An IP address configuration is being obtained using the Dynamic Host Configuration Protocol (DHCP).
Limited or no connectivity A DHCP server was not contacted and an Automatic Private IP Addressing (APIPA) address from the range 169.254.0.0/16 was assigned. This state is not shown for wireless ad-hoc networks, which typically do not have DHCP servers. Instead, the status of the connection is displayed as “Connected.”
Connected A DHCP server was contacted and a valid IP address configuration was obtained.
These improvements give the user and the network troubleshooter more information about how the wireless connection is progressing, from the initial association to the allocation of a valid IP address.
If the wireless connection obtains an APIPA address, Windows XP with SP2 and Windows Server 2003 with Service Pack 1 warns you with the following message in the notification area of the desktop: "The connection has limited or no connectivity. You might not be able to access the Internet or some network resources. For more information, click this message." When you click on the message, Windows displays the Support tab of the Status dialog box for the wireless connection, from which you can view additional details or attempt to repair the connection.
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-based 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 configuration process. If a DHCP server is not found, it automatically configures an APIPA or alternate address.
For Windows 2000 Service Pack 4 (SP4) or later or Windows 2000 Service Pack 3 (SP3) with Microsoft 802.1X Authentication Client, use the Ipconfig tool to display the adapter status and IP address configuration for the wireless network adapter.
To obtain detailed information about the Wireless Zero Configuration service for Windows XP SP2 or Windows Server 2003 with Service Pack 1 and the EAP authentication process for all versions of Windows XP or Windows Server 2003, you must enable tracing by typing netsh ras set tracing * enabled at a command prompt.
To obtain detailed information about how the Wireless Zero Configuration service connected to a wireless network for computers running Windows XP with SP2 or Windows Server 2003 with Service Pack 1, try the wireless connection again and view the Wzcdlg.log and Wzctrace.log files in the SystemRoot\Tracing folder. For detailed information about the contents of the Wzcdlg.log and Wzctrace.log files, see A Support Guide for Wireless Diagnostics and Troubleshooting.
To obtain detailed information about the EAP authentication process, try the authentication process again and view the Eapol.log and Rastls.log files in the SystemRoot\Tracing folder. For detailed information about the contents of the Eapol.log file, see A Support Guide for Wireless Diagnostics and Troubleshooting.
For Windows 2000, you can enable tracing in the same way to view the Rastls.log files in the SystemRoot\Tracing folder.
To disable tracing, type netsh ras set tracing * disabled at a command prompt.
For more information about tracing, see "IAS Troubleshooting Tools" in this article.
For Windows XP with SP1, Windows XP with SP2, Windows Server 2003, or Windows 2000 with SP4, 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, available from the Authentication tab for the properties of a wireless network. The names of the servers must match the names of the authenticating servers or authentication will fail. Figure 2 shows the default properties of the Smart Card and Other Certificate EAP type for Windows XP with SP1, Windows XP with SP2, and Windows Server 2003.
For Windows XP with no service packs installed and Windows 2000, 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 wireless connection that corresponds to the wireless LAN network adapter. Figure 3 shows the default properties of the Smart Card and Other Certificate EAP type for Windows XP with no service packs installed and Windows 2000.
For general troubleshooting of Windows XP wireless client issues, see Microsoft Knowledgebase article Q313242, "How to Troubleshoot Wireless Network Connections in Windows XP.”
Wireless Monitor snap-in
For Windows Server 2003-based wireless clients, you can use the new Wireless Monitor snap-in, which can be used to view wireless APs and wireless client event information.
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 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
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 firstname.lastname@example.org was granted access. Fully-Qualified-User-Name = example.com/Users/Client NAS-IP-Address = 10.7.0.4 NAS-Identifier = <not present> 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.
You can use Network Monitor, available in the Microsoft Systems Management Server or the Windows 2000 Server and Windows 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.
Windows Server 2003 has an extensive tracing capability that you can use to troubleshoot complex problems for specific components. You can enable the components in Windows Server 2003 to log tracing information to files using the Netsh command 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 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
Although, you can enable tracing for individual components, it is typically more useful to enable tracing for all components at once, and then look through the log files that begin with "IAS" and the Rastls.log file.
To enable tracing for all components, use the following command:
netsh ras set tracing * enabled
To disable tracing for all components, use the following command:
netsh ras set tracing * disabled
The log files that are generated are stored in the Systemroot\tracing folder.
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.
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, firewalls, 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.
If you are using a third party certification authority, verify that the IAS server can reach Internet resources to perform certificate revocation checking for its own computer certificate and wireless client certificates. For more information, see the "Using a Third-Party CA" section of Deployment of Protected 802.11 Networks Using Microsoft Windows.
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.
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 or computer account (set to Allow access), or if the user or computer 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 must 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.
For more information about certificate revocation, see Troubleshooting Certificate Status and Revocation.
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 184.108.40.206.220.127.116.11.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, 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:
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.
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.
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.
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, the name and password as sent by the wireless client must match the credentials of a valid user or computer account. The successful validation of the MS-CHAP v2 credentials by the IAS server depends on the following:
The domain portion of the account 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 account name corresponds to a valid account in the domain.
The password is the correct password for the account.
To verify user 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.
The certificate has a valid digital signature.
Additionally, the IAS server computer certificate must have the Server Authentication EKU (OID 18.104.22.168.22.214.171.124.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.
This article describes the various tools and techniques to troubleshoot 802.1X-authenticated IEEE 802.11 wireless connections. For Windows XP and Windows Server 2003-based wireless clients, use the information in Network Connections and the tracing facility. For Windows Server 2003-based wireless clients, use the Wireless Monitor snap-in. For wireless APs, use the troubleshooting facilities of the AP. For IAS, use event logging, accounting logging, Network Monitor, and the tracing facility.
See the following resources for further information: