Workflow and Troubleshooting checklist for policy enforcement based on user groups
Symptom
Symptoms
This document provides a walk through into policy enforcement based on user groups retrieved from Active Directory
Pre-requisites
You should have a working knowledge of:
Active Directory
User-Id feature on the Palo Alto Networks firewall
Components Used
The information in this document is based on these software and hardware versions:
Palo Alto Networks VM firewall running PANOS 7.1.7
Active Directory Services running on Microsoft 2012 r2 server, configured as a Domain controller
The information in this document was created from the devices in a specific lab environment.
If your network is live, make sure that you understand the potential impact of any command
Consider a security policy which is configured with groups retrieved from active directory domain controllers using LDAP
The policy appears as below, with the groups configured under the "user" section
Let us take a look how does the PAN firewall enforce policies based on the groups configured in the security policies
Diagnosis
Workflow
1. The firewall performs a top down lookup through the policy rulebase to find a match and uses the group as one of the key fields.
2. The User-id feature on the Palo Alto Networks firewalls enumerates usernames with ip address.
It fetches the IP address from the source IP address field of the IP header of the packets, ingressing on the security zone of the firewall where user-id feature is enabled
Consider the security policy above which is configured with groups named "captive portal" and "sme_group" retrieved from active directory using LDAP , under the "user" section
In the above example the security policy is configured from zone "dmz" or "trust" hence it is imperative that user-id should be enabled on these security zones
3. Once enabled the firewall attempts to resolve the username for every IP address during the session installation phase, also known as 'slowpath'
For username to ip mapping it may leverage any of the methods such as Software based User-id agent , PANOS or Agentless userid, Syslog, XMLAPIs or Captive Portal etc
4. Once the firewall gets the username corresponding to the source IP address of the packet the next step is to determine the groups to which this user belongs
In most of the enterprises firewall retrieves groups from active directory domain controllers using LDAP
5. Now it compares the username from the username-ip cache with the username in the group-mapping cache on the Data Plane
6. If the username exactly matches between the two caches then the firewall is able to determine the IP address with it's username and its corresponding group membership
With the group name or membership retrieved it can perform a top down policy look up to find a matching policy
Resolution
Troubleshooting and Checklist
1. Ensure that groups are retrieved from active directory
In this scenario the two groups namely captive_portal and sme_group are retrieved from Active directory
2. Check the membership within these groups
In this you can explicitly look for the users which are a part of the group "sme_group" or similarly for "captive_portal"
3. Group-mapping cache showing the membership of the users with the respective groups it belongs to on the active directory
4. Note the username and its format in the user-ip cache on the data plane (DP)
It's the same as the one in the group-mapping cache
Since the username "test\testuser" in the ip-user cache matches exactly with the username in the group-
mapping cache so the firewall can find all the policies where these groups are being used
Look closely at the "Groups that the user belongs to (used in policy)" section and the groups under it
It lists all the groups to which the user "test\testuser" belongs and which are referenced in the policies
If the username were not to be a mis-match then these groups would not be present
Please refer Avoid fetching duplicate groups in group-mapping profile for more information on this