About SpencerMitchell

GlobalProtect: 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 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 CA Navigate to   Device > Certificate Management > Certificates > select the newly created machine certificate   > Export Certificate  Set the   File Format to Encrypted Private Key and Certificate PKCS12 and enter a   Passphrase twice Install the certificate on your test machine For the steps with Windows machines, read the following article:   Deploy Machine Certificates for Authentication   For the steps with OS X machines, please read the following articles:   Import a personal certificate into Mac Keychain   GlobalProtect Requests System Keychain Access on OS X For the steps with iOS machines, please read the following article: Configure GlobalProtect App 5.0 on iOS 12 to Use Client Certificate For Authentication   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 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 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:  Authentication Override is enabled and the   Certificate Profile created previously   is applied under the   Portals > (your portal) > Authentication tab Authentication Override is   enabled and the Certificate Profile created previously   is not applied under the Portals > (your portal) > Authentication tab 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 Config Navigate to   Config Selection Criteria   and set   User/User Group   to   pre-logon Configs > 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 Gateway Navigate to External and enter the same information that exists in your other agent configuration Configs > 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) 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 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) 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 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 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. ... View more

GlobalProtect: Authentication Policy with MFA   In my previous article, " GlobalProtect: User/Device Context & Compliance ," we covered security policy matching based on user identity and device context provided via the GlobalProtect app. We also enabled notifications to the end user based on compliance of the endpoint.   In this post, we are going to configure 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 .   The value in leveraging Authentication Policy with MFA is to ensure that regardless of whether or not a user is known and the device is compliant, they must authenticate with multiple factors to validate their identity prior to accessing a specific resource. This helps prevent lateral movement by malicious attackers that are persisting internally via a compromised machine or with phished credentials.   NOTE: This article assumes the following: You have already followed the previous articles in this series You have   DUO MFA configured Although this capability can be configured without GlobalProtect for HTTP applications, we are going to focus on non-HTTP applications to highlight the GlobalProtect app's role in the authentication prompt process.     Part IV - Authentication Policy with MFA Navigate to   Device > Certificate Management > SSL/TLS Service Profile > Add to create a profile that references the root CA created previously SSL/TLS Service Profile to Add a Profile Navigate to   Device > Authentication Profile > Add to create a new profile that consists of the LDAP and DUO   Server Profiles that were previously created On the   Authentication tab Enter a   Name Set the   Type to   LDAP Set the   Server Profile to   LDAP Enter a   Login Attribute of   sAMAccountName Set the   User Domain to your domain Authentication Profile to Set User Domain On the   Factors tab Check the   Enable Additional Authentication Factors box Add the   Multi-Factor Authentication Server Profile that was previously created as part of your DUO setup Authentication Profile for LDAP Auth-Duo On the   Advanced tab, select the user group previously created to add to the   Allow List Click   OK Navigate to   Device > User Identification > Captive Portal and click on the gear icon Check the   Enable Captive Portal box Select the   SSL/TLS Service Profile and   Authentication Profile that were previously created Set the   Mode to   Redirect Set the   Redirect Host to an IP address of an interface on the firewall In my case, its the IP address of my trust interface Click  OK Captive Portal window to Enable Captive Portal Navigate to   Network > GlobalProtect > Portals > select the previously configured portal   > Agent > select the previously configured config   > App > and change the following   App Configurations parameters Set   Connect Method to   User-logon (Always On) Set   Enable Inbound Authentication Prompts from MFA Prompts (UDP) to Yes Set   Trusted MFA Gateways to the IP address referenced in your   Captive Portal along with port 6082 In my case its   192.168.1.254:6082 Click   OK Config App Tab App to Configurations Parameters Navigate to   Objects > Authentication > Add to create a new Authentication Enforcement Enter a   Name Set the   Authentication Method to   web-form Set the   Authentication Profile to the MFA profile that was previously created Click   OK Authentication Enforcement for Duo Navigate to   Policies > Authentication > Add to create an authentication rule NOTE: If you need a resource for testing, there are plenty of test SSH servers available publicly. In the example below, that is what I am using As shown below, any user in the trust or gp zone that generates traffic destined to a specific server in the untrust zone will be prompted to authenticate, regardless of whether they are a verified user or not Policies > Authentication > Add Authentication Rule Commit the configuration Lastly, when testing with a Windows client, make sure that the host firewall is allowing UDP port 4501 inbound   You should now be able to test access to the resource. Here is the general workflow that you can follow: Ensure the GlobalProtect app is connected to either an external or internal gateway From operational mode in the CLI, run the  ' show user ip-user-mapping all type CP' to show authenticated users It should show   0 users Attempt to access the resource referenced in the Authentication Policy rule, and you will see a prompt requiring you to authenticate GlobalProtect - Protected Resource Upon authenticating via the factors you defined, you should be able to access the resource as well as run the same  'show user ip-user-mapping all type CP'  and see your user account In my next article, "GlobalProtect: Pre-Logon Authentication," we will configure pre-logon authentication using machine certificates. ... View more

GlobalProtect: User/Device Context and Compliance     In my previous article, " GlobalProtect: Expanded Setup ," we covered the expanded setup of GlobalProtect, which included multiple authentication types, as well as the creation of an internal gateway.   In this post, we are going to modify security policy matching based on user identity and device context provided via the GlobalProtect app. We will also enable notifications to the end user based on compliance of the endpoint. You can see a diagram of the environment  here . The value in leveraging user identity and device context in security policy along with end user notifications allow for greater visibility as well as more granular control over what users can access. This same methodology is applicable regardless of user location, and best practices dictate that they should be leveraged wherever possible. If a user is outside of what is required in order to access resources, they can be notified or mapped to a different rule to provide the minimum level of access required in order to become compliant.   NOTE:  This article assumes that you have already followed the previous articles in this series.   Part III - User/Device Context and Compliance Navigate to   Objects > GlobalProtect > HIP Objects > Add to create one or more test objects that are applicable to your environment Name the   HIP Object and enable, checking for something specific to your environment. In my case, I run Cortex XDR Prevent on my workstations, and I will be also testing via an iPhone, so I will create two objects called   AV and   iPhone. HIP Object - General Tab - AV HIP Object - Anti-Malware Tab HIP Object - General Tab - iPhone Navigate to   Objects > GlobalProtect > HIP Profiles > Add to create a profile that references both of the previously created objects NOTE: In the screenshot below, the profile will match based on either of the previously created objects HIP Profile - Compliant HIP Profile Navigate to   Network > GlobalProtect > Gateways > open each of the existing gateways   > Agent > HIP Notification > Add Select the   Host Information profile that was previously created On the   Match Message tab Check the Enable box Enter a message On the   Not Match Message tab Check the   Enable box Enter a message HIP Notification - Compliant HIP Profile - Match Message HIP Notification - Compliant HIP Profile - Not Match Message Navigate to   Policies > Security to create rules based on user group and device context As shown below, we are adding a user group and HIP profile as match criteria Security Policies - Add User Group and HIP Profile Commit the configuration You should now be able to log into GlobalProtect and see a message similar to the following: GlobalProtect - Home Internal Gateway Compliant   You should also be able to see rule matches via the   Traffic logs.   In my next article, "GlobalProtect: Authentication Policy with MFA," we will configure authentication policy with MFA for both HTTP and non-HTTP access to sensitive resources. ... View more