FortiClient 7.0.8.0427 SAML authentication not Cached

[AntoineCOSTA]

Hi, with the new Forticlient version SAML authentication is no longer cached.

Before the update, we were in 7.0.7.0345 and after the first SAML authentication, the data was cached and the user did not have to reauthenticate several times

during the day.

We erase cookies when the machine is shut down.

Is it possible to re-enable this feature?

Or is it possible to download a complete last version (7.0.7.0345)?

[maxs]

It was a bug in 707 that was fixed in 708. If you want caching. then switch to using external browser for SAML auth.

[pfournier]

So is this not being fixed? We had been using this for the last few years with zero issues, but now its a pain unless external browser is enabled. 

The SSO popup gives you an option to keep me signed in, but it doesn't actually work. 

[mhberglund]

We are also experiencing the same issue with FortiClient VPN 7.0.8.0427

The "Stay Signed in" feature offered by Azure Active Directory authentication is ignored and users have to reauthenticate each time they login to FortiClient VPN.

Still working with version 7.0.7.0345.

We have not got the "Use external browser as user-agent for saml user authentication" to work with either 7.0.7.0345 or 7.0.8.0427.

I have also contacted Microsoft support as I initially thought it was an issue with Azure Active Directory authentication. They are analysing the HTTPS traffic to also assist in the troubleshooting steps. Will report back if the issue can be resolved.

[pminarik]

The behaviour has changed over time.

6.4 branch: cookie(s) never cached

7.0.0~7.0.7: cookie(s) always cached

This would never keep everyone happy, so starting from 7.0.8 the behaviour was changed to follow the state of the "save password" option. If it is checked, the SAML IdP cookie is cached and reused during the next login (assuming that it is still valid by that time).

https://docs.fortinet.com/document/forticlient/7.0.8/windows-release-notes/22791/resolved-issues

744544 - "FortiClient (Windows) always saves SAML credentials."

The title/description doesn't explicitly call out the new behaviour, so you will have to trust me on that. If you're observing behaviour that is different, you should report it to TAC as a (most likely) bug.

[mhberglund]

Hi @pminarik 

Thank you for the reply and clarification of the default behaviour of the different versions of FortiClient VPN.

When you mentioned "save password" option, did you mean the 3rd party Single Sign On service offering an option to save the password? I do not see this as an option explicitly in the FortiClient VPN app.

[pminarik]

I meant the "Save Password" checkbox in FortiClient, as shown for example here: https://docs.fortinet.com/document/forticlient/7.2.1/administration-guide/437773/save-password-auto-...

However, now that I think about it, I suspect that this may be one of the features that are only available in EMS-managed clients, not in the free version.

If you're using the "external browser" option to handle SAML through your regular browser, then the caching of credentials/cookies would be fully in control of the browser itself.

[mhberglund]

I have done some testing on "Use external browser as user-agent for saml user authentication".

The credentials do get cached but the FortiClient fails to connect, error message "Credential or SSLVPN configuration is wrong. (-7200)"

[mhberglund]

@pminarik  would you know where to start troubleshooting the 7200 error message?

[pminarik]

sslvpn debug is always a good place to start.

diag debug console timestamp enable

diag debug app saml -1
diag debug app sslvpn -1

diag debug enable

=>reproduce issue now

diag debug disable

diag debug reset