- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
07-25-2022 02:09 PM
I am building and always on VPN with Prelogin (both windows and MAC) and SAML authentication. Everything works as expected with PC computers. With the MAC computers, we see the Prelogin connection, Then it is supposed to switch to user authentication via SAML. On the Mac computers the prelogin works but then it never switches to the user login and fails. In the GP logs it shows login failure but with a username (machine cert name as the username) instead of the user's AZURE login name and GP just spins with the prelogin connected.
08-11-2022 08:18 AM
The issue is, If you are using Pre login using machine certificates then using SAML Auth, the embedded web browser will Prompt for a cert confirmation if you have a user certificate from the same Root CA. Palo Alto says it is a browser issue, but I disagree and believe it to be an issue with how Global Protect is handling the requests. this happens with Windows and Mac Computers if you use the default 443 on any interface. I found two fixes. The easy one is to use a separate CA for user certificates making sure you identify in the portal app configuration the OID of the Root CA for Machine certificates. delete the original user cert, and the issue will be resolved.
If you have two portals sharing the same on an eternal Interface, you can use a non-routable IP on the loopback Interface and then nat an alternative port to the loopback. Then when you want to access the second portal that is using a URL such as vpn.yourdomain.com:444 the cert prompt never comes up. There is a cost with this as you take a performance hit requiring using SSL VPN and not IPsec.
08-11-2022 08:18 AM
The issue is, If you are using Pre login using machine certificates then using SAML Auth, the embedded web browser will Prompt for a cert confirmation if you have a user certificate from the same Root CA. Palo Alto says it is a browser issue, but I disagree and believe it to be an issue with how Global Protect is handling the requests. this happens with Windows and Mac Computers if you use the default 443 on any interface. I found two fixes. The easy one is to use a separate CA for user certificates making sure you identify in the portal app configuration the OID of the Root CA for Machine certificates. delete the original user cert, and the issue will be resolved.
If you have two portals sharing the same on an eternal Interface, you can use a non-routable IP on the loopback Interface and then nat an alternative port to the loopback. Then when you want to access the second portal that is using a URL such as vpn.yourdomain.com:444 the cert prompt never comes up. There is a cost with this as you take a performance hit requiring using SSL VPN and not IPsec.
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!