Share via

Troubleshooting Windows Vista Secure 802.3 Wired Connections

  • Article

This document is for IT professionals, network administrators, help desk personnel, and developers who are troubleshooting IEEE 802.3 wired Ethernet connectivity problems for clients running Windows Vista®. This document outlines a general approach to troubleshooting and provides information about features in Windows Vista that you can use to troubleshoot connectivity problems for clients running Windows Vista that are attempting to make 802.1X authenticated connections to Windows Server® 2003 domain networks.

Note

In this document, networks that adhere to the IEEE 802.3 standard for Ethernet are generically referred to as networks; 802.1X authentication refers to connections over Ethernet that use the Wired AutoConfig service.

In a typical 802.1X network deployment, the following services are in place to support network clients:

  • Windows Server 2003 Active Directory® with:
    • Domain Name System (DNS)
    • Active Directory Users and Computers
    • Group Policy Wired Network (IEEE 802.3) Policies
    • Active Directory Certificate Services (AD CS) or a Remote Authentication Dial-in User Service (RADIUS) server certificate purchased from a non-Microsoft certification authority (CA)
  • Internet Authentication Service (IAS), a RADIUS server
  • Dynamic Host Configuration Protocol (DHCP)
  • One or more IEEE 802.1X-compliant switches to provide 802.1X authenticated network access

In this document

This document is divided into the following sections:

Section 1: Troubleshooting client connectivity

This section provides a summary of the troubleshooting approach used in this document.

Section 2: 802.1X infrastructure components

This section describes the components that are typically required to support 802.1X authenticated client access for Windows Server 2003 domain networks.

Section 3: The 802.1X authentication process

This section provides an overview of the high-level phases involved in establishing 802.1X authenticated client connections to 802.3 Ethernet networks. It is crucial to understand these concepts when troubleshooting connectivity problems and performing root-cause analysis in an 802.1X-authenticating environment.

Note

Because there are so many Extensible Authentication Protocol (EAP) authentication methods and types, it is not practical to provide information for every EAP deployment. The examples in this section are for an authentication process that uses PEAP-MS-CHAP v2.

Section 4: Netsh Commands for LAN

This section demonstrates, using step-by-step procedures, how to use netsh lan to return detailed information about Ethernet network adapter capabilities and settings and profile configuration. There are also examples of troubleshooting information that is reported by running two netsh lan commands.

Section 5: Investigative questions and quick lists for common connectivity problems

This section provides a list of questions that you should consider when determining the cause of network connectivity problems. It also contains lists of the most common configuration errors and other conditions that cause 802.1X authenticated network connectivity problems.

Section 6: Wired-AutoConfig Operational log and Wired Diagnostics Report

This section describes information found in logs and reports in Windows Vista Wired-AutoConfig Operational logs, and LAN tracing reports.

Appendices

The appendices in this document contain information about Windows Vista features or components for advanced users, examples that are too long for the main body of this document, or other Ethernet-based troubleshooting information that is not specifically related to 802.1X and the Wired AutoConfig service:

  • Appendix A: Common non-802.1X connectivity problems:
    • General network connectivity problems
    • Domain network connectivity problems
  • Appendix B: Using netsh lan to manage tracing
  • Appendix C: Detailed PEAP-MS-CHAP v2 and EAP-TLS operations
  • Appendix D: Trace file examples
  • Appendix E: Network Diagnostics Framework
  • Appendix F: Windows Vista DLLs and function descriptions

Section 1: Troubleshooting client connectivity

Troubleshooting is a process of finding the source of a problem, and then resolving the problem. Due to the complicated nature of 802.1X-authenticated wired Ethernet technologies, the process of identifying and correcting problems can also be complicated. You can make the troubleshooting process easier by understanding your network environment, gathering useful information, and applying a consistent method.

  • Understand your network infrastructure components and the main phases of the 802.1X connection process. This understanding is the foundation of a good troubleshooting process.
  • Run the Diagnostics wizard in Windows Vista when connectivity fails. In many cases, the Diagnostics wizard can either solve your problem automatically or walk you through a process to solve it.
  • Use the netsh lan command to gather information about client configuration settings and hardware capabilities.
  • Review basic investigative questions in Section 5: Investigative questions and quick lists for common connectivity problems to determine the types of issues you should be looking for.
  • Review common or likely problems in the quick lists to see if you can quickly identify the problem.
  • Review operational and diagnostics logs and reports, as described in Section 6: Wired-AutoConfig Operational Log, Wired Diagnostics Report.

Back to In this document

Section 2: 802.1X infrastructure components

There are many ways to deploy an 802.1X authenticating domain network. The following illustration shows components that are found in an Active Directory domain that provides 802.1X authenticated access.

Note

This illustration is provided as an example only. It does not reflect best practices. For information about Microsoft CAs and PKI, see Public Key Infrastructure for Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkId=83694).

This section provides information about the roles of each of the main components in an 802.1X-authenticating domain network with Windows Vista client computers.

802.1X

802.1X is an IEEE standard for port-based network authenticated access to IEEE 802.3 wired Ethernet networks and IEEE 802.11 wireless networks, and other IEEE standard network types. IEEE 802.1X provides support for centralized user identification, authentication, dynamic key management, and accounting. The 802.1X standard enhances security by allowing a computer and a network to authenticate each other.

802.1X uses 802.1X-compliant switches and EAP for message exchange during the authentication process. With EAP, an authentication method, such as passwords, smart cards, or certificates, is used to authenticate the connection request. The support that 802.1X provides for EAP types allows you to use a variety of authentication methods.

Wired AutoConfig service

The Wired AutoConfig service (dot3svc) is responsible for connectivity and the client-side components of Layer Two authentication over Ethernet connections. The Wired AutoConfig service listens for 802.3 media connectivity and identifies whether Layer Two authentication is required. When Layer Two authentication is required, 802.1X authentication is performed on the specified Ethernet interface. The Wired AutoConfig service supports only a single 802.3 profile, and does not support roaming across Ethernet interfaces. This limitation is by design, because there is no discovery on Ethernet networks.

Unlike the WLAN (wireless) AutoConfig service, the Wired AutoConfig service is in stopped mode by default. To perform 802.1X authentication over Ethernet connections for clients running Windows Vista, you must first start the Wired AutoConfig service. There are several ways to start the Wired AutoConfig service:

To manually start the Wired AutoConfig service on individual computers

  • Start the service in the Services console. Click Start, right-click Computer, click Manage, and click Services and Applications. In the details pane, double-click Services, and then do one of the following:

    • To configure the startup type, right-click Wired AutoConfig, and then click Properties. In Startup type, select Automatic, the recommended setting, and then click Start.
    • To start the service for the current session only, right-click Wired AutoConfig, and then click Start.

To manually start the Wired AutoConfig service on individual computers

  1. Open Command Prompt.

  2. At the command prompt, type: set autoconfig.

    For more information, see set autoconfig.

To programatically configure the Wired AutoConfig service to start on multiple computers

  • Use netsh lan set autoconfig in a logon script.

    ---OR---

  • On the General tab of the Wired Network (IEEE 802.3) Policies, select Use Windows Wired Auto Config service for clients.

Note

To navigate to the Wired Network (IEEE 802.3) Policies in Windows Server 2003, in the Group Policy Management Console, in Default Domain Policy, open Computer Configuration, open Windows Settings, and then open Security Settings.

Windows Server 2003 Active Directory

The Windows-based directory service that stores information about objects on a network and makes this information available to users and network administrators. Active Directory gives network users access to permitted resources anywhere on the network using a single logon process. It provides network administrators with an intuitive, hierarchical view of the network and a single point of administration for all network objects.

Domain Name System

A hierarchical, distributed database that contains mappings of DNS domain names to various types of data, such as IP addresses. DNS enables the location of computers and services by user-friendly names, and it also enables the discovery of other information stored in the database.

Active Directory Users and Computers

An administrative tool used by an administrator to perform day-to-day Active Directory administration tasks. The tasks that can be performed with this tool include creating, deleting, modifying, moving, and setting permissions on objects stored in the directory. These objects can be organizational units (OUs), users, contacts, groups, computers, printers, and shared file objects.

Group Policy

The infrastructure that enables directory-based change and configuration management of user and computer settings, including security and user data. You use Group Policy to define configurations for groups of users and computers. With Group Policy, you can specify policy settings for registry-based policies, security, software installation, scripts, folder redirection, remote installation services, and Internet Explorer maintenance. The Group Policy settings that you create are contained in a Group Policy object (GPO). By associating a GPO with selected Active Directory system containers—sites, domains, and OUs—you can apply the GPO's policy settings to the users and computers in those Active Directory containers. To create an individual GPO, use the Group Policy Management Console. To manage Group Policy objects across an enterprise, you can use the Group Policy Management Console.

The wired network policy is part of the Wired AutoConfig service. Windows Vista clients that are members of a domain on which Wired Network (IEEE 802.3) Policies is applied are configured with a wired network profile. The profile contains a collection of settings that defines the operations of the Wired AutoConfig service and controls the client aspects of 802.1X authentication. For more information, see Active Directory Schema Extensions for Windows Vista Wired and Wired Group Policy Enhancements (https://go.microsoft.com/fwlink/?LinkId=70195).

Note

802.3 Group Policy network profiles always supersede the local profile and cannot be modified by domain-member users.

Certificates

For PEAP-MS-CHAPv2, administrators can deploy AD CS on the network to issue a RADIUS server certificate, or they can purchase a RADIUS server certificate from a non-Microsoft CA.

EAP-TLS requires a PKI deployment to issue computer certificates to the RADIUS servers, and user and client certificates to network clients.

Note

PEAP-MS-CHAPv2 is easier to deploy than other authentication methods, such as EAP-TLS, for several reasons. First, PEAP does not require the deployment of a PKI; only the RADIUS server is required to have a server certificate installed. Nor does PEAP require smart cards or another type of client certificate to validate connecting clients. The result is a user-friendly experience in which network clients must provide only their account credentials (user name and password) for authentication. The account credentials are then verified against the account that exists in the user accounts database (such as Active Directory). From a security standpoint, PEAP MS-CHAP-v2 relies on passwords for authentication, which can be stolen or guessed. With EAP-TLS authentication, the certificate that is used for authentication cannot be easily forged.

Certificate

A digital document that is commonly used for authentication and to secure information on open networks. A certificate securely binds a public key to the entity that holds the corresponding private key. Certificates are digitally signed by the issuing CA, and they can be issued for a user, a computer, or a service.

Certification authority

An entity responsible for establishing and vouching for the authenticity of public keys belonging to subjects (usually users or computers) or other CAs. Activities of a certification authority can include binding public keys to distinguished names through signed certificates, managing certificate serial numbers, and revoking certificates.

Active Directory Certificate Services

A software service that issues certificates for a CA. It provides customizable services for issuing and managing certificates for the enterprise. Certificates can be used to provide authentication support, including secure e-mail, Web-based authentication, and smart-card authentication.

Internet Authentication Service (IAS)

The Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy, which provides authentication and accounting for network access.

IAS remote access policy

A set of conditions and connection parameters that define the characteristics of the incoming connection and the set of constraints imposed on it. Remote access policy determines whether a connection attempt is authorized to be accepted.

Dynamic Host Configuration Protocol (DHCP)

A TCP/IP service protocol that offers dynamic leased configuration of host IP addresses and distributes other configuration parameters to eligible network clients. DHCP provides safe, reliable, and simple TCP/IP network configuration; it prevents address conflicts, and helps conserve the use of client IP addresses on the network.

DHCP uses a client/server model in which the DHCP server maintains centralized management of IP addresses that are used on the network. DHCP-supporting clients can then request and obtain a lease of an IP address from a DHCP server as part of their network boot process.

Authenticating switches (IAS RADIUS clients)

One or more 802.1X-compliant network switches must be configured as RADIUS clients so that they can communicate with the RADIUS server running IAS. Add all switches as RADIUS clients to the server or servers running IAS. You will need to know the IP address of each switch to add them as RADIUS clients to IAS.

The switch is configured as a RADIUS client to the server running IAS that is deployed on the local area network (LAN). The switch must support the IEEE 802.1X standard for authentication for 802.1X network deployments.

Note

For consistency and ease of deployment, it is recommended that you deploy switches of the same brand and model.

  • The following table lists some common switch configuration items.

Note

The names of the configuration items for switches can vary by brand and model, and might be different from those listed in the table. See the product documentation for your switch for configuration-specific details.

Switch Configuration Items Configuration Item Information

Switch address (static)

For each switch, configure a unique static IP address that falls within the exclusion range specified in the DHCP scope of the subnet on which the switch is deployed.

Switch subnet mask

Configure this to match the subnet mask of the attached subnet.

DNS name

Some switches can be configured with a DNS name provided that the DNS service on the network can resolve switch DNS names to IP addresses.

For each switch that supports this feature, enter a unique name for DNS resolution.

Disable switch DHCP service

If the network has a DHCP server that is providing DHCP leases, and if the DHCP service is also enabled on the switch, disable the DHCP service on the switch.

RADIUS shared secret

Use a unique RADIUS shared secret for each switch. Each shared secret should be a random sequence of uppercase and lowercase letters, numbers, and punctuation that is at least 22 characters long. To ensure randomness, use a random character generation program to create shared secrets to configure on the server running IAS and the switch. You will need to match the shared secret for each switch when you configure the switches as RADIUS clients in the applicable IAS remote access policy.

Important
It is recommended that you record the shared secret for each switch, and store the record in a secure location, such as an office safe.

RADIUS server IP addresses

Configure your switch with the IP addresses of your servers running IAS.

UDP port(s)

By default, IAS uses UDP ports 1812 and 1645 for authentication messages and UDP ports 1813 and 1646 for accounting messages.

Recommendation:

Unless you have reason to do so, do not change the default RADIUS UDP ports settings.

Vendor-specific attributes (VSAs)

Some switches require that the IAS RADIUS server is configured with specific attributes in order to provide full switch functionality.

VSAs are added to an IAS remote access policy.

Back to In this document

Section 3: 802.1X authentication process

This section provides an overview of the phases involved in establishing 802.1X authenticated client connections to 802.3 Ethernet networks. It is crucial to understand these concepts when troubleshooting connectivity problems and performing root-cause analysis in an 802.1X-authenticating environment.

Note

For a more detailed explanation of EAP and PEAP-MS-CHAPv2 processes, see Appendix C: Detailed PEAP-MS-CHAP v2 and EAP-TLS operations.

802.1X network connection phases overview

Although there are many EAP authentication types, the primary focus of this guide is on PEAP-MSCHAP v2. By default, PEAP-MS-CHAP v2, EAP-TLS, and PEAP-TLS are supported by Windows Server 2003, Windows XP, and Windows Vista. This section provides an overview of the main phases that take place in 802.1X-authenticated connections that use PEAP-MS-CHAP v2. The phases are numbered in the order in which they occur; a diagram is included to illustrate, by number, where each phase occurs on the network.

Phases 1- 5: Client authentication and authorization

Phases 1-5 are shown in the following figure:

  1. Registration: When the client sends an EAP over LAN (EAPOL) Start frame to initiate authentication and attempt a connection to the network, the switch registers the requesting client’s Media Access Control (MAC) address and assigns a unique virtual port that is mapped to that MAC address.
  2. Access Request: Using its 802.1X uncontrolled port, the switch, on behalf of the client, forwards an Access-Request message to the RADIUS server.

Note

Only 802.1X EAPOL frames are sent over the uncontrolled port. The uncontrolled port is never used to send other frame types, such as TCP/IP, UDP, or IPX/SPX, that are generated by a requesting client. The client cannot send traffic using the controlled port until it is authenticated and authorized (phases 8-9). For more information about EAP and EAPOL communications, see: Appendix C: Detailed PEAP-MS-CHAP v2 and EAP-TLS operations.

  1. EAP: If the server running IAS does not reject the Access-Request, the EAP authentication method is negotiated between the client and IAS.
    After the negotiation is complete, the switch acts as a pass-through device, exchanging messages between the client and the server running IAS.

Note

When PEAP is used, a TLS channel is first created, and then authentication occurs through the secure TLS channel.

  1. Authentication: After the EAP authentication method is agreed upon between the client and IAS, the server running IAS verifies the client credentials against the user accounts database in Active Directory.
    • If a matching user account does not exist, IAS sends an Access-Reject message to the switch, in response to the connection request.
    • If the user account is found, the server running IAS proceeds to the authorization phase.
  2. Authorization: The server running IAS performs authorization, as follows:
    1. IAS checks the user account dial-in properties in Active Directory.
    2. IAS then attempts to find a remote access policy that matches the connection request.

Phases 6-10: Controlled port DHCP address, Group Policy, and network access

Phases 6-10 are shown in the following figure:

  1. Access-Accept: If a matching remote access policy is found, IAS authorizes the connection request based on that policy and sends an Access-Accept message to the switch.

Note

If user authorization is not successful, IAS sends an Access-Reject message, and the request is terminated.

  1. 802.1X controlled port: When the switch receives the Access-Accept message, the 802.1X mechanism on the switch enables the controlled port. Traffic from the network client is allowed to traverse the controlled port.
  2. DHCP address request: The client sends a DHCP address request through the 802.1X controlled port to the network. If a DHCP server responds, the client obtains an IP address.
  3. Group Policy applied: If configured, Group Policy is refreshed on the client.

Note

Although the Group Policy refresh is not part of 802.1X authentication, it is useful to understand how Group Policy is updated and applied during the wired 802.1X authentication process: For computers already configured with Wired Network (IEEE 802.3) Policies, Group Policy for the Wired AutoConfig service is applied when the computer is started, and whenever an updated policy is downloaded. If Group Policy is updated on the server while the computer is turned off, the last known policy is immediately applied when the computer is started. If the 802.1X settings on the computer authorize the computer for network access, updated policies are downloaded and applied when the computer connects to the network, prior to user authentication. If 802.1X settings on the computer cannot authorize computer network access at startup, then the application of updated policies occurs immediately after user authentication.

  1. Network Access: The client is able to access network resources, subject to any applied restrictions.

Back to In this document

Section 4: Netsh commands for LAN

The Windows Vista® Netsh commands for local area network (LAN) provide methods to configure connectivity and security settings on IEEE 802.3 Ethernet interfaces. You can use the Netsh lan commands to configure the local computer, or to configure multiple computers by using a logon script.

You can run these commands directly from the Windows Vista command prompt by typing netsh lan followed by the command, or by switching to the lan context by using the following instructions.

To enter the netsh context for lan

  1. Click Start, click Run, type cmd, and then click OK, to open a command prompt.

  2. At the command prompt, type netsh, and press ENTER.

  3. Type lan, and press ENTER.

Using Netsh lan for troubleshooting and diagnostics

The commands used primarily for troubleshooting 802.1X connectivity problems are set and show. You can use these commands to gather all the data required to troubleshoot configuration problems.

set

Sets the configuration on interfaces. The following commands are available in this context:

  • set autoconfig
  • set tracing

set autoconfig

Enables or disables Wired AutoConfig service on an interface.

Syntax:

set autoconfig enabled={yes|no}interface=InterfaceName

Parameters:
  • enabled {yes | no}
    Required. Specifies whether to set Wired AutoConfig service to enabled or disabled.
  • interface
    Required. Specifies the name of the interface on which the service is enabled or disabled.

Remarks:

When enabled, Windows Windows Vista automatically connects to the network by using the specified interface. By default, autoconfiguration is enabled.

If disabled, Windows will not automatically connect to any networks by using the specified interface.

There is wildcard support for the interface parameter. You can use the characters ? and * to replace a letter or letters of the interface name, respectively.

Example command:
  • Set autoconfig enabled=yes interface="Local Area Connection1"

set tracing

Enables or disables tracing.

Syntax:

set tracing [[mode=]{yes|no|persistent}]

Parameters:
  • mode {yes | no | persistent}
    Required. Specifies whether tracing is disabled, enabled and not persistent, or enabled and persistent. See "Remarks."

Remarks:
  • If the mode parameter is set to yes, tracing is on until the mode is either set to no or the computer is restarted.
  • If the mode parameter is set to persistent, tracing will still be on even after the computer is restarted.
  • If the mode parameter is set to no, tracing is turned off for either tracing or persistent tracing.

The default value for the mode parameter is nonpersistent.

Example command:
  • set tracing mode=persistent

For more information about managing tracing with the netsh lan command, see Appendix B: Using netsh lan to manage tracing.

show

Displays information. The following commands are available in this context:

  • show interfaces
  • show profiles
  • show settings
  • show tracing

show interfaces

Displays a list of the current wired interfaces on the computer.

Syntax:

show interfaces

Parameters:

There are no parameters for this command.

Remarks:

Shows the wired interfaces configured on the computer.

Displayed information includes:

  • Number of interfaces on the computer
  • Name
  • Description
  • GUID
  • Ethernet address
  • State [network authentication support (yes or no)]

Example command:
  • showinterfaces

show profiles

Displays a list of wired profiles that are configured on the computer.

Syntax:

show profiles[[interface=]InterfaceName]

Parameters:
  • interface
    Optional. Specifies the name of the interface that has this profile configured. See "Remarks."

Remarks:

If the interface parameter is specified, then only the contents of the profile for the specified interface are displayed. Otherwise, all profiles will be displayed with their name and description.

Example commands:
  • show profiles interface="Local Area Connection"
  • show profiles

show settings

Displays the current global settings of the wired LAN.

Syntax:

show settings

Parameters:

There are no parameters for this command.

Remarks:

Shows whether autoconfiguration is enabled on each interface.

Example command:
  • show settings

show tracing

Displays whether wired tracing is enabled or disabled.

Syntax:

show tracing

Parameters:

There are no parameters for this command.

Remarks:

Displayed information includes:

  • Tracing state (enabled or disabled)
  • Tracing persistence state (running or not running)
  • Trace log file location (for example, "c:\Windows\system32\logfiles\WiredAutoLog\")

Example command:
  • show tracing

Back to In this document

Section 5: Investigative questions and quick lists for common connectivity problems

When troubleshooting network connectivity problem, ask yourself the following types of questions to help define the problem.

Is the problem isolated to a single computer? If so:

  • Has the computer previously connected successfully to the network?
  • Can other computers on the same subnet reach targeted resources?
  • Is the network interface or network adapter in a media disconnected state?
    • Is the network cable connecting the computer to the network damaged or disconnected?
    • Is the computer connected to a network hub that is either unplugged from its power source or malfunctioning?
    • Is the network connection disabled in Network Connections?
    • Is the network adapter hardware malfunctioning?
  • Can you identify configuration changes on the computer between the time the computer most recently connected to the network successfully and when the connection failed?
  • Review the status details of the local area connection in Network Connections. Is there any information in Network Connection Details that can help define connectivity problems?

Note

To open the details for a local area connection, in Network Connections, right-click the local area connection icon, click Status, and then click Details.

  - Is there a value listed for **Connection-specific DNS Suffix**? Is the value the same as the name of your domain?  
  - Are the TCP/IP properties of the local area connection configured for dynamic addressing? If so, the **DHCP Enabled** value will be **Yes**.  
  - Are both the IPv4 address and IPv4 subnet mask in the same range as those defined for the network subnet? Or, is the IPv4 value in **Autoconfiguration IPv4 Address** in the range of 169.254.0.1 through 169.254.255.254, with a subnet mask of 255.255.0.0?

Note

TCP/IP addresses in the range of 169.254.0.1 through 169.254.255.254 are Automatic Private IP Addressing (APIPA) addresses. When the TCP/IP protocol is configured for dynamic addressing and a DHCP server is not available, APIPA automatically configures a unique IP address from the 169.254.x.x range (where x is an integer between 1 and 254).

  - Is there **Lease Obtained** or **Lease Expires** information provided?  
  - Are the correct IP addresses displayed for the DHCP, DNS, and WINS servers?

Are multiple computers presenting the same symptoms? If so:

  • What do those computers have in common?
    • Do those computers share a common network hub?
    • Do the computers connect through a common network switch?
    • Are the computers on the same subnet?
    • Do the computers or users belong to a common group in Active Directory?
    • Do the computers or users belong to an Active Directory group that is controlled through a common IAS remote access policy?
    • Do the computers obtain their TCP/IP addresses from the same DHCP server?
    • Is the connectivity outage constant or intermittent?
  • Can you identify changes within your network between the time the computers connected to the network successfully and when connections began to fail?

Review the location and timing of the problem to help narrow the scope of the problem. In addition, examine the failures systematically by referring to the sequence of steps used to establish communications, as described in “Section Two: 802.1X network connection phases overview” of this document.

Common 802.1X connectivity problems

For the purposes of this document, network connectivity problems are separated into three groups:

  • General network connectivity problems
  • Domain network connectivity problems
  • 802.1X-authenticated network connectivity problems

This section contains a series of tables for connectivity problems that are specific to 802.1X authenticated connections. You will find information about general network connectivity problems and domain network connectivity problems in Appendix A: Common non-802.1X connectivity problems

802.1X-authenticated network connectivity problems

This section provides examples of the types of configuration problems that are specific to networks that deploy 802.1X-authenticating switches and IAS for 802.1X-authenticated connections.

Active Directory

Possible Cause Corrective Measure

In the Active Directory Users and Computers snap-in, the dial-in properties of the user and computer accounts are not configured correctly.

In the Active Directory Users and Computers snap-in, in the domain container, open Users, right-click the user account, click Properties, and then on the Dial-in tab, select Control access through Remote Access Policy.

The IAS remote access policy grants access for members of an Active Directory security group. However, the user is not a member of the security group that is specified in the remote access policy.

In the Active Directory Users and Computers snap-in, in the domain container, open Users, right-click the security group that is specified in the IAS remote access policy, and click Properties. On the Members tab, click Add, and then in Enter the object names to select, type the user account to add the user to the security group.

The authentication method specified in Wired Network (IEEE 802.3) Policies does not match the authentication method specified in the IAS remote access policy.

Change the mismatched Extensible Authenticated Protocol (EAP) authentication method specified in either the IAS remote access policy or in Wired Network (IEEE 802.3) Policies to match the method deployed for your network.

Client

Possible Cause Corrective Measure

The Wired AutoConfig service is not running.

Note
By default, the Startup type of the Wired AutoConfig service is Stopped.

For a single computer, manually start the service in the Services snap-in.

For multiple computers, in Group Policy Management Console, open Wired Network (IEEE 802.3) Policies. In the details pane, right-click the policy, click Properties, and then on the General tab, select Use Windows Wired AutoConfig service for clients.

Note

Selecting the Use Windows Wired AutoConfig service for clients policy setting is equivalent to configuring the Startup type of the service properties to Automatic.

AD CS

Possible Causes Corrective Measures

When using EAP-TLS, the user does not have a client certificate.

Instruct the user to join the computer to the domain by using a wired Ethernet connection and domain credentials; the certificate is installed automatically.

The client does not have a corresponding root CA certificate that matches the issuing CA of the IAS server certificate.

To specify trusted root CAs:

  1. In Group Policy Management Console, open Wired Network (IEEE 802.3) Policies.
  2. In the details pane, right-click the wired policy, and then click Properties.
  3. On the Security tab, in Select a network authentication method, click Properties, and then in Trusted Root Certification Authorities, select the certificate that matches the IAS server certificate.

IAS (RADIUS)

Possible Causes Corrective Measures

The RADIUS shared secret on the 802.1X switch does not match the shared secret configured for RADIUS clients in IAS.

Configure the switch to use the same shared secret. The shared secret is specified in the RADIUS Clients node of the IAS snap-in.

The IAS remote access policy properties are configured to reject the user or computer requests. For example:

  • On the Settings tab, the properties of the policy are set to Deny remote access permission.
  • On the Dial-in Constraints tab of the remote access policy, time restrictions prohibiting the connection are configured.
  • On the Dial-in Constraints tab, an incorrect media type is specified.
  • In the IAS snap-in, right-click the applicable remote access policy, click Properties, and then click Grant remote access permission.
  • In the IAS snap-in, right-click the applicable remote access policy, click Properties, and then click Edit Profile. On the Dial-in Constraints tab, select Allow access only on these days and at these times, and then click Edit to specify allowed access times.
  • In the IAS snap-in, right-click the applicable remote access policy, click Properties, click Edit Profile, and then on the Dial-in Constraints tab, do one of the following:
    • Clear Allow access only through these media (NAS-Port-Type).
    • Select Allow access only through these media (NAS-Port-Type), and then select Ethernet.

A mismatch exists between the trusted root CA that issued the RADIUS server certificate specified in the IAS remote access policy and the trusted root CA specified in the selected EAP type in Wired Network (IEEE 802.3) Policies.

To specify trusted root CAs:

  1. In Group Policy Management Console, open Wired Network (IEEE 802.3) Policies.
  2. In the details pane, right-click the wired policy, and then click Properties.
  3. On the Security tab, in Select a network authentication method, click Properties, and then in Trusted Root Certification Authorities, select the certificate that matches the IAS server certificate.

The vendor-specific attributes (VSAs) for the 802.1X switch are configured incorrectly.

Check the product documentation, and then specify the IAS vendor-specific attributes in the IAS snap-in. If you are unsure about the correct VSA setting, select RADIUS Standard.

The IP address of the 802.1X switch (RADIUS client) specified in IAS is incorrect.

To specify a RADIUS client IP address:

  1. In the IAS snap-in, select RADIUS Clients.
  2. In the details pane, right-click the RADIUS client that corresponds to the 802.1X switch, and then click Properties.
  3. On the settings tab, in Address (IP or DNS), type the correct IP address, and then click Verify.

The IAS server certificate has expired.

For information about requesting an IAS server certificate, see Computer certificates for certificate-based authentication (https://go.microsoft.com/fwlink/?LinkId=95258).

The IAS service is stopped.

In the Services snap-in, right-click Internet Authentication Service, and then click Start.

The configuration of EAP in the applicable remote access policy is different from its configuration in Wired Network (IEEE 802.3) Policies in Active Directory.

Configure both the IAS remote access policy and Wired Network (IEEE 802.3) Policies to use the EAP method that is appropriate for your network deployment.

On a newly configured server running IAS:

  • IAS is not registered in Active Directory.
  • The server running IAS does not have a server certificate.
  • In the IAS snap-in, right-click Internet Authentication Service, and then click Register Server in Active Directory.
  • For information about requesting an IAS server certificate, see Computer certificates for certificate-based authentication (https://go.microsoft.com/fwlink/?LinkId=95258).

802.1X switch

Possible Causes Corrective Measures

The 802.1X switch does not have the correct or latest firmware.

Contact the 802.1X switch manufacturer.

The IP address of the 802.1X switch is incorrectly configured for the subnet.

Configure the 802.1X switch with a static IP address and subnet mask according to your network TCP/IP addressing scheme.

The 802.1X switch does not specify the correct IP address of the IAS RADIUS server.

On the 802.1X switch, configure the RADIUS server IP address to match the IP address of your server running IAS.

Back to In this document

Section 6: Wired-AutoConfig Operational log and Wired Diagnostics Report

This section contains information about how to locate and review data collected in the following logs and reports:

  • Operational logging (Applications and Services, Wired-AutoConfig Operational logs)
  • Wired tracing reports (Wired LAN Diagnostics)

Wired-AutoConfig Operational log

The Wired-AutoConfig Operational log provides information that administrators and Help Desk personnel can use to troubleshoot 802.1X authenticated wired Ethernet connections. The Windows Vista 802.3 Wired AutoConfig service logs record events or conditions based on the connection state of the interface. The Wired-AutoConfig Operational log contains information about the network adapter, the properties of the wired 802.1X connection profile, the network authentication details, and for 802.1X-based connectivity problems, the cause of the failure.

Opening the Wired-AutoConfig Operational log

To access the Wired-AutoConfig Operational log

  1. On a computer that is attempting to connect to an 802.1X authenticated network, click Start, right-click Computer, and then click Manage.

  2. In the Computer Management console, click Event Viewer, click Applications and Service Logs, and then open Microsoft, as shown in the following figure:

  3. Click Windows, open Wired-AutoConfig, and then click Operational, as shown in the following figure:

  4. In the details pane, click the event to display the logged information.

After navigating to the Wired-AutoConfig folder and opening the Operational node, you can view the recorded service log events. The General tab below the Operational field provides a summary of the logged event. By selecting the Details tab, you can gather more comprehensive data about the event. You can display the information in Friendly View or XML View. Additionally, you can copy the information reported in the event, and save it to a text file. If you have Internet connectivity, you can also get more information about the event by clicking Event Log Online Help.

Example Wired-AutoConfig Operational logs

The following examples illustrate the types of information reported in the Wired-AutoConfig Operational log.

Example 1

A newly downloaded Wired Group Policy was applied to your computer.
Wired Group Policy Name: New Vista Wired Network Policy.
Applied settings:
AutoConfig Enabled: Yes
Wired Group Policy Summary
Profile applied: Yes
Reason Code: 0

Example 2

The profile was applied on the network adapter.
Network Adapter: Broadcom NetXtreme 57xx Gigabit Controller
Interface GUID: {213F8676-606C-43EA-9539-0E9E4DDDEF0B}
Profile Type: Interface
Profile Content: 
AutoConfig Version: 1
802.1x: Enabled
802.1x: Not Enforced
EAP type: Microsoft: Protected EAP (PEAP)
802.1X auth credential: Not specified
Cache user information: No

Example 3

Wired 802.1X Authentication failed.
Network Adapter: Broadcom NetXtreme 57xx Gigabit Controller
Interface GUID: {213F8676-606C-43EA-1111-0E9E4DDDEF0B}
Peer Address: 00152C28147F
Local Address: 00123F23F073
Connection ID: 0x9
Identity: EXAMPLE\Client01
User: Client01
Domain: EXAMPLE
Reason: 0x50005
Reason Text: Windows cannot connect to this network
There is a problem with the certificate on the server required for authentication.

Example 4

Wired 802.1X Authentication failed.
Network Adapter: Broadcom NetXtreme 57xx Gigabit Controller
Interface GUID: {213F8676-606C-43EA-9539-0E9E4DDDEF0B}
Peer Address: 00152C28147F
Local Address: 00123F23F073
Connection ID: 0x8
Identity: -
User: -
Domain: -
Reason: 0x70004
Reason Text: The network stopped answering authentication requests
Error Code: 0x0

Example 5

Wired 802.1X Authentication failed.
Network Adapter: Broadcom NetXtreme 57xx Gigabit Controller
Interface GUID: {213F8676-606C-43EA-9539-0E9E4DDDEF0B}
Peer Address: 00152C28147F
Local Address: 00123F23F073
Connection ID: 0x5
Identity: EXAMPLE\user01
User: Client01
Domain: EXAMPLE
Reason: 0x50005
Reason Text: The authentication failed because there is a problem with the user account
Error Code: 0x40420110

Example 6

Wired 802.1X Authentication failed.
Network Adapter: Broadcom NetXtreme 57xx Gigabit Controller
Interface GUID: {213F8676-606C-43EA-9539-0E9E4DDDEF0B}
Peer Address: 00152C28147F
Local Address: 00123F23F073
Connection ID: 0x2
Identity: -
User: -
Domain: -
Reason: 0x50006
Reason Text: The authenticator is no longer present
Error Code: 0x0

Example 7

The profile was applied on the network adapter.
Network Adapter: Intel(R) Pro/100+ Management Adapter
Interface GUID: {F91C6DD5-AOCE-818E-958999F60FE0}
Profile Type: Group Policy
Profile Content:
AutoConfig Version: 1
802.1X: Enabled
802.1X: Not Enforced
EAP type: Protected EAP (PEAP)
802.1X auth credentials: Machine or user credential
Cache user information: Yes

Note

This example illustrates the type of information that is captured in the log when a computer configured by Wired Network (IEEE 802.3) Policies connects to a network that does not support 802.1X authenticated Wired Ethernet access, such as a home network.

Microsoft Wired Diagnostics Report

Sometimes the basic Event Viewer system logs and operational logs cannot provide enough information for you to diagnose a connection issue. In these cases, you can use LAN Diagnostics in the Computer Management console to generate the Microsoft Wired Diagnostics Report, which captures several diagnostic trace files for the Wired AutoConfig service. The information generated by the Microsoft Wired Diagnostics Report is intended for Microsoft Product Support Services personnel and developers. If you are working with Microsoft Product Support Services to resolve problems related to wired 802.1X connectivity problems, you might be asked to generate this report.

The following list follows the structure of the Microsoft Wired Diagnostics Report, and summarizes the information found in each part of the report:

  • Diagnostic Results: Provides basic information about the computer system resources and the result of the check for enabled Ethernet adapters.
  • Wired Networking Troubleshooting information: Intended for Microsoft Product Support Services and developers, this report contains the following information:
    • Software Configuration: Contains details about the Windows Vista operating system and wired networking system files.
    • Hardware Configuration: Contains information about the computer manufacturer and model, and network adapter information.
    • System State: Enumerates the state of system services at the time the Microsoft Wired Diagnostics Report was generated, and provides current user, environment, and 802.1X restart information.
    • Wired Network Configuration: Contains information about network configuration profiles.
    • Wired Group Policy Profiles: Lists details about the applied Wired Group Policy profile.
    • Wired Trace: Contains Wired trace logs and Wired AutoConfig event logs. These logs are used primarily by developers and Microsoft Product Support Services.
    • CPU: Provides statistics about CPU usage.

Generating the Microsoft Wired Diagnostics Report

Generating the Microsoft Wired Diagnostics Report is a three-step process: enable tracing, reproduce the connectivity error, and then stop the wired tracing.

When tracing is enabled, it runs silently in the background while the problem is re-created. When the logging is turned off, a process will run and compile the Microsoft Wired Diagnostics Report.

To generate a Microsoft Wired Diagnostics Report

  1. Click Start, right-click Computer, and then click Manage.

  2. In the Computer Management console, click Reliability and Performance, click Data Collector sets, click System, and then click LAN Diagnostics. This is shown in the following figure:

  3. Right-click LAN Diagnostics, and then click Start.

  4. Log off and log back on to the network, or otherwise reproduce the error condition.

  5. Return to the Computer Management console, click Reliability and Performance, click Data Collector sets, click System, right-click LAN Diagnostics, and then click Stop to stop the wired diagnostic tracing.

  6. In Reliability and Performance, click Reports, click System, click LAN Diagnostics, and then click Wired to open the top level of the Microsoft Wired Diagnostics Report. This is shown in the following figure.

Wired trace logs

The wired trace logs that are generated in the Microsoft Wired Diagnostics Report are a set of files that contain highly detailed information about aspects of wired service-related components in Windows Vista. If you are working with Microsoft Product Support Services, you might be asked to supply trace files.

To open wired trace logs

  1. In the Microsoft Wired Diagnostics Report, open Wired Networking Troubleshooting Information. This is shown in the following figure:

  2. Click Wired Trace, as shown in the following figure:

For sample logs, see Appendix D: Trace file examples.

Back to In this document

Appendices

The appendices in this document contain information about Windows Vista features or components for advanced users, and examples that are too long for the main body of this document:

  • Appendix A: Common non-802.1X connectivity problems:
    • General network connectivity problems
    • Domain network connectivity problems
  • Appendix B: Using netsh lan to manage tracing
  • Appendix C: Detailed PEAP-MS-CHAP v2 and EAP-TLS operations
  • Appendix D: Trace file examples
  • Appendix E: Network Diagnostics Framework
  • Appendix F: Windows Vista DLLs and function descriptions

Back to In this document

Appendix A: Common non-802.1X connectivity problems

This appendix provides troubleshooting information for Ethernet-based network connectivity problems that are not specifically related to 802.1X and the Wired AutoConfig service.

  • General network connectivity problems
  • Domain network connectivity problems

General network connectivity problems

The following problems can occur on networks ranging from small office or home office (SOHO) workgroup-based networks to enterprise networks:

  • A disconnected or damaged Ethernet cable.
  • A computer connected to an unplugged or malfunctioning network hub.
  • An adapter disabled in Network Connections.
  • Malfunctioning network adapter hardware.
  • TCP/IP properties of the local area connection that are not configured for dynamic addressing (excluding networks on which client computers are configured with static addresses).
  • A DHCP server disconnected or powered off.
  • A DHCP service that is not running. (In a SOHO network, the DHCP service is typically provided by the router or by Internet Connection Sharing [ICS].)

In Windows Vista, the Windows Network Diagnostics tool can frequently determine the cause of these types of errors; it can either fix the problem or provide next-step user actions for the problem.

Need text to introduce this table, so that the reader understands how the preceding list is different from what's provided in the table.

Possible Causes Corrective Measures

Network clients that are configured for static IP addressing are using an IP address or subnet mask that is not in the correct range.

Configure the IP settings with a unique IP address in the IP address range, using the same subnet mask.

For more information, see “Configuring a static IP address on computers running Windows Vista,” in this section.

The DHCP service is enabled on the 802.1X switch to allocate IP addresses to network clients, but one or more network clients are configured with a static IP address.

Configure the Internet Protocol (TCP/IP) properties of the network adapter to obtain an IP address automatically.

For more information, see “Configuring computers running Windows Vista for DHCP leases,” in this section.

The DHCP server is disconnected from the network, powered off, or the DHCP service is not running.

In a SOHO network, the DHCP service is typically provided by a wireless router, network router, or ICS. Restore the DHCP service.

In a SOHO network:

  • In a new network or when replacing your modem, wireless AP, or router, you have not registered your modem or your router's media access control (MAC) address with your Internet service provider (ISP). Modem or router registration varies by ISP.
  • You have not configured the public connection on the router to accept DHCP leases from the ISP network. For example, you have configured the public connection on the wireless router with a static IP address.
  • Contact your ISP to register your device.
  • Configure the public interface to accept DHCP leases from the ISP network.

Configuring computers running Windows Vista for DHCP leases

To configure computers running Windows Vista for DHCP leases

  1. Click Start, and then click Control Panel.

  2. In Control Panel, click Classic View, and then double-click Network and Sharing Center.

  3. In Network and Sharing Center, in Tasks, click Manage Network Connections.

  4. In Network Connections, right-click the network connection that you want to configure, and then click Properties.

Note

On computers running Windows Vista®, the User Account Control dialog box opens, requesting permission to continue. Click Continue.

  1. In Local Area Connection Properties, in This Connection uses the following Items, select Internet Protocol Version 4 (TCP/IPv4), and then click Properties. The Internet Protocol Version 4 (TCP/IPv4) Properties dialog box opens.

  2. In Internet Protocol Version 4 (TCP/IPv4) Properties, on the General tab, click Obtain an IP address automatically.

  3. Click OK, and then click Close.

Configuring a static IP address on computers running Windows Vista

To configure static IP address on computers running Windows Vista

  1. Click Start, and then click Control Panel.

  2. In Control Panel, click Classic View, and then double-click Network and Sharing Center.

  3. In Network and Sharing Center, in Tasks, click Manage Network Connections.

  4. In Network Connections, right-click the network connection that you want to configure, and then click Properties.

  5. In Local Area Connection Properties, in This connection uses the following items, select Internet Protocol Version 4 (TCP/IPv4), and then click Properties. The Internet Protocol Version 4 (TCP/IPv4) Properties dialog box opens.

  6. In Internet Protocol Version 4 (TCP/IPv4) Properties, on the General tab, click Use the following IP address. In IP address, type the IP address that you want to use.

  7. Place the cursor in Subnet mask. A default value for subnet mask is entered automatically. Either accept the default subnet mask, or type the subnet mask that you want to use.

  8. In Default gateway, type the IP address of your default gateway.

  9. In Preferred DNS server, type the IP address of your DNS server. If you plan to use the local computer as the preferred DNS server, type the IP address of the local computer.

  10. In Alternate DNS Server, type the IP address of your alternate DNS server, if any. If you plan to use the local computer as an alternate DNS server, type the IP address of the local computer.

  11. Click OK, and then click Close.

Domain network connectivity problems

In addition to the general network connectivity problems, these types of problems commonly occur on domain networks, ranging from small organizations to enterprise networks:

Active Directory

Possible Causes Corrective Measures

The user does not have an account in the Active Directory Users and Computers snap-in.

Create an account for the user.

The dial-in properties of the user account or computer account in the Active Directory Users and Computers snap-in is set to Deny access.

Set the user and computer account dial-in properties to Allow access.

Note
In 802.1X networks that use IAS to authenticate connections, set the user account dial-in properties to Control access through Remote Access Policy.

The user account is disabled.

In the Active Directory Users and Computers snap-in, in Users, right-click the account, and then click Enable.

The user account has expired.

In the Active Directory Users and Computers snap-in, right-click the account, click Properties, and then on the Account tab, in Account expires, select Never, or in End of, set a new expiration date.

The user is attempting a connection at a prohibited time, as specified in the logon hours of the user account (the default setting is Logon Permitted for all hours).

In the Active Directory Users and Computers snap-in, in the user account properties, on the Account tab, click Logon Hours, and then configure the settings to specify the hours that the client is allowed to connect to the network.

The user is attempting a prohibited connection by using a computer that is not specified in the Log On To setting of the user account properties, or the default setting All computers is not selected.

In the Active Directory Users and Computers snap-in, in the user account properties, on the Account tab, click Log On To, and then either select All computers, or select The following computers. In Computer name, specify the computers that the user is allowed to use to connect to the network.

The Domain Name System (DNS) service is stopped or is not configured.

On your DNS server, in the Services snap-in, right click DNS Server, and then click Start.

The domain controller is offline.

Restart the server.

Users and Computers

Possible Causes Corrective Measures

The client computer is not a member of the domain.

Join the computer to the domain.

The client is attempting to log on to the domain by using non-domain credentials. With new computers or user accounts users commonly log on to the computer (not the domain) by using their computer account.

At the log-on window, in Log on to, select the domain if it is available, and then use the domain user account. For newly joined computers, log on using the domain name and user account in the format DomainName\UserName.

DHCP

Possible Causes Corrective Measures

The DHCP scope is full, so the DHCP server cannot lease addresses to requesting DHCP clients.

If the DHCP scope does not use the full address range, edit the scope to expand the address range.

The IP address of the DHCP server was changed and now DHCP clients cannot get IP addresses.

Make sure that the static IP address and subnet mask of the DHCP server are within the addressing scheme of the subnet.

The DHCP service is stopped.

On your DHCP server, in the Services snap-in, right-click DHCP Server, and then click Start.

On a newly configured DHCP server:

  • The DHCP server is not authorized in Active Directory.
  • The IP address range of the DHCP scope is incorrectly specified.
  • The DHCP scope is not activated.
  • The DHCP server is not on the same subnet as the clients.
  • The DHCP server is offline.

In the DHCP snap-in, right-click the domain container, and then click Authorize.

Set the IP address range and subnet mask in the scope to match the addressing scheme of your subnet.

In the DHCP snap-in, right-click the domain container, right-click the scope for the subnet with connectivity problems, and then click Activate.

Physically connect the DHCP server to the correct subnet.

Restart the DHCP server.

Back to In this document

Appendix B: Using netsh lan to manage tracing

You can start tracing for the Wired AutoConfig service by using Performance Monitor or the netsh lan set tracing command. By default, when tracing is enabled, it remains running until it is manually stopped or the system is restarted.

Config logs

There are several subfolders in the %sysroot%/Windows/Tracing/Wired folder: config, eventLog, Reg, temp and traces.

In the config folder, there are three logs that contain information about the 802.1X network environment:

Adapterinfo.txt: This log captures information about the network card driver, such as date, version, and provider. If multiple network adapters are installed, the information for all wired interfaces will appear.

Osinfo.txt: This log contains information about the operating system, such as SKU, whether the system is a single or multiprocessor computer, the versions of the LAN binaries, and whether the installation is a new installation or an upgrade.

Envinfo.txt: This is the most useful of the logs. It contains all of the information about the Wired AutoConfig environment, including the profile on the adapters and the computer certificate. All of the data in this log can be gathered individually by using the following show commands:

  • show interfaces
  • show settings
  • show profiles
  • show networks

The following procedure shows the steps used to collect wired trace sets.

To collect LAN-related trace sets

  1. Click Start, and in Start Search, type cmd.

  2. In Programs, right-click the cmd icon, and select Run as administrator to start command prompt with administrator credentials.

  3. At the command prompt, type netsh lan set tra yes, and then press ENTER.

  4. Reproduce your problem or error condition.

  5. In the command prompt, type netsh lan set tra no, and then press ENTER to stop wired tracing and create the tracing logs.

After running the command you will receive a message similar to the following:

Wired tracing has been started.

Trace logs will be stored in C:\Windows\tracing\wired

Note

Tracing for LAN remains on until you use the netsh lan set tra no command to stop it.

In some cases, you must enable tracing at startup so that you can troubleshoot and debug issues that might take place before user logs on. In other words, traces are needed when the Wired AutoConfig service starts at boot time before user logon. Tracing, when enabled, must persist after a system reboot.

When logging must resume when the computer is restarted, use the command-line interface to enable LAN tracing at startup.

Using the persistent command, LAN tracing starts immediately and continues even after the computer is restarted. When the system reboots, tracing will resume after the Wired AutoConfig service starts; any pre-existing trace logs and files are overwritten.

To set persistent LAN tracing

  1. Click Start, and in Start Search, type cmd.

  2. In Programs, right-click the cmd icon, and select Run as administrator to start command prompt with administrator credentials.

Note

To run the netsh lan set tracing command, you must run cmd with elevated privileges.

  1. At the command prompt, type netsh lan set tra persistent, and then press ENTER.

After running the command, you will receive a message similar to the following:

Persistent wired tracing has been enabled.

Trace logs will be stored in C:\Windows\tracing\wired

Note

Tracing for LAN remains on until you use the netsh lan set tra no command to stop it.

Back to In this document

Appendix C: Detailed PEAP-MS-CHAP v2 and EAP-TLS operations

This section describes the detailed PEAP-MS-CHAP v2 and EAP-TLS operations.

Detailed PEAP-MS-CHAP v2 operations

This section provides information about the 802.1X PEAP authentication phases.

PEAP-MS-CHAP v2 requires a certificate on each RADIUS server, but not on the network client. Servers running IAS must have a certificate installed in their Local Computer certificate store. Instead of deploying a PKI, you can purchase individual certificates from a non-Microsoft CA to install on your servers. To ensure that clients can validate the IAS server certificate chain, the root CA certificate of the CA that issues the IAS server certificates must be installed on each network client.

Windows XP, Windows Server 2003, and Windows Vista include the root CA certificates of many non-Microsoft CAs. If you purchase your IAS server certificates from a non-Microsoft CA for which your Windows clients do not include a corresponding root CA certificate, you must install the root CA certificate on each client. If you purchase your IAS server certificates from a non-Microsoft CA that corresponds to an included root CA certificate, no additional client configuration is required.

Part 1: Creating the TLS channel and authentication method negotiation

The following process creates the TLS channel:

  1. Registration and request for identity
    When a client connects to a switch, it transmits an EAPOL-Start message. When the IEEE 802.1X process on the switch receives an EAPOL-Start message from the client, it transmits an EAP-Request/Identity message to the client.
  2. The client responds with an EAP-Response/Identity message that contains the identity (user name or computer name) of the client.
  3. The EAP-Response/Identity message is sent by the switch to the RADIUS server. From this point on, the logical communication occurs between the RADIUS server and the client by using the switch as a pass-through device.
  4. The RADIUS server sends and EAP request/Start PEAP message to the client.
  5. The client and the RADIUS server exchange a series of TLS messages through which the cipher suite for the TLS channel is negotiated and the RADIUS server sends a certificate chain to the client for authentication.

At the end of PEAP negotiation:

  • The RADIUS server has authenticated itself to the client.
  • Both the client and RADIUS server have determined mutual encryption keys for the PEAP-TLS channel by using public key cryptography, not passwords.
  • All subsequent EAP messages sent between the client and the RADIUS server are encrypted.

Part 2: PEAP-MS-CHAP v2 operation of 802.1X authentication and authorization

After the PEAP-TLS channel is created, PEAP-MS-CHAP-v2 performs the following steps to authenticate the client, based on user name and password credentials:

  1. The RADIUS server sends an EAP-Request/Identity message.
  2. The client responds with an EAP-Response/Identity message that contains the identity (user or computer name) of the client.
  3. The RADIUS server sends an EAP-Request/EAP-MS-CHAP v2 Challenge message that contains a challenge string.
  4. The client responds with an EAP-Response/EAP-MS-CHAP v2 Response message that contains both the response to the RADIUS server challenge string and a challenge string for the RADIUS server.
  5. The RADIUS server verifies the client credentials against the user accounts database, and if a matching record is found, sends an EAP-Request/EAP-MS-CHAP v2 Success message. The EAP-Request/EAP-MS-CHAP v2 Success message indicates that the client response is correct, and contains the response to the client challenge string.
  6. The client responds with an EAP-Response/EAP-MS-CHAP v2 Ack message, indicating that the RADIUS server response is correct.
  7. The RADIUS server sends an EAP-Success message.

At the end of this mutual authentication exchange:

  • The client has provided proof of knowledge of the correct password (the response to the RADIUS server challenge string).
  • The RADIUS server has provided proof of knowledge of the correct password (the response to the client challenge string).
  • The entire exchange has been encrypted through the TLS channel created in the first part of the PEAP authentication.

At this point, the 802.1X controlled port on the switch allows the client’s traffic to traverse the controlled port. The client sends a DHCP "address request" through the 802.1X controlled port to the network. If a DHCP server responds, the client obtains an IP address. If configured, Group Policy is applied or refreshed. Provided the client has the correct permissions, the client is able to access network resources.

Detailed EAP-TLS operations

With EAP-TLS, each peer negotiates to perform EAP during the connection authentication phase. When the connection authentication phase is reached, the peers negotiate the use of an EAP authentication scheme known as an EAP method or EAP type.

EAP over RADIUS is used in environments where RADIUS is the authentication provider. An advantage of using EAP over RADIUS is that EAP types do not need to be installed at each network access server (switch), only at the RADIUS server. However, the access server must support the negotiation of EAP as an authentication protocol and the passing of EAP messages to a RADIUS server. In a typical deployment of EAP over RADIUS, the switch is configured to use EAP and to use RADIUS as its authentication provider. Because EAP is part of the IEEE 802.1X standard, you must enable IEEE 802.1X authentication to enable a switch to use EAP.

EAP over RADIUS is not an EAP type; it is the passing of EAP messages of any EAP type, by the access server to a RADIUS server, for the purpose of authentication. An EAP message sent between the access client and access server is formatted as the EAP-Message RADIUS attribute and sent in a RADIUS message between the access server and the RADIUS server. The switch becomes a pass–through device, passing the EAP message between the client and the RADIUS server. EAP messages are processed by the access client and the RADIUS server, not by the switch.

The following is the EAP-TLS process for a network client authentication using RADIUS authentication:

  1. Registration and request for identity
    When a client connects to a switch, it transmits an EAPOL-Start message. If the IEEE 802.1X process on the switch receives an EAPOL-Start message from the client, it transmits an EAP-Request/Identity message to the client.
  2. EAP-Response/Identity response
    If there is no user logged on to the client, it transmits an EAP-Response/Identity containing the computer name. For Windows clients, the fully qualified domain name (FQDN) of the computer account is sent. If there is a user logged on to the client, it transmits an EAP-Response/Identity containing the user name. For Windows clients, it transmits an EAP-Response/Identity containing the user name. For Windows clients, the user principal name (UPN) of the user account is sent. The switch forwards the EAP-Response/Identity message to the RADIUS server in the form of a RADIUS Access-Request message.
  3. EAP-Request from RADIUS server (Start TLS)
    The RADIUS server sends a RADIUS Access-Challenge message containing an EAP-Request message with the EAP-Type set to EAP-TLS, requesting a start to the TLS authentication process. The switch forwards the EAP message to the client.
  4. EAP-Response from the client (TLS Client Hello)
    The client sends an EAP-Response message with the EAP-Type set to EAP-TLS, indicating the TLS client hello. The switch forwards the EAP message to the RADIUS server in the form of a RADIUS Access-Request message.
  5. EAP request from RADIUS server (RADIUS Server’s Certificate)
    The RADIUS server sends a RADIUS Access-Challenge message containing an EAP-Request message with the EAP-Type set to EAP-TLS and includes the RADIUS server’s certificate chain. The switch forwards the EAP message to the client.
  6. EAP-Response from the client (Client’s Certificate)
    The client sends an EAP-Response message with the EAP-Type set to EAP-TLS and includes the client’s certificate chain. The switch forwards the EAP message to the RADIUS server in the form of a RADIUS Access-Request message.
  7. EAP-Request from RADIUS server
    The RADIUS server sends a RADIUS Access-Challenge message containing an EAP-Request message with the EAP-Type set to EAP-TLS, which includes the cipher suite and an indication that TLS authentication message exchanges are complete. The switch forwards the EAP message to the client.
  8. EAP-Response from the client
    The client sends an EAP–Response message with the EAP-Type set to EAP-TLS. The switch forwards the EAP message to the RADIUS server in the form of a RADIUS Access-Request message.
  9. EAP-Success from RADIUS server
    The RADIUS server sends a RADIUS Access-Accept message containing an EAP-Success message. After receiving the RADIUS server message, the switch forwards the EAP-Success message to the client, and enables the 802.1X controlled port (as described in phases 6 and 7, in Section 3: The 802.1X authentication process).

Back to In this document

Appendix D: Trace file examples

The trace files that are generated by Wired Diagnostics capture detailed information about connection processes. Because the connection process for 802.1X authenticated wired access is complicated, the resulting logs can be quite long. For readability, the example trace files in this appendix have had sections of text removed to limit the length of each example to about two pages. The string "+++++++Text removed for readability+++++++" is used to indicate where text was removed from the original trace file.

  • OneX Trace
  • Msmsec Trace
  • Wired AutoConfiguration Service Trace

OneX Trace

[3596] 12:56:33.557 OneXDestroySupplicantPort
[3596] 12:56:33.557 Port(58): Completing the port destruction
[3596] 12:56:33.557 Port(58): Draining the event queue (SupplicantQueue)
[3596] 12:56:33.557 Port(58): EapEndSession called for eap type 25
[3596] 12:56:33.557 Port(58): Calling EapHostPeerClearConnection...
[3596] 12:56:33.563 Port(58): EapHostPeerClearConnection returned
[3596] 12:56:33.563 Port(58): Setting working set data of size 0
[3596] 12:56:33.563 Port(58): Setting a 1x profile of size 0
[3596] 12:56:33.563 Port(58): Setting the quarantine state to 1
[3596] 12:56:33.563 Port(58): De-initing the Eap context. Deleting all cached UI Responses
[3596] 12:56:33.563 Port(58): Reset the runtime state
[3596] 12:56:33.563 Port(58): Setting a 1x profile of size 0
[3596] 12:56:33.563 Port(58): Draining the event queue (GlobalQueue)
[2428] 12:56:33.606 OneXCreateSupplicantPort
[2428] 12:56:33.609 Port(59): Setting the quarantine state to 1
[2428] 12:56:33.609 Port(59): Setting the Eap method backend support to BackendSupportUnknown
+++++++Text removed for readability+++++++
[2428] 12:56:33.610 Port(59): Processing local event complete: (PAEStartAuth)
[2428] 12:56:33.610 Port(59): Start processing local event: (BackendStartBackend)
[2428] 12:56:33.610 Port(59): StateSBackendNotStarted ----> StateSBackendDeactivated
[2428] 12:56:33.610 Port(59): Processing local event complete: (BackendStartBackend)
[2428] 12:56:33.610 Port(59): Start processing local event: (PAEUCT)
[2428] 12:56:33.612 Port(59): Got the token(00000E24) for the user logged on the active console id 3. 
       Proposing user auth
[2428] 12:56:33.612 Port(59): Identified OneX credentials. Using User Auth
[2428] 12:56:33.612 Port(59): User name = Client01, domain name = EXAMPLE
[2428] 12:56:33.612 Port(59): 802.1X user identified. auth identity = User Auth, sessionId = 3,
       username=Client01, domain=EXAMPLE
+++++++Text removed for readability+++++++
[2428] 12:56:33.618 Port(59): The result and the backend support is same as last time. Not sending 
       ResultUpdate notification
[2428] 12:56:33.618 Port(59): The auth and port status is same as last time. Not updating MSM 
       with OneX Result
+++++++Text removed for readability+++++++
[5596] 12:56:34.178 Port(59): A pending UI request exists size = 752, session Id = 3
[4408] 12:56:34.179 Not enough buffer
[4408] 12:56:34.179 The final balloon title is - Additional information is required to connect
       to the network
[4408] 12:56:34.179 The final balloon text is - Click to provide additional information and connect
+++++++Text removed for readability+++++++
[2136] 12:56:40.215 Port(59): Received an Eap packet length=4, type=EapFail, identifier=138, eapType=0
[2136] 12:56:40.215 Port(59): ProcessOneXEvent: Event [EapPkt]
[2136] 12:56:40.215 Port(59): Start processing local event: (BackendEapPktReceived)
[2136] 12:56:40.215 Port(59): Calling EapHostPeerProcessReceivedPacket ...
[2136] 12:56:40.215 Port(59): EapHostPeerProcessReceivedPacket returned
[2136] 12:56:40.215 Port(59): EapHostPeerProcessReceivedPacket returned Action = 
       EapHostPeerResponseResult
[2136] 12:56:40.215 Port(59): Calling EapHostPeerGetResult...
[2136] 12:56:40.216 Port(59): EapHostPeerGetResult returned
[2136] 12:56:40.216 Port(59): Invalid state for UI requests
[2136] 12:56:40.216 Port(59): Setting the quarantine state to 1
[2136] 12:56:40.216 Port(59): Sending notification = (EapAttributes) to MSM
[2136] 12:56:40.216 Port(59): Received a failure indication from the local Eap dll with 
       error code 0x30a and reason code 0x30a
[2136] 12:56:40.216 Port(59): Eap error info contains winError=0x80420204, reasonCode=0x30a,
       Method(Type=25), rootCauseString=Windows cannot connect to this network
There is a problem with the certificate on the server required for authentication.

Msmsec Trace

[3596] 12:56:33.534 Interface(1): Start processing event (Global:Disconnect)
[3596] 12:56:33.534 Interface(1): Start processing event: (Local:Disonnect)
[3596] 12:56:33.562 Interface(1): Authenticated ----> Disconnected
[3596] 12:56:33.562 Interface(1): Completed processing event (Local:Disonnect)
[3596] 12:56:33.562 Interface(1): Draining the event queue (ConnectSMQueue)
[3596] 12:56:33.562 Interface(1): Completed processing event (Global:Disconnect)
[2428] 12:56:33.604 Interface(1): Start processing event (Global:Connect)
[2428] 12:56:33.604 Interface(1): Start processing event: (Local:Connect)
[2428] 12:56:33.605 Interface(1): Set the 1X multicast addresss as the destination MAC address
[2428] 12:56:33.605 Interface(1): Disconnected ----> Connecting
[2428] 12:56:33.605 Interface(1): Completed processing event (Local:Connect)
[2428] 12:56:33.605 Interface(1): Start processing event: (Local:MediaConnect)
[2428] 12:56:33.609 Interface(1): Updating MSM cookie 1-->2
[2428] 12:56:33.609 Interface(1): Connecting ----> Connected
[2428] 12:56:33.609 Interface(1): Completed processing event (Local:MediaConnect)
[2428] 12:56:33.609 Interface(1): Start processing event: (Local:OneXEnabled)
[2428] 12:56:33.609 Interface(1): Queued 1X auth success timer 60000 msec
[2428] 12:56:33.609 Interface(1): Connected ----> Authenticating
[2428] 12:56:33.609 Interface(1): Completed processing event (Local:OneXEnabled)
[2428] 12:56:33.609 Interface(1): Draining the event queue (ConnectSMQueue)
[2428] 12:56:33.609 Interface(1): Completed processing event (Global:Connect)
[5900] 12:56:33.611 Interface(1): Start processing event (Global:OneXResult)
[5900] 12:56:33.611 Interface(1): Start processing event: (Local:AuthInProgress)
[5900] 12:56:33.611 Interface(1): The event Local:AuthInProgress doesn't have any 
       transitions in the current state Authenticating
[5900] 12:56:33.611 Interface(1): Completed processing event (Local:AuthInProgress)
[5900] 12:56:33.611 Interface(1): Draining the event queue (ConnectSMQueue)
[5900] 12:56:33.611 Interface(1): Completed processing event (Global:OneXResult)
[2428] 12:56:33.614 Interface(1): Received packet sourced by us. Discarding packet
[2428] 12:56:33.614 Interface(1): Set the SWITCH MAC address to 00:15:2C:28:14:7F
[2428] 12:56:33.617 Interface(1): Received packet sourced by us. Discarding packet
[3596] 12:56:33.957 Interface(1): Set the SWITCH MAC address to 00:15:2C:28:14:7F
[2136] 12:56:33.974 Interface(1): Received packet sourced by us. Discarding packet
[2136] 12:56:34.170 Interface(1): Set the SWITCH MAC address to 00:15:2C:28:14:7F
[2136] 12:56:34.177 Interface(1): Cleared 1x UI Response time
[5596] 12:56:40.088 Interface(1): Stored 1x UI Response time
[2136] 12:56:40.093 Interface(1): Received packet sourced by us. Discarding packet
[2136] 12:56:40.214 Interface(1): Set the SWITCH MAC address to 00:15:2C:28:14:7F
[2136] 12:56:40.217 Interface(1): Cleared 1x UI Response time
[2136] 12:56:40.252 Interface(1): Start processing event (Global:OneXResult)
[2136] 12:56:40.252 Interface(1): Start processing event: (Local:AuthFailure)
[2136] 12:56:40.252 Interface(1): Cleared 1x UI Response time
[2136] 12:56:40.256 Interface(1): OneX notified us of auth failure. Reason = 0x50005, 
       ErrorCode = 778
[2136] 12:56:40.256 Interface(1): Authenticating ----> AuthenticationFailed
[2136] 12:56:40.256 Interface(1): Completed processing event (Local:AuthFailure)
[2136] 12:56:40.256 Interface(1): Start processing event: (Local:UCT)
[2136] 12:56:40.256 Interface(1): AuthenticationFailed ----> Failure
[2136] 12:56:40.256 Interface(1): Completed processing event (Local:UCT)
[2136] 12:56:40.256 Interface(1): Draining the event queue (ConnectSMQueue)
[2136] 12:56:40.256 Interface(1): Completed processing event (Global:OneXResult)
[2136] 12:56:40.263 Interface(1): Start processing event (Global:Disconnect)
[2136] 12:56:40.263 Interface(1): Start processing event: (Local:Disonnect)
[2136] 12:56:40.265 Interface(1): Failure ----> Disconnected
[2136] 12:56:40.265 Interface(1): Completed processing event (Local:Disonnect)
[2136] 12:56:40.265 Interface(1): Draining the event queue (ConnectSMQueue)
[2136] 12:56:40.265 Interface(1): Completed processing event (Global:Disconnect)
[3596] 12:56:40.404 No 1X port exists. Ignoring the packet received
[2136] 12:56:50.411 No 1X port exists. Ignoring the packet received

Wired AutoConfiguration Service Trace

[4156] 11:31:30.637 Could not find the interface using the given GUID, error 87.
[1236] 11:31:47.399 Extra data is passed with trigger MSM Connection Progress.
[5088] 11:32:02.415 Extra data is passed with trigger MSM Connection Success.
[340] 11:32:07.451 Extra data is passed with trigger MSM Connection Progress.
[5844] 11:32:22.495 Extra data is passed with trigger MSM Connection Success.
[5392] 11:32:36.951 Could not find the interface using the given GUID, error 87.

Back to In this document

Appendix E: Network Diagnostics Framework

In Windows Vista, when a user experiences a network problem, Windows Vista will provide the user with the ability to diagnose and repair the problem. The diagnostic assessment and resolution steps that are provided to the user are in the application or user interface (UI) itself. During the diagnosis, the Network Diagnostics Framework (NDF) will analyze why the user’s task failed, and will either present a solution to the problem or list possible causes and steps that the user can to take to fix the problem. The solution can be a process that is run automatically by Windows Vista, or it might be a request that the user manually perform a step. The resolution steps can involve configuration changes, or in some cases, contacting Microsoft Product Support Services and providing a report of the problem from the computer.

Windows Network Diagnostics overview

Diagnostics are used to identify and correct troubleshooting connectivity issues. Network Diagnostics works with NDF, which, in turn, is part of Windows Diagnostics Infrastructure (WDI). The role of diagnostics is to collect and analyze information about connectivity, to provide the results of the analysis, and to provide the user with repair options.

The following describes the design approach of Network Diagnostics in Windows Vista:

  • Inform the user about what has happened or what is causing the problem.
  • Be sure that the user can understand the information and that the information is appropriate in the context of what the user is doing.
  • Instruct the user about how to fix the problem.
  • Provide options instead of errors.
  • Provide better support when Network Diagnostics cannot present a solution.
  • Provide best-effort analysis of collected data.
  • Avoid asking the user for data that is available on the computer.
  • Direct the customer to someone who can help.

All diagnostics are prescriptive in nature, and solutions are corrective when possible. The design is also based on the principle that the solutions will not put the computer at risk.

Parts of Network Diagnostics

For the purposes of this document, Network Diagnostics are divided into two parts:

  • Network Diagnostics wizard. The Network Diagnostics wizard is similar to a configuration wizard. It can assist users by either fixing connectivity problems, or by providing a next-step action. Although the primary focus is on identifying and resolving client-side connectivity problems, the Network Diagnostics wizard will attempt to analyze end-to-end network health, as seen from the client perspective and with client user rights, and attempt to determine if the problem is related to network services or infrastructure components.
    Running the Network Diagnostics wizard should be the first step when you are trying to resolve connectivity problems. Users can access the interactive Network Diagnostics wizard in several locations in the UI, which is discussed in Starting the Network Diagnostics wizard.
  • Diagnostics logs and reports. In addition to providing the interactive Network Diagnostic wizard, Network Diagnostics also logs information in the Wired AutoConfig event logs, operational logs, and tracing reports. These logs and reports capture detailed information about network status and activity, connection attempts, system state, and the network environment.
    IT administrators can automatically collect logged information from the client computers and store it for analysis in a central location using MOM integration or a similar tool. Administrators can also use this information for planning purposes (for example, when considering whether to increase network service levels by adding servers or network hardware).
    Microsoft Product Support Services and developers can generate tracing reports for advanced troubleshooting and debugging.
    Information about the logs and reports that are generated by diagnostics is discussed in Section 6: Wired-AutoConfig Operational Logs, Wired Diagnostics Report. Samples of diagnostic logs are provided in Appendix D: Trace file examples.

The remainder of this section contains information about the Network Diagnostics wizard.

Starting the Network Diagnostics wizard

You can start the Network Diagnostics wizard from several places on a client running Windows Vista. This section includes several procedures for starting the Network Diagnostics wizard.

Using the Network and Sharing Center notification area icon

The icon for the Network and Sharing Center is located to the left of the clock in the notification area.

Note

When you position the mouse pointer directly over the Network and Sharing Center notification area icon, the Currently connected to notification will appear. If the computer running Windows Vista is not connected to a network or another computer, the Network and Sharing Center icon is displayed with an "X" to indicate that your computer is not connected.

To start the Network Diagnostics wizard by using the Diagnose and repair option of the Network and Sharing Center notification area icon

  • Right-click the Network and Sharing Center icon in the notification area, and then click Diagnose and repair.

Using the Diagnose network problems option in Network and Sharing Center

To start the Network Diagnostics wizard by using the Diagnose and repair option in the Network and Sharing Center

  1. Click Start, click Network, and in the menu, click Network and Sharing Center.

  2. In the left pane, click Diagnose and repair.

Using the Diagnose and repair option in Network and Sharing Center (option 2)

To start the Network Diagnostics wizard by using the Diagnose and repair option in the Network and Sharing Center

  1. Click Start, click Connect to, and in Connect to a network, click Open Network and Sharing Center.

  2. In Network and Sharing Center, in the left-hand pane, click Diagnose and repair.

Using the Diagnose option for a network connection icon in Network Connections

Network Connections provides several methods for starting the Network Diagnostics wizard.

To start the Network Diagnostics wizard by using the Diagnose options for a Network Connections icon

  1. Open Network Connections by using one of the following methods:

    • Click the Network and Sharing Center icon in the notification area, click Network and Sharing Center, and then in the left pane of Network and Sharing Center, click Manage network connections.
    • Click Start, click Network, click Network and Sharing Center, and then click Manage network connections.
    • Click Start, click Connect to, click Open Network and Sharing Center, and then click Manage network connections.

  2. In LAN or High-Speed Internet, select the network connection you want, and then do one of the following:

    • Click Diagnose this connection.
    • Right-click the connection item, and then click Diagnose.

Additional entry points

Internet Explorer: If Internet Explorer fails to connect to the target resource, it displays:

  • a message indicating that it cannot display the Web page.
  • a list of the most likely causes.
  • links to Network Diagnostics and online help.

You can click Diagnose Connection Problems to start the Network Diagnostics wizard.

Start Search: If an attempt to access a resource by typing a UNC (Universal Naming Convention) name in Start Search fails, the resulting error message provides a link that you can use to start the Network Diagnostics wizard.

To use the Start Search entry point to open Network Diagnostics

  1. Click Start, in Start Search, type the UNC name for the target resource, such as \\servername\sharename\directory\filename, and then press ENTER.

  2. If the attempt to access the resource is unsuccessful, when the Network Error dialog box opens, click Diagnose to open Network Diagnostics.

In some cases, running the Network Diagnostics wizard will not fix the problem. In these situations, your next step is to use the netsh lan commands to gather information that will be useful for troubleshooting.

Back to In this document

Appendix F: Windows Vista DLLs and function descriptions

The 802.1X Wired AutoConfig service (dot3svc) is a new feature in Windows Vista. Its main functions are separated into DLL components. The following list of Wired AutoConfig service DLLs is provided for, and typically only useful to, Microsoft Product Support Services.

DLL list and function description

Main DLLs

dot3ui.dll: The dot3UI implements the Windows Vista supplicant user interface for creating and editing wired profile settings.

dot3api.dll: The public API interface with Auto Configuration Module (ACM).

dot3svc.dll: The Wired AutoConfig service is the core service for Windows Vista. It is responsible for discovering, connecting, and disconnecting from Ethernet networks. It also sends configuration information to the 802.3 Media Specific Module (MSM).

dot3msm.dll: The 802.3 Media Specific Module manages communication between Security Module, the IHV Security Manager and Native Wi-Fi and FAT (legacy) network drivers. It is the bridge between the media-specific drivers and is also responsible for bridging associations.

Supporting DLLs

dot3cfg.dll: The netsh command line provides all scripting and command line configuration functionality. For example, profile import and export functions, profile configuration, and control of the Wired AutoConfig service can all be accomplished through the netsh lan.

dot3gpui.dll: The Group Policy user interface implements the user interface for wired Group Policy settings.

dot3gpclnt.dll: The Group Policy Client is responsible for downloading the Wired Network (IEEE 802.3) Policies Group Policy object settings from Active Directory, and plumbing the settings to the ACM.

onex.dll: The 802.1x Authentication Module is responsible for managing the communication between the Security Module and the various EAP methods through the EAPHost API.

dot3dlg.dll: The dot3dlg.dll implements the interactive user interface dialog boxes and notifications displayed during the connection process.

Back to In this document

See Also

Other Resources

Active Directory Schema Extensions for Windows Vista Wireless and Wired Group Policy Enhancements
Network Diagnostics Technologies in Windows Vista
Windows Server 2003 Technical Reference
Online Windows Server 2003 Product Help