FortiProxy
FortiProxy provides enterprise-class protection against internet-borne threats and Advanced Web Content Caching
ppatel
Staff
Staff
Article Id 190075

Description

 

This article describes how users' group membership is not updated at FortiProxy.


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-time and some long-time group information caches.
When the LDAP group query is finished, the FortiProxy unit always builds a short-time cache, so when the user is authenticated, the short-time 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 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.


Solution

 

In order to have real-time communication with the AD, the long-time cache must be disabled:

 

# config web-proxy global
    set ldap-user-cache disable  <- by default it is enabled.
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, '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 that disabling the 'ldap-user-cache' can cause more load on the LDAP /AD server, depending on the number of authentication requests and a number of proxy users, as it would send more queries to the LDAP server.