06-11-2019 09:59 AM - edited 02-21-2020 11:06 AM
So we have our guest portal successfully working, but its using a self signed cert that is causing issues with some clients being able to join (browser cert restrictions)
I updated the portal certificate to a DigiCert publicly signed cert. I thought this would work great, but then realized the guests were hitting the IP of ISE to authenticate. The IP address is not in the SAN of the cert, and Digicert wont let me add an IP SAN.
So then I thought to change the portal URL to be a DNS name rather than IP, but ran into another issue that the guests are using public Umbrella DNS servers and not our internal DNS servers, so the address does not resolve.
Im not sure how to fix this issue now. I appear to be in a catch 22.
Solved! Go to Solution.
06-11-2019 10:40 AM
06-11-2019 10:21 AM
06-11-2019 10:24 AM - edited 06-11-2019 10:25 AM
We dont have PKI
Using the internal ISE CA would still present an untrusted cert to the end user, no?
06-11-2019 10:55 AM
06-11-2019 10:40 AM
06-11-2019 10:45 AM
06-11-2019 10:56 AM
06-11-2019 10:58 AM
06-11-2019 12:00 PM
06-11-2019 08:09 PM
Hi @scsc_tech
I would like to see your Authorization Profile that is used for the re-direction - why the heck would that include an IP address? Portal URL's should never include an IP address.
In the ISE Authorization Profile, either state the Static FQDN, or leave that field blank, and then ISE will auto-populate with the PSN node's FQDN on the CLI.
There's all sorts of shenanigans should can do with DNS etc - but let's check the AuthZ Profile first.
regards
Arne
06-12-2019 07:01 AM - edited 06-12-2019 07:07 AM
Access Type = ACCESS_ACCEPT
cisco-av-pair = url-redirect-acl=DNAC_ACL_WEBAUTH_REDIRECT
cisco-av-pair = url-redirect=https://10.200.254.11:port/portal/gateway?sessionId=SessionIdValue&portal=5a386de2-15f1-11e9-8d48-b08bcf6d2bcc&daysToExpiry=value&action=cwa
Again, the reason for the IP is that we don't have a private DNS server exposed to the guest VN.
06-12-2019 08:06 AM
06-12-2019 11:02 PM
Right, now I get it. The DHCP server was handing out some public DNS server (like OpenDNS) and therefore you had to hard code the ISE IP address into the URL. That's nasty.
So you ended up doing what pretty much every one else does, which is to allow guests to use the internal DNS server. Nothing too wrong with that. In that case you may as well put the FQDN into the URL Authorization Profile (as long as that FQDN lives in the cert (preferably in the Subject Alternative Name as DNS: <FQDN>)
The ideal case is to either
06-13-2019 11:49 AM
We are using a Cisco Umbrella DNS relay internally, so it decides whether to query our internal DNS servers or public based on domain.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide