This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
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.
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.
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.
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