GlobalProtect: Pre-Logon Authentication

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Audit
Last Reviewed: 09-04-2023 03:56 AM
Audited By: kiwi
L3 Networker
100% helpful (3/3)

GlobalProtect: Pre-Logon AuthenticationGlobalProtect: Pre-Logon Authentication

 

In my previous article, "GlobalProtect: Authentication Policy with MFA," we covered Authentication Policy with MFA to provide elevated access for both HTTP and non-HTTP traffic to specific sensitive resources. You can see a diagram of the environment here.

 

In this post, we are going to add pre-logon authentication using machine certificates.

The value of pre-logon authentication means that a device can be connected to a gateway before an actual user logs into the machine, allowing certain internal resources to be accessible or scripts to be run. For more information about pre-logon, please review this TechDocs article: Remote Access VPN with Pre-Logon.

 

NOTE: This article assumes the following:
  • You have already followed the previous articles in this series.

 

Part V - Pre-logon Authentication

  • Navigate to Device > Certificate Management > Certificates > Generate to create a machine certificate signed by the root CA that was previously created
    • Enter a Certificate Name that represents the device
    • Enter a Common Name that represents the device
    • Select the root CA that was previously created for Signed By
    • Click Generate
      • NOTE: It is recommended to use an enterprise CA in a production environment 

Generate Certificate - Machine Certificate Signed by Root CAGenerate Certificate - Machine Certificate Signed by Root CA

  • Navigate to Device > Certificate Management > Certificates > Generate to create an authentication cookie certificate signed by the root CA that was previously created
    • Enter a Certificate Name that represents the device
    • Enter a Common Name that represents the device
    • Select the root CA that was previously created for Signed By
    • Click Generate

Generate Certificate - Authentication Cookie Certificate Signed by Root CAGenerate Certificate - Authentication Cookie Certificate Signed by Root CA

 

  • Navigate to Device > Certificate Management > Certificate Profile > Add to create a new Certificate Profile
    • Enter a Name
    • Navigate to CA Certificates > Add to add the root CA that was created previously
    • Click OK

Certificate Profile - Add New Certificate ProfileCertificate Profile - Add New Certificate Profile

  • Navigate to Policies > Security > Add to create a rule above your existing rules which allows access from devices assigned the Pre-logon user to the minimum internal resources necessary

Policies > Security > Add RulePolicies > Security > Add Rule

  • Navigate to Network > GlobalProtect > Portals > select the existing portal that was previously created
    • Navigate to Agent > Add
      • Enter a Name
      • Enable Authentication Override and select the certificate to be used for authentication cookies that was created previously
        • NOTE: Pre-logon will only work if: 
          1. Authentication Override is enabled and the Certificate Profile created previously is applied under the Portals > (your portal) > Authentication tab
          2. Authentication Override is enabled and the Certificate Profile created previously is not applied under the Portals > (your portal) > Authentication tab
          3. Authentication Override is not enabled and the Certificate Profile created previously is applied under the Portals > (your portal) > Authentication tab
        • In this use case, we are using option two, but it's important to note that it will fail if the user has not been previously connected. As we have an internal gateway configured, this will allow the user to connect, or refresh the connection, while on the internal network to generate the Pre-logon cookie.
          (See "GlobalProtect Pre-Logon Using Cookie-Based Authentication" for more information.)

Configs > Authentication Tab  for Portal Machine ConfigConfigs > Authentication Tab for Portal Machine Config

  • Navigate to Config Selection Criteria and set User/User Group to pre-logon

Configs > Config Selection Criteria Tab for Portal Machine ConfigConfigs > Config Selection Criteria Tab for Portal Machine Config

  • Navigate to Internal and enter the same information that exists in your other agent configuration

Configs > Internal Tab for Home Internal GatewayConfigs > Internal Tab for Home Internal Gateway

  • Navigate to External and enter the same information that exists in your other agent configuration

Configs > External Tab for Home External GatewayConfigs > External Tab for Home External Gateway

  • Navigate to App and set the Connect Method to Pre-logon (Always On)
  • Click OK

Configs > App Tab for Connect Method to Pre-logon (Always On)Configs > App Tab for Connect Method to Pre-logon (Always On)

  • Navigate to Network > GlobalProtect > Portals > select the existing portal that was previously created
    • Navigate to Agent and select the other Agent that was created prior to beginning the configuration changes in this article (NOT the portal machine config you created above)
    • Enable Authentication Override and select the certificate to be used for authentication cookies that was created previously 

Configs > Authentication Tab for Portal User ConfigConfigs > Authentication Tab for Portal User Config

  • Navigate to App and set the Connect Method to Pre-logon (Always On)
  • Click OK

Configs > App Tab to Connect Method to Pre-logon (Always on)Configs > App Tab to Connect Method to Pre-logon (Always on)

  • Navigate to Network > GlobalProtect > Gateways > select the external gateway that was previously created
    • Navigate to Authentication > Certificate Profile and the certificate profile that was previously created

GlobalProtect Gateway - Configuration Certificate ProfileGlobalProtect Gateway - Configuration Certificate Profile

  • Navigate to Agent > Client Settings > select the existing config > Authentication Override then enable it and select the certificate to be used for authentication cookies that was created previously
    • Click OK

Configs > Authentication Override TabConfigs > Authentication Override Tab

  • Click OK
  • Commit the configuration
You should now start seeing entries in the System Logs that show successful authentication events with a user name of Pre-logon (you can filter the logs by (description contains 'pre-logon')). Based on the configuration changes implemented from this and previous articles, we are now authenticating via machine certificates, user credentials, and DUO.
Rate this article:
(1)
Comments
L1 Bithead

Hopefully you see this and can offer some advice.  We have pre-logon set up and was working in testing.  As it relates to the gateway, we have the following client configs:

 

Pre-logon

Students

Staff

 

Each has their own IP Pools.  When you boot you successfully authenticate to the gateway in the pool for pre-logon.  When you log on we are seeing the user stay in that pool but show the proper username.  If you do a "refresh connection" you land in the proper ip pool based on user.  Have you seen this?

L3 Networker

Hi Brian,

 

I haven't seen this behavior before. That stated, it seems logical that this would occur because the tunnel and its corresponding IP address won't refresh when the user changes from Pre-logon to the actual user's account. What is the reasoning behind the multiple client configs and pools? 

 

-Spencer

L1 Bithead

Thanks for your reply.  The engineer that installed our palos originally set it up that way (different ip pools for different users groups - students vs staff vs it staff) prior to me implementing pre-logon.  In an on-demand world it worked fine.  It makes sense to me to have different pools.  Are you saying that you don't think it will ever switch during a logon?  I don't think the user changes until they're fully logged in (desktop visible) so it could happen then and not have any impact.  Perhaps something is wrong, because our clients do actually disconnect from GP as they are logging on.  I see the client go through "Connecting" again.

L3 Networker

Hi Brian,

 

It wouldn't hurt to open a case just to validate the behavior. I would think that if it doesn't go through a full refresh of the connection then it would retain the existing IP.

 

In the past with traditional VPN concentrators I have seen the use of different IP pools as a mechanism to segment user traffic at the network layer. Many times this was because there was lack of security capabilities beyond basic ACLs to control user access after authentication on the concentrator, and segmenting traffic at layer 3 would allow security admins to control the traffic in different ways as it traversed the rest of the security stack (i.e. firewall, IPS, content filter, etc.) to access internal resources and the Internet. My recommendation would be to explore the Source User and HIP aspects of security policy. As every user must authenticate to use GlobalProtect for access, you will have a user mapping as well as host information that you can leverage to determine identity/posture and subsequently enforce policy based on that context. In other words, leveraging a policy construct based on those elements makes it unnecessary to split users up into different pools. I would just have a single pool because there is no loss in visibility or granularity of control. Not sure if that is helpful or not, but I just thought I would share what I've seen and recommended while in the field :).

 

-Spencer

L1 Bithead

Thanks for taking the time to reply.  I know you were waiting with anticipation on the answer...  I heard back from support - sounds like I just needed to change the pre-logon tunnel rename timeout from -1 to 0.

 

Pre-Logon Tunnel Rename Timeout (sec) (Windows Only)

 

This setting controls how GlobalProtect handles the pre-logon tunnel that connects an endpoint to the gateway.
A value of -1 means the pre-logon tunnel does not time out after a user logs on to the endpoint; GlobalProtect renames the tunnel to reassign it to the user. However, the tunnel persists even if the renaming fails or if the user does not log in to the GlobalProtect gateway.
A value of 0 means when the user logs on to the endpoint, GlobalProtect immediately terminates the pre-logon tunnel instead of renaming it. In this case, GlobalProtect initiates a new tunnel for the user instead of allowing the user to connect over the pre-logon tunnel. Typically, this setting is most useful when you set the Connect Method to Pre-logon then On-demand, which forces the user to manually initiate the connection after the initial logon.

L1 Bithead

I would like to share my experience with GlobalProtect which forced me to use different IP pools instead of relying on user identification. We use Active Directory authentication via RADIUS profile for our users. If a user connects via GlobalProtect and then logs via Remote Desktop on a machine in internal network, connected user losses it's association to the IP address received from VPN pool, and is associated with the IP address of remote machine on which he/she logged. All the user can do is work via established RDP session until it disconnects. When RDP session disconnects, VPN connection must be reset, as no other session can be made from the client's IP (because rules are user-based, and Palo Alto Firewall no longer associates IP address of GP client with that user, so request are not recognized as coming from that user). Because of this we made several IP pools and we make rules based on IP addresses instead of users. I feel that this is wrong, but can't find a way around the user identification problem. 

L3 Networker

@brianjreed thanks for finding that setting.

I have 2 gateways... pre-logon users all go to gateway A. Post-login, default users stay on gateway A but a certain user group needs to connect to gateway B. The trouble is that the user group was staying on A instead of switching to B. So hopefully this timeout will fix my issue.

L3 Networker

I tried this with no change at all.

  • 48505 Views
  • 8 comments
  • 2 Likes
Register or Sign-in
Article Dashboard
Version history
Last Updated:
‎10-03-2022 09:51 AM
Updated by: