Why does creating a Guest Type, automatically create a mirrored User Identity Group?

[Arne Bier]

Hello

Something I have always wanted to know .... but never got around to asking ...

When I create a new Guest Type (call it "ANNUAL_GUEST_TYPE" or whatever), ISE automatically creates a User Identity Group called GuestType_ANNUAL_GUEST_TYPE.    I don't need this Group and I don't understand its purpose.   I can't even delete this Group because it's system-generated.  Therefore it must have some special purpose.

If I am doing Sponsored Guest Access (which I am) then why do I also need a User Identity Group?  UIG is a Group of internal users (NOT Guest users) that I create via a totally different mechanism. 

Looking forward to the response :-)

[Nidhi]

Hello Arnie,

I did some tests around this, and while it creates the group automatically,  it also gives flexibility to the admin to add guest user as part of this group. Also, with more guest users the guest flow with url-redirect, you can reference the guest group and create policies.

Thanks,

Nidhi 

[Arne Bier]

Hi Nidhi

The User Identity Group that ISE automatically creates is no different to a User Identity Group that I could have created myself, had I wanted such a facility.  It seems like a back-door mechanism to add in a few local identities in ISE that may want to also use the Sponsored Guest facility without being created as an actual Sponsored Guest.   Why would anyone want to do that, instead of creating the guest accounts properly in the first place?

URL re-direction is handled by MAB policies already - is there any value in using the User Identity Group?  if you have an example I would like to learn more.

When I tested this too, I didn't see any entries in the User Identity Group after I logged in through the portal.  When I click on the Add button, ISE only allows me to add local ISE accounts.

[Surendra]

AFAIK, they are there to validate the Sponsor’s privileges w.r.t to a guest type. For example If sponsor A is supposed to manage accounts for only Guest Type A, then there needs to be a group or at least a dummy group which can be validated against. Since guest user identity store is different from the internal user identity store, there has to be something that is common for both of these identity stores to be able to control the sponsor’s access and it’s this user identity group in internal users that is linked to the guest type in guest identity store. IF you are asking why this group is shown in the internal user group if this is just a reference, as @Nidhi pointed out, you can use that group in the policies to control access to different guest types. For example, if the User Identity group is Contractor, push authz profile contractor. Have a look at this https://community.cisco.com/t5/security-documents/ise-guest-access-prescriptive-deployment-guide/ta-p/3640475#toc-hId-2129827407 .