Location, location, location: Segmenting FlexConnect Authentications in ISE Without Overriding WLC Central-Auth

One of the foundational steps when configuring your Network Access Devices (NADs) in ISE is adding the NADs to relevant Network Device Groups (NDGs); NDGs allow you to create a descriptive and hierarchical attribute tree which you can apply to your NADs in order to streamline context visibility, reporting, Policy Set/rule match conditions, or simply help apply a meaningful label beyond the device name.

One of the most commonly used NDG types is Device:Location, which allows you to tie the NAD and its associated AAA transactions to any logical or physical location you deem appropriate; "LAB-Floor2Rack3" or "Boston, MA", for example. NAD location provides a handy label you can then use to differentiate AAA requests coming into ISE from NADs associated with that location; perhaps you want to apply a different policy set to wireless authentication requests coming from London vs those coming in from Singapore, or even split out authentication from one location vs another to different Identity Source Sequences within a single Policy Set - there are many options available to you.

What happens, though, when you are using ISE to authenticate wireless endpoints which are connecting to Cisco APs in FlexConnect mode? FlexConnect is a common Cisco Wireless deployment method which allows the access points to function somewhat autonomously (think HREAP) in that the AP, not the WLC, is responsible for some functions of the control plane such as applying 802.1q tags and applying session ACLs. This requires a bit of extra configuration on the WLC as opposed to Local Mode (where the WLC does everything), but it reduces processing overhead on the WLC and allows the APs to switch traffic locally, which is useful particularly for decentralized deployments where you may have a single WLC (or an HA pair) sitting in a datacenter controlling APs across many branch offices in disparate geographies.

By default, the FlexConnect APs do not act as NADs unless the WLC becomes unreachable, in which case they (if configured) will begin sourcing RADIUS access-requests from themselves using their management IP as the source interface. This means that if you have a series of branch offices across the globe being served by FlexConnect APs that are controlled by a single logical WLC, the WLC is the only NAD ISE will interact with under normal operating conditions; as such, you cannot use your "Location" NDG on a per-AP-basis to engineer your AAA policies. Bummer!

So, if I want to use something like AP location to enforce different AAA policy results, why not just change the WLAN to use FlexConnect Local Auth? This option enables the AP to ignore the WLC's presence and always (with some exceptions) send RADIUS access-requests directly to the ISE server from their own interfaces. Sounds like this fixes the problem!

This is one of those "one step forward, two steps back" scenarios. While the Flex APs can act as the RADIUS Authenticator (NAD) via this configuration, this introduces a few caveats; namely, device-sensor (ISE NAC) and client profiling are forced to be disabled on the WLAN in order to get this to work. CWA redirection to ISE for something like a Guest or BYOD flow is also no longer supported. Not ideal. We need a different way to identify these AP locations based on information ISE will be able to see during the authentication request so we can get the best of both worlds and not have to disable a powerful and useful feature like endpoint profiling and CWA.

We need some help from the IETF.

If we take a look at Section 5 (Attributes) of the RADIUS RFC document, we can see a number of attributes at our disposal; of those listed, two are of particular interest:

30: Called-Station-Id
32: NAS-Identifier

A Cisco WLC will, by default, construct the Called-Station-Id attribute out of the associated AP's MAC address and the SSID name in one string separated by a colon. Additionally, the NAS-Identifier (an attribute of the AP group) will be set to "none" and the WLC will substitute its own hostname for this field when constructing the RADIUS Access-Request. If we look at the ISE Livelog details for an authentication we can see both of these fields available in the Access-Request, which is important since ISE can only act on the attributes it can see - that is, you cannot create things like Policy Set match conditions (which occur before authentication has completed) based on RADIUS attributes which would only be present during or after authorization, such as Session:PostureStatus.

Now that we know we can see these attributes, lets go about configuring them to meet our needs for defining the authentications source's location.

Starting with the NAS-Identifier field, we can edit this as part of the AP Group config under WLANs > Advanced > AP Groups and clicking on our desired AP Group name:

From here we can set our NAS-Identifier field to whatever we want - Boston, MA in this example:

While we're here, lets also check out the Called-Station-Id attribute. Under Security > AAA > RADIUS > Authentication, note the default setting of AP MAC Address:SSID, which we saw reflected in our Authentication log earlier. Drop this menu down and you can see we have a myriad of options available:

While we could choose any of these options, choosing one which includes the SSID will likely prove valuable since that is a commonly leveraged attribute for authorization rules to differentiate between SSIDs within a given Policy Set (RADIUS:Called-Station-ID CONTAINS/ENDS WITH <ssidName>). Let's change this to AP MAC:SSID:AP Group:

Now, lets take a look at a successful authentication once more, and we can see our updated attributes are showing up as expected:

Nice! Now use either or both of these attributes in our Policy Sets or authentication/authorization rules to identify traffic we wish to differentiate:

And of course, always test and verify the correct rule(s) are being hit and traffic is being handled as desired. We can see here that we're hitting the correct policy set and authorization rule based on the attributes added:

Of course, you can get as granular with this concept as you like; creating compound custom dictionary conditions per site, adding these attributes to other flows for things like posture or TC-NAC, etc.

At the end of the day, it is often best to step back and look at the tools available when trying to solve for a given scenario - while setting the Flex APs to be the RADIUS auth source will work, it comes with a set of caveats which limit visibility and introduces an authentication topology change, requiring the addition of all of your FlexAPs to ISE as NADs at a minimum, along with considerations for additional overhead, Flex site latency, etc.

Using what we already have available to us allows us to achieve the desired business outcome while making minimal changes to the infrastructure, helping ensure consistency and adding as little technical debt as possible to the overall solution.