Describes an issue that prevents Windows 10 devices from connecting to a WPA-2 Enterprise network that's using certificates for server-side or mutual authentication. Occurs after you apply the Windows 10 November update. A resolution is provided. IEEE 802.1X is an IEEE Standard for port-based Network Access Control (PNAC). It is part of the IEEE 802.11 group of networking protocols. It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN. IEEE 802.1X defines the encapsulation of the Extensible Authentication Protocol (EAP) over IEEE 802.11, which is known as 'EAP over LAN' or EAPOL.
This is the Tips and Tricks section of my Configuring 802.1x Authentication for Windows Deployment series. Be sure to check out all of the other parts here.
Enable Ieee 802.1 X Authentication Windows 10 Pro
These are just some random things I found while going through this.
Windows 10 802.1x Settings
C:Windowsdot3svcPolicies*.TMP (rename TMP to XML to see the Policy and Profile)
- Rename the .TMP file located in C:Windowsdot3svcPolicies to .OLD.
- Restart the Wired Autoconfig (dot3svc) service
That’s it. You should be able to configure a local 802.1x Authentication Policy. Reverse steps to re-apply GPO.
The Windows Event Viewer has a Wired-AutoConfig log buried in the logs. Take a look at it as you restart dot3svc and you can see the policy or profile get applied and trigger client authentication. It can be found under Applications and Services Logs > Microsoft > Windows > Wired-AutoConfig.
While this doesn’t appear to affect all of the items I’ve covered on 802.1x for OSD, I found a Windows 7 hotfix that fixes an issue where our clients will attempt to authenticate with the local 802.1x profile first, then attempt the Group Policy profile (local is user, GPO is computer) and the machines will get locked out. You can see the events in the Wired-AutoConfig event log to verify. The issue appears to go away in Windows 10 1709.
KB2481614 – the description doesn’t fully match what we are seeing, but it certainly fixes the issue.
- If you apply a local profile during OSD, that profile will stay on the computer. If the computer ever loses it’s Group Policy, the LAN interface will revert to the previous profile. If you used a user authentication profile and embedded credentials in it, you run the risk of locking the account if the password has changed.
- Post-Upgrade, the HKEY_LOCAL_MACHINESOFTWAREMicrosoftdot3svcMigrationData registry key will have a value of dot3svcMigrationDone = 1 if the 802.1x migration has been complete. If the key is missing but the MigrationData folder and registry keys exist, restart dot3svc. The key should appear and the previous GPO or profile will be applied to your LAN interfaces.
Enable Ieee 802.1 X Authentication For This Network Windows 105,212-->
This article includes general troubleshooting for 802.1X wireless and wired clients. While troubleshooting 802.1X and wireless, it's important to know how the flow of authentication works, and then figure out where it's breaking. It involves a lot of third-party devices and software. Most of the time, we have to identify where the problem is, and another vendor has to fix it. We don't make access points or switches, so it's not an end-to-end Microsoft solution.
Enable Ieee 802.1 X Authentication Windows 10 Download
This troubleshooting technique applies to any scenario in which wireless or wired connections with 802.1X authentication is attempted and then fails to establish. The workflow covers Windows 7 through Windows 10 for clients, and Windows Server 2008 R2 through Windows Server 2012 R2 for NPS.
See Advanced troubleshooting 802.1X authentication data collection.
Viewing NPS authentication status events in the Windows Security event log is one of the most useful troubleshooting methods to obtain information about failed authentications.
NPS event log entries contain information about the connection attempt, including the name of the connection request policy that matched the connection attempt and the network policy that accepted or rejected the connection attempt. If you don't see both success and failure events, see the NPS audit policy section later in this article.
Check Windows Security Event log on the NPS Server for NPS events that correspond to rejected (event ID 6273) or accepted (event ID 6272) connection attempts.
In the event message, scroll to the very bottom, and then check the Reason Code field and the text that's associated with it.
Example: event ID 6273 (Audit Failure)
Example: event ID 6272 (Audit Success)
The WLAN AutoConfig operational log lists information and error events based on conditions detected by or reported to the WLAN AutoConfig service. The operational log contains information about the wireless network adapter, the properties of the wireless connection profile, the specified network authentication, and, in the event of connectivity problems, the reason for the failure. For wired network access, the Wired AutoConfig operational log is an equivalent one.
On the client side, go to Event Viewer (Local)Applications and Services LogsMicrosoftWindowsWLAN-AutoConfig/Operational for wireless issues. For wired network access issues, go to ..Wired-AutoConfig/Operational. See the following example:
Most 802.1X authentication issues are because of problems with the certificate that's used for client or server authentication. Examples include invalid certificate, expiration, chain verification failure, and revocation check failure.
First, validate the type of EAP method that's used:
If a certificate is used for its authentication method, check whether the certificate is valid. For the server (NPS) side, you can confirm what certificate is being used from the EAP property menu. In NPS snap-in, go to Policies > Network Policies. Select and hold (or right-click) the policy, and then select Properties. In the pop-up window, go to the Constraints tab, and then select the Authentication Methods section.
The CAPI2 event log is useful for troubleshooting certificate-related issues.By default, this log isn't enabled. To enable this log, expand Event Viewer (Local)Applications and Services LogsMicrosoftWindowsCAPI2, select and hold (or right-click) Operational, and then select Enable Log.
For information about how to analyze CAPI2 event logs, seeTroubleshooting PKI Problems on Windows Vista.
When troubleshooting complex 802.1X authentication issues, it's important to understand the 802.1X authentication process. Here's an example of wireless connection process with 802.1X authentication:
If you collect a network packet capture on both the client and the server (NPS) side, you can see a flow like the one below. Type EAPOL in the Display Filter for a client-side capture, and EAP for an NPS-side capture. See the following examples:
Client-side packet capture data
NPS-side packet capture data
If you have a wireless trace, you can also view ETL files with network monitor and apply the ONEX_MicrosoftWindowsOneX and WLAN_MicrosoftWindowsWLANAutoConfig Network Monitor filters. If you need to load the required parser, see the instructions under the Help menu in Network Monitor. Here's an example:
By default, NPS audit policy (event logging) for connection success and failure is enabled. If you find that one or both types of logging are disabled, use the following steps to troubleshoot.
View the current audit policy settings by running the following command on the NPS server:
If both success and failure events are enabled, the output should be:
If it says, 'No auditing,' you can run this command to enable it:
Even if audit policy appears to be fully enabled, it sometimes helps to disable and then re-enable this setting. You can also enable Network Policy Server logon/logoff auditing by using Group Policy. To get to the success/failure setting, select Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff > Audit Network Policy Server.
Troubleshooting Windows Vista 802.11 Wireless Connections
Troubleshooting Windows Vista Secure 802.3 Wired Connections