Traffic is hitting an incorrect security rule when the rule has an LDAP group as a source.
The users initiating the traffic are in the given LDAP group and should match a specific allow rule, but instead they are hitting a default deny rule.
If a "show user ip-user-mapping" is performed for a user that has the problem, instead of the information about groups the user belongs to, we see "Groups Info is outdated":
> show user ip-user-mapping ip 10.176.130.82
IP address: 10.193.88.82 (vsys1)
Idle Timeout: 2693s
Max. TTL: 2693s
Groups Info is outdated
On a user that is OK, we should see something similar to this output:
> show user ip-user-mapping ip 10.193.88.91
IP address: 10.193.88.91 (vsys1)
Idle Timeout: 6449s
Max. TTL: 6441s
Groups that the user belongs to (used in policy)
Group(s): cn=domain users,cn=users,dc=al,dc=com
The issue here is with the group being added to a security rule, before the user-id process had a chance to pull the information from the LDAP.
This usually happens when:
The domain admin creates the group in the LDAP (as a subgroup of an already monitored group on the firewall) and adds the user as a member of it.
Before the LDAP group refresh is done on the firewall, the admin creates a security rule using the same group, which he manually adds in the "user" tab of the policy creation.
To avoid this, after creating a new group on the LDAP server, wait for the group refresh on the firewall to happen and the group to become visible and selectable in the "user" tab of the policy creation process.