Security

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?

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?

 

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!

What type of switches are you using ?
Is this happening on the same switch ?
Can you share your Interface config ?
Are these devices behind a VoIP Phone ?

Hello Victor-

 

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

queue-set 2

priority-queue out

authentication event server dead action reinitialize vlan XX

authentication event server dead action authorize voice

authentication host-mode multi-auth

authentication open

authentication order dot1x mab

authentication priority dot1x mab

authentication port-control auto

authentication periodic

authentication timer reauthenticate server

mab

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 portfast

spanning-tree bpduguard enable

 

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.

Are you doing posturing at all?

 

No, we are not doing any posturing at all.