Guest access and randomized MAC addresses

With randomized MAC addresses becoming more of the norm for mobile devices, it’s time to think about how you handle guest access. The main configuration I’ve seen is authenticating the connection, adding the MAC address to GuestEndpoints, and then allowing future authentications for X amount of days based on that MAC address. Obviously, that’s about to change.

Note: I will get this out of the way. I do NOT recommend suggesting to the guest user they disable MAC address randomization on their personal device. Teaching end users a way to reduce their privacy is a bad practice.

Currently, ISE doesn’t have a way to utilize something like Passpoint for seamlessly authenticating guest users. BYOD Onboarding? Way too much overkill for simple guest access.

Don’t utilize automatic reauthentication, requiring guests to go through the hotspot portal upon every reconnection? The steps below may help with other configurations you run but definitely not needed for short term guests that must accept an AUP on every connection.

I’m a fan of having an open wireless network for guests to connect to without a portal. The only exception is if you want to force registration of guests. Otherwise, if you absolutely, positively need to run a hotspot portal (maybe you want to display an ad?), here is a suggestion for a temporary workaround.

Portal notifying the user

I’m going to configure two different guest portals. One will be for devices that are detected to be using a randomized MAC address and the other for devices not detected to be using a randomized MAC address. The set up is the same as any other guest hotspot. The only difference is the wording I’m presenting.

On the randomized guest hotspot page (Hotspot – RanMAC), I’m letting them know that they may be presented with the AUP again if they disconnect and reconnect to the guest network.

The hotspot portal for devices not detected as using a randomized MAC address (Hotspot – NonRanMAC) is a simple page without the warning.

The main reason for the randomized MAC address portal is so that the guest is aware it could be a different experience than what they are used to (ie automatic reconnection and access during the same day).

Authorization results and policies

I will configure two different authorization policies and results. This is so the correct hotspot is presented depending on the if an endpoint MAC address is believed to be randomized or not.

The first authorization result will be for the randomized MAC address. The settings are to assign the Hotspot – RanMAC portal along with a redirect ACL that is configured on the WLC. The redirect ACL, named Redirect_ACL (pretty original), allows access to DHCP, DNS, and the ISE node (172.16.100.21) ports. TCP/8443 is the default guest portal port. TCP ports 8905 and 8084 are for posture assessment so I can utilize the same ACL (posturing not configured in this example).

The second authorization profile is for devices that are not detected as using a randomized MAC address. The same redirect ACL is used but a different portal, Hotspot – NonRanMAC, is assigned.

Now the authentication and authorization policies can be configured. The policy set has a single condition that looks for the RADIUS called-station-id containing the SSID (SecDemo-Hotspot). The allowed protocols list, under Policy > Policy Elements > Results > Authentication > Allowed Protocols, is configured for MAB only by enabling Authentication Bypass > Process Host Lookup in a new allowed protocols service called MAB_Only. The authentication policy is configured to only utilize Internal Endpoints with the option If User not found set to Continue.

The authorization policies are configured with the two portal results and the authenticated guest rule. The first rule has a condition looking at the GuestEndpoints identity group. If the MAC address exists there, permit access to the guest network. The second rule is analyzing the RADIUS calling-station-id (the endpoint’s MAC address) to see if the second character is a 2, 6, A, or E using the regular expression ^.[26AEae].*. If that is the case, the result will be the hotspot for endpoints using randomized MAC addresses. The default rule is the standard, non-randomized MAC address hotspot portal.

I tested connecting to the hotspot using my phone running Android 10. The first connection is using the default configuration for connecting to new wireless networks which is randomize the MAC address.

The endpoint ID shows a MAC address of AA:04:27:78:59:2F is being used by my phone. That triggers the second authorization rule (SecDemo Random MAC) to be matched. The authorization result Hotspot_RanMAC is assigned. I am able to click through the AUP and gain access to the guest network. Note that the randomized MAC address is added to the GuestEndpoints database. If I disconnect, reconnect, and the same random MAC is still assigned by my phone, I will hit the first rule and gain access to the guest network.

Now, I test by changing the SSID setting on my phone to use the hardware MAC address.

The endpoint ID now shows the phone MAC address as being C0:EE:F8:D0:FC:8B. This is not in the GuestEndpoints database nor does it trigger the randomized MAC address check in rule 2 so the default rule is matched. The default rule returns the Hotspot_NonRanMAC authorization result.

This is just one way to deal with the randomized MAC address setting we are starting to see more and more with Android and iOS devices. The obvious next question is “What about profiling?”. My thought on that is: Is profiling guest endpoints really that important? We will gather profile information from the device hitting the portal itself even if the MAC is randomized. Without that, profile data is rarely used when it comes to authenticating or authorizing a guest endpoint so I’m not sure how lack of profiling data for guest endpoints is really an issue that needs to be solved. Drop a comment below if you have other ideas around that.

One more note: Configure your endpoint purge rules! This is for anything but especially guest endpoints. Don’t let guest endpoints just pile up. If you have a rule to allow guest access for 1 day, configure a purge rule to delete any device in GuestEndpoints with an inactive time of zero days. Why zero? Because if they just started connecting today, they will have no inactive time. Adjust according to your business requirements.