<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: sporadic failed 802.1X authentications on Win10 PCs in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/sporadic-failed-802-1x-authentications-on-win10-pcs/m-p/4899817#M583302</link>
    <description>&lt;P&gt;I have been trying to get my head around the various "Power Saving" modes of Windows 10/11 and it's quite a complex thing these days. The CPU "Sleep" states are described as S0 through S4, where S0 means the CPU is awake and running, and S4 means it's powered off. There is a type of "sleep" in Windows these days that is technically S0 - which means the PC is still able to communicate with the network layer - it listens for its MAC address and then sends data - but to the user the laptop looks like it's asleep. I don't know how to enable or disable this feature. I have been exploring the powercfg command in Windows and I would recommend you run the Sleep Study - it's amazingly details - an HTML output of what the PC has been up to. You must run this as Administrator user:&lt;/P&gt;
&lt;LI-CODE lang="markup"&gt;powercfg /sleepstudy&lt;/LI-CODE&gt;
&lt;P&gt;The laptop is most likely having to keep the USB-C interfaces active even while in sleep mode. You can check this with the command:&lt;/P&gt;
&lt;LI-CODE lang="markup"&gt;powercfg -devicequery wake_armed&lt;/LI-CODE&gt;
&lt;P&gt;If you want to see what "thing" last caused the PC to wake from its sleep, use this command:&lt;/P&gt;
&lt;LI-CODE lang="markup"&gt;powercfg -lastwake&lt;/LI-CODE&gt;</description>
    <pubDate>Sun, 06 Aug 2023 21:59:08 GMT</pubDate>
    <dc:creator>Arne Bier</dc:creator>
    <dc:date>2023-08-06T21:59:08Z</dc:date>
    <item>
      <title>sporadic failed 802.1X authentications on Win10 PCs</title>
      <link>https://community.cisco.com/t5/network-access-control/sporadic-failed-802-1x-authentications-on-win10-pcs/m-p/4894686#M583118</link>
      <description>&lt;P&gt;Hello Community,&lt;/P&gt;&lt;P&gt;I took charge of the local Cisco Infrastructure&amp;nbsp;network administration for 2 years already since I finished my apprenticeship.&lt;/P&gt;&lt;P&gt;I received issues from users that their PCs sometimes have problems with network connection. Our enterprise functions on NAC based solution. We work with ISE and C9300/2960S/2960X switches each equipped with different IOS/Xe versions.&lt;/P&gt;&lt;P&gt;I took the matter seriously and togheter with our ServiceDesk, we performed some research on the supplicant side.&lt;/P&gt;&lt;P&gt;Following has been examined:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;&lt;STRONG&gt;Drivers for the Ethernet and Realtek adapters&lt;/STRONG&gt; - we constantly updated the DELL drivers to the newest versions&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Certificate of the Supplicant&lt;/STRONG&gt; - we have a PKI server and certificates installed on the clients&amp;nbsp; are sometimes updated via gpupdate /force&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Other issues like -&amp;nbsp;&lt;/STRONG&gt;Bitlocker, Inter vPro or Docking station&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;We have conducted research on 11 random clients and each was a different model. Further we couldn't get a fix of the problem by just updating the network adapters drivers. For like a range of 4 to 8 Weeks the authentication worked and then the issues re-appeared.&amp;nbsp;&lt;/P&gt;&lt;P&gt;We got failed 802.1X authentications:&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;On every switch model randomly&lt;/LI&gt;&lt;LI&gt;It is always a different DELL PC model that gets a failed authentication&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;So we couldn't say in the end that the clients have problems. We also got other clients with older drivers and they never had any issue with the 802.1X authentication than those with newer drivers. I said then I will debug the authentication process and the EAPOL packets. We use EAP-TLS Type 13 authentication.&lt;/P&gt;&lt;P&gt;I debuged a successful authentication and a failed one. I used the commands&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;Debug radius&lt;/LI&gt;&lt;LI&gt;Debug eap packets&lt;/LI&gt;&lt;LI&gt;Debug dot1x all&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;On&amp;nbsp;&lt;STRONG&gt;Debug dot1x all&amp;nbsp;&lt;/STRONG&gt;logs I saw that when an EAPOL packet was sent to the supplicant, the client didn't send any dot1x keys data and on other occasions I saw in the authentcation database that there were some clients with failed dot1x authentication. I restared the port and then only the MAC of the Alcatel VoIP Phone got authenticated but the MAC of the client was not listed anymore. Like it got cached on the interface during the live authentication session.&amp;nbsp;&lt;/P&gt;&lt;P&gt;Some of times the users laptop was in the rejection group on ISE after 3 failed attempt to authenticate and after 1h it retried to authenticate and it succeeded on the first try. We had cases with MAC Cacheing through the VoIP Phone but the R100 from Alcatel solved the issue 90% of the cases.&lt;/P&gt;&lt;P&gt;My last&amp;nbsp;&lt;SPAN&gt;assumption would be that the configured timeout and automated re-authentification syntax on the interface is causing the issue.&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;This is our NAC configuration&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;switchport mode access&lt;BR /&gt;switchport voice vlan 546&lt;BR /&gt;no logging event link-status&lt;BR /&gt;authentication host-mode multi-domain&lt;BR /&gt;authentication order dot1x mab&lt;BR /&gt;authentication priority dot1x mab&lt;BR /&gt;authentication port-control auto&lt;BR /&gt;authentication periodic&lt;BR /&gt;authentication timer reauthenticate server&lt;BR /&gt;no snmp trap link-status&lt;BR /&gt;mab&lt;BR /&gt;dot1x pae authenticator&lt;BR /&gt;dot1x timeout quiet-period 300&lt;BR /&gt;dot1x timeout tx-period 3&lt;BR /&gt;dot1x timeout ratelimit-period 300&lt;BR /&gt;spanning-tree portfast&lt;BR /&gt;spanning-tree bpduguard enable&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;What is our opinion? Where should I look deeper?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 28 Jul 2023 08:03:46 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/sporadic-failed-802-1x-authentications-on-win10-pcs/m-p/4894686#M583118</guid>
      <dc:creator>NetAdminCisco</dc:creator>
      <dc:date>2023-07-28T08:03:46Z</dc:date>
    </item>
    <item>
      <title>Re: sporadic failed 802.1X authentications on Win10 PCs</title>
      <link>https://community.cisco.com/t5/network-access-control/sporadic-failed-802-1x-authentications-on-win10-pcs/m-p/4895434#M583147</link>
      <description>&lt;P&gt;Sounds like a very frustrating issue, especially when it's sporadic.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Can you list the error messages as seen in ISE when these Workstations fail 802.1X ? - e.g. click on the details in Live Logs and dig out the error condition. That is the starting point to see what the cause might be.&lt;/P&gt;
&lt;P&gt;Are you doing dynamic VLAN assignment (i.e. does ISE return a VLAN Name/ID on successful authentication) ? I don't see a switchport access vlan XX in your IOS config - default is VLAN 1, but best practice is to avoid VLAN 1. But that should not have any impact on your issue.&lt;/P&gt;
&lt;P&gt;If these workstation do work, but fail occasionally, then we should rule out the Windows client certificate at least. But most of the time it's an endpoint issue, not a switch or ISE. There are more variables on the Windows PC that can cause issues.&lt;/P&gt;
&lt;P&gt;Have you looked at the Windows Event Viewer for clues?&amp;nbsp; The Events are hidden under&lt;/P&gt;
&lt;P&gt;Applications and Services Logs &amp;gt; Microsoft &amp;gt; Windows &amp;gt; Wired-AutoConfig &amp;gt; Operational&lt;/P&gt;
&lt;P&gt;Also, do you know what state these workstations were in when they failed?&amp;nbsp; Were they in sleep mode, and then woken up, and then failed? Or did the user restart the workstation and then it failed immediately?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sat, 29 Jul 2023 22:34:22 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/sporadic-failed-802-1x-authentications-on-win10-pcs/m-p/4895434#M583147</guid>
      <dc:creator>Arne Bier</dc:creator>
      <dc:date>2023-07-29T22:34:22Z</dc:date>
    </item>
    <item>
      <title>Re: sporadic failed 802.1X authentications on Win10 PCs</title>
      <link>https://community.cisco.com/t5/network-access-control/sporadic-failed-802-1x-authentications-on-win10-pcs/m-p/4898162#M583262</link>
      <description>&lt;P&gt;Exactly. Our RADIUS server sends a return value and the VLAN is dynamicly assigned to the interface.&lt;/P&gt;&lt;P&gt;I tried this week to test the state of a laptop. We are having many different and individual issues.&lt;/P&gt;&lt;OL&gt;&lt;LI&gt;Expired certificate&lt;/LI&gt;&lt;LI&gt;Missing AD Group for a client&lt;/LI&gt;&lt;LI&gt;Too old drivers&lt;/LI&gt;&lt;/OL&gt;&lt;P&gt;But what I saw is, that many laptops who got affected don't have any of the common issues listed in my post. I tested your idea about the state of the client and saw that many users put their laptops in sleep mode. The TX traffic was slowly droppng till it hit under 10 bits. But...and now comes the interesting part. When it is in sleep mode. The MAC address remains autenticated via dot1x till next reauthentication till the next re-authentication session.&lt;/P&gt;&lt;P&gt;I disabled and re-enabled the interface to forcefully start a new link up and then of course the communication dropped from Layer 3 to Layer 1. But ISE still tried to authenticate the MAC Address and voilla...the MAC Address was in the reject group.&lt;/P&gt;&lt;P&gt;Cause we got a user, and every morning when he arrives in the office, he sees his laptop unable to get a network connection via wired LAN. After 1h it works again. Our clients go for 1h in to the reject group everytime they failed to authenticate. I saw after the re-enaling of the interface that even though the communication is only Layer1. And there is no active authentication session, ISE still tries to authenticate the MAC Address and then no wonder why the MAC failed at getting authenticated and it landed in the reject group.&amp;nbsp;&lt;/P&gt;&lt;P&gt;The laptop is a DELL and was connected to a DELL docking station. When the Ethernet cable is connected to the laptop. The issue doesn't occur. It occured only when vPro was an issue, but it has been deactivated on most clients now. When the Laptop is connected via USB-C to the dockingstation, then the&amp;nbsp;dockingstation to the switch interface and the laptop is in sleep mode. There is no authentication on the interface but the MAC is still visible on ISE and it fails to authenticate. Like the dock is still trying to communicate with the interface...even though the laptop is in sleep mode.&lt;/P&gt;</description>
      <pubDate>Thu, 03 Aug 2023 11:09:27 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/sporadic-failed-802-1x-authentications-on-win10-pcs/m-p/4898162#M583262</guid>
      <dc:creator>NetAdminCisco</dc:creator>
      <dc:date>2023-08-03T11:09:27Z</dc:date>
    </item>
    <item>
      <title>Re: sporadic failed 802.1X authentications on Win10 PCs</title>
      <link>https://community.cisco.com/t5/network-access-control/sporadic-failed-802-1x-authentications-on-win10-pcs/m-p/4899817#M583302</link>
      <description>&lt;P&gt;I have been trying to get my head around the various "Power Saving" modes of Windows 10/11 and it's quite a complex thing these days. The CPU "Sleep" states are described as S0 through S4, where S0 means the CPU is awake and running, and S4 means it's powered off. There is a type of "sleep" in Windows these days that is technically S0 - which means the PC is still able to communicate with the network layer - it listens for its MAC address and then sends data - but to the user the laptop looks like it's asleep. I don't know how to enable or disable this feature. I have been exploring the powercfg command in Windows and I would recommend you run the Sleep Study - it's amazingly details - an HTML output of what the PC has been up to. You must run this as Administrator user:&lt;/P&gt;
&lt;LI-CODE lang="markup"&gt;powercfg /sleepstudy&lt;/LI-CODE&gt;
&lt;P&gt;The laptop is most likely having to keep the USB-C interfaces active even while in sleep mode. You can check this with the command:&lt;/P&gt;
&lt;LI-CODE lang="markup"&gt;powercfg -devicequery wake_armed&lt;/LI-CODE&gt;
&lt;P&gt;If you want to see what "thing" last caused the PC to wake from its sleep, use this command:&lt;/P&gt;
&lt;LI-CODE lang="markup"&gt;powercfg -lastwake&lt;/LI-CODE&gt;</description>
      <pubDate>Sun, 06 Aug 2023 21:59:08 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/sporadic-failed-802-1x-authentications-on-win10-pcs/m-p/4899817#M583302</guid>
      <dc:creator>Arne Bier</dc:creator>
      <dc:date>2023-08-06T21:59:08Z</dc:date>
    </item>
  </channel>
</rss>

