----------------------------------------------------------------------------------------------------------------
In my previous post, 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.
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 post assumes that you have already followed the previous post in this series.This post 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 and create the following:
- LDAP Server Profile
- Note - Best practices dictate that a dedicated service account be used for integrating your domain controller with Palo Alto Networks.
- 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.
- 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
- 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
- Navigate to the Advanced tab and select the user group that was previously added to the Group Include List that was part of the Group Mapping that was 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
- Navigate to the Advanced tab and select the user group that was previously added to the Group Include List that was part of the Group Mapping that was 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
- 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 that was previously created
- 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
- 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 is mind that you could 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
- 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
- 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
- Commit the configuration
You should now be able to 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 this means that the app was unable to connect and authenticate to the internal gateway.
In my next post, 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.
thanks
ReplyDelete