ISE - Sponsor Portal - FQDN in guest approval mails

[Martin Jelinek]

Hi All,

I'm trying to figure out an issue with guest approval mails which are being sent to the "Person being visited". 

Scenario is clear, user/guest connect to wireless network and it is redirected to the Guest portal to register an account. Once user register an account it's creation needs to be approved by ntoed person in "Person being visited". Such person receive an e-mail from ISE with APPROVE/DENY links.

I'm trying to get rid of the IP address in the URL and have real FQDN.

Since Guest portal flow contains what Sponsor portal is used to verify approvals.

Such Sponsor portal has a setting for FQDN which should be used and it referred within APPROVE/DENY links, but how PSN nodes are distinguished? We have 2 PSN nodes and each of them has different hostname and of course once user click on such link it's DNS resolution behind to connect into proper portal/approval (tokenized). But this settings is for whole portal which runs on both PSNs, so how this is achieved?

I can put HLB (Load-balancing) FQDN but that doesn't work as session seems to not exist on the HLB, but of course, because that is just a link existing on PSN which needs to be accessed to approve guest account creation.

Need to note that both PSN nodes are configured in Node Group and therefore sessions should be synced.

FYI - running ISE 2.2 with latest Patch #12

Thanks for any hint.

Martin

[Arne Bier · Accepted solution]

Hi Martin

You're stumbling on the same issue that many of us have encountered before.  You can achieve HA without a load balancer by the way.  This means, without a load balancer your NAS will send Radius MAB to PSN1.  If PSN1 does not respond, then NAS will send to PSN2.  Ok - that is the HA setup on the NAS.  But as you rightly pointed out, the NAS MAB auth is sent to PSNx and then the corresponding DNS resolution in the URL has to resolve to PSNx too - how does one do that?   It's a clever little trick. 

Because each PSN (that is running Session Service) gets identical programming from the PAN, they are effectively clones of one another.  it means each node can process any request from the NAS.  BUT.  Guest flow is special and the session is created on the PSNx that received the MAB auth.  Now comes the trick - how do you return the correct URL to the client? 

Answer:  By having two Policy Set Authorization Rules

Imagine your PSN FQDN hostnames are  PSN1.net.local and PSN2.net.local - then the AuthZ rules could be

1) IF ISE Node Name STARTSWITH PSN1 then return Result Profile with CWA Redirection and static FQDN guest1.mycompany.com

2) IF ISE Node Name STARTSWITH PSN2 then return Result Profile with CWA Redirection and static FQDN guest2.mycompany.com

You cannot design a solution that returns guest.mycompany.com without a load balancer.  Remember I said we're doing it without load balancer (for reasons of simplicity - unless you want to open a world of pain ....)

So now your DNS server will have a CNAME record that looks like this

guest1.mycompany.com   CNAME psn1.net.local

guest2.mycompany.com   CNAME psn2.net.local

And of course psn1 and psn2 resolve to the DNS A records (IP addresses).

Your Sponsor portal can be static FQDN sponsor.mycompany.com

In your DNS you will then have two entries (ISE 1 and ISE 2's IP address)

sponsor.mycompany.com  A  10.10.10.10

sponsor.mycompany.com  A  10.10.10.11

Your Windows/MAC clients will round robin if 10.10.10.10 doesn't respond to a TCP connection and then try 10.10.10.11 - this is poor man's HA - but it works.

If you want to build a load balancer solution then check out BRKSEC-3699 - it's complex!  With 2 PSN's spare yourself the agony and do it like shown above.  You'll be glad you did.  What's the worst thing about seeing guest1.mycompany.com ?  Nothing, because the clients never enter that URL anyway - it's just shown in the browser and most people don't care.  Just make sure you apply for a public cert that can handle that domain (*.mycomany.com ... or SAN entries guest1.mycompany.com, guest2.mycompany.com, sponsor.mycompany.com - sometimes SAN certs are cheaper than wildcard certs.)

Good luck!

[Martin Jelinek]

Hi Arne,

Thank you very much first of all. Just I was trying to not be too complex about "simple" thing I'm trying to achieve. The scenario I have is just a LAB before moving into production which contains 8 ISE nodes in three regions with HLB and GSLB in place. :-)

Therefore sponsors are easily going to just a single link from anywhere and by GSLB they always enter the "closest" PSN node to create guest accounts for wireless etc. But the fact that also the visitors can perform self-registration which actually requires an approval (tokenized) by person "Being visited" then I need to find a nice and shiny way how to prevent an IP address within APPROVAL/DENY links. Again with IP it works of couse, but "nice and shiny" is the problem.

I will need through your answer once more as I might have misunderstood something but scenario you are referring to is not really applicable in our case (yes in LAB but not in production and LAB should reflect planned stage for production).

Thank you

[Martin Jelinek · Accepted solution]

Looks it is fixed now.

We play around little bit more with Load-Balancer in place and luckily Approve/Deny links are strictly under defined port TCP/xxxx and therefore we configured Load-Balancer to lister on port xxxx and do just "stupid" forward for PSN1 or PSN2 sync sessions are synced so it doesn't really matter if links is directed to PSN1 or PSN2 as both knows it and can approve/deny guest account creation.

So solution was additional policy definition on load-balancer.

Thank you

[Arne Bier]

Glad to hear. Yes sponsor portal load balancing should be trivial. The guest portal load balancing is not trivial because of session persistence