Cisco ISE - What does "Multiple Matched Rule Applies" mean?

[muthumohan]

Hi,

In Cisco ISE authroiztion policy configuration, what does the option "multiple matched rule applies" mean? I can understand the "first matched rule", but in "multiple matched rule" how is the "permissions picked if multiple rules match? Or, what is the logic involved in picking up the permissions, if multiple rules are matched in authorization policy.

No where in cisco document I see any explaination for this.

Would appreciate if any one can point me to  a document or explain me the login in selecting the persmissions if multiple rules are matched. Also, what would the use-case for this?

Thanks and Regards,

Mohan

[Tarik Admani]

Moham

This means that ISE just doesnt stop if you meet the first rule condition it keeps processing till you match all the rules...one case I can think of. UserA is a member of groupA and groupB.

Here is your authz policies

rule 1 - if memberOf GroupA = accessreject

rule2 - if memberOf GroupB = accessaccept

So the access-accept should be applied to the user session.

Even though it makes sense to prioritize your rules correctly, the intent of this in my opinion is to limit any "corner issues".

Thanks,

Tarik Admani
*Please rate helpful posts*

[muthumohan]

Thanks again Tarik. 2 things...

1. So, what is the logic in selecting the permissions if multiple rules are matched? Is it the last match (as per your example) or it will logical OR all the matched permissions?

2. Can a user A belong to two groups, GroupA and GroupB?

Appreiate your help again.

Regards,

Mohan

[Tarik Admani]

Mohan,

I havent tested this feature so I am not sure I understand which policy gets applied if they are both set to permit access. However there is a bug where the access-reject takes presedence over access-accept which was a bug and should not have happened:

Here are the bug details from 1.0.4 -

CSCtn99145

An authorization policy matching multiple rules does not appropriately match the existing ACCESS_ACCEPT rule When an authorization policy use the "multiple rule match" option, and any of the matched policy rules contain ACCESS_REJECT, the ACCESS_REJECT  rule overrides the ACCESS_ACCEPT rule, regardless of where the two rules  appear in relation to one another. Workaround   There is no known workaround for this issue.

However when I spoke about multiple groups I was referrring to group membership simliar to an AD environment. You can have a user mapped to multiple groups and you can use that scenario to match the mulitple match scenario.

Your best bet at this point will be to open a TAC case to get better clarification as to which access-accept policy is used when multiple rules are matched.

Thanks,

Tarik Admani
*Please rate helpful posts*

[muthumohan]

Thank you Tarik. Appreciate your response. I will share if I find more information on this.

Regards,

Mohan

[Tarik Admani]

Not a problem, please do not forget to rate any helpful posts.

Thanks,

Tarik Admani
*Please rate helpful posts*

[edgar.reinke]

After testing the feature it seems to be that it is only collection AuthZ parameters to built the final AuthZ profile via the matched rules. An already assigned parameter (e. g. DACL) will not been overriten by the same parameter (here: DACL) of a following matched rule. It is like a first-match-out per AuthZ parameter.

That´s juts the result of doing some tests. Therefore, it might be wrong. Nevertheless, I do not know if there is a use-case for this feature ...

Regards // Edgar

[Michael ONeil]

I need ISE to behave like DAP does and aggregate multiple authorization policies when a VPN user authenticates. In my testing with ISE Authorization Policies set to multiple match, only applies the DACL from the first match and does not create a dynamic ACL of all  the matched policies. 

We are trying to use ISE instead of DAP since these deployment is spreadspread accross  several global data centers. ISE is more scalable than DAP even if configured using Cisco Security Manager.

[edgar.reinke]

Michael,

it works like designed: multiple match is a first match out based on the AuthZ Parameters. E.g.:

- Rule 1: DACL1, VLAN10

- Rule 2: DACL 2, Timeout X

... the AuthZ Result is DACL1, VLAN10 and Timeout X

It is not a Merger of DACL1 and DACL2.

From my perspective DAP doesn´t offer a Merger of functions as well. The final result is based on the Order of Operation: DAP -> User -> Group Policy -> Default Group Policy.

Regards,

Edgar

[Michal Kalinowski]

Hi Michael,

We have faced a similar challenge, and much to our dismay we had to find the same - even with multiple match only the first dACL was used.

We managed to get it to work on the ASA while having to abandon dACL's.

If you use multiple match, and pass the access list entries to the NAD as a part of the Advanced Attribute Setting (eg.):

Cisco:cisco-av-pair = ip:inacl#=permit ip any 10.0.0.0 255.255.255.0

they will get concatenated into a single ACL, provided multiple results will be matched.

The remaining issue is, to my knowledge You cannot use Multiple match AND Policy Sets. Hence whatever else you do in the policy, You need to harden the rules carefully so you only get multiple matches withing the intended scope.

Regards

Mike

[vikasyad]

I agree with tarik & also this might be helpful for you:

An authorization policy can  consist of a single rule or a set of rules that are user-defined. These  rules act to create a specific policy. For example, a standard policy  can include the rule name using an If-Then convention that links a value  entered for identity groups with specific condition(s) or attributes to  produce a specific set of permissions that create a unique  authorization profile. There are two authorization policy options you  can set:

•First Matched Rules Apply

•Multiple Matched Rule Applies

These two options direct Cisco ISE  to use either the first matched or the multiple matched rule type  listed in the standard policy table when it matches the user's set of  permissions. These are the two types of authorization policies that you  can configure:

•Standard

•Exception

Standard policies are policies  created to remain in effect for long periods of time, to apply to a  larger group of users or devices or groups, and allow access to specific  or all network endpoints. Standard policies are intended to be stable  and apply to a large groups of users, devices, and groups that share a  common set of privileges.

Standard policies can be used as  templates in which you modify the original values to serve the needs of a  specific identity group, using specific conditions or permissions to  create another type of standard policy to meet the needs of new  divisions, or groups of users, devices, or groups in your network.

By contrast, exception policies  are appropriately named because this type of policy acts as an exception  to the standard policies. Exception polices are intended for  authorizing limited access that is based on a variety of factors  (short-term policy duration, specific types of network devices, network  endpoints or groups, or the need to meet special conditions or  permissions or an immediate requirement).

Exception policies are created to  meet an immediate or short-term need such as authorizing a limited  number of users, devices, or groups to access network resources. An  exception policy lets you create a specific set of customized values for  an identity group, condition, or permission that are tailored for one  user or a subset of users. This allows you to create different or  customized policies to meet your corporate, group, or network needs.

http://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_authz_polprfls.html