Fortinet black logo
2.0.2

Performance considerations

Performance considerations

To improve authentication performance, consider the following:

Group information cache

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 control the lifetime of this cache.

During workday mornings, all short-time caches are flushed of the off-work inactivity. Workday mornings create some authentication traffic bursts towards 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.

The following table summarizes the differences among the authentication methods.

Method

Client environment requirement

Convey sensitive information

IP based/session based

Server communication when cache hit

Kerberos Log on to domain No Both No
Basic No Yes Both No
Agentless NTLM No No Both Domain controller
Form based No Yes IP based No

PAC data

In Kerberos authentication, the client offers the Kerberos service ticket, which includes the PAC data. The PAC data is the group’s security identifier (SID) that the user belongs to. Every group has one unique SID (for example, S-1-5-21-186985262-1144665072-74031268-1309 is the SID for “cn=grp1,cn=users,dc=tony,dc=ca”). However, the FortiProxy cannot use SIDs directly. If pac-data is enabled in the keytab configuration, the FortiProxy unit translates the SID to the group name and creates one long-time cache. After the cache is built, there is no communication between the FortiProxy unit and the LDAP server, which is usually recommended for large deployments.

Server load balancing

If the ldap-user-cache feature is enabled, server2 and server3 in the user LDAP configuration can be used for server load balancing. The domain controller can support multiple servers in agentless NTLM authentication.

Use the srcaddr setting in the authentication rule to distribute the user’s authentication to multiple servers with multiple rules.

Performance considerations

To improve authentication performance, consider the following:

Group information cache

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 control the lifetime of this cache.

During workday mornings, all short-time caches are flushed of the off-work inactivity. Workday mornings create some authentication traffic bursts towards 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.

The following table summarizes the differences among the authentication methods.

Method

Client environment requirement

Convey sensitive information

IP based/session based

Server communication when cache hit

Kerberos Log on to domain No Both No
Basic No Yes Both No
Agentless NTLM No No Both Domain controller
Form based No Yes IP based No

PAC data

In Kerberos authentication, the client offers the Kerberos service ticket, which includes the PAC data. The PAC data is the group’s security identifier (SID) that the user belongs to. Every group has one unique SID (for example, S-1-5-21-186985262-1144665072-74031268-1309 is the SID for “cn=grp1,cn=users,dc=tony,dc=ca”). However, the FortiProxy cannot use SIDs directly. If pac-data is enabled in the keytab configuration, the FortiProxy unit translates the SID to the group name and creates one long-time cache. After the cache is built, there is no communication between the FortiProxy unit and the LDAP server, which is usually recommended for large deployments.

Server load balancing

If the ldap-user-cache feature is enabled, server2 and server3 in the user LDAP configuration can be used for server load balancing. The domain controller can support multiple servers in agentless NTLM authentication.

Use the srcaddr setting in the authentication rule to distribute the user’s authentication to multiple servers with multiple rules.