ISE Sponsor Portal per AD Group possible?

[Arne Bier]

Hi Guest Sponsor experts,

My customer ISE deployment currently runs on one Guest Sponsor portal.

I have various Sponsor Groups based on AD Group membership.

Customer asked me today whether we can present a customised Sponsor Portal per AD Group, specifically for one reason:  When notifying guests via email, they want to be able to specify a custom .png file, depending on the AD Group that the Sponsor belongs to.  The logo on the email needs to represent the Group that sent it.

I thought about this.  If I created a new Sponsor Portal (which also runs on port 8445), I could perhaps use the Identity Source Sequence to differentiate Portal A from Portal B - but the Identity Source Sequence doesn't work at the AD Group level :-(

The only option I can see right now is to create a new Portal, on port 8446, using a new FQDN, new cert, and then I can customise it however I need.  Is there a better way?

cheers

[Jason Kunst]

Craig Hyps has a document that is used for granting access to a sponsor portal depending on LDAP grouping this was used before

This may work

https://communities.cisco.com/docs/DOC-64526?mobileredirect=true

Point ISE to itself for the different portals and have an fqdn for each

[Arne Bier]

Hi Jason

The notification functionalities like SMS and email are tied to the Sponsor Portal definition, and not to the Sponsor Group definitions.  I don't think Mr Craig's docoment addresses that use case

My Use case 1: Sponsors print account emails with Logo X

My Use case 2: Sponsors print account emails with Logo Y

Therefore I have to create a new Sponsor Portal where I can tinker around with that Notification stuff.

My intuition tells me that the Sponsor Portal look and feel should be tied to Sponsor Group definitions, then this would work.  Currently there is a lot of "shared/central" Portal config that is share by all the Sponsor Groups.

Maybe I need to rephrase my question

I don't see a way of keeping my existing https://sponsor.company.com FQDN that can service both types of use cases above, because in order to produce two different looking account emails, I need to invoke a Specific Sponsor Portal - and how are those enumerated in any logic?

I believe I need to create a new Sponsor Portal Y, and use the existing Sponsor Group concept to restrict access to that AD Group.  New Sponsor Portal would have different TCP port and FQDN, and new cert etc.

It would be handy to make the Sponsor Portal look and feel dependent on the AD Groups somehow (kind of like how Guest Portals are enumerated for Authorization Profiles - same  TCP port, but separate virtual https servers).

I'll try this out in the lab if I get time

[Jason Kunst]

I don’t see a way to do what you’re looking for unfortunately without creating your own customizations with api which is a lot of work

I suggested that link solution so that you can create a different sponsor portal and only allow certain groups to use it

This ways sponsor group x can only use sponsor portal x

[Craig Hyps · Accepted solution]

The ask here is a bit different in that you are NOT looking for authorization to portal based on AD, but rather AD-based portal/notification content per user (i.e. content changes AFTER auth based on AD membership) which is not something built into ISE today.  Mr Kunst has proposed variable-based portal content (in this case, the Sponsor Group is variable), but that would require requests from customers to help prioritize.  I suggest work with your Cisco account/partner SE to provide use case and impact to help with prioritization.

Craig

[Jason Kunst]

Exactly Craig

My proposal is to create a portal per customization and to restrict who can login that portal based off your document