Palo Alto - Zero Trust in Practice
INTERSECT '23: Network Security Summit: Hands On Lab to get hands-on experience with Palo Alto’s Zero Trust for identity solution
Last updated
Was this helpful?
INTERSECT '23: Network Security Summit: Hands On Lab to get hands-on experience with Palo Alto’s Zero Trust for identity solution
Last updated
Was this helpful?
Objectives
Activity 1: Explore Cloud Identity Engine (CIE) Directory Sync feature
Activity 2: Configure Palo Alto firewall to sync cloud directory information from CIE
Activity 3: Create a user-id based Security policy
Activity 4: Review CIE’s Cloud Authentication Service
Activity 5: Setup Palo Alto Firewall for Cloud Authentication Service
Activity 6: Create Authentication Policy rules and Test Authentication
Activity 7: Restrict user access via Security policy
Activity 8: Enable forward proxy Decryption
Activity 9: Add Threat Prevention, URL filtering and Wildfire
Activity 10: Learn about AIOps
The dotted lines represent OOB (out of band) management traffic.
Windows and Linux client machines are configured to use VM series firewall (ETH1/2) as the default gateway. All outgoing traffic from these machines, except RDP and SSH, will flow through the VM-series firewall.
Windows and Linux client machines can only be managed via the windows jump server.
The Palo Alto Networks VM series firewall has a public IP address configured on its management interface. It can be accessed using its public IP address directly from your laptop's browser or Windows jump server.
VM-series firewall will connect to the Cloud Identity engine using the Internet via its Mgmt interface.
The Windows and Linux client can only reach the Internet using NAT policy pre-configured on the firewall using ethernet 1/1.
The Cloud Identity Engine instance is shared between all users of this lab, please do not make any changes to its configuration.
Learn about CIE Directory Sync feature
Get familiar with CIE user interface
Explore existing cloud directories that are integrated with CIE
Reviewing pre-configured Okta and Azure Directories.
Recap - This activity explored the Okta and Microsoft Azure AD directories in the Cloud Identity Engine (CIE) and how these directories are integrated with CIE along with the different user and group information that is accessible from CIE.
Associate Cloud Identity Engine with the Palo Alto VM series firewall
Enable User Identification capability on the Network Zones
Navigate to Device -> User Identification -> Cloud Identity Engine -> Add
Enable User-identification in Trust Zone by navigating to Network -> Zones -> Trust
Create a new security policy and utilize the user group learned from Okta directory via CIE
Verify that the user-id information with the correct username attribute is downloaded on the firewall
On the firewall, navigate to Policies -> Security -> Click Add to create a new policy rule
Create a security policy rule to allow all traffic from any source zone, source user-group panw-zt.oktapreview.com\zt-group to any destination
From the Windows jump server, use Putty to open a new SSH connection to the firewall. Use the public IP address of the firewall to create an ssh session.
Verify that the Okta group panw-zt.oktapreview.com\zt-group is programmed on the firewall & display all the users that are of Okta group zt-group:
Verify all the users that Cloud Identity engine learned from Okta group zt-group are shown.
In the cloud identity Engine go to Directories -> Under Okta directory click group number to see Okta groups:
Click on the details button to see the group information including the members of the group and match it with the users learnt on the firewall:
Display the directory attributes that are used for primary username, email and Alt UserNames.
Recap - This activity demonstrated how to create a security policy that applies to user-group zt-group from the Okta Directory service to then confirm from the firewall's CLI that the firewall correctly pulled all the group and user information from Cloud Identity engine.
Learn about Cloud Identity Engine’s Cloud Authentication Service
Review the pre-configured Identity provider configuration in Cloud Identity engine
The Cloud Authentication Service uses a cloud-based service to provide user authentication using SAML 2.0-based Identity Providers (IdPs). When the user attempts to authenticate, the authentication request is redirected to the Cloud Authentication Service, which redirects the request to the IdP. After the IdP authenticates the user, the firewall maps the user and applies the security policy.
You can configure most SAML 2.0-based identity providers (IdPs) in the Cloud Identity Engine to authenticate your users. Currently the following IdPs are supported:
Azure AD
Okta
PingOne
PingFederate
In CIE, click on Authentication Types and review the two pre-configured authentication types created for Okta and Azure AD
Authentication profile redirects users behind the firewall to the correct authentication type. On CIE, click on Authentication Profiles to see the two profiles created, one for each Authentication type. These Authentication profiles will be referenced from the firewall in the next section of the lab
Recap - This activity shows CIE’s Cloud Authentication Service feature. You saw a demo of how it is configured and reviewed the existing configuration.
Create Authentication Profile to authenticate users against Okta IDP via Cloud Identity Engine
Configure Authentication Portal to use Authentication profile and redirect users for authentication
Create a new Authentication Enforcement Object and tie that with the Authentication profile
Log-in to firewall and navigate to Device -> Authentication Profile and Click Add to create a new Authentication Profile.
Navigate to Device -> User Identification -> Authentication Portal settings and click on the gear icon ⚙ to modify the settings
Modify the following Authentication Portal settings:
Set the authentication profile to Okta-Authprofile that was created in Task 1.
Set the mode to redirect.
Set Redirect host ip as 10.101.0.100. This will ensure that the incoming requests on Eth1/2 (Trust Interface) will be redirected for Authentication based on the Authentication profile.
The Authentication Enforcement object uses the Authentication profile to redirect users to log-in using their authentication type. It ties Authentication policy to the Authentication profile.
Navigate to Objects -> Authentication and Click Add
Commit configuration changes on the firewall and wait for completion:
Recap -This activity demonstrated how to create the authentication profile, modified authentication portal settings and created an Authentication Enforcement object. This configuration is necessary for completing the cloud authentication service setup.
Review URL Category object that is utilized in the authentication policy rule
Create authentication policy rule that allows users to bypass authentication when trying to reach the Identity Provider’s sign-in web applications
Create Authentication Policy rule to require users to authenticate before accessing web traffic
Test Authentication Policies from Windows client
Verify user-to-ip mapping on firewall using SSH
It is important to ensure that prior to valid authentication, the user is allowed to access Identity provider’s URLs that are necessary for authentication. If these URLs are blocked then the user will not be able to complete the sign-in process with the IDP and consequently won’t be able to access the network.
auth_whitelist is pre-configured and contains all the URLs necessary to complete authentication with Microsoft Azure AD and Okta. Review the URLs by navigating to Objects -> Custom Objects -> URL Category -> auth_whitelist. No configuration changes are required in this step.
Navigate to Policies -> Authentication and Click Add
This policy rule will ensure that anytime a user attempts to go to any URLs defined in the auth_whitelist object, the user isn’t redirected.
Click Add to create a new policy rule
Configure a new Authentication Policy Rule:
Select Any for Source and Destination Zones
Add service-https under Service/URL Category
Under Actions, set Authentication Enforcement to AuthObj that was create earlier to redirect users to Okta for authentication. Click OK to save the Policy rule.
RDP into the Branch1-Windows machine
From the Windows client, open up Google chrome in Incognito mode and navigate to www.yahoo.com. You should be redirected to the firewalls Eth1/2 interface (10.101.0.100)
Click Advanced and then Proceed to 10.101.0.100 (unsafe)
Log in to Okta and the user should be redirected to Yahoo’s website on successful authentication.
Back on the firewall navigate to Monitor -> Log -> Authentication and take some time to review the logs and understand the sequence of events.
Notice the Authentication policy rule that's in effect and how it first redirects the user to Cloud Identity Engine which further redirects it to Okta for authentication. The firewall only has to interact with CIE for authentication.
Switch back your Cloud Identity Engine session and click on Log Viewer to see the detailed log for successful authentication attempt.
SSH into the firewall on its public IP address from Windows Jump server or directly from your laptop.
