03-25-2021 08:28 AM
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.....
03-25-2021 12:37 PM - edited 03-25-2021 12:40 PM
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
03-25-2021 09:54 AM
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.
03-25-2021 09:56 AM
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.
03-25-2021 10:04 AM
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.
03-25-2021 12:37 PM - edited 03-25-2021 12:40 PM
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
03-26-2021 05:18 AM
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 ).
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!
