GlobalProtect: Expanded Setup
In my previous article, "GlobalProtect: Initial Setup," we covered the initial setup of GlobalProtect, which included a portal, external gateway, and user authentication via local database.
In this post, we are going to configure multiple external authentication types as well as add an internal gateway. You can see a diagram of the environment here.
Internal Gateways & External Authentication
The value of adding an internal gateway means that when users are on the local network, user-to-IP address mappings will be supplied to the firewall along with device context. This data can then be used as security policy match conditions, allowing for much more granular, identity-based visibility and enforcement. External authentication types are recommended for a production environment. In this case, we are going to configure the deployment to leverage LDAP authentication for the portal, MFA via RADIUS (AD credentials and Duo) for the external gateway, and LDAP authentication for the internal gateway. This will provide the best possible user experience for users when they are internal, while also enforcing additional factors of authentication when users are remote.
NOTE: This article assumes that you have already followed the initial setup, which is the previous article in this series. This article also assumes that you already have a domain controller (I am running Windows Server 2012 R2) in your environment installed with DUO authentication proxy installed and running. For details on DUO integration, see this post.
Part II - Expanded Setup
Navigate to Device > Server Profiles > LDAP > Add to create an LDAP Server Profile
NOTE: Best practices dictate that a dedicated service account be used for integrating your domain controller with Palo Alto Networks
LDAP Server Profile
Navigate to Device > Server Profiles > RADIUS > Add to create a RADIUS Server Profile
NOTE: Per my note above, this post assumes that you already have Duo Authentication Proxy installed and running on your domain controller
RADIUS Server Profile
Navigate to Device > User-ID > Group Mapping Settings > Add to create a Group Mapping
For Server Profile, select the LDAP profile that was previously created
Enter the domain name under User Domain
Group Mapping - Server Profile tab
Navigate to the Group Include List and add the group where your users are stored
NOTE: If you are unable to expand the available groups, this typically means that your credentials in the LDAP Server Profile are incorrect
Click OK
Navigate to Device > Authentication Profile > Add
For Type select LDAP
For Server Profile select the LDAP profile that was previously created
Enter sAMAccountName for the Login Attribute
Enter your domain for the User Domain
Authentication Profile - LDAP type
Navigate to the Advanced tab and select the user group that was previously added to the Group Include List, which was part of the Group Mapping you previously created
Click OK
Navigate to Device > Authentication Profile > Add
For Type select RADIUS
For Server Profile select the RADIUS profile that was previously created
Enter your domain name of the User Domain
Authentication Profile - RADIUS Type
Navigate to the Advanced tab and select the user group that was previously added to the Group Include List, which was part of the Group Mapping you previously created
Click OK
Navigate to Network > GlobalProtect > Gateways > select the existing external gateway > Authentication > select the client authentication > change the Authentication Profile to the RADIUS profile that was previously created
GlobalProtect Gateway Configuration - Home External Authentication
Click OK
Click OK
Navigate to Network > GlobalProtect > Gateways > Add to create an internal gateway
Select the Interface and IPv4 Address that correspond to the trust interface
Navigate to the Authentication tab
Select the SSL/TLS Service Profile that was created in the previous post
Create a new Client Authentication profile and select the LDAP Authentication Profile previously created
GlobalProtect Gateway Configuration - Home Internal Authentication
Click OK
Click OK
Navigate to Network > GlobalProtect > Portals > select the existing portal > Agent > select the existing portal config > Internal > Internal Gateways > Add to create an Internal Gateway
The IPv4 entry should correspond to the IP address assigned to the trust interface
Click OK
Internal Gateway - Home Internal Gateway
Navigate to the App tab, and set the Connect Method to User-logon (Always On)
NOTE: Internal Gateway authentication will fail if the Connect Method is set to On-demand
Click OK
Click OK
Navigate to Device > Certificate Management > Certificates > Generate
NOTE: As you already created a GlobalProtect certificate in the previous post, you will be creating a new one that both the external and internal gateways can reference. The previous certificate contains a common name that refers to the IP address of the portal and external gateway. As the IP address of the internal gateway is not referenced, this will cause authentication to the internal gateway to fail.
NOTE: Keep in mind that you can also leave the current certificate in place and just create a new one for the internal gateway (essentially, having two), but for the purposes of this post, we will be creating a single certificate to be used for everything.
Enter a Certificate Name
Enter the IP address or the DNS name of the interface to which remote users will connect for Common Name
NOTE: In this series of posts, we will be using the public IP address for the common name (represented by 1.1.1.1). It is recommended to use a DNS name in a production environment, but IP addresses will work as well.
Select the root CA that was previously created for Signed By
Enter the IP address of the trust interface that corresponds to the internal gateway under Certificate Attributes
GlobalProtect Generate Certificate
Navigate to Device > Certificate Management > SSL/TLS Service Profile > select the existing profile that was created previously and change the Certificate value from the old certificate to the new one that was just created
Click OK
SSL/TLS Service Profile
Navigate to Policy > NAT > Add
NOTE: A NAT rule must be created so that the internal users can reach and authenticate to the portal from the internal network
In the General tab, enter a Name
In the Original Packet tab, set the Source Zone to trust, Destination Zone to untrust, and the Destination Address to the untrust IP address (the IP address to which the GlobalProtect Portal is assigned)
In the Translated Packet tab, leave everything set to None
Click OK
Creating a new NAT rule
Commit the configuration
You should now be able to authenticate both internally and externally via the GlobalProtect app and access resources. It is important to note that authentication failures to an internal gateway are notoriously quiet. In other words, it will look as though you are connected even when you are not. You can validate connectivity by issuing the ' show user ip-user-mapping all type GP' command. If there is no mapping present, then it means that the app was unable to connect and authenticate to the internal gateway.
In my next article, "GlobalProtect: User/Device Context & Compliance," we will make changes to the configuration to include security policy matching based on user identity and device context via the GlobalProtect app. We will also enable notifications based on compliance of the endpoint.
... View more