cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
951
Views
2
Helpful
5
Replies

Cisco ISE Policy Set

Wyatt Tegg
Level 1
Level 1

Hopefully there is an easy explanation for this, but I have had the worst experience using Cisco ISE Policy Sets Conditions Studio. Selecting an attribute for a condition seems to almost never search properly and doesn't find half of the attributes I'm looking for.

For example, I would like to use "DHCP:host-name" or "IP:FQDN" within my condition, but I haven't been able to locate it within the Conditions Studio yet. If I go to Authorization Profiles area since it allows for advanced attributes settings and search within there, it finds it immediately, but I didn't find it anywhere within the drop downs that are given.

I'd assume I don't fully understand what I'm doing or am doing something wrong, but seems pretty logical that those options would be present within the Conditions Studio in my opinion.

This is while running ver 3.1.0.518

1 Accepted Solution

Accepted Solutions

Why not use profiling for this instead?

View solution in original post

5 Replies 5

Wyatt Tegg
Level 1
Level 1

I do have a workaround for now, but am still would like to figure out why I'm not able to find more attributes within the conditions studio. If I check the MAC address I can see they're listed under "other attributes" containing the value I'd like to set a condition with.

I do understand that it may not be the most secure way of doing it, but all I'm using it for is an additional check. You could relate it to a belt with suspenders.

Why not use profiling for this instead?

Thank you for the recommendation ahollifield.

I am using a profiling policy for this and wanted to add an additional
check. The device I'm working with has a manufacturer that produces
devices that do different tasks, but ISE was profiling all of their
devices as one. What my goal was to do is to assign DACLs to each product
type to limit their communication.

My workaround was to create a sub profiling policy, then I referred to
that within my policy set. I would have preferred to do this a different
way, so if you have any recommendations I would be happy to hear them.

I guess I was mostly looking for an explanation on why attributes are so
difficult to locate within the conditions studio.

Thank you!

Ahh, I think I see what you're referring to now! Thanks a ton. I'll go
ahead and setup new profiler conditions.

Hi @Wyatt Tegg 

I hear what you're saying. I think Cisco did that intentionally, because the specific types of attribute class you're asking for is handled by Profiling, as @ahollifield mentioned. It would be a doubling up of functionality if you could access those attributes directly in the Conditions editor (but I agree, it would be handy) . Perhaps also a partial reason is that, during RADIUS Authentication, those attributes are not (yet) present - thus ISE would not have access to them. Attributes like Hostname, OS etc. are learned via the Profiling probes AFTER authentication. And Cisco wants you to pay for the Profiling "premium" feature, whilst other NAC vendors throw that in the base license.