Forticlient VPN - SAML SSO Azure AD - credentials cache

[Marco84it]

Hi to everybody,

one of my customer has this problem:

We have implemented SAML SSO login in a Fortigate unit (Fortigate VM00) where Azure AD acts as SAML IdP

Everything works fine except we have a "strange" behavior with Forticlient VPN.

Seems Fortigate VPN makes a sort of credential cache.
After a user makes logout, if he tries to reconnect, the authentication phase is skipped.

This happens only if Forticlient VPN interface is not close.

If the user, after a disconnect / logout, closes the Forticlient VPN interface , when he tries to reconnect he must follow the authentication steps.

Seems this cache is done by the lock file inside C:\users\(username)\appData\Local\FortiClient

Everytime Forticlient VPN interface is closed, this file is deleted.

Seems that, until the lock file exists, the session between forticlient and microsoft is kept open (if he clicks disconnect, the session is close between laptop and fortigate firewall but not beween laptop and microsoft)

In order to close this "persistent session", is enough to close the login form

I have opened a TT with Fortinet support but Forticlient VPN is not a "paid product" and they can't help me directly. They suggested me to open here my case..... 

Somebody else has the same issue?

Regards
Marco

[Jond]

Also noticed this and would be interested in a solution

[Debbie_FTNT]

Hey Marco,

as far as I know: If FortiClient is not closed properly, it will still have the SAML cookie stored (and Azure SAML IdP will also still have the SAML session, as no logout was sent to it).

When establishing VPN again, FortiGate will redirect the client to Azure for SAML login, and at that point FortiClient will present the stored cookie, which Azure will accept because it also still has the SAML session, and the user is considered logged in without needing to input credentials.

-> if you clear the existing session in Azure, that should also enforce a new login

-> I tested this a bit with FortiAuthenticator serving as IdP; FortiAuthenticator retained an IdP session for the FortiClient login unless there was a proper logout with a SAML assertion sent to the IdP logout URL; I assume Azure behaves similarly with retaining the session until it times out if no explicit assertion was sent to the logout URL.

I'm not aware of any configuration option to have FortiClient purge its cache if SSLVPN is dropped instead of properly logged out, and there is no setting on FortiGate to have it send a logout request to Azure SAML IdP if VPN drops.

This would probably require some kind of feature request to straighten out.

[Marco84it]

Hi @Debbie_FTNT ,

what do you mean with "FortiClient is not closed properly" ?

The VPN is closes properly. The customer clicks disconnect on Forticlient VPN interface.

The only problem is, if he doesn't close this interface, in case he does reconnect, the authentication is skypped. In case he closes Forticlient VPN interface / form (not close application on system tray.. the application is still open on background) and reopen it, the authentication is required again.

[doug_davidson]

You can set up a disconnect script "del /s C:\users\%username%\AppData\Local\FortiClient\cookies". This works for Windows, have not found the solution for a mac. It appears that it runs even if the VPN drops, due to a connectivity issue.

[AwareTH]

Hi, do you have any idea where those cookies are stored on Ubuntu?

[Icebun]

Deleting the Cookies and Cookies-Journal files for sure forces re-authentication.

Q.

Do you know how long the cookie persists. Kept the cookies for over a week or two and I still do not need to reauthenticate?

Q.

As a half way house, is there anyway the UPN is preserved always so users only need to enter their password and MFA?

[sweetjim]

Here is how i was able to resolve this through Group Policy.

First created a simple .bat file that does 2 things:

-Kills forticlient.exe

-Deletes Cookies and Cookies-journal files

Save the following as forticlient_delete_cookies.bat

-----------------------------

@echo off

taskkill /IM "FortiClient.exe"

del /f C:\Users\%username%\AppData\Local\FortiClient\Cookies

del /f C:\Users\%username%\AppData\Local\FortiClient\Cookies-journal

@echo off

----------------------------------

This closes the Forticlient Console GUI as it is using the required files we need to delete. The user will stay connected to vpn and this will not interfere with their established connection, and just need to relaunch shortcut or open from app tray in bottom right corner of screen to bring the gui back up.

GPO:

I created a GPO that does two things:

-Copies the .bat file from a network share drive reachable by the end users machine via VPN at the same location of the cookies files:

C:\Users\%username%\AppData\Local\FortiClient\

-Creates a task schedule to run the .bat twice a day and when the user reboots.

Tested in a new GPO over VPN with a user that has no administrator permissions to machine.

[Icebun]

Brilliant!

Thanks for the detailed breakdown which I will take a look at.

For me, I am keen to preserve the UPN element when users next sign on so all they need to is

enter in their password (or matching code number).

Right now I have DUO set up for MFA with the password cached so all users do is authorise the push authentication prompt on their DUO mobile app.

Just trying to balance convenience with security. Suspect users will baulk at the idea of enter of all the extra steps they would need to do to sign in via Azure SSO.

Preserving the UPN is the halfway house I am after.

As I understand it, you do need FortiOS 7.x as well (to read and presence the user agent string) but I am only running 6.x on the Firewall at the moment.

Since users login using Windows hello PIN code, I am aiming for passwordless authentication for the VPN as well, hence the move to SAML authentication.