GlobalProtect Pre-Logon VPN WITHOUT using Machine Certificate for Authentication
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

The Enhanced LIVEcommunity Experience is finally here! Learn all about it.

GlobalProtect Pre-Logon VPN WITHOUT using Machine Certificate for Authentication

L0 Member

Hi,

 

I currently have my lab PA-220 where its configured for prelogon and then on demand for the VPN, and it works just fine with saving cookies for the authentication and authenticates at the windows login screen without any issues.

 

Move to our production PA-220 and we cannot seem to get the pre-logon to connect, and I have mirrored the same settings as the lab environment. When I opened a ticket with Palo Alto, they state that a Machine Certificate is required for Pre-Logon authentication, but I have a hard time believing this as I have it working in my lab. Anyone else have pre-logon working WITHOUT a client certificate? I can't be the only one.....

1 ACCEPTED SOLUTION

Accepted Solutions

L4 Transporter

Is the only reason you don't want to use machine certificates is that you don't have an internal root CA?  I have spent an extensive amount of time configuring machine-based certificate pre-login along with SSO + SAML Authentication integration and the config is quite intricate.  In my experience there are so many scenarios in which tokens can be invalidated (new application installs, configuration changes, IP changes, etc.) for either the portal or gateway I just can't see this working consistently.

 

I would also agree that not using a machine certificate could create a pretty big security hole especially if you are creating and relying on tokens with long lifetimes.  If you don't have a internal root CA you could consider using self signed certificate(s) if your deployment is not large as they could be deployed easily through a GPO.

 

Edit:  This is a very comprehensive explanation on configuring pre-login and interactive logins for GlobalProtect:

https://live.paloaltonetworks.com/t5/blogs/globalprotect-overview/ba-p/322170


- Good luck

View solution in original post

5 REPLIES 5

L4 Transporter

Hello @MartyMcFly 

Assume that you manage to finish the setup without a certificate. This would allow anyone to connect to to your environment (using whatever is granted for user pre-logon). I don't think is is a good idea.

Thats not true either. You have to login with the user before you logout to cache the cookie, so saying anyone is not accurate. Anyone who has connected previously with an authentication cookie, sure.

L2 Linker

From what I've seen with deployments of GP in combination with pre-logon, mostly in combination with AD/SCCM/Azure managed endpoints, a machine certificate is the easiest method on the Portal and Gateway if you have a freshly spun-in devices (Also easier in deployment with less user complaints).

 

As the portal needs some form of authentication at first, unless you specify that anyone can connect, in practice you either deploy a machine certificate in the image of the device to identify it and have a certificate profile to verify the authenticity.

The other option is to have a user connect manually at first (With a local or external account) after which authentication cookies are generated and placed on the machine locally. The cookie is valid for your selected period (Due mind the Portal and Gateway both have their own settings where the certificate for encrypting/decrypting needs to match and you can have different timers for each).

 

When the machine boots up, if the user has logged in before, it connects to the portal due to the settings it received previously, and connects to the gateway presenting the cookie it has locally. The gateway inspects the cookie and connects the device if the cookie is still valid and assuming you don't set the authentication to also force a certificate check or additional MFA.

-- In case of emergency unplug cables--

L4 Transporter

Is the only reason you don't want to use machine certificates is that you don't have an internal root CA?  I have spent an extensive amount of time configuring machine-based certificate pre-login along with SSO + SAML Authentication integration and the config is quite intricate.  In my experience there are so many scenarios in which tokens can be invalidated (new application installs, configuration changes, IP changes, etc.) for either the portal or gateway I just can't see this working consistently.

 

I would also agree that not using a machine certificate could create a pretty big security hole especially if you are creating and relying on tokens with long lifetimes.  If you don't have a internal root CA you could consider using self signed certificate(s) if your deployment is not large as they could be deployed easily through a GPO.

 

Edit:  This is a very comprehensive explanation on configuring pre-login and interactive logins for GlobalProtect:

https://live.paloaltonetworks.com/t5/blogs/globalprotect-overview/ba-p/322170


- Good luck

View solution in original post

L4 Transporter

As a workaround you can use "Enforce GlobalProtect for Network Access", so that the user will need to start the VPN if they want any network connection also block them for disabling./deleting the VPN app (it works best when there is Mcrosoft AD environment ).

 

 

https://docs.paloaltonetworks.com/globalprotect/10-0/globalprotect-admin/globalprotect-quick-configs...

 

 

https://docs.paloaltonetworks.com/globalprotect/8-1/globalprotect-admin/globalprotect-portals/define...

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!