This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
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,
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".
*Please rate helpful posts*
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.
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 -
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.
*Please rate helpful posts*
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
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.
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.
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.
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 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.