05-22-2018 04:36 AM - edited 03-11-2019 01:38 AM
I'm looking for a design guide covering the use case of user belonging to multiple AD groups, each assigned a unique SGT with associated SGACLs.
Everything I've seen in the various resources seems to assume that a given user is only ever a member of one group and thus the classic ISE first-match AuthZ policy works just fine.
How do we accommodate the case where users may belong to multiple groups and we need a multi-match sort of logic? It doesn't scale to have n*(n-1) ...much less n! SGTs.
Solved! Go to Solution.
05-22-2018 10:38 AM
Marvin, As the rest of the folks stated in the thread, that is the limitation today with the security groups where we don't have inheritance. But one way to workaround that is by using ISE authZ policies with multiple AD groups added to one condition and assign an SGT based on that. Also complement that by auto-SGT assignment we have in ISE. This is not the best method and not scalable as you said.
05-22-2018 08:11 AM
Marvin-
I am curious as to what you are trying to accomplish. Could you please give a brief explanation of the scenario you are looking at?
Thanks
-Vince
05-22-2018 08:21 AM
Say we have 7 groups (mapped to SGTs) plus a shared resources group. Users are generally assigned to 1 of the 7 (with AD group membership) and access restricted accordingly (e.g. a group 1 user can access group 1 resources plus shared resources). That's the assumption of most SGT / Trustsec presentations.
My customer has users (developers) who may be assigned to multiple groups - e.g. 1 and 3 and 5. The only solution I see for that is to make a whole lot of new groups with associated SGTs and unique AD groups and use that for mapping. That's very unwieldy and not scalable.
With a multi-match I could check is the user a member of group 1 or 2 or 3 etc. If 1 and 2 and 3 then grant access to resources in all of those groups. The current logic is all first-match so I never have the opportunity to check for additional group membership.
05-22-2018 09:31 AM
Bingo. This has been a limitation for a long time. I’ve brought it up multiple times. I’m still unaware of a feasible workaround.
05-22-2018 08:15 AM
I think you are right in that the first match would define the SHT you receive.
At the moment one user can only belong to one SGT, there was some talk of being allowed multiple SGT's in the future at the PVT in Amsterdam.
05-22-2018 10:38 AM
Marvin, As the rest of the folks stated in the thread, that is the limitation today with the security groups where we don't have inheritance. But one way to workaround that is by using ISE authZ policies with multiple AD groups added to one condition and assign an SGT based on that. Also complement that by auto-SGT assignment we have in ISE. This is not the best method and not scalable as you said.
05-23-2018 08:59 AM
kthumula thanks.
Your reply confirms my thinking. If anyone from the BU is monitoring, please take this is (another) customer story where the current solution doesn't quite meet the mark.
05-23-2018 10:12 AM
Totally agree Marvin. Provided the feedback to the PMs.
05-22-2020 06:53 AM
The number of variations for n groups is 2^n, not n! or n*(n-1)*...
(Power set)
05-22-2020 07:25 AM
Math is hard - that's why I am in engineering. ;)
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: