Skip to main content
Marco84it
Marco84it
Visitor III
January 12, 2022
Question

Forticlient VPN - SAML SSO Azure AD - credentials cache

  • January 12, 2022
  • 4 replies
  • 31796 views

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

 

 

4 replies

Jond
Jond
New Member
January 12, 2022

Also noticed this and would be interested in a solution

    Debbie_FTNT
    Staff & Editor
    Debbie_FTNT
    Staff & Editor
    January 12, 2022

    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
    Marco84itAuthor
    Visitor III
    January 12, 2022

    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
    doug_davidson
    New Member
    April 20, 2022

    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.

      sweetjim
      sweetjim
      New Member
      June 29, 2022

      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.
       
      GPOpart2.pngGPOpart1.png
       

       

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

       

       

        Icebun
        Icebun
        Explorer II
        June 30, 2022

        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.

         

         

         

         

        Terms & ConditionsAccessibility statement