cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2036
Views
10
Helpful
6
Replies

Wildcards in Conditions for ISE TACACS Policy Sets?

tylerpalmer
Level 5
Level 5

Is it possible to use wildcards for conditions in ISE policy sets? 

 

For our network device admin access, I'd love to be able to set a condition that says something like "DEVICE:Device Type EQUALS *" rather than having to use ORs and listing each group individually.

 

I was used to the hierarchical policies in ACS where I could simply list the top-level group and it would match on anything under that, but so far, ISE doesn't see to do that, it seems to want to match on the specific group that a particular device is directly in. 

6 Replies 6

Arne Bier
VIP
VIP

Hi

 

you can use wildcards and regular expressions in some cases (check the Admin Guide).  In both scenarios you must use the MATCHES operator (not EQUALS).

 

regards

Arne

Thanks for the pointer. That'll definitely come in handy commands sets and such.

 

When I'm looking at top level conditions for a policy though and try to add "DEVICE:Device Type", I don't get a "matches" options, just equals, not equals, starts with, not starts with, ends with, not ends with, contains, not contains. At least that's what I get under ISE 2.1. I will be updating to 2.2 soon 

I just learned something.  Your statement about the Policy Set condition not having all the operators is partially true.  I just found out by trying various attributes, that the range of conditional operators depends on what you're looking at. e.g. If you wanted to do a regex on Radius User-Name, then you can!  The Matches operator appears.  But if you wanted to do a regex on DEVICE:Device Type, then you are restricted, and Matches is not offered.

thanks for bringing this to my attention.  So the answer is, you can use Matches in the Policy Set  Conditions, but only for attributes where it makes sense.

I tested this in ISE 2.2

Ah. I see what you are saying. I'll have to take a look at our policy elements and see if using some of the other attributes would make more sense.

DO NOT jump into 2.2 version. I strongly suggest you to run a test in a lab for your current functionalities on version 2.3 instead.

The bummer with 2.1 is that with the Apple iOS 11 release, it broke BYOD/etc portal provisioning and Cisco only fixed the issues in 2.2 and 2.3. I've been warned off 2.3 at present.