Palo Alto Networks Knowledgebase: Avoid fetching duplicate groups in group-mapping profile

Avoid fetching duplicate groups in group-mapping profile

1806
Created On 02/08/19 00:06 AM - Last Updated 02/08/19 00:06 AM
User-ID
Resolution

Scenario

 

For username-to-IP address mapping, the software-based and agentless User-ID agent installs the most recently learned mapping. Consider an example where user1 is mapped to ip1 and this mapping is learned via an agentless userid agent, then the source is A. Now, if user1 launches a VPN connection via GlobalProtect from the same PC and is assigned a new IP address, then the username-to-IP mapping would change on the firewall to user1 and ip2 ,and the source is GlobalProtect. Hence, the old user cache of user1 and ip1 is overwritten by the new entry of user1 and ip2.

 

Similarly, groups retrieved from an active directory domain controller should be unique in each group mapping profile.
It can be argued that groups are often referenced in security policies and it doesn't matter which group-mapping profile
we get this information from, but in some cases it does matter and may well turn the tables completely.

 

In the following scenario, you'll notice that the same group, when referenced from two different group mapping profiles, can cause issues in matching the security policy due to failure to match a user against the active directory group to which it belongs.

 

A group mapping profile is configured with user domain under Domain Settings as test, where

test is the netbios domain name equivalent of the FQDN domain name test.kunaldc.com.

 

 GM SCREEN1.JPG

 

A group, cn=group2,cn=users,dc=test,dc=kunaldc,dc=com is fetched using this group mapping profile.

 

show user group mapping.JPG

show usr group name.JPG

 

A user gptest belongs to this group and its username is stored as domain\username format on the firewall

as test\gptest.

 

show usr group name.JPG

show usr group name.JPG

 

show-User-userid.JPG

 

Now configure another group mapping profile, AD-FQDN-FORMAT, where the user domain is not overridden and is test.kunaldc.com instead of test.

 

Use the include group option to include only the above AD group in this group-mapping profile.

 

Commit this change.

 

GM SCREEN 2.JPG

 

 

When the group-mapping refresh is complete, then check the group-mapping state.

 

Now the same AD group, cn=group2,cn=users,dc=test,dc=kunaldc,dc=com, is also fetched by the new group-mapping profile AD-FQDN-FORMAT.

 

show user group mapping 2.JPG


Carefully look at the usernames that belong to this group.

The username format has been changed from netbios\user to fqdn\user.

The source has also been changed from the old group-mapping profile - GPOUP-MAPPING-TEST to the new one,

AD-FQDN-FORMAT.

 

show user userid 2.JPG

 

The primary issue that arises now is that the username learnt via any User-ID mechanism (agent or agentless User-ID / GlobalProtect /captive portal, etc.)  doesn't match the username format in the group-mapping table.

 

Traffic from the same user would fail to match the security policy where this user group is referenced.

 



Attachments
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClemCAC&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Attachments
Choose Language