ODBC Support for two parameters to fetch attributes

[junk1]

Hi all,

In my customer network we are rolling out DNAC with ISE (image version 1.1.6 and 2.3P2 respectively). Customer has more than 4000 projects with multiple ODCs under each project. As the scale limit of number of AuthZ policies are less than 600, we chose to have an external ODBC to authorise endpoints with SGT and VLAN. So this solves the scale limit issue with just one policy as shown below:

if EapChainingResult EQUALS User-AND-Machine-Both-Passed, then SQL:SGT & SQL:VLAN.

So that, the SGT and VLAN parameters are fetched from the SQL ODBC. We are using Microsoft SQL 2016 as the external ODBC.

This works when attributes are fetched using single parameter, which is the userid.

For some specific types of ODC users (S2S), they need location stickiness. In other words, the ODC1-user from location-1 should get access to ODC1 destinations, whereas when the same user access from location-2 then he should general-access only and not to ODC1 destinations.

This could be achieved by below AuthZ Policy:

if EapChainingResult EQUALS User-AND-Machine-Both-Passed,

AND

if location-id EQUALS SQL:Loc1

then

SQL:SGT & SQL:VLAN.

But this would increase the no. of AuthZ policies and we need to configure so many AuthZ policies per location per ODC.

I realised currently ISE can't query the ODBC with a logic of "if (userid + locationid) = matches, then fetch SGT & VLAN attributes".

Is there a way to address this requirement? Because with location stickiness, we still would end up crossing the scale limit of 600 AuthZ policies.

Note: Upgrade to 2.4 is not an option currently!

Thanks and Regards

V Vinodh.

[hslai]

My suggestion is to make SGT and VLAN assignments agnostic to locations.

For Cisco IOS platforms, VLAN can be a VLAN name or VLAN group name, besides a numeric VLAN number. An SGT may have different permissions to different destinations in different locations and ISE 2.2 allows multiple matrices.

[Craig Hyps · Accepted solution]

Vinodh,

We have discussed this design at length in past and design options provided.  As reviewed, some attributes can be dynamically assigned based on response from local or external ID store attributes, but the more advanced case requested will require some enhancements.  Please continue to work with PM team to help prioritize the requested functionality.

Craig