cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7172
Views
8
Helpful
9
Replies

SGT for users belonging to multiple groups

Marvin Rhoads
Hall of Fame
Hall of Fame

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.

1 Accepted Solution

Accepted Solutions

kthumula
Cisco Employee
Cisco Employee

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.

View solution in original post

9 Replies 9

vrostowsky
Level 5
Level 5

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

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.

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.

Toucanzoo
Level 1
Level 1

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.

kthumula
Cisco Employee
Cisco Employee

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.

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.

Totally agree Marvin. Provided the feedback to the PMs.

Peter Koltl
Level 7
Level 7

The number of variations for n groups is 2^n, not n! or n*(n-1)*...

(Power set)

@Peter Koltl 

Math is hard - that's why I am in engineering. ;)

Getting Started

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: