I have a query for Clientless VPN. I have a working solution which is suitable for a normal user. Unfortunately I seem to have abnormal users (don't we all really) who are complaining that there are too many log ons. They have to log on to Clientless VPN and then log on the the RD Web session that is offered to them. Is there a way we could push their Clientless VPN authentication through to the RD Web session? I think the answer is no tbh.
My only other solution is to remove the authentication for the Clientless VPN and lock access to known source addresses except if an address is spoofed it is open to them, albeit if a user account is compromised it's open now....assessment of two evils.
Hi @a.jones ,
I recently started researching Clientless GlobalProtect and from what I have found - No, unfortunately GP does not support any kind of Clientless SSO. There are some workarounds that would give you similar experience, but still workarounds:
- Best option in my humble opinion is to use SAML for GP Portal and RD Web. If you use same Identity provider for the SAML, users will need to provide credentials agains GP portal, but will use SAML ticket for RD Web. I haven't test it, but in theory it should work as mainly depends on the SAML Idp.
- Use machine certificate authentication for GP Portal. This way users wouldn't need to enter credentials (may be just prompt from browser to select which certificate to use for authentication), but still will have some kind of authentication.
Not sure if you aware of this, but - if you grand access only to single clientless application and disable "display url button", once the user is authenticated it will automatically redirected to the RD Web page. Which means if you choose certificate auth, user will only see the RD Web authentication page, if you choose SAML, user will see only GP portal auth page and after that login automatically to RD Web.
Just wanted to strongly recommend the use of certificates wherever possible. You aren't running into any abnormal complaint from end-users, and certificates are the least painful option imaginable from a user aspect that still provides a reasonable level of security for most organizations. As long as you own the endpoints, assuming they are managed, you can make the certificate non-exportable to negate common certificate authentication concerns organizations have.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!