Description
This article explains why user group membership updates may not reflect immediately on FortiProxy due to LDAP caching mechanisms.
It outlines how short-term and long-term caches are used to reduce LDAP server load and how this impacts group membership synchronization.
Scope
FortiProxy.
Solution
The authentication methods covered in this manual will always involve some communication with a remote server, such as Samba authentication, LDAP user binding, and LDAP group queries.
To improve performance, the FortiProxy unit builds some short-term and some long-term group information caches.
When the LDAP group query is finished, the FortiProxy unit always builds a short-term cache, so when the user is authenticated, the short-term cache is searched first.
If there is a match, the LDAP group query procedure is saved. The proxy-auth-timeout setting controls the lifetime of this cache.
During workday mornings, all short-time caches are flushed off the off-work inactivity.
Workday mornings create some authentication traffic bursts toward the server, with more users logging on at the same time. If this is an issue, the FortiProxy unit has one long-time cache (using the ldap-user-cache setting).
When the long-time cache is enabled, the group cache is kept for 15 days for inactivity and uses background refreshing to fetch server-side changes.
The FortiProxy unit queries the local short-time cache first and then queries the public long-time cache.
If there are any cache hits, there is no external server communication.
This is done to prevent a higher load on the LDAP server itself, as otherwise, FortiProxy would send group membership queries for all users with each new authentication request.
This can especially generate a high load on the LDAP server with session-based authentication.
A common misunderstanding is that the config system global setting 'proxy-auth-lifetime' would control when the group is updated, however, the group membership stays cached inside FortiProxy for the predefined time, regardless of the 'proxy-auth-lifetime' timeout value.
To have real-time communication with the AD, the long-time cache must be disabled:
config web-proxy global
set ldap-user-cache disable
end
Enable: LDAP auth is done by WAD user-info.
Disable: LDAP auth is done by fnbamd.
Note that the 'ldap-user-cache' option only works with Windows AD. For any other vendors like Novel e-directory LDAP server, the 'ldap-user-cache' option should be disabled.
To ensure group changes are seen for already authenticated users, it is necessary to unauthenticate the individual explicit proxy user or the whole user list:
diagnose wad user clear <----- Clear all proxy users.
diagnose wad user clear <ID> <IP> <VDOM> <----- Clear a specified user.
Example:
diagnose wad user list
ID: 2, IP: 10.0.11.142, VDOM: root
user name : proxusr@DOMAINTEST.LOCAL
duration : 124
auth_type : 0
auth_method : 3 (Kerberos)
pol_id : 12
g_id : 11
user_based : 0
expire : 8
LAN:
bytes_in=107500 bytes_out=1169255
WAN:
bytes_in=799170 bytes_out=40959
diagnose wad user clear 2 10.0.11.142 root
The next authentication attempt should fetch the user's group information from the LDAP server, any new group change performed for this user on the LDAP will be shown in the group membership for the authenticated user.
Note:
Disabling the 'ldap-user-cache' can cause more load on the LDAP /AD server, depending on the number of authentication requests and many proxy users, as it would send more queries to the LDAP server.
Troubleshooting
By default, the user cache and group cache timeout is set to 1440 seconds. It can be changed to 5 minutes for troubleshooting purposes. To do that, execute the following –
diagnose debug enable
diagnose test application wad 2500
diagnose test application wad 1900005 <----- Changes user cache timeout from 1440 to 5 minutes.
diagnose test application wad 1910005 <----- Changes group cache timeout from 1440 to 5 minutes.
To verify if the timeout setting changes are applied, execute the following –
diagnose debug enable
diagnose test application wad 2500
diagnose test application wad 170 <----- For FortiProxy 7.2.x,
diagnose test application wad 181 <----- For FortiProxy 7.4.x.
For example:
diagnose debug enable
diagnose test application wad 2500
diagnose test application wad 181
User Info Server Stats:
user cache flush timeout(min): 5
group cache flush timeout(min): 5
To find out if the FortiGate retrieved the group information from the cache, execute the following commands -
diagnose debug enable
diagnose test application wad 2500
diagnose test application wad 159
To test, make a group membership change on the AD, then wait for 5 minutes (or the time set for user and group cache timeout as shown above), and then execute the above-mentioned commands to check if the FortiProxy has updated the user group cache.
For example:
diagnose debug enable
diagnose test application wad 2500
diagnose test application wad 159
uname=Testuser@corp.example.com,pwd=no,vd=root ldap=prod-example.com,ref_cnt=1,upd=0,wait=0 sid-auth=0,status=2 last_access=Thu Apr 10 13:46:45 2025 <- LDAP Query time
user id=999, refresh_time=Thu Apr 10 13:39:39 2025 <- Cache Refresh Time
user dn=CN=Testuser,OU=TestStore,OU=TestGroup Users,DC=CORP,DC=EXAMPLE,DC=COM
sid:S-0-0 name=CN=FortiProxyUsers-AllUsers,OU=Security Groups,DC=CORP, DC=EXAMPLE,DC=COM
If the FortiProxy has successfully updated the group cache from the AD, then the output above should show the new group membership in the cache, and the LDAP Query and Cache Refresh time should be updated as well.
For more diagnostic information, the following debugs can be run after making the group membership change in the Active Directory -
diagnose wad debug enable category auth
diagnose wad debug enable category http
diagnose wad debug enable level verbose
diagnose debug console timestamp enable
diagnose debug enable
Note:
After making the changes in the Active Directory, it may take at least 30 minutes to sync the group information changes to all the AD nodes.
