MacOS Wired .1X Silence

[nplusplus]

Good Day, Community,

I am an ISE operator, and I have been tasked with resolving the issue of Apple Macs occasionally failing to respond to EAP-Request frames and frequently failing to send EAPOL-Start frames upon link-up in a wired 802.1X environment using EAP-TLS.  Now, I think we can all agree that Apple really should be the entity resolving this, but nevertheless, I have been asked to come up with something. (Please pardon me if you recognize a little disdain in my tone.)

As such, and as part of my noodling about potential resolutions for this beyond training the desktop team or user to reseat the cable every time MacOS fails to authenticate properly, I started looking for potential solutions that might allow me to trigger CoA on a limited basis of some sort.  Is anyone aware of any sort of authorization flow in ISE that might allow me to easily bounce the port of an impacted MacOS endpoint to attempt to trigger EAP-Request responses or EAPOL-Start transmissions without causing an endpoint to get stuck in a CoA loop of sorts?  I think what I am imagining is some way to affect a profiling policy or authorization result that would drop an endpoint into an identity group for up to, like, three CoA cycles before just failing it outright for manual intervention.

To date, the only things that have improved the situation have been extending the .1X retry timeout to beyond 45 seconds and extending the reauthentication timeout to the max.  Even then, it is only an improvement, and attempting to maintain user-experience in this case is a requirement.

Actually, if anyone else has been successful dealing with or improving this at all, I would love to hear about it.

Thank you,

Nathan

[Christopher_Starcher]

Actually, I've been through this from the perspective of getting macOS devices added to the domain and authenticating via ISE/AD.  But, that sounds like a different scenario than yours.  If you go that route, I can probably offer some advice.  But, if you're sticking to EAP-TLS, I'll probably follow you're lead since I'll be converting my scenario to yours over the summer...

[nplusplus · Accepted solution]

So, this turned out to be a problem with Filevault.  Prior to disk decryption, Macs do not have access to locally configured profile information, so they cannot participate in EAP-TLS for wired 802.1X.  As such, it really comes down to timing.  If a user connects to Ethernet and logs in immediately, if you have default authentication timers configured on your switchports, Filevault decryption may occur quickly enough to allow the Mac to respond before the final switch retry.  Most of the time though, this does not appear to be the case.

I messed around with a couple of timing settings, but nothing could really accomplish what I wanted because it was always dependent on when the user elected to login after connecting to Ethernet.  You know, they may connect to the dock then walk off to grab a cup of coffee.

What I finally landed on was a MAB policy that matched on an "Apple-Device" endpoint profile condition to pass in a 60-second reauthentication timer authorization result to cause the attached switchport to attempt to reauthenticate the attached device every 60 seconds.  This has worked well so far.  I guess now we'll just have to see if there are any scaling problems as we expand our wired .1X footprint.

Thank you,

Nathan

(Also, BTW, this post is essentially redundant to an earlier one I created: https://community.cisco.com/t5/network-access-control/macbook-802-1x-initialization-delay/m-p/4943239/highlight/true#M584693 )