ISE 1.3 Sponsor Portal.

[graham.harper]

Hi There, Just trying out ISE Version 1.3 and encountering some issues getting access to the sponsor portal.

Just checking about a Standalone deployment is it OK to have the sponsor portal interface the same as you manage the ISE from?

I cant seem to get to the sponsor portal on 8443 it just doesn't display the page. It doesn't even fill out the URL at the end.

When I fill in the URL for it. I get this.

The Portal is set up like this So from what I see it should work. If I use the preview button in the portal set up I can get to it fine. Am I missing something?

[Mady]

Thanks Ben G.:)

So we will do on dns server something like this:

ISE1.domain.local static ip 192.168.1.1

ISE1.domain.local static ip 192.168.1.2

sponsor.domain.local static 192.168.1.1 and 192.168.1.2

Sorry, I'm not familiar with DNS. So is it possible to have two IPs for 1 FQDN?

Thank you so much.

Regards,

Mady

[ajc]

You only need to create 1 entry into the DNS for the sponsor.domain.com and point all the PSN's to that entry independently of having different FQDN. I mean:

192.168.1.1 sponsor.domain.com (FDQN = ISE01.domain.com)

192.168.1.2 sponsor.domain.com (FQDN = ISE02.domain.com)

Then in the SPONSOR PORTAL Configuration, configure the entry sponsor.domain.com (see screenshot above I posted in the past)

I recommend you to use at least version 1.4.0.253 patch 6

[Mady]

Hi Abraham,

Thanks for that. Sorry I am a bit confuse. Can you provide me a screenshot also or any reference to do this on DNS. I really don't know how to do this on DNS. :(

Thank you very much.

Regards,

Mady

[ajc]

Take a look on the following video. Unfortunately I am not responsible for the DNS Administration.

https://www.youtube.com/watch?v=WYj7KSIn2Xo

[Mady]

Hi Abraham,

Thanks!:)

[ajc]

Something else interesting I found regarding HotSpot under which we SHOULD NOT use the AUTHZ policy UserCase = Guest Flow even though the workflow diagram for the Default HotSpot Portal on 1.4 shows on top a title that says GUEST FLOW.

DOC ISE 1.3 HotSpot flows CoA changes

CSCus46754

Description

Symptom:
Customers upgrading from 1.2 who had DRW working with a Network UseCase = Guest Flow as a policy will no longer hit this condition in 1.3 since CoA sent after the customer hits accept will be Admin Reset and not Re-authenticate.
This causes the endpoint to hit a loop since the new session ID is different from the initial redirect and UseCase flag won't be there for the endpoint.

Also clients having a preferred notwork ( production SSID) will attempt to connect to the preferred SSID after the Admin-Reset CoA is sent.

Client experience:

* Connect to the hotspot and register device.
* Admin Reset CoA is sent.
* WLC de-authenticates the client.
* Client connects to preferred SSID instead of reconnecting to HotSpot SSID.

Conditions:
1.3 deployment .
HotSpot portal configured.
Under Authz policies something similar to:
* NetworkAccess UseCase = GuestFlow then PermitAccess.
* Wireless MAB then Hotspot Redirect.
Under this setup, the endpoint will hit a loop since it is impossible to hit UseCase=GuestFlow

Workaround:
Take the UseCase=GuestFlow rule out and instead match the Identity Group the endpoint is placed on during the registration process.
ie:

* If "GuestEndpoint" + Wireless MAB then Permit Access.
* If Wireless MAB then HotSpot Redirect.

For the "Preferred Network" Issue there is no workaround.
Client needs to manually switch from Production SSID to HotSpot once CoA is sent.

Further Problem Description:
Since this is the way it is intended to work in 1.3, we need to add this change in behavior to official documentation.

* There is no UseCase for Guest HotSpot flows.
* Correct CoA is Admin Reset and not Re-authenticate.

[Benoit G]

If I remember well, our certificate (manually generated and imported from our PKI) was badly formated. We also were in a cluster configuration, with 2x PSN, the DNS was correctly configured with the name and both PSN IP addresses.

Take a look at the certificate naming constraints.

The link with all the details is here : http://www.cisco.com/c/en/us/td/docs/security/ise/1-4/admin_guide/b_ise_admin_guide_14/b_ise_admin_guide_14_chapter_01000.html

[ajc]

Solution found, 

On the Guest Access TAB --- > COnfigure --- > Sponsor Portals -- > Sponsor Portal (Default) --- > Portal Settings --- > Fully Qualified Domain Name field add the SPONSOR.DOMAIN.COM entry that you have in the DNS. 

Taking into account that DNS makes round robin when the same entry applies to multiple IP's you should not have any issue with the PSN's and sponsorportal.

See attached screenshots that show you how to fix the issue. 

If you do not add that entry above into the FQDN field of the Sponsor Portal page, then you should have to type in into the browser something like the following sequence:

https://sponsor.domain.com:8443/sponsorportal/PortalSetup.action?portal=6dc51942-4cea-11e5-96d6-a46c2a9fd7d2

Hoping this helps, please remember to rate the response.

[antonioyan99]

Even if you added the DNS entry 'sponsor.domain.com', when you type it in the URL, how does the browser know to add ":8443/sponsorportal/PortalSetup.action?portal=6dc51942-4cea-11e5-96d6-a46c2a9fd7d2"  to the end?

[Peter Koltl]

sponsor.domain.com is defined as a virtual webserver in ISE. If an HTTP request arrives with 'Host: sponsor.domain.com' header ISE will send a redirect to the long URL with the hex ID.

[kelhaka]

I've had this same issue and TAC-case open for several weeks, Cisco engineers and developers have been trying to solve it, but without success.

[ajc]

Hi Kelhaka,

What version are you running? I tested the sponsor portal on version 1.4 patch 3 (the latest one). take a look on the 2 screenshots I posted and see if that helps on your case.

[Peter Koltl]

Have you tried the simplest URL

https://sponsor.domain.local/

without 8443 ?

[ajc]

Hi Peter,

it does not work. Posting another screenshots with the exact configuration on the Sponsor Portal of ISE 1.4 patch 3.