03-03-2016 05:33 AM
We are currently deploying Clearpass in a pilot in a few of our buildings, and after a week or so, we noticed that HP PC's running Windows 7 would sporadically fail to respond to 802.1x authentication conversations from our switches. These are PC's that are configured correctly for 802.1x authentication, and have succeeded 802.1x authentication previously with no config change. We cannot repeat the failure in our test environments, and we can only catch it by monitoring Access Tracker. Our first remediation step was to install all recommended hotfixes from Microsoft. This did not make much of a difference. Secondly we updated the ethernet driver to the latest version. This resolved around 90% of the intermittent failures, but there are still some machines that continue to fail periodically. It always happens either when a computer goes to sleep, or when a computer is moved to a different location and plugged in (i.e. from home to plugging in at the office, from conference room to cube, from building to building, etc...). The workaround is just to unplug and plug back in the ethernet cable (reset the nic), but this is an unacceptable solution for the long run. Wireless 802.1x works perfectly.
Has anyone else run into this issue and found a solution?
03-03-2016 05:45 AM
What does the access tracker say during the failure? Did you get any of the event viewer logs from the client? That information might give us an idea.
Are the clients configured with Group Policy? Is the wired 802.1x service set to automatic on those clients?
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
03-03-2016 06:16 AM
After no response from the Windows supplicant from the 802.1x request, the switch falls back to MAB authentication, to which the Windows machine does respond, and causes the authentication to be processed against a different CPPM service. We see the MAB auth fail in Access Tracker, with the error that the user was not found.
I'm assuming when you say event viewer you're referring to on the Windows machine, and not in CPPM, and from when I've checked after these failures, I have not found anything outstanding, but I can look next time I investigate a failure agian and get back to you.
The wired autoconfig 802.1x service is indeed set to automatic via GPO on the Windows machines.
Thank you for your response!
03-03-2016 07:02 AM
Is this happening on the same switch ?
Can you share your Interface config ?
Are these devices behind a VoIP Phone ?
Lead Mobility Engineer @ Integration Partners
AMFX | ACMX | ACDX | ACCX | CWAP | CWDP | CWNA
03-03-2016 01:53 PM - edited 03-03-2016 01:58 PM
The switches in this envirnoment are Cisco, and the issue occurs across multiple switches in the buildings. I cannot say with 100% accuracy that none of the computers are behind a VoIP phone, but many of them are not.
Port config follows:
switchport access vlan XX
switchport mode access
switchport voice vlan XXX
no logging event link-status
power inline auto max 7700
srr-queue bandwidth share 10 10 60 20
authentication event server dead action reinitialize vlan XX
authentication event server dead action authorize voice
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication timer reauthenticate server
no snmp trap link-status
mls qos cos 2
mls qos trust cos
dot1x pae authenticator
dot1x timeout server-timeout 30
dot1x timeout tx-period 10
dot1x max-req 3
dot1x max-reauth-req 3
spanning-tree bpduguard enable
03-14-2016 06:13 PM
At the time of the failure, in the event logs I looked into, there was not anything too exciting. The Netbios went down then up, the McAfee service started up, and it pulled GPO. Nothing too special unfortunately.