Always on GP Using Local CA for Prelogin and SAML Auth

cancel
Showing results for 
Search instead for 
Did you mean: 

Always on GP Using Local CA for Prelogin and SAML Auth

L2 Linker

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.

1 ACCEPTED SOLUTION

Accepted Solutions

L2 Linker

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.

View solution in original post

1 REPLY 1

L2 Linker

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.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!