Securing Wireless LANs with PEAP and Passwords

On This Page

	Introduction
	Overview
	Chapter Prerequisites
	Essential Maintenance Tasks
	Operating the WLAN Infrastructure
	Troubleshooting
	Summary
	References

Introduction

This chapter covers the operational procedures involved in managing the Securing Wireless LANs with PEAP and Passwords solution. The chapter contains guidance on the key operational and support tasks that you need to perform to maintain the wireless local area network (WLAN) security infrastructure, including the Internet Authentication Service (IAS) servers, certification authority (CA), wireless access points (APs), and the WLAN clients. However, this chapter does not include guidance on general network management or the management of aspects other than security services; for example, network traffic analysis and optimization.

Top of page

Overview

The major sections in this chapter are:

Top of page

Chapter Prerequisites

You should be familiar with the administration of Microsoft Windows Server™ 2003 or Windows 2000 Server. The following areas are especially relevant:

In addition, you should have read the following chapters and have a thorough understanding of the architecture and design of the solution:

Top of page

Essential Maintenance Tasks

This section lists the key tasks that you must perform to successfully operate your WLAN infrastructure. These tasks can be divided into two categories:

This section also lists the tools and technologies used in the procedures in this chapter.

Initial Setup Tasks

The following table shows the tasks that must be performed to put the WLAN security infrastructure into production.

Table 8.1: Initial Setup Tasks

Maintenance Tasks

The following table shows the tasks that must be performed regularly to keep your LAN security infrastructure operating correctly. You can use this table for planning the required resources and the operational schedule for administering the system.

Table 8.2: Maintenance Tasks

Tools and Technology Required

The following table lists the tools or technologies required for the procedures described in this chapter.

Table 8.3: Required Technology

Table 8.4: Recommended Technology

Top of page

Operating the WLAN Infrastructure

This section includes the major tasks that you need to perform to maintain the WLAN security infrastructure.

Operational Tasks

Operational tasks include jobs that need to be done at regular intervals to keep the WLAN infrastructure functioning correctly.

Backing up IAS and the Certification Authority

You need to perform regular backups of the IAS servers, including the IAS server running the CA. IAS requires a special procedure to export its settings to a file, which can then be backed up with a normal file backup. You can back up Certificate Services using Windows system state backup, which is available in the Windows Backup tool. You should establish adequate backup procedures on all the servers on which IAS is running.

The following two procedures are not mutually exclusive; you need to configure both an IAS backup and a server backup.

Configuring the IAS Backup

You need to create a folder with restricted permissions into which the IAS configuration will be exported each night. You also need to create a scheduled job that will run the IAS configuration backup every night (the backup script does not require IAS to be shut down during the backup operation). If the backup succeeds, an event is written to the Windows Application log. An error event will be logged in the case of a backup failure.

Caution: The IAS backup files include all of the RADIUS client secrets. This is highly sensitive information, so you should be careful to store this backup data securely.

To configure the IAS backup

Taking Server Backups

Having set up a scheduled task to back up IAS configuration to disk, you must also configure a regular backup of the server system state and the exported IAS configuration files to a removable medium or to a network location. The simplest way to do this is to use the built-in Windows Backup tool. If you use a different backup system, you must establish whether it includes the functionality equivalent to the Windows system state backup (you should be able to find this out from your backup system's documentation). A system state backup (or equivalent) is essential to properly back up Active Directory and Certificate Services keys and certificate databases.

If your backup software does not have Windows system state backup functionality, you can perform the following steps:

You should do the following to ensure safe and consistent backups:

Testing the Backups

You can test system backups adequately only by restoring them to a test server and verifying that the restored server functions as expected. A system state backup must be restored to a system that has a disk layout identical to that of the backed up server. For example, Windows must be installed in the same path on the test restore server as on the backed up server and the drive layout for storing Windows files (such as paging files) should be identical for the two servers.

Important: To help avoid name and IP address clashes between the test restore server and the original server, the test server should be kept offline from the time when the system state restore is started.

To restore the server

Monitoring

This section describes monitoring the IAS and CA components of the WLAN security infrastructure. It does not include any guidance on monitoring the wireless APs or other network devices, nor does it include general advice on monitoring Windows servers. Information on monitoring Windows servers is available from the "References” section at the end of the chapter.

Most of the procedures in this section use automated monitoring scripts supplied with the solution. If these scripts detect a failure, they will trigger an alert and, in some cases, attempt to recover from the failure.

Configuring Alert Types

Any alerts from the monitoring scripts can be sent to the Windows Application event log or to one or more e-mail recipients (or both). Before enabling the monitoring tools, you need to specify the alert types that you want. In addition, if you have opted to send e-mail alerts, you need to provide the e-mail addresses of the recipients and the name of the e-mail server to which you want to send the messages.

To specify these parameters, you need to edit the constants.vbs file. The relevant sections from this file are shown here, with items that you may want to change shown in Italics:

'Alerting parameters 
CONST ALERT_EMAIL_ENABLED = FALSE    'set to enable/disable e-mail  
CONST ALERT_EVTLOG_ENABLED = TRUE    'set to enable/disable eventlog entries 
' set to comma–separated list of recipients to get e-mail alerts 
CONST ALERT_EMAIL_RECIPIENTS    = "Admin@woodgrovebank.com,Ops@woodgrovebank.com" 
'SMTP server to use (use DNS name or IP address) 
CONST ALERT_EMAIL_SMTP     = "mail.woodgrovebank.com"

Monitoring IAS

IAS will record many different events in the Windows System log. These include service start and stop notifications (and any associated errors or warnings) and notifications of authentication attempts. (Authentication request log entries are described in detail in the "Troubleshooting” section later in this chapter.)

Enabling Monitoring of IAS

The solution includes a simple script that monitors the responsiveness of IAS. The script checks to see if IAS process is running. If it is, the script tries to query IAS using the Server Data Objects interface. If either of these checks fails, the script issues an alert.

Note: The monitoring script does not check for successful RADIUS authentication—it only checks the general responsiveness of the IAS process. To check end-to-end RADIUS operations, you need a RADIUS client to emulate the wireless APs relaying the WLAN client request.

The following procedure describes how to configure the monitoring script to run as a scheduled task so that it automatically alerts you if IAS stops responding. However, because the script is running on the server itself, it will obviously not alert you if the server as a whole has failed; therefore, you must also monitor your servers to ensure that they are alive and responding. You need to carry out the following procedure to configure the script to run as a scheduled task on each IAS server.

Every time an error is detected, an alert is sent by e-mail (if e-mail alerts have been configured) and an event is written to the Application log (see the table in the next section for details of the event types logged). In contrast to the CA monitoring script, no attempt is made to correct problems by restarting IAS. Because IAS, unlike a CA, is needed continuously to authenticate WLAN clients, allowing the monitoring script to blindly restart IAS may cause problems rather than resolve them. Instead, you should watch for any alerts generated by the script and perform a proper diagnosis of the cause of the alert before attempting to repair the problem manually.

To configure IAS monitoring

IAS Events Logged by the MSS Scripts

The monitoring script and the IAS backup script log the following types of events to the event log.

Table 8.5: IAS Events Returned by IAS Tools Scripts in This Solution

Monitoring the Certification Authority

The CA requires relatively little attention beyond monitoring for general server health and performing adequate backup. In this solution, the CA is only required for the relatively rare tasks of issuing certificates to new IAS servers and renewing existing certificates once a year. The CA, therefore, is not normally a critical service.

The CA also publishes a list of certificates that have been revoked by the administrator. This list, known as a Certificate Revocation List (CRL), is published weekly to the Active Directory. This CA will only issue a small number of certificates, so the CRL will also be small and will typically be empty. Despite this, it is essential that the CRL is published to Active Directory in a timely manner so that the applications can check on the revocation status of any certificates issued by the CA. For example, the CA itself needs to check the revocation status of any certificate it issues before sending it to the certificate requestor.

The CA monitoring script checks that the CA is responding to requests and that a valid CRL is available in Active Directory. If either of these checks fails, the script attempts to restart the CA. In case of a CRL failure, it also tries to publish a new CRL. If a failure is detected even after these recovery attempts, an alert is generated that is sent as an e-mail message to the configured e-mail account and is written to the event log.

Enabling Monitoring of the Certification Authority

The following procedure describes how to configure the monitoring script to run as a scheduled task so that it will automatically alert you and attempt recovery if an error is encountered. This script needs to be run only on the CA server.

To configure the CA monitoring script

Certification Authority Events Logged by the MSS Scripts

The CA monitoring script logs the following events to the event log.

Table 8.6: CA Events Returned by the CA Monitoring Script in This Solution

Managing Changes

The tasks in this section relate to changes that you may need to make to the configuration of your WLAN security infrastructure.

Windows Security Update Management

Both IAS and Certificate Services updates are included in the base service packs and patches for Windows Server 2003; you do not need to update these components separately.

You should read through the guidance and follow the references given in the "Server Security Patching" section in Chapter 3, “Preparing Your Environment.”

Managing Changes on Your IAS Servers

Chapter 5, “Building the Wireless LAN Security Infrastructure,” recommended that you nominate one of your IAS servers as the "master" server; the server on which you will make all IAS configuration changes (see the "Deploying Settings to Multiple IAS Servers" section in Chapter 5). These changes will then be replicated to the other servers in your organization, using automated export and import of the IAS configuration database to ensure consistent settings throughout your IAS infrastructure.

The set of RADIUS clients (the wireless APs) configured on each IAS, however, are not normally replicated. The Wireless APs supported by each server may vary substantially and rarely will two IAS servers have exactly the same set of clients (this can be the case if you have two central IAS servers to service all wireless APs in your organization, for instance).

Backing up IAS Settings Prior to Making Changes

Even though you have scheduled backups of your servers every night, it is a good idea to perform a manual backup of IAS prior to making changes on your servers. This will allow you to roll back any changes and restore the server state immediately prior to the changes made. The following procedure uses the backup script to export server configuration, policies, log settings, and RADIUS clients.

To backup the IAS configuration

Replicating Settings to Other IAS Servers

You should establish your own repeatable procedure to ensure that the settings from your master server are replicated to all other IAS servers in your organization. This may involve instructing local support staff to import the settings. More often, this will be performed remotely by copying the configuration files and using a Remote Desktop session to run the configuration import script.

To replicate the settings to other IAS servers, follow the procedures described in the "Replicating Settings from the First IAS Server" section in Chapter 5, “Building the Wireless LAN Security Infrastructure.”

Note: You might find it useful to embed a version number in the Remote Access Policy name so that it is easy to check that all IAS servers have same settings version.

Adding IAS Servers to Your Environment

Before installing a new IAS server, you should identify the wireless APs that will be configured as clients of this server, following the guidelines provided in Chapter 2, “Planning a Wireless LAN Security Implementation.” You will also need another IAS server configured as the secondary RADIUS server to provide the APs with resilience in case of server failure. If you are reconfiguring the existing APs to use this new server, you must carefully plan the migration to avoid disruption of service for your users during the AP switchover. Normally, as long as an AP has at least one active authentication RADIUS server, there will be no disruption.

To install IAS on a new server

Adding a Wireless Access Point to the Network

To add a new wireless AP, you need to complete the following two tasks:

The IAS servers you choose as primary and secondary RADIUS servers will depend on the network location of the AP. Ideally, choose a primary IAS server that is on the same LAN as the AP or at least has reliable connectivity to the AP. Choose a secondary IAS server that has reliable connectivity to the AP. For more information, see the guidance provided in the "Assignment of APs to RADIUS Servers" section in Chapter 2, “Planning a Wireless LAN Security Implementation.”

Once you have identified suitable IAS servers for the AP, carry out the following procedures. These are the same as the procedures given for adding an AP to IAS in Chapter 5, "Building the Wireless LAN Security Infrastructure.”

To add an AP to the network

Removing a Wireless Access Point

You might need to remove a wireless AP from the network if you are relocating or reorganizing your sites. You should always remove RADIUS client entries from IAS if they are no longer in use.

To remove a wireless AP from the network

Granting WLAN Access to a User or Computer

If you have followed the default setup for this solution, all users and computers in the domain in which you installed the IAS servers will automatically have access to the WLAN. This is because the Domain Users and Domain Computers groups are members of the Wireless LAN Users and Wireless LAN Computers groups, respectively. These groups are, in turn, members of the Wireless LAN Access group, which is used by the IAS remote access policy to grant access to the WLAN.

Controlling Access for Members of the Same Domain

If you want to explicitly control which users and computers can connect to the WLAN, you should use security groups to manage their access. You should remove the Domain Users and Domain Computers groups from the Wireless LAN Users and Wireless LAN Computers groups, respectively. In their place, add the specific users and computers to which you want to grant access to the WLAN.

This changes the solution default so that the WLAN is inaccessible to everyone unless access is explicitly granted by adding someone to a security group. This is a more precautious approach than "allow by default" and is normally preferred by organizations with high security needs. It may also be useful in other cases where only a limited number of people are allowed access to the WLAN; for example, during the pilot phase of a larger rollout.

To enable WLAN access for a user or computer in the same domain

Controlling Access for Members of Another Domain

If you have a multi-domain forest, you may want to enable users and computers from other domains to use the WLAN. For this, you need to be logged on using an account that is one of the following:

To grant WLAN access to the users and computers from other domains

Denying WLAN Access to a User or Computer

The default for this solution is to allow access to the WLAN to all users and computers in the domain into which you installed the IAS servers. They are granted access automatically because they are members of the Domain Users and Domain Computers groups, respectively. This can be problematic if you need to block WLAN access for individual users or computers. You must not remove users or computers from the built-in Domain Users and Domain Computers groups. Use one of the following strategies instead:

Controlling WLAN Access Using a Deny Policy

If you want to allow access by default but be able to deny access to individual users and computers by exception, you need to create a "Deny" Remote Access Policy in IAS.

To create a Deny Remote Access Policy

Any users or computers that you add to the Deny Wireless LAN Users or Deny Wireless LAN Computers groups will be refused access to the WLAN. However, this setting will only take effect the next time the denied user logs on or the denied computer is restarted.

Support Tasks

This section covers common tasks that you need to perform to recover from problems in your WLAN security infrastructure. Many of these tasks are referenced by the “Troubleshooting” section included in this chapter.

Restoring an IAS Server Configuration from Backup

IAS policies and settings are stored in the IAS configuration database. They can be restored independently of the rest of the system settings. You should schedule the IAS backup task to backup IAS settings to the C:\IASBackup folder every night. For more information on this topic, see the "Configuring the IAS Backup" procedure in the "Operational Tasks" section of this chapter. If you need to undo changes made that day, you can restore settings from the backup files (in C:\IASBackup) created the previous night or from the "rollback" backup made prior to the making changes. For further details, see the "Backing up IAS Settings Prior to Making Changes" procedure in the "Managing Changes" section.

If you need to restore an earlier version of the settings, you must recover the exported IAS settings from the server backup.

Warning: This procedure will restore all IAS settings including RADIUS clients, overwriting any existing settings on the server. The backup that you are attempting to restore should be one that was taken from the same server.

To restore the IAS settings

If, for some reason, you do not have a usable backup of this system, you can export the settings from another IAS server and import them to this server. Typically, IAS servers in the same role will share the same configuration settings but will have a different set of RADIUS clients, so you should not use this procedure to restore the settings from another server. Instead use the "Replicating Settings from the First IAS Server" procedure described in Chapter 5, “Building the Wireless LAN Security Infrastructure.”

Important: You must ensure that the restored system is patched up to date. Restoring from an old backup may mean that patches previously applied have been rolled back.

Restoring Full Server Configuration from Backup

Procedures for restoring the server will vary depending on the choice of backup system. The following is based on the assumption that you have backed up the system by performing Windows system state backup to a file, followed by a file backup of this file and other required files.

To restore the server

Optimization Tasks

This section covers the tasks that are relevant for optimizing the running of the IAS infrastructure.

Determining Maximum Load on the IAS Server

This section provides information on the likely maximum load on the IAS server.

Performance is rarely an issue for IAS servers that are properly sized and configured. IAS servers are under most load during peak times such as morning hours when many users simultaneously log on, shortly after a major network outage, or during a RADIUS server failure when wireless APs failover to a backup server.

The following table gives an indication of the WLAN authentication requirements for different sizes of organization.

Table 8.7: WLAN Authentication Requirements

The New Authentications per Second column is a part of the steady load; you can assume an average of four new full authentications as users rove between wireless APs. The Peak New Authentications per Second column indicates the type of load expected when all users require authentication over a 30 minute period (for example, at the start of the day). The Re-authentications per Second column shows the number of authentications with fast reconnect caused by IAS forcing a session time-out after 15 minutes. (Although a 60 minute time-out is the solution default, 15 minutes is used here to give a worst-case figure.) You should assess these figures against your own organization's requirements to determine the type of load that you need to support.

Internal tests by Microsoft show that IAS can handle a high load on modest server hardware. The load serviced by IAS is best represented by the number of Extensible Authentication Protocol (EAP) authentications per second. The following table shows the results from an IAS server running on an Intel Pentium 4 2GHz server running Windows Server 2003.

The tests were conducted with RADIUS logging enabled (to a separate disk) and with IAS on a separate server from the Active Directory domain controller; therefore, these figures should be regarded as a worst case. The default configuration for this solution is to have logging disabled and IAS housed on the same server as the domain controller. Both of these items will improve authentication throughput.

Note: This information is provided without warranty of accuracy and should only be used as a guideline for capacity planning purposes and not for performance comparisons.

Table 8.8: Sample IAS Server Capacity Measurements

IAS can be configured to generate disk-based RADIUS logs containing varying amounts of RADIUS request information. If you choose to enable RADIUS logging, you should consider the overhead that this will place on the servers, particularly on the disk subsystems. Slow disk throughput will act as a bottleneck on IAS performance and will delay IAS RADIUS responses to APs, leading to protocol time-outs and unnecessary failover of APs to secondary RADIUS servers. If you expect a high load (you can use the figures in the previous tables as a guideline) and are going to enable RADIUS logging, you should ensure that IAS is configured to write RADIUS logs to a high performance disk that is separate from the Windows system drive and page file drive.

Enabling Windows Server 2003 IAS tracing features (as described in the "Enabling and Disabling Tracing on the IAS Server" section in this chapter) will also generate additional load on IAS servers. This may be required occasionally to troubleshoot network access issues but should not be enabled permanently. Nevertheless, you may want to ensure that your IAS servers have some additional headroom to allow tracing to be used for limited periods of time and still service the production load.

Other Optimization Measures

For other IAS optimization guidelines, see the "Designing an Optimized IAS Solution" section in the "Deploying IAS" chapter of the Windows Server 2003 Deployment Kit.

Top of page

Troubleshooting

This section contains procedures and techniques that will help you diagnose and fix problems with the wireless LAN solution.

Troubleshooting Procedures

The following procedures help you identify the possible causes of a problem and the action to take to resolve the problem. This section is organized hierarchically. The first procedure "Determining the Kind of Problem” will point you to one of several procedures, each of which drills down into detailed troubleshooting steps. These procedures, in turn, may point you to further troubleshooting procedures that focus on particular components of the solution.

Each of these procedures is described in detail later in this chapter (some are given in the pictorial form; others, for which the text description is too lengthy for a figure, are presented in tables or text). Some of the procedures make use of the "Troubleshooting Tools and Techniques" section of this chapter. You should familiarize yourself with that section to use the troubleshooting procedures effectively.

Important: These diagnostic procedures do not cover every eventuality. Where the recommended investigation steps do not lead you to the source of the problem, you should backtrack and follow the other diagnostic procedures given here. Sometimes, the full extent or nature of symptoms is not apparent and may point you in the wrong direction. For example, a single user may be the only person in an office to report a problem that affects the whole office. Although the table points to diagnostic procedures related to a single client failure, other procedures are probably more appropriate.

You should also consult the WLAN and IAS troubleshooting documents listed at the end of the chapter.

Determining the Type of the Problem

Start by classifying the type of problem that you are experiencing, using the following flowchart. The diamonds represent questions or decision points and the rectangles represent the diagnosis of the problem and indicate the name of the procedure to follow.

Figure 8.1 Determining the type of problem

Diagnosing Client Connection Problems

The following table categorizes different types of connection problems based on the number and location of clients affected. The Likely Problem(s) column indicates the factors that are most likely to produce the shown symptoms. The Diagnostic Procedures to Follow column lists the diagnostic procedures that you should try first to diagnose the problem. Each of these procedures is described in detail later in this chapter.

Table 8.9: Who is Unable to Connect to the WLAN?

Diagnosing Performance Problems

This section focuses on performance problems associated with the WLAN security infrastructure. General wireless and wired network performance problems are not dealt with in this chapter.

Table 8.10: Performance Problems

User Authenticating but Computer Failing

This solution uses both user authentication and computer authentication to the WLAN. The computer domain credentials are used to authenticate to the WLAN when no user is logged on to the computer. When a user logs on, the user's credentials are then used to re-authenticate to the WLAN. This arrangement allows the computer to communicate with the WLAN when no one is logged on and enables the computer to be managed remotely, to download server GPO settings, and so forth.

When a user logs on to a WLAN computer, there is a slight delay while the user is authenticating to the WLAN. Until the user is properly authorized to connect, the computer's authenticated WLAN session is still active. However, if the computer was unable to authenticate to the WLAN, this delay means that there is no network connectivity at the start of the user's logon session.

This can cause a number of subtle problems. For example, roaming user profiles will fail to load, some computer GPO settings will not be applied, and user logon scripts and GPO-based software deployments (which run very early in the logon process) will fail.

To determine the cause of the failure of computer authentication, you should follow the "Check User/Computer Account" procedure later in this guide.

Computer Authenticating but User Failing

Unlike the previous case, this problem is immediately obvious and will be reported by the affected users straight away. To determine the cause of failing user authentication, you should follow the "Check User/Computer Account" procedure.

Diagnostic Procedures

The following section provides the detailed troubleshooting steps referred to in the previous sections.

Check User/Computer Account

The following flowchart helps you in diagnosing the cause of a user or computer authentication failure.

Note: The arrow shaped box in the flowchart indicates that you should refer to the "Check Client Computer" procedure, as specified in the box.

Figure 8.2 Checking the user or computer account
See full-sized image

Check Client Computer

The following flowchart helps you diagnose problems with the client computer.

Figure 8.3 Checking the client computer
See full-sized image

Note: The arrow shaped box in the flowchart is a link from the "Check User/ Computer Account" procedure.

The status of the WLAN card (as required by the "Disable/Enable WLAN card and watch status" step shown in the flowchart) can be seen in the Details pane of the Network Connections folder (in Control Panel). When you enable the card, you should see the card status stepping through the following phases:

Monitoring the point at which this process fails is one of the most useful diagnostic procedures.

Check IAS

The following table lists a series of checks to be performed if you suspect that an IAS server is causing problems.

Table 8.11: IAS Diagnostic Checks

Check the Certification Authority

The following table contains a series of checks, which you can perform to determine whether the CA is performing correctly.

Table 8.12: CA Diagnostic Checks

Check Active Directory and Network Services

The following table lists a series of checks that you can perform on Active Directory and other network components to determine whether they are performing correctly.

Table 8.13: Active Directory Diagnostic Checks

Check Wireless Access Point Configuration

The following table lists a series of checks that you can perform on the wireless APs to determine whether they are performing correctly.

Table 8.14: Wireless AP Diagnostic Checks

Check WAN Connectivity

WLAN failures may be caused by WAN connectivity problems between different components. The following table lists the items that are most likely to be the sources of problems.

Table 8.15: WAN Diagnostic Checks

Troubleshooting Tools and Techniques

This section describes some of the techniques and tools that will be useful during troubleshooting.

Checking Client Network Connections Folder Status

The Network Connections folder and the Windows XP system tray notification icons provide information about the state of the WLAN authentication.

In the Network Connections folder (in Control Panel), the status text under the wireless network adapter describes the current state of the connection. Highlighting the adapter displays additional information about the connection in the Details panel of the Network Connections folder. Disabling and then re-enabling the adapter will display the status of the adapter as it tries to connect to and authenticate to the WLAN; this information can be useful when debugging client connection problems.

Right-click the adapter icon and click Status to see the WLAN signal strength (on the General tab) and the IP address details (on the Support tab).

Viewing IAS Authentication Events in the Event Log

Client authentication success and failure events, which are recorded in the System event log on the IAS servers, can be useful for troubleshooting. By default, event logging is enabled for successful and failed authentication requests. This setting can be changed from the Service tab for the IAS server properties in the Internet Authentication Service MMC.

Looking at these events is useful for troubleshooting authentication failures. The event types produced by IAS are listed in the following table.

Table 8.16: IAS Authentication Request Events

Each event contains detailed information about the authentication request including:

If the authentication fails, the reason codes and descriptions will often indicate the precise problem (although the reason given can sometimes be misleading or ambiguous). The available reason codes are given in the following table.

Table 8.17: IAS Authentication Request Event Reason Codes

In some cases, the information gleaned from the event log entries is not enough to diagnose the cause of the problem. In such cases you may need to enable tracing on the IAS client and the IAS server. These are described in the next procedures.

Enabling and Disabling Tracing on Client Computers

Windows supports detailed tracing information on most components to help with diagnosis of problems that may arise. Enabling tracing for a component causes diagnostic output to be written to text log files and provides a level of detail beyond that found in event logs.

To obtain detailed information about the WLAN authentication process, you must enable tracing for the EAP over LAN (EAPOL) and Remote Access Service-Transport Layer Security (RASTLS) components using the netsh command. After enabling tracing, try the authentication process again and examine the Eapol.log and Rastls.log files for indications of problems (these files are written to the %Systemroot%\Tracing folder).

To enable tracing on client computers

To disable tracing on client computers

Enabling and Disabling Tracing on the IAS Server

Enabling tracing on IAS works in the same way as on the client.

You can use the netsh command to enable and disable tracing for a variety of different components related to network authentication. The most useful components to enable for tracing of 802.1X with PEAP authentication issues are the following:

Enabling tracing on the following IAS components is normally not required for troubleshooting 802.1X authentication but may be useful for troubleshooting other problems:

To enable tracing on the IAS server

To disable tracing on the IAS server

By default, IASSAM and RASTLS tracing logs are set to 1 MB only, which might cause valuable information to be overwritten in log files during heavy load. The following procedure sets the tracing logs to 10 MB. When a log file reaches the 10 MB limit is reached, it is renamed (to IASSAM.old and RASTLS.old) and a new log file created. This keeps a maximum of 20 MB of data on the server for each tracing type. You can repeat this for any of the tracing types by substituting the tracing category name (such as RASTLS and RASCHAP) for the "IASSAM" key name used in the procedure.

To set the IASSAM tracing log file to 10 MB

Enabling SChannel Logging on the IAS Server

SChannel is a security support provider (SSP) that supports a set of Internet security protocols, such as Secure Sockets Layer (SSL) and Transport Level Security (TLS). If you suspect that there are problems related to the IAS server certificate, or if the RASTLS log indicates that there is some problem with creating the TLS session, you should enable SChannel logging on both the client and the server. Events are logged to the Security log.

Follow the same procedure for both client and server.

To enable SChannel logging

When you finish troubleshooting, be sure to disable SChannel logging because this consumes significant system resources and will flood the event log with unwanted entries.

Pocket PC Diagnostic Tools

Windows XP has a range of network diagnostic tools. Pocket PCs, by contrast, have relatively few built into the base system. Your Pocket PC vendor, Microsoft, and other companies provide different types of tools to help you diagnose Pocket PC problems. Some examples include: