cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

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.

4855
Views
8
Helpful
9
Replies
Highlighted
Hall of Fame Guru

SGT for users belonging to multiple groups

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
Highlighted
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
Highlighted
Contributor

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

Highlighted

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.

Highlighted

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.

Highlighted
Beginner

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.

Highlighted
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

Highlighted

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.

Highlighted

Totally agree Marvin. Provided the feedback to the PMs.

Highlighted
Frequent Contributor

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

(Power set)

Highlighted

@Peter Koltl 

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