Is it possible to have dynamic DACL based on network subnet?

[Stefan90]

Hello Everyone,

Question for NAC and MAB.

Scenario is following. 

I have enabled device profiling on ISE and successfully mapped all end point devices that are connected on one switch.

What is in place already is Profiler Policy that match MAC:OUI from Endpoint Classification, Policy elements Results for Authorization profile and DACL.

Then i configured policy set where i included Condition for all device types that i earlier added to network devices with specific profile.

Authorization Policy is simple it allow default network access from internal Endpoints

Authorization Policy is Condition (OUI of vendor identified by enabled profiling) and Wired_MAB then Name of the profile that include DACL and allow access.

That DACL is specific to one network device and i can apply it only to one switch because of the subnet 3rd octet will always be different for other switches and DACL as well, and am wondering how to apply same policy set to let say 100+ switches, i think it would be stupid to create policy set for each device because same DACL cannot be applied to all switches and same endpoint device(Same vendor OUI:MAC) is connected to multiple switches.. 

example 

permit ip any host 10.10.xx.1

permit ip any host 10.10.xx.2

permit ip any host 10.10.xx.3

permit ip any host 10.10.xx.4

permit ip any host 10.10.xx.5

deny ip any any

Am sure i might confuse because am not that good explaining things but am sure some one faced same challenge when doing NAC and MAB.

[Mohammed al Baqari]

Why don't you create a wildcard such as 10.10.0.1 0.0.255.0 instead of host
acl

[Stefan90]

Yes that could be the solution, but the environment does not allow such wide scope to be used, it has to be per host.

[Mohammed al Baqari]

There is no other way of doing this in as far as I know

[Mike.Cifelli]

It may be easier for you to manage your situation by just creating several authorization results with different unique dacls for each use case. Basically would look like this:
Use local ISE identity groups to map them to their vlan. Then each result has a different dacl for whatever you require them to have access to.

[ldanny · Accepted solution]

You can use "Network Conditions" in your Authorization Policy.

See the following under

Policy > Policy Elements > Conditions > Network Conditions

[Stefan90]

Thanks for replays guys, i will check this tomorrow and see probably will come up with more results as what i did.

[Damien Miller]

By no means a quick fix to the issue you are facing due to the design work, but this is one of the use cases of TrustSec. By departing from the traditional acl method of using source/destination ip's, you instead use only Sgt's.

Your protected assets could be given ip to sgt mappings, manually or via ise if they authenticate. Any authenticating endpoint that you decide doesn't meet the security requirements is given a different sgt. You write policy for sgt to sgt traffic just like acls, only the ip doesn't matter. 

[Stefan90]

Thanks for the suggestion, to be honest i have not used TrustSec and i don't know how can be used. But already got some material that i will research to understand more and its functions. So far the Network condition seems like it did the trick with what i wanted to achieve

[Stefan90]

Another scenario that am thinking of, could be possible to manipulate with Result>Authorization Profile >Advanced Attributes Settings

Some how that based on Name ID of the profile the 3rd octet from DACL is always changed based on profile ?

Example what am thinking is.  If ID in name column is 133  > Attribute settings can pull the ID and inject it in 3rd octet of 1 DACL?