cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
533
Views
4
Helpful
11
Replies

Authorization policies scalability and best practice

thomas.mason1
Level 1
Level 1

Hello all,

on a new environment we are implementing NAC with Cisco ISE 3.2

We will manage 802.1x and MAB access for different companies belonging to the same groups.

I would like to focus on authorization policies managing MAB access and the best practice on creating them on large scale.

Each company has the same vlans (assigned to specific segment of the network, printers, voip ecc) that will be assigned dynamically depending on the endpoint group the endpoint belongs to.

We wil have policies of this kind

(endpoint belongs to endpoint group "X-company Y") && (device location equals company Y) -> assign vlan 10

If i manage all wired mab flows in a unique policy set I would reach like 800 authorization rules but I've seen from here https://www.cisco.com/c/en/us/td/docs/security/ise/performance_and_scalability/b_ise_perf_and_scale.html that the critical threshold is 600.

I could create a different structure using OR condition like the following

((endpoint belongs to endpoint group "X-company W") && (device location equals company W)) ||
((endpoint belongs to endpoint group "X-company E") && (device location equals company E)) ||

((endpoint belongs to endpoint group "X-company R") && (device location equals company R))  -> assign vlan 10

In each OR condition I would have around 60/70 different condition and I'd expect to have the same performance result, if not worse, than the first scenario.

Is creating different policy sets per location the best choice in my scenario? In that case I would have around 60/70 policy sets with aroud 15 authorization policies each.

Thanks

 

1 Accepted Solution

Accepted Solutions

OK, I was suspecting the Company x EndpointGroup permutations but wanted to confirm.

My recommendation is to use Endpoint Custom Attributes or an external CMDB for mapping all MAB endpoints to their assigned VLAN since Location and EndpointGroup are not dynamically assigned based on the network but rather organizational attributes assigned statically to the asset/endpoint.  My goal is to take the static Company X EndpointGroup = VLAN mapping out of your policy entirely.

There are a couple of ways to implement this depending on your endpoint/asset management process. You said you are currently assigning endpoints by MAC into Endpoint Identity Groups. I would instead recommend using Endpoint Custom Attributes to assign their Company, EndpointType (to differentiate from EndpointGroup) and VLAN (!!) using attributes. You may add as many additional attributes as you like to help you track and manage each endpoint and you may keep them in their existing Endpoint Identity Groups for now.

Screenshot 2024-06-14 at 9.15.58 AM.png

Next, create a single ISE Authorization Profile which I called Custom_Attribute_VLAN to assign whatever VLAN you put in each endpoint's VLAN custom attribute (EndPoints:VLAN). You must do this using the Advanced Attributes Settings because you cannot assign a value from an ISE dictionary using the Common Tasks VLAN option.

Screenshot 2024-06-14 at 9.22.24 AM.png

Finally, create/update your MAB/IOT policy set with a single, simple Authorization Rule that will assingn the VLAN name/number in the VLAN attribute but ignore any endpoint that does not have the VLAN custom attribute assigned.

image.png

For thoroughness, context, and complexity comparison, here is my full IOT Policy Set. I only show a single permutation using your company/location and IdentityGroup but you can clearly see how complex even a single rule is compared to the Endpoints:VLAN option. I also implemented your Company X EndpointGroup as custom attributes to show how your existing model could be implemented (innefficiently) using custom attributes.

Screenshot 2024-06-14 at 09-49-19 Identity Services Engine.png

Updating ISE Endpoint Custom Attributes either by the ISE GUI under Context Visibility > Endpoints or via REST API can be tedious and may place an unnecessary burden on you as the ISE admin. I highly recommend pushing this VLAN registration/maintenance into an external database and process such as a Configuration Management Database (CMDB) that you may import and synchronize into ISE using a pxGrid Direct Connector in ISE 3.2 and later.

Please watch my ISE Webinars archived to our ISE YouTube Channel on ▷ User & Endpoint Custom Attributes and ▷ ISE pxGrid Direct with CMDBs for a more thorough discussion with more examples.

View solution in original post

11 Replies 11

Cisco ISE is not designed for multi-tenancy.  I would suggest multiple ISE deployments for your use-case.  

We are not really in a multi-tenancy scenario. We have same AD and all companies use same services published by the groups.

The only limit I have is that endpoints of one company (MAC belonging to company specific segment group) can't access network in other companies, so I need to create conditions matching both location and endpoint group membership.

I would argue that this statement "endpoint of one company can't access the network of another company" is 100% a multi-tenancy deployment; which ISE has zero concept of and is not designed for.  IMHO the only scalable solution and most secure solution here is multiple ISE deployments.  

davidgfriedman
Level 1
Level 1

If you could ignore the location / site identifier, would most of your policies have a small number of conditions in common?  If so, I would recommend a two step process:

1. Try adding device groups to each NAD to group similar sites together, perhaps reducing you to a few location "regions", "countries", etc.
2. Make the vlan "abstract" by sending a name which the switch or AP translates to a site specific VLAN. For example, send a string for wired using the text "VLAN NAME" associated with your VLAN ID, or a switch (cisco) vlan group name for the vlan.
3. If you have multiple clients, you could specify their 802.1x policy "top" entry condition requires a specific issuer. But we don't use that here.

That helps us group things better here, and allow more variance at different "sub" site types, but use fewer rules in each policy set.

Regards,
-David

I can't ignore location because I need to discriminate on which site the endpoint is accessing (endpoint of one company can't access the network of another company..).

802.1x is present but it's already managed.

Vlan ID is not the real issue because we decided them in order to have the same value for different segments in all different sites (printers has always X, voip has always Y, ecc)

To not overcome some "hardware" threshold I could group some location and then create their specific authorization rules in order to not overload ISE with both too many policy sets and/or authorization rules.

Regards,

Thomas

thomas
Cisco Employee
Cisco Employee

First, since you want to focus on MAB as a scenario I recommend using a "MAB" or "IOT" Policy Set regardless of Company or Location and we'll work on the authorization rule optimization. That's the easy part.

Second issue is VLAN numbering. You say "Each company has the same vlans ... depending on the endpoint group". Excellent, but it looks like you are doing numbered VLANs instead of named VLANs. Using named VLANs would make your authorization profiles much easier because the Printer VLAN is named "Printer" everywhere regardless of the local VLAN implementation. 

So if the endpoint group is really the determining factor or authorization by VLAN, why not only use that for determining the VLAN assignment? I honestly do not understand what difference the location makes in your policy unless you are trying to prevent endpoints moving from location to location. If so, you could potentially handle that with an ISE Authorization Policy Local Exception.

I also read "endpoints of one company can't access network in other companies" which is confusing because I thought a printer is a printer, regardless of the company that owns it or the location it is connected. So are you saying you have unique VLANs for every single Company X EndpointGroup?! That's a lot of VLAN permutations!

If this Company X EndpointGroup permutation is really what's going on, I think you are better off doing static VLAN assignment based on an Endpoint Custom Attribute either in ISE or from an external database (fetched via pxGrid Direct). I can show some screenshots and potentially give webinar recommendations but we need to better understand how you want to assign authorization profiles (that just happen to be VLANs).

Vlan name - ID pair is the same on all location (printers has always id 12, pc has always id 13 ecc).

Per policy I can't permit that the printer, or any other object authenticated via MAB, of one company can access the network of another company; making an example, printer assigned to site A if moved to site B shouldn't be able to access the network.

This rule above creates a lot of single Company x EndpointGroup possible permutation that brings the need for the number of authorization policies I indicated in the first message of this post.

Without the limit on the location where the endpoint is connecting to I would have one authorization rule per vlan.

It really sounds to me like you are trying to use ISE as a firewall. What is the segmentation strategy from a routing standpoint? Or firewalls?

OK, I was suspecting the Company x EndpointGroup permutations but wanted to confirm.

My recommendation is to use Endpoint Custom Attributes or an external CMDB for mapping all MAB endpoints to their assigned VLAN since Location and EndpointGroup are not dynamically assigned based on the network but rather organizational attributes assigned statically to the asset/endpoint.  My goal is to take the static Company X EndpointGroup = VLAN mapping out of your policy entirely.

There are a couple of ways to implement this depending on your endpoint/asset management process. You said you are currently assigning endpoints by MAC into Endpoint Identity Groups. I would instead recommend using Endpoint Custom Attributes to assign their Company, EndpointType (to differentiate from EndpointGroup) and VLAN (!!) using attributes. You may add as many additional attributes as you like to help you track and manage each endpoint and you may keep them in their existing Endpoint Identity Groups for now.

Screenshot 2024-06-14 at 9.15.58 AM.png

Next, create a single ISE Authorization Profile which I called Custom_Attribute_VLAN to assign whatever VLAN you put in each endpoint's VLAN custom attribute (EndPoints:VLAN). You must do this using the Advanced Attributes Settings because you cannot assign a value from an ISE dictionary using the Common Tasks VLAN option.

Screenshot 2024-06-14 at 9.22.24 AM.png

Finally, create/update your MAB/IOT policy set with a single, simple Authorization Rule that will assingn the VLAN name/number in the VLAN attribute but ignore any endpoint that does not have the VLAN custom attribute assigned.

image.png

For thoroughness, context, and complexity comparison, here is my full IOT Policy Set. I only show a single permutation using your company/location and IdentityGroup but you can clearly see how complex even a single rule is compared to the Endpoints:VLAN option. I also implemented your Company X EndpointGroup as custom attributes to show how your existing model could be implemented (innefficiently) using custom attributes.

Screenshot 2024-06-14 at 09-49-19 Identity Services Engine.png

Updating ISE Endpoint Custom Attributes either by the ISE GUI under Context Visibility > Endpoints or via REST API can be tedious and may place an unnecessary burden on you as the ISE admin. I highly recommend pushing this VLAN registration/maintenance into an external database and process such as a Configuration Management Database (CMDB) that you may import and synchronize into ISE using a pxGrid Direct Connector in ISE 3.2 and later.

Please watch my ISE Webinars archived to our ISE YouTube Channel on ▷ User & Endpoint Custom Attributes and ▷ ISE pxGrid Direct with CMDBs for a more thorough discussion with more examples.

Thanks for your suggestion and clear explanation.

In order to mantain also the check on the company/location my endpoint is connecting to can I proceed as in the following?

thomasmason1_0-1718464832741.png

Locations assigned to NAD and endpoints:company custom attributes are taken from the same list.

Yes, that should work if the Endpoint:Company attributes matches the network device's Location NDG. That's a good extra check to ensure the endpoint has not moved if that is one of your policy goals.