Avoid fetching duplicate groups in group-mapping profile

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.

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

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

as test\gptest.

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.

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.

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.

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.