FortiClient 7.4.2 and SSL VPN + Azure SAML not working with internal browser, works with external

[rewt]

So I have been struggling for a bit to figure out why my SSL VPN configuration with Azure SAML doesn't work with FortiClient 7.4.2.  Older FortiClient version seem to not have this issue.  The most telling thing I see in the server debug log is:

[394:root:5b4b]SSL state:fatal decode error (x)
SSL state:fatal decode error (x)

then:

[394:root:5b4c]saml login [394:23372] SAML_ERROR: Error occurred during remote login 'could not found corresponding saml session (101)'

If I use the option in FortiClient "Use external browser as user-agent for saml user authentication", I get no such error and everything works just fine.

Any guesses as to what might be causing this issue?  When I searched on this issue, I only found similar issues  but where the opposite was true - using external browser for saml user authentication did not work as expected.

I am a little reluctant to upgrade the users to such an unstable situation.

[rewt]

Fortigate 201F is on 7.4.7

[sferoz]

There's a known issue regarding SAML config not working when using internal browser as user agent for saml user authentication can be tracked in engineering ticket #1113234.

As a workaround, kindly try using Use external browser as user-agent for saml user authentication. 

Thanks. 

[tt93]

Hi, is there any idea when this will be patched (next release)? We have our clients using external browser auth at the moment as a workaround but due to browser caching, they're not being prompted to authenticate every single time which is causing some security concerns.

[andrewp]

FortiClient 7.4.x has 3 internal browsers. When I switched to Elektron, the -7200 error disappeared. Unfortunately, in this mode, Elektron does not suggest the last login used.

Here is an article about it:
FortiClient SAML Authentication Configura... - Fortinet Community

[Mithunmn]

We have experienced a similar issue with version 7.4.2. According to Fortinet Support, the issue has been fixed in FortiClient version 7.6.3, which is yet to be released. You can either revert to version 7.2.3, 7.2.7, or 7.2.8, or wait for the next release.

[JasonBurns]

Just wanted to say I have run into this issue at one of my customers - Fortigate version 7.2.11 with FortiClient 7.4.0 - 7.4.2.  SAML auth randomly works, oft doesn't.  We tried checking the "use external browser..." box and it did not change the behavior.

Upgrading the Fortigate to 7.4.7 did not change the behavior, but it does now work properly when checking the "use external browser..." box.  This had been going on since Monday the 17th.

[Mithunmn]

We have experienced a similar issue with version 7.4.2. According to Fortinet Support, the issue has been fixed in FortiClient version 7.6.3, which is yet to be released. You can either revert to version 7.2.3, 7.2.7, or 7.2.8, or wait for the next release.

Another workaround is to use an external web browser.

[BackerTheHacker]

I just ran into this with a customer. After I enabled "use external browser......" the SAML auth worked with no issue. Running 7.2.10 on the FortiGate and FortiClient VPN 7.4.2.1737

[Christian_89]

Below are a few common reasons why embedded (internal) browser-based SAML authentication can fail in newer FortiClient releases—especially if it works when using an external browser, but fails within the built-in webview. Hopefully one or more of these points will help narrow down the root cause:

 1. Internal Browser / SAML Handshake Changes in FortiClient 7.4.x

-Updated Webview Engine: FortiClient sometimes updates the embedded webview engine for SAML logins. If Azure AD’s authentication flow or cookie handling (e.g., SameSite cookie policies) is not fully compatible with how the built-in webview is handling redirects, you can see handshake failures or “SAML session not found” errors.
- Cipher or TLS Mismatch: The “fatal decode error” often appears when there’s a mismatch or failure during the TLS handshake. The external browser (Edge/Chrome/Firefox) may support a broader or more up-to-date cipher set than the internal browser in FortiClient 7.4.2.

Suggested Check:
Consult FortiClient 7.4.x release notes or known issues documentation to see if there is any mention of internal browser SAML flow issues or recommended cipher settings.

2. Cookie Handling / SameSite Settings

Session Cookie Not Saved: If the internal browser fails to store or return the session cookie, Azure AD will drop the SAML flow, causing an error like “could not found corresponding saml session.”
SameSite Enforcement: Azure AD might be enforcing stricter SameSite cookie policies than before. If the internal browser doesn’t handle these correctly, the session token/cookie never makes it back to the FortiGate.

Suggested Check:
Compare the cookie and redirect traffic during login using the external browser vs. the internal browser (if possible, with a capture or debug logs).
- Inspect for any blocked cookies or missing parameters.

 3. Deep Inspection or SSL/Certificate Issues

If SSL deep inspection is in place, or your FortiGate is re-signing SAML traffic under certain conditions, the internal webview may be rejecting it because of untrusted certificates or pinned certificate errors. This is less common if your external browser is also behind the same firewall rules, but it’s still worth checking:

- Ensure certificate trust: The internal browser must trust the same certificate chain that Azure uses. Sometimes the external browser is okay because the user has already trusted or established that chain, but the internal webview might not.
- Disable SSL Inspection  temporarily on the SAML authentication URL(s) to see if that resolves the decode error.

 4. Potential Bug / Regression in 7.4.2

Occasionally, new FortiClient versions introduce bugs in the SAML flow. If older 7.0.x or 7.2.x clients work without issue, it may be an actual regression or an unaddressed corner case in 7.4.2.

Suggested Check:
- If possible, test with a slightly different 7.4.x build (e.g., 7.4.1 or 7.4.3 if available) to see if the problem remains.
- Open a ticket with Fortinet to confirm if there is a known issue or a hotfix. Providing debug logs from both the client (verbose logs) and the FortiGate (using `diagnose debug authd saml` or similar) can help them confirm.

 5. Workarounds / Next Steps

1. Keep Using External Browser 
While less seamless, using the external browser for SAML logins is a valid workaround until Fortinet resolves the internal browser issue.

2. Check FortiGate SAML IdP Configuration
- Make sure the SP URLs, IdP URLs, and certificate settings exactly match the configuration in Azure. Minor differences (extra trailing slash, unmatched domain, etc.) can cause the embedded browser to fail.
- Confirm the redirect URIs in Azure’s enterprise application setup are accurate.

3. Upgrade/Downgrade Testing
- If feasible, test a prior FortiClient release (e.g. 7.2.9) with the same configuration to confirm it works (you’ve mentioned older clients do work). That helps you prove a potential bug in 7.4.2.
- If Fortinet has a patch or a recommended build, it might solve the “fatal decode error.”

4. Engage Fortinet Support 
 Provide them with a debug capture of the SAML process:

diagnose debug application samld -1
diagnose debug enable

 They can confirm if the handshake breaks due to an internal webview limitation or a known bug.

Conclusion

Because external browser works just fine, it strongly suggests there’s something specific to the internal FortiClient webview in 7.4.2—likely a mismatch in TLS ciphers, cookie handling, or a bug introduced in that version. If you’re in a position to adopt a workaround for now (external browser) and either upgrade/downgrade or escalate to Fortinet with logs, that’s the most direct path forward.

Hope this clarifies the likely causes and provides a path to resolution. If you have any follow-up details or logs, feel free to share so we can dig deeper!