Basic GlobalProtect Configuration with Pre-logon

Printer Friendly Page

 What is GlobalProtect with Pre-logon?

 

As 'pre-logon' in the name suggests, GlobalProtect is connected "before" a user-logs on to a machine. The idea behind pre-logon is to have the "device" get connected to the GlobalProtect gateway, even before a user logs into the machine, most commonly to have certain internal resources connected or scripts executed even before a user logs in. For example, in the case of Windows, GlobalProtect pre-logon get connect to the gateway while the system is still booting up or is at the Ctrl+Alt+Del screen, that is, before a user logs in to the machine. Pre-logon will also kick in once a user logs off that machine. Since there is no user associated at these times, the gateway will see this connection coming from a generic username called 'pre-logon'. Once the user logs on to the machine, the tunnel gets renamed (in Windows) from the 'pre-logon' user to the actual 'user' who logged in. In the case of MAC, the tunnel is re-established with the actual user who logged in. 

 

  • Pre-logon is most commonly used in conjunction with 'user-logon' and SSO so that the GP connection is seamless to the user.
  • Since this deals with two users called 'pre-logon' and the actual 'user', separate client configs need to be created under portal one for 'pre-logon' and other for 'any/specific user groups'. Separate security rules are also needed to provide access for these two users.
  • Once the 'actual user' is connected to GP (ie user-logon), the user will see a 'disable' option (if allowed by admin) to disable the GP application when needed.  

 

This document explains basic GlobalProtect configuration for pre-logon with following considerations:

 

  • Authentication - local database
  • Same interface serving as portal and gateway.
  • Root, intermediate and server certs are generated on PAN

 

1. Generate a root CA, intermediate CA and a server cert as explained in this document:

https://live.paloaltonetworks.com/t5/Management-Articles/Certificate-config-for-GlobalProtect-SSL-TL...

 

 

Certificate-chain.png

 

 

2. Create a SSL/TLS profile under Device>Certificate Management>SSL/TLS service profile, referencing the above created 'server certificate'.

SSL-TLS-profile.png

 

3. Create an authentication profile under Device > Authentication Profile > Add.

 

  • Name- Give a name to this authentication profile
  • Type - Choose Local Database(You may choose ldap,radius etc depending on your requirement)
  • Advanced Tab > Allow List > Add - Select all (If you have groups, you may restrict it to required groups)

Click OK to save.

Auth-profile.png

 

 Auth-profile-2.png

 

 

4. Create a tunnel interface under Network > Interfaces > Tunnel. Give a tunnel number, virtual router and security zone. It is recommended to create a separate zone for VPN traffic as it gives better flexibility to create separate security rules for the VPN traffic.

 

tunnel-interface.png

 

 

Configure GlobalProtect Portal

 

5. Go to Network > GlobalProtect > Portals > Add.

General Tab. Give a name to the portal and select the interface that serves as portal from the drop down.

  GP-portal-general.png

 

6. Authentication tab.

 

a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down.

b. Client Authentication> Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3.

c. Click ok to save.

GP-portal-auth.png

 

One of the following 3 conditions must be met for pre-logon to work:

 

i.  Portal contains ‘certificate profile’ but ‘no’ auth cookies(explained in step 7).

ii. Portal does ‘not’ contain ‘certificate profile’ but has ‘auth cookies’.

(In this case, the very first GP connection must be made by a user, which will create two cookies one for the ‘user’ and other for ‘pre-logon’. From then on the pre-logon will work.

 

Attempting ‘pre-logon’ in the very first time without having a user connected to GP previously will not work in this case since the ‘pre-logon’ cookie will only get generated after a user is logged in the first time.)

 

iii. Portal contains both ‘certificate profile’ and ‘auth cookies’.

 

 7. Agent tab.

 

Needs two client configs, one for pre-logon and second for any user/specific user groups.

 

Client config for Pre-logon

 

Add a new client config 

 

a. Authentication tab.

  • Give any name to this client config
  • Client certificate - leave it to none, this will only be needed if we want to push any client certificate to clients for authentication purpose.
  • Save user credentials - Yes (default)
  • (Optional)Authentication override: Check the boxes for 'Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate that is selected from the drop down of ''. Note: If a certificate is selected here under portal, the same certificate needs to be selected under Gateway's config for encrypt/decrypt cookie.

prelogon-client-config.png

  

 b. User/User group tab. Select 'pre-logon' from drop-down

 

prelogon-client-config-2.png 

IMPORTANT!

c. Gateways tab.

 

  • Under 'External gateways', click Add. Give any name to it.
  • Address- Enter the IP address or FQDN which was referenced in the certificate Common Name(CN) or Subject Alternate Name(SAN) of Step 1. In this example we enter 'gp.portal-gw01.local'

GP-portal-gw.png

   

 d. App tab.

Under 'Connect-method' drop down, select 'Pre-logon(Always On)'. 

 

prelogon-client-config-3.png

   

e. Click OK to save.

 

Client config for actual users

 

Add a new client config 

 

a. Authentication tab.

  • Give any name to this client config
  • Client certificate - leave it to none, this will only be needed if we want to push any client certificate to clients for authentication purpose.
  • Save user credentials - Yes (default)
  • (Optional) Authentication override: Check the boxes for 'Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate that is selected from the drop down of ''. Note: If a certificate is selected here under portal, the same certificate needs to be selected under Gateway's config for encrypt/decrypt cookie.

user-clientconfig-1.png

 

  b. User/User group tab. Select 'any' from the drop-down or add specific user/user groups.

 

user-clientconfig-2.png

 

 

IMPORTANT!

 

c. Gateways tab.

 

  • Under 'External gateways', click Add. Give any name to it.
  • Address- Enter the IP address or FQDN which was referenced in the certificate Common Name(CN) or Subject Alternate Name(SAN) of step 1. In this example we enter 'gp.portal-gw01.local'

GP-portal-gw.png

 

   d. App tab.

 

  • Under 'Connect-method' drop down, select 'Pre-logon(Always On)'.
  • Also, make sure 'Single Sign-on' is set to 'Yes'.

 

user-clientconfig-3.png

    

e. Click OK to save.

 

 f. Under 'Trusted Root CA', select the root CA and intermediate CA. Also, select 'Install in Local root certificate store' to install these certificates in the client's local root certificate store after the client successfully connects to the portal for first time.

portal-all-configs.png

 

g. Click OK to save and close the GlobalProtect portal config.

 

Configure Client certificate profile

 

(Location: Device > Certificate Management > Certificate Profile)

 

Certificate profile specifies a list of CAs and Intermediate CAs. When this certificate profile is applied to the config, the portal/gateway will send a client certificate request to the client to request for a client/machine cert signed by the CA/intermediate CA specified in the cert profile. We recommend placing both the root and intermediate CAs in this profile, instead of just the root CA.

  

IMPORTANT!


Client certificate refers to user cert, it can be used for 'user-logon'/'on-demand' connect methods. Used to authenticate a user.

 

Machine certificate refers to device cert, it can be used for 'pre-logon' connect method. This is used to authenticate a device, not a user.

 

  • Import the "Root CA" that signed the client/machine cert into Device> Certificate Management >Certificates (optional private key)
  • Import the "intermediate CAs" if any that signed the client/machine cert into Device> Certificate Management >Certificates (optional private key)
  • Go to Device>Certificate Management>Certificate Profile, Add.
  • Give a name to the profile.
  • Add the above root and intermediate CAs.

client-certprof.png

  • Note: Username field by default is set to 'None', in typical setup where username is pulled from ldap/radius authentication you can leave this to none. On the otherhand, if certificates are the only method of authentication ie if you do not have radius/ldap for portal/gateway authentication then you must change username field from none to 'Subj' or 'Subj Alt' to extract username from the client certificate common name or email/principal name. Failing to do this will result in commit failure.
  • (optional) Check CRL or OCSP if the portal/gateway needs to verify the client/machine cert's revocation status using CRL or OCSP. Please use this with caution as it can result in clients failing to connect if used in conjunction with 'Block session if certificate status is unknown'.
  • Reference this certificate profile portal/gateway as needed.

  

Configure GlobalProtect Gateway

 

8.  Go to Network> GlobalProtect > Gateways > Add.

 

General Tab. Give a name to the gateway and select the interface that serves as gateway from the drop down.

GP-GW-General.png

 

9. Authentication Tab. This is similar to Step 6 but this is for the gateway.

a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down.

b. Client Authentication > Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3.

c. Select the above created certificate profile from drop down

d. Click OK to save.

 gw-1.png

 

10. Agent Tab.

a. Tunnel Settings. Check 'Tunnel mode' to enable tunnel mode and select the tunnel interface created in step 4 from the drop-down. 

b. Enable IPSec. Check this box to enable IPSec, this is highly recommended. With this setting enabled, GP will always try to first connect over IPSec, if it fails then GP falls back to SSL.

Gateway-tunnel.png

 

c. Timeout settings - leave them to defaults. For any changes to this, refer to GP admin guide.

d. Client settings

Click Add> Give a name to authentication override tab

(Optional) Authentication override: Check the boxes for 'Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate selected from the drop down of ''.

 

Note: If a certificate was selected in step 7 under portal, the same certificate needs to be selected here under Gateway 'certificate to encrypt/decrypt cookie'.

GP-GW-Client-config.png

 

e. User/User group tab. Leave the OS and User group to 'any' (You may restrict it to required groups if wanted). 

 

IMPORTANT!

If a group is chosen from the drop-down, make sure that the GlobalProtect user is part of this group, if not the client will NOT receive IP address from gateway.

 

Common issues here are when the user is identified by GlobalProtect as 'domain\user' but firewall's userid may have it as 'fully qualified domain\user', in those cases make sure the group/user is shown identical at both places by overwriting domain field in user-identification>group mapping. 

GP-GW-Client-user-group.png

 

f. Network Settings. 

Under the Ip Pool:  

 

IMPORTANT!

  • GlobalProtect gateway will be assigning IPs from this pool to clients. Specify the one or more IP pool ranges which DO NOT OVERLAP with any of the existing networks in the organization. Overlapping subnets can cause routing issues and network outages.
  • (Optional but recommended) You can add a second IP pool range for backup which will be useful in cases where the user connects a wifi that is providing same IP pool range as your primary IP pool.

GP-GW-IP-pool.png

g. Access Route. This defines which subnets can be reached by GP clients once they are connected to gateway.

  • If left blank, it takes it as 0.0.0.0/0 ie all the traffic from GP client will be forced to go through GP tunnel.
  • For Split tunneling: Specify required internal subnets like 10.0.0.0/8, 192.168.x.0/24 etc so that GP client will use the tunnel to reach only these subnets. Anything outside these subnets will be accessed directly from the client's local network, this is called split tunneling.

 

h. Click OK to save and close client settings. One more OK to save and close GP gateway settings.

 

11. Create a local username/password under Device>Local user database>users for testing.

12. Create security and NAT policies for the newly created VPN zone to give access appropriately.

13. Commit the changes.

 

Installing client/machine cert in end client

 

This is a pre-logon, hence we need to use 'machine' certificate.

 

When importing a machine certificate, import it in PKCS format which will contain its private key.

 

Windows - 

 

1. Click start > Run, type mmc to open Microsoft certificate management console.

1.JPG

2. Go to File > Add/Remove Snap-in

 add-remove-snapin.png

 

 

IMPORTANT!

 

3. Click Certificates > Add and select one or both of the below:

 

a. To add machine(device) certificate, select 'Computer Account'. This is used for 'pre-logon' as it authenticates a machine.

cert-1.png

 

 

 

 cert-2.png

 

 

4. Import machine certificate into mmc.

For importing machine certificarte, import it to 'Personal' Folder under 'Computer Account'

cert-3.png

 

 

 

5. Similarly import the Root CA in the 'Trusted Root Certificate Authorities and Intermediate CAs(if any) in the 'Intermediate Certification Authorities'

cert-4.png

 

 

 

IMPORTANT!

 

6. Once imported, double click the imported machine certificate to make sure

 

a. it has private key

b. its certificate chain is full upto its root CA. If the chain is missing root CA or intermediate CA, import them to their respective folders as explained in Step 5.

 cert-5.png

 

 cert-6.png

 

 

7. At this point the certificates are imported on the client, you can close the mmc console without saving it.

 

To test on client machine

 

1. From the browser go to https://gp.portal-gw01.local/ ie https://<portal-ip/fqdn>

2. Enter the credentials

3. Download the GP client 

4. In the GP client, enter the Portal address and credentials, click connect.

5. On the gateway firewall, you will see that actual user connected.

6. Log-off from that computer to simulate pre-logon situation

7. On the gateway firewall, you will see the pre-logon user connected.

8. Log into the computer with actual username,

9. On the gateway firewall, you will see the pre-logon gets renamed to actual user.

 

 

Comments

I am curious why you would choose to utilize the connect method Pre-logon (Always On) , for the "any" users portal app config. I would have expected to use the connection method of User-logon (Always On) for the "Actual users" client config since you are no longer in a pre-logon state. 

Been looking for this guide for a while now.

Much better than other Admin Guides.

A few additional steps would be on how to push this via SCCM or what Regkeys need to be updated so that no user interaction would be required anymore.

(Optional)Authentication override, this is mandatory in my lab set up. or it would report 

 

HTTP/1.1 512 Custom error

Server:

Date: Fri, 28 Apr 2017 14:07:12 GMT

Content-Type: application/xml; charset=UTF-8

Content-Length: 0

Connection: keep-alive

ETag: "37623-5ef-58a37b58"

Pragma: no-cache

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

x-private-pan-globalprotect-extension: auth-failed-password-empty

x-private-pan-globalprotect: auth-failed

Expires: Thu, 19 Nov 1981 08:52:00 GMT

X-FRAME-OPTIONS: DENY

Set-Cookie: PHPSESSID=808761d72fc3600025dc99d540dfb435; secure; HttpOnly

I'm not sure how does this work for you on version 8.0.2 and GP 4.0.2-19 


In our scenario we have LDAP Authentication and Certificates. 

Using the infromation from this article I can get pre-logon running based on certificates only or on LDAP only but not both.


My desired outcome is that the machine comes up, presents certificate and gets pre-authenticated (pre-logon)

User logs in, the tunnel comes up as user.


However whatever I try to do with the setting provided in this article I get authentication failed on pre-logon.

 

Can this article be updated for version 8+ ? 

 

 

 

Hi MP_IRL - have you found a solution to this yet? I am experiencing similar issue whereby I couldn't get both Pre-Logon and User-Logon working at the same time. The system log indicates both successful and unsuccessful Pre-Logon attempts respectively.

 

I find this to be very good article over pre-logon. If all steps followed it should work. 

I have configured pre-logon with difference that I use LDAP authentication and PKI to distribute certs.

What I would like to add to this article is that we also need security policies configured, and also specific for user pre-logon.

 

The problem is we can't see pre-logon user in the traffic logs, unless we create specific rules with user added.

The next screenshot shows 2 rules configured, one for domain services and other for AV update.

 

pre-logon policies.png

 

If no specific rules are added, pre-logon will just use any other matching rule configured for GP clients.

So the advantage of having specific rule is visiblity on the first place.

 

The new client version 4.1 will even display connection information prior to login into windows. Windows 10 will connect on the wireless before the users logs in.

I have tested this and indeed machine is connected even before I login. This provides the similar experience as connected on the local network. 

 

https://www.paloaltonetworks.com/documentation/41/globalprotect/globalprotect-app-new-features/new-f...

 

 

To everyone above me who has had troubles getting pre-logon and user-logon working with LDAP and machine-based certificates - there was a bug introduced in PanOS 8.0.0 that prevented the pre-logon tunnel from working with machine based certificates that wasn't patched until 8.0.4. I recently upgraded to 8.0.4 and am running the config mentioned in this article, albeit with several differences:

 

- I changed the cookie lifetime for the pre-logon from 24 hours to 30 days (change made today, upgrade a week or two back). What I've been seeing since going to 8.0.4 is that the pre-logon tunnel works for some users, sometime. However, my theory is that if a user doesn't login to their computer for 24-hours since they last logged in, then the cookie to authenticate the pre-logon user has expired. If this happens and the user is on, say, the untrust wireless network or at home, they may experience problems with logins. Would love for someone to give a recommendation on another length of time for this...

     - (3/13/2018 edit): One thing we've noticed with the 30-day lifetime on this cookie is that if a user is rapidly removed from the company and you revoke the certificate in use, the pre-login tunnel will still login successfully until those 30 days are up for the cookie. Other than this, I do not believe my GP config has changed much (or at all) since this comment 6 months back and it has been going strong!

 

- To what tshannon questioned: I think the person who created this article fat-fingered the user-agent config. I've never used the pre-logon (always on) option for a user setting, have never seen a config guide telling me to do so, nor had a PA engineer tell me the user-logon (always on) is the incorrect option.

Hi ,

 

I tried it but pre-logon just effect when the client logoff computer. (Can see pre-logon on gateway)


But when the client start/restart computer, it seem not effect (didn't see pre-logon on gateway).

 

Anyone help me on this ?

 

Thank You,

hi @TranTienDat

 

If you followed the steps and it's not working, you may need to reach out to support

Would this work if auth profile is SAML and with cert profile configured

Hi All,

 

How to resolve problem when cookies authentication expired for pre-logon ?

The logs like as bellow:
GlobalProtect portal user authentication failed. Login from: 10.10.10.113, Source region: 10.0.0.0-10.255.255.255,  User name: pre-logon, Client OS version: Microsoft Windows 10 Pro , 64-bit, Reason: Cookie expired, Auth type: cookie.

 

Thank You and Best Regards,

dat