WLC MAB with 802.1x Authentication

[CA_HA]

Hello,

I'm trying to setup a Cisco WLC attached to an ISE server to complete the following:

- 802.1x authentication for devices that support 802.1x,

- MAB for legacy devices that don't support 802.1x.

The ISE is authenticating users with 802.1x, however I cannot get the MAB working. I can see the rule getting hits, however the devices do not connect to the wireless SSID. The device just hangs and sits trying to connect until it eventually fails. I don't get a reason showing in the logs however.

[Jason Kunst · Accepted solution]

I assume you have 2 separate SSIDs? 1 for dot1x and 1 for OPEN (MAB)

There should be a built in basic authenticated access. Did you use that rule? It will allow them through.

You can use the guest deployment guide to get some examples (removing redirection to portals and other aspects) on how MAB rules work.

https://community.cisco.com/t5/security-documents/ise-guest-access-prescriptive-deployment-guide/ta-p/3640475

https://community.cisco.com/t5/security-documents/ise-training/ta-p/3619944

[CA_HA]

Thank you for your reply Jason.

I've setup an additional SSID to test the MAB with. Is it possible to have an SSID setup with both to do MAB and dot1x authentication?

I'm using this default rule and can see the rule getting hits so I know that rule is working.

I will take a look at the guides now, thank you for attaching them.

[CA_HA]

Thank you for your reply Jason.

I've setup an additional SSID to test the MAB with. Is it possible to have an SSID setup with both to do MAB and dot1x authentication?

I'm using this default rule and can see the rule getting hits so I know that rule is working.

I will take a look at the guides now, thank you for attaching them.

[Arne Bier · Accepted solution]

Nope - at least not on a Cisco WLC.  The Cisco WLC with 802.1X enabled will always send EAP frames to ISE because the WLC does not have a fallback to MAB auth (like a Cisco switch does). The client has to be configured with a supplicant in order to get any attention from the SSID configured with 802.1X.   It's not technically possible to associate to an 802.1X SSID if you're not using a supplicant.

In the wired world this is different.  Client can have no supplicant, but because it causes a link-up on a switch, it can pass frames to the switch port for analysis. This is the key deifference.  On a Cisco switch you can specify that 802.1X is tried first, and if Radius does not respond positively, then try MAB next, and failing that, chuck the user in a guest VLAN.

[CA_HA]

Thanks Arne.

I was under the impression that it would still follow the Authorisation rules (Hit MAB first and the if there are no authenticated MAC's go to 802.1X). However, it sounds like this isn't the case?

I've managed to get the MAB working on a separate SSID - I assume this is how it will have to be? One SSID for MAB and one SSID for 802.1X?

[Arne Bier]

Hi @CA_HA

I can only speak about how the Cisco WLC works, since that is the one I understand the best.  The problem is that the WLC WLAN has to be set to be of a certain type/mode.  You cannot configure the WLAN profile to be MAB & 802.1X.   And when the WLAN is configured as 802.1X then it will only authenticate the client session if, and only if, the Radius server returns an EAP Success in the final Radius Access-Accept EAP payload.  If it doesn't, then the client session remains in 802.1X_REQD state, waiting for a miracle to happen.  So let's assume you have a wireless client that does not have a supplicant configuration.  In most cases it won't be able to even attempt to connect to the 802.1X SSID.  Windows 10 for example will try PEAP by default, but that is not MAC auth either.  The comms will break down due to things like TLS establishment failures etc.  You can't short circuit an EAP conversation. 

In wired world there is no requirement to have a supplicant in order to send an Ethernet frame to a switch port.  The switch (configured primarily for 802.1X will wait patiently for an EAPOL message, and also send EAPOL START frames - depending on your timers (say 30 seconds) this song and dance will lead nowhere and the switch will eventually give up.  And if you configured MAB as the next auth method, then the switch will pass on your Ethernet frame to the AAA for MAC authentication.  This concept does not work in the wireless domain because OSI Layer 1 and 2 work differently.

Having two SSIDs would do the trick - you can try cool stuff like Identity PSK on Cisco controllers where each wireless client can potentially have different pre-shared key depending on their MAC address.

[mishadib]

Is it possible to have MAB on a PSK secured SSID? I guess that is the same issue. When the supplicant asks to  join an SSID he gets bounced back if he doesn't show the PSK right? 

[BrianPersaud]

Hi I have a question for the two SSID's.  For the MAB (open) SSID, are there any security risks that I should be aware of?  I know it is going to be broadcasting as an open SSID but the ACL's are done on the WLC with ISE pointing to them.

Thanks 

[Arne Bier]

MAB authentication can be spoofed. That’s the security risk.

Your WLC should ensure that the ACL only allows a MAB client access to the allowed subjects. You would never use MAB to grant employee access. MAB used for guest redirection, and for devices that don’t have a supplicant and iPSK (on WLC). 
Think of MAB as “identifying the client by MAC address”. 

[BrianPersaud]

Thanks that's what I was thinking.  I am presently testing with iPSK and ISE.  It is mainly for IoT devices.  So far the tests have been successful.

[Jason Kunst]

---

@BrianPersaud wrote:

Thanks that's what I was thinking.  I am presently testing with iPSK and ISE.  It is mainly for IoT devices.  So far the tests have been successful.

---

nice, check out the iPSK manage on this page cs.co/ise-byod

[BrianPersaud]

Fantastic Guide thanks