We originally had one User Realm that everyone logged into, and the various mapped Roles had access to numerous Resource Profiles that used Passthrough Proxy with a virtual hostname to access content. No problems there at all.
We've now added a second User Realm (different authentication settings), that still aligns the users with the same user Roles, that still has access to the same Resource Profiles, but when those users try and access the resource via the virtual hostname, the SSL VPN redirects to the original User Realm Sign-In page like they're not logged in.
Is this intended behaviour? I can't see anywhere that says a Resource Profile is linked to a User Realm. As far as we understood it, the Resource Profile permissions are based on Role, and these users are logged in and assigned those Roles.
Thanks in advance.
Solved! Go to Solution.
Due to it being a production system and change control procedures, it would have taken longer to try the different IP approach, so I tried the suggestion itdept listed - using a different path. It works.
This got me thinking about why the SSL VPN authenication may break on a different domain, then it hit me - Cookies. I'm betting that as with most cookie-based systems the SSL VPN sets the domain that the cookie can be read on, so if its set to 'www.company.com' then browsers will only use it on that hostname, whereas setting it to '.company.com' would allow subdomains to use it as well. So I think the SSL VPN is using the full domain, and when the client tries to access the different subdomain (secure.company.com) the browser doesn't send the cookie and therefore the SSL VPN believes you're not authenticated.
I haven't yet been able to find a setting in the SSL VPN that would allow you to change the cookie domain, but if you could and can change it to the base domain, I bet it would work.
need more info what is the sign in url used for the first realm, how is the new realm access what is its sign in url.
What is the virtual hostname url?
First Realm Sign-In page is https://www.company.com
Second Realm Sign-In page is https://secure.company.com (has extra authentication for 2FA)
The Resource Profile Passthrough Proxy virtual hostname is service.company.com and accessed https://service.company.com
Users signing into the first realm have no problem accessing https://service.company.com, it proxies the internal site immediately. Users signing into the second realm trying to access https://service.company.com get sent to the first realm sign-in page.
this is by design.
If we access using the PTP virtual hostname, it gets redirected to the URL configured under Network identity > hostname.
For 2nd realm users, they can access https://secure.company.com and then access the resource.
That's the problem, they login via https://secure.company.com - but if they then try and access the virtual host it redirects them to the other login page.
What IP does PTP hostnamehttps://service.company.com resolve to on the outside, is it to the external public IP.
Yes, wildcard DNS - all resolve to the same external SSL VPN IP.
We don't have a spare SSL VPN to replicate it so it will be good to see if anyone has the issue or comes across any possible setting that might explain why.