Technical Tip: FortiGate ZTNA presents authentication error message after configuring session-based form authentication.

[pjang]

Description	This article describes an expected behavior that can occur when attempting to access a ZTNA-protected server when authentication is required. Notably, this issue occurs when the following conditions are met: FortiGate ZTNA is configured (issue can occur equally with HTTPS Access Proxy or TCP Forward Access Proxy). The ZTNA Proxy Policy includes session/form-based authentication. Note that this issue does not occur when using basic authentication (though basic authentication notably does not support FortiToken MFA)
Scope	FortiGate, ZTNA.
Solution	When configuring ZTNA access proxies, administrators may wish to add username/password/multi-factor authentication (MFA) to the ZTNA proxy policy on top of the existing FortiClient certificate verification and EMS tag-based filtering. This is supported on the FortiGate by using session-based form authentication, which is discussed in the following documents: ZTNA session-based form authentication Technical Tip: How to configure ZTNA Session Based Authentication with MFA token After user authentication is added, administrators would typically expect the following general flow when accessing ZTNA resources (this example is based on a ZTNA HTTPS Access Proxy): External User navigates to an FQDN that resolves to the FortiGate's external ZTNA gateway address. User receives a prompt to present a client certificate for authentication. This certificate must be signed by the EMS server that the FortiGate is communicating with. Assuming the certificate is associated with a FortiClient instance known to the EMS server, the FortiGate will check the ZTNA tags associated with this instance to ensure that it meets the tag requirements of the proxy policy. The External User will be redirected to an authentication page to enter username and password credentials (and optionally an MFA token, if require-tfa is enabled in the Authentication Scheme). If the credentials are valid, then the user is allowed to access the ZTNA-protected resource. After adding the required Authentication Scheme and Authentication Rule, administrators may find that the ZTNA resource is not accessible, and the FortiGate may return an error page stating 'you must authenticate to use this service': In the case of TCP Forward Access Proxy, users will find that FortiClient will show a prompt for username/password credentials (no prompt for MFA token), but after entering the credentials, the authentication never succeeds. FortiClient will then show a notification for FortiClient ZTNA Agent stating that 'an error has occurred in the FortiClient ZTNA', and selecting that notification will open an embedded browser page showing the same authentication error message as above. Note: When checking WAD debugs on the FortiGate as well as the web browser Developer Tools, administrators the authentication error message above is associated with an HTTP 401 Server authentication required page being sent back to the ZTNA client. Root Cause and Resolution: The reason this occurs is most likely due to misconfiguration of the ZTNA access-proxy settings. Administrators must add set auth-portal enable on the ZTNA access-proxy in addition to the Authentication Scheme and Authentication Rule changes; otherwise, the above error will be seen. This setting is notably CLI-only on the FortiGate: config firewall access-proxy edit <ZTNA Access Proxy Name> set auth-portal enable next end Once auth-portal has been enabled, users for both HTTPS and TCP Forward Access Proxies will be properly redirected to an authentication page asking for username, password, and an MFA token (if require-tfa is enabled in the Authentication Scheme): Note: It is not strictly mandatory to set auth-virtual-host here. This setting may be used to specify a shared FQDN used when redirecting a user to the web portal for form-based authentication, but if it is not configured, then ZTNA will instead redirect the user to the same ZTNA gateway address that is used for accessing the ZTNA service. For example, HTTPS Access Proxy users accessing 'https://webserver.example.com:9443' will be redirected to 'https://webserver.example.com:9443/XX/YY/ZZ/ckauth?[...]' for authentication. Likewise, TCP Forward Access Proxy users will be redirected to the ZTNA Destination's Proxy Gateway IP/FQDN to perform authentication. One major advantage of setting an auth-virtual-host is that it acts as a single sign-on (SSO) point for all services associated with this ZTNA access proxy configuration (i.e., users only need to authenticate once to this auth-virtual-host FQDN to gain access to all associated ZTNA resources, rather than authenticating to each service individually).