Hello
it's a bit of a long posting ... please stick with me on this one ... 
...
It's a design question regarding the best practice when deploying Guest/Sponsor/BYOD portals in a 2 PSN deployment. It does not require load balancing, but rather, high availability. In most postings/trainings/docs I have seen, the theory is explained but either for a single PSN only or load balancer design (but not much info for a simple two node setup for HA)
Let's assume
- I want to implement a Guest Portal (CWA). And a Sponsor Portal and a MyDevices Portal.
- I have two PSN's at my disposal. Both of them are confgured for Radius auth and Web auth.
- I have one GigE interface per node (GigE0)
- ISE nodes reside on a domain-name called net.local
- No load balancer in this design.
- Let's say I have a registered internet domain called mycorp.com (for purposes of creating public SSL certs later on)
My design goal is to have the ISE nodes on their own internal DNS domain, e.g. net.local - this might be the root of all my concerns. But let's continue ...
I also want to present a Guest URL that looks professional and doesn't expose the DNS domain that ISE PSN resides on.
e.g. I don't want to see in my URL's things like ise-01.net.local (not that it would work anyway because I cannot get a public cert for a domain called net.local)
However, I don't have a load balancer, and therefore (I believe) I won't be able to set a static FQDN on my URL redirect AuthZ Result.
Question: Is it possible to achieve ISE web redirection to use static FQDN guest.mycorp.com without a load balancer in place?
Question: If not, am I forced to create ISE ip domain-names that contain my registered DNS domain (e.g. mycorp.com) ?
ISE Portal certificate proposed
- Subject CN: guest.mycorp.com
- SAN DNS: guest.mycorp.com
- SAN DNS: sponsor.mycorp.com
- SAN DNS: mydevices.mycorp.com
- SAN DNS: guest1.mycorp.com
- SAN DNS: guest2.mycorp.com
DNS Server config
- guest1.mycorp.com CNAME ise01.net.local
- guest2.mycorp.com CNAME ise02.net.local
- ise01.net.local A 192.168.21.100
- ise02.net.local A 192.168.21.101
- sponsor.mycorp.com A 192.168.21.100 (1min TTL)
- sponsor.mycorp.com A 192.168.21.101 (1min TTL)
- mydevices.mycorp.com A 192.168.21.100 (1min TTL)
- mydevices.mycorp.com A 192.168.21.101 (1min TTL)
I am aware that by default a PSN will craft a redirect URL https://<ISE_FQDN>:port
and whichever PSN is chosen in the MAB auth, will return the FQDN. So if I don't override with a static FQDN I will get either
https://ise01.net.local:8443....
https://ise02.net.local:8443....
But that won't match any SAN in my certificate. So I will get browser warnings.
- How do I get it to be https://guest01.mycorp.com:8443 ? (and guest02.mycorp.com if PSN02 is chosen) ? I am unable to use the command "ip host 192.168.21.100 guest1.mycorp.com" because I am running on Gig0 only and ISE tells me it's not possible on Gig0. Does that mean I have to plumb a GigEth1 interface to achieve my goal? Alternatively, if I only have GigE0, then I would have to ensure that all of my ISE nodes are in the mycorp.com domain as per the previous question above.
- Regarding the sponsor/mydevices portals, is there any better approach than having just two A records as shown above? When I tested this in CentOS (as a client) I found that 192.168.21.100 was always chosen first as long as psn01 was alive. When psn01 was unreachable (no route to host) then CentOS very quickly tried 192.168.21.101. Every subsequent attempt always resulted in 192.168.21.100 being tried first. I guess this is the failback mechanism that would ensure the restoration of normality when PSN01 comes back to life? It seems to work quite well actually.
Bottom line: is the idea of using a non-registered DNS domain like net.local on an ISE node more hassle than it's worth? It's a neat way of keeping the DNS design clean, but I am having a hard time figuring out my concerns mentioned above. Sorry for the long elaboration but I didn't want there to be any ambiguity in my questions.
Accepted Solutions
Not following true motivation for two domains. Most customers have internal domain and choose to add second domain for public certs and avoid cert warning and wish to retain internal certs for management and EAP communications. I do not see how it makes design clean. If wishing to obfuscate internal domain, then use secondary interface with custom alias to alternate domain.
See BRKSEC-3697 and BRKSEC-3699 reference presentations from Orlando 2018 on CiscoLive.com for some additional details use of secondary interfaces and HA without LB. For Sponsor/MyDevices, need intelligent DNS as I would not rely on clients to properly fallback to secondary entry in DNS response.
It may be possible to add secondary domains to SAN field of certs, but cleaner option is to use second interface which has its own FQDN and public domain which is distinct from internal domain on GE0. Here is slide from BRKSEC-3699 which calls out use cases and caveats of static hostname redirect:
The example shows rule logic to select PSN based on RADIUS server.
/Craig
Would this work? I create two AuthZ profiles, each with their own static FQDN pointing to the appropriate PSN?
And then I apply these in AuthZ depending on which PSN received the request?
Not following true motivation for two domains. Most customers have internal domain and choose to add second domain for public certs and avoid cert warning and wish to retain internal certs for management and EAP communications. I do not see how it makes design clean. If wishing to obfuscate internal domain, then use secondary interface with custom alias to alternate domain.
See BRKSEC-3697 and BRKSEC-3699 reference presentations from Orlando 2018 on CiscoLive.com for some additional details use of secondary interfaces and HA without LB. For Sponsor/MyDevices, need intelligent DNS as I would not rely on clients to properly fallback to secondary entry in DNS response.
It may be possible to add secondary domains to SAN field of certs, but cleaner option is to use second interface which has its own FQDN and public domain which is distinct from internal domain on GE0. Here is slide from BRKSEC-3699 which calls out use cases and caveats of static hostname redirect:
The example shows rule logic to select PSN based on RADIUS server.
/Craig
Hi Craig
When you say "Most customers have internal domain and choose to add second domain for public certs..." then that is exactly what I am after.
My main constraint was the fact that I only have one GigE interface - thus, the ip hostname trick won't work here 
- in some cases customer cannot justify consuming an extra switch port per PSN (or two, if bonding)
Ok, so with one ISE interface, if you build your nodes with an internal domain like this
ip domain-name ise01.net.local
then you run into the issue where you MUST override the FQDN in the URL redirection - because the client will get a cert warning since ise01.net.local will never make it into a publically signed certificate. And then the only way out is the Network Access:ISE Host AuthZ rule to override the FQDN with the desired FQDN that is contained in the Portal cert.
OK I think I get it now. I was mostly after a sanity check from the field to see whether I was perhaps missing something obvious.
I'll go over the Cisco Live docs again.
