802.1x failure due to 'catch-22' scenario

[jitendrac]

We are deploying 802.1x for our customers. We are using EAP-TTLS with PAP at the Windows native supplicant level.

The help desk team has created a GPO to push 802.1x wired and Wi-Fi profiles at the computer level. 

When a new user logs in to a machine connected to an 802.1x-enabled switch port or SSID, user authentication does not happen because 802.1x wired and Wi-Fi profiles are not pushed via GPO. This happens because ISE blocks the network access due to missing 802.1x setting at the supplicant, creating a 'catch-22' scenario. We urgently need a solution or workaround for this. Should we advise customers to set up a staging network (without 802.1x at the switch port) where the machine has AD reachability so that users can get the 802.1x wired and Wi-Fi profiles pushed in their profile.?

Can we ask customer to open ticket with MS for any workaround?

[Arne Bier]

I am not aware of any clever tricks you can plan in ISE to allow that onboarding to happen on-prem in the organisation. I guess the challenge is for ISE to understand that the user's machine is in a valid "non-compliant" state and then allow them to finish the onboarding on a safe way.

The pragmatic solution in most cases is to prep/stage the devices before handing them over to the end user.

The work-from-home scenario would be easier, since the user will connect to their home internet and then you can use an MDM solution to push all the required config. In the work place, users could "hotspot" themselves temporarily - but that is not an elegant soution. I would not recommend setting up a PSK SSID just for internet - you might be able to get them to use the guest portal (if you have one) - but I have seen issues with the onboarding process in Microsoft Autopilot where the web portal can present challenges. 

[Greg Gibbs]

This is a very old (but relevant) problem with the build process not implementing any sort of 802.1x capability. MS has never been interested in fixing this. See this old discussion on this issue with some suggested options to investigate.

https://community.cisco.com/t5/network-access-control/pc-imaging-on-nac-secured-ports/td-p/3486098

There have also been various API enhancements since that discussion, so you could look at coding API calls into the build process to 'Allow List' the endpoint until the build process and User GPO push are completed.

[jitendrac]

Can I create a separate policy set for MAB like the one below as a workaround, relying on your expertise?

Perform MAB-based authentication for that machine where the IEEE 802.1X profile is not configured via GPO. (There will be a manual process where the help desk team can provide the MAC address to the ISE Admin and the ISE Admin can create a temporary Endpoint Device Group in ISE and populate with all such MACs where 802.1X profile is required to push from AD)

Once MAB authentication is successful, the machine will be reachable to AD, and the 802.1X profile will be loaded in a user profile. 

We will use the 802.1x method next time users log in. Since 802.1x has a higher priority, it will not perform MAB again or remove the MAC from the EDG.

will this workaround be workable?

[Arne Bier]

it's not possible to do MAB on wifi on an 802.1X enabled SSID, because 802.1X is the only authentication method that the wireless LAN will accept for associating to that SSID.

On wired it could be possible - however, how will you know whether you are dealing with a genuine/valid catch22 endpoint? You'd have to either create an AuthZ Policy that looks up the Ethernet MAC address in an Endpoint Identity Group - and someone has to populate that Group with Ethernet MAC addresses of new devices. What access would you grant that session?  Ony enough to talk to AD or whatever, to finish the job of onboarding?  And once that is done, you will have to clean up and remove those MAC addresses.  it's a very operational process

[jitendrac]

Hi Arne,

I just wanted to ask you why you are saying it's not possible to do MAB on wifi on an 802.1X-enabled SSID.
We checked with ARISTA, and as per the below document (Use Case 3: Onboard Clients Using MAC Authentication) it is possible MAB on WiFi 
https://wifihelp.arista.com/post/integration-with-cisco-ise-wireless-802-1x-and-mba-use-cases/?pdf=1732

[Arne Bier]

On an Enterprise SSID protected by EAP, 802.1X must succeed for the client to associate. There is no MAB fallback as is possible on wired LAN.
Of course you can do MAB on an Open SSID. But that is not 802.1X

[jitendrac]

Ok I got can we then publish 2 SSID (One with 802.1X enabled and the other as an open SSID that will have MAC-based authentication from ISE) ?

[Arne Bier · Accepted solution]

That's right - you can offer an alternative SSID for users to connect - whether that is an open SSID with MAB or a Guest Portal with some other form of authentication (registering for access). The MAB approach might be the best one if you want to make this as smooth as possible - and then after the user's issue has been resolved, then remove their MAC address from ISE, which will ensure that they cannot connect on that SSID again.