Other issues

This section covers other issues that affect authentication.

When a server has made a group change and wants it applied immediately

The short-term and long-time group cache skips the group query procedure, so it cannot get the server-side change. To apply the server-side changes immediately, do the following:

1. Clear the short-time cache (deauthorize the user)
2. Clear the long-time cache if it has been enabled.
3. Clear the service ticket on the clientʼs PC if pac-data was enabled.

Improving the security of IP-based authentication in active authentication

Use the set proxy-re-authentication-mode absolute command, which forces IP-based authentication to re-map users after the proxy-auth-timeout timer is finished.

Users must explicitly log out using the FortiProxy web authentication portal before unplugging the network cable and exiting the desktop.

Clearing user group information

1. List all users authenticated by the WAN optimization daemon (WAD) in the short-time cache.

   diagnose wad user list

   diagnose wad user clear << clear the short-time user group cache

2. List all IP-based user membership and FSSO user membership.

   diagnose test application wad 2400 << switch to informer daemon

   diagnose test application wad 110

3. List all long-time group caches.

   diagnose test application wad 2500 << switch to user-information daemon

   diagnose test application wad 159 << user group cache

   diagnose test application wad 160 << clear user group cache

   diagnose test application wad 156 << SID group-mapping cache

   diagnose test application wad 157 << clear SID group-mapping cache

4. List the short-time group caches.

   diagnose test application wad 2200 << 2201, 2202, 22XX; XX is the worker ID

   diagnose test application wad 110

Redundancy for LDAP integration for Active Directory

To add redundancy, add a second server and third server to your configuration.

config user ldap

edit <LDAP_server_entry_name>

set server <server_name_or _IP_address>

set secondary_server <server_name_or _IP_address>

set tertiary-server <server_name_or _IP_address>

next

end

Active Directory/LDAP membership

In some environments, LDAP changes are not directly communicated on the FortiProxy unit with group membership updates. This issue might be caused by LDAP caching. To check if LDAP caching is the cause, temporarily disable the LDAP cache to see if the problem disappears.

config web-proxy global

set ldap-user-cache disable

end

Fortinet recommends enabling the LDAP cache.

Active Directory/LDAP browsing speed

With large Active Directory deployments, you can add a filter on the LDAP integration to speed up the browsing of the group and members.

config user ldap

edit "ldap_server"

set server "10.30.0.11"

set cnid "cn"

set dn "dc=domain,dc=com"

set type regular

set username "cn=admin,dc=domain,dc=com"

set password password

set group-filter "(|(objectclass=user)(objectclass=group))"<------- Group filter to only return users and groups

next

end

Session-based web-auth-cookie

The web-auth-cookie command is normally hidden. To make the web-auth-cookie command visible, you need to disable ip-based first.

After you enable web-auth-cookie, only one request per session is authenticated. This setting reduces authentication requests for existing sessions, which makes NTLM authentication more scalable.

config authentication rule

edit NTLM_rule

set srcaddr "all"

set ip-based disable --> to use only session-based authentication; the default is enabled

set active-auth-method "auth-scheme"

set web-auth-cookie enable --> available without IP-based authentication; the default is disabled

next

end

To enable web-auth-cookie when the FortiProxy unit is in explicit proxy mode:

1. Create an HTTP CONNECT service object.

   config firewall service custom

   edit "http-connect"

   set proxy enable

   set protocol CONNECT

   set tcp-portrange 0-65535:0-65535

   next

   end

2. Create a new policy and place it before the policy with user authentication. The new policy should not have any authentication applied to it, and SSL deep inspection is needed.

   config firewall policy

   edit 3

   set type explicit-web

   set explicit-web-proxy "web-proxy"

   set dstintf "port1"

   set srcaddr "all"

   set dstaddr "all"

   set action accept

   set schedule "always"

   set service "http-connect"

   set logtraffic all

   set log-http-transaction enable

   set utm-status enable

   set ssl-ssh-profile "FPX-deep-inspection"<===== You must apply deep inspection.

   next

   end

3. Check that the policies are ordered correctly. For example:

   config firewall policy

   edit 3

   set type explicit-web

   set explicit-web-proxy "web-proxy"

   set dstintf "port1"

   set srcaddr "all"

   set dstaddr "all"

   set action accept

   set schedule "always"

   set service "http-connect"

   set logtraffic all

   set log-http-transaction enable

   set utm-status enable

   set ssl-ssh-profile "FPX-deep-inspection"

   next

   edit 1

   set type explicit-web

   set name "Authenticate"

   set explicit-web-proxy "web-proxy"

   set dstintf "port1"

   set srcaddr "all"

   set dstaddr "all"

   set action accept

   set schedule "always"

   set service "webproxy"

   set logtraffic all

   set log-http-transaction enable

   set webcache enable

   set webcache-https enable

   set webproxy-profile "XFF"

   set users "IT Team""System Team"

   set utm-status enable

   set ssl-ssh-profile "FPX-deep-inspection"

   next

   end

Integrating authentication for multiple domains/forests

You can integrate multiple domains or forests. Integration works best with Kerberos authentication. You need to upload multiple keytab files and one LDAP-server configuration per domain/forest domain controller (or global catalog server). If there is no keytab specified, the FortiProxy unit tries all uploaded keytab files to decrypt the service ticket received in the client request (configure Kerberos with the CLI to leave the keytab file field empty).

Authentication is always done per user principal name (UPN), and the domain information is retrieved from the Kerberos ticket. This deciphered information is used to select the corresponding LDAP server.

Agentless multi-domain/forest integration with NTLM is trickier. It is best to use UPN format for the user name because it contains the domain. When only the user name is used for authentication, you are restricted to a single domain.

First, the user name is used to authenticate with the Server Message Block (SMB) service through the NTLM challenge/response mechanism. Second, authorization is with an LDAP search to retrieve group membership information for policy matching.

You need to configure an LDAP server per domain/forest.

Integrating redundant domain controllers

To set up a redundant domain controller, specify extra servers using the CLI. These servers are used to authenticate the user by retrieving domain information for NTLM authentication.

config user domain-controller

edit "domain1"

config extra-server

edit 1

set ip-address "10.0.0.2"

set port 445

end

end

end

Integrating redundant Active Directory services

To set up a redundant LDAP-server binding, use the FQDN of the LDAP server. The LDAP requests will get load-balanced if the FQDN resolves to multiple servers. Alternatively, you can configure multiple LDAP servers as secondary and tertiary servers using the CLI.

config user ldap

edit "ldap-server"

set secondary-server "10.0.0.2"

set tertiary-server "10.0.0.3"

end

Proxy-chain authentication

In a network topology where the downstream proxy performs the authentication and the upstream proxy performs the authorization, you can pass on authentication headers like x-authentication-user. To do so, enable forward-proxy-auth.

config web-proxy global

set forward-proxy-auth enable <===== forward authentication header

end

Obtain active user login information or de-authenticate

Use the captive portal to obtain login information or to de-authenticate yourself using the web portal.

1. Create a firewall object of the FQDN type (for example, fpxvm.abc.local).

   config firewall address

   edit "fpxvm"

   set type fqdn

   set fqdn "fpxvm.abc.local"

   next

   end

2. Set the FQDN of the captive portal.

   config authentication setting

   set captive-portal "fpxvm"

   end

3. Adjust the portal name and set the reauthentication mode.

   config system global

   set alias "FortiProxy-KVM"

   set hostname "fpx2"

   set proxy-re-authentication-mode absolute

   end

4. Go to https://fpxvm.abc.local:7831/ to obtain the login information or for de-authentication.