Troubleshooting SAML Auth on FortiClient VPN when applying Microsoft Security Baselines

Dearest gentle reader… (Yes, my wife is making me watch that Bridgerton series on netflix, so I may speak like a 19th century gentlemen during this blog post… or not…) I recently wrote about Center for Information Security (CIS) and how those configurations broke Windows Autopilot. It then developed into a series on CIS with another gentleman of the manor, Nick Benton. And so, speaking of security posture, on my latest customer engagement they wanted to modernise their Windows Management and explore Entra joined only devices using Autopilot, but also, to improve their security configuration by using Microsoft Security Baselines - which of course I did but in doing so this broke their SAML authentication on Forticlient VPN - so here’s the story of how I fixed it.

Declaration

Here are the conditions I was testing under:

• Windows 11 23H2 test machine (virtual) enrolled into Intune using Autopilot.
• Forticlient version 7.0.12 - this is important because I’ve seen a lot of posts surrounding either the need to upgrade OR a work around (more on this later)
• I have implemented Microsoft Security Baseline for Windows 10 and later to my test machine. Version 23H2 (link below)

Experience

A device was enrolled into Microsoft Intune using Autopilot (v1). The device had numerous applications installed, one was Forticlient. The client had a VPN profile installed using fcconfig.exe (a tool that comes with the client for this specific purpose). Autopilot completed and all the applications were installed successfully. After the build completed, it was discovered that the Forticlient would not connect. It seemed to pause, but it was noted that behind the main window, after clicking on SAML Login, highlighted below

..an error was showing..

My instincts here screamed Internet Explorer error. It had a somewhat familiar look to it. But.. Windows 11.. and we use Edge now, right? If you search this online, you will see one person suspected this and get shot down, but lots of people using a work around (which works by the way) of using the following option on your configuration:

This forces “some element” of the VPN to use Edge, and thus connects successfully. I say “some element”, because in truth, I’m not sure. There are no local logs and nothing recorded in event viewer so this is good old fashioned guess work. When you use this option and you try to connect your SAML VPN, it opens an Edge window showing this, and connects.

You can be forgiven for thinking “why not just export a new profile with this in” because if it works, it works, right? Looking online at some of the community posts, some have done this, some have even logged tickets with Fortinet and been told to do this as a workaround. One post claimed the problem was fixed in version 7.2.3, however, one said the problem had returned in version 7.2.4. Comedy. Rather than use workarounds, my customer wanted a fix or at least to identify the problem so the sleeves were rolled up and I began a trial-and-error process to figure out what was causing it.

Approach

My approach was simple, find out which policy setting causes it by stripping out sub categories one by one until it works and finally narrowing down the setting within the sub category. I thought this was going to be quick and easy. It was not, by any stretch of the imagination, quick. Hopefully my efforts will save you time.

Because I’m cocky, and my ‘spidey-sense’ was telling me it was an Internet Explorer error, thats the thing I removed first. BINGO! So we certainly had our culprit.

Next I started to remove the sub categories one by one. Here is a list of the policy sub categories all of which sit under the category of “Administrative Templates:

Subcategory
Windows Components > Internet Explorer > Internet Control Panel > Advanced Page
Windows Components > Internet Explorer > Internet Control Panel
Windows Components > Internet Explorer > Internet Control Panel > Security Page > Internet Zone
Windows Components > Internet Explorer > Internet Control Panel > Security Page
Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone
Windows Components > Internet Explorer > Internet Control Panel > Security Page > Locked-Down Local Machine Zone
Windows Components > Internet Explorer > Internet Control Panel > Security Page > Locked-Down Internet Zone
Windows Components > Internet Explorer > Internet Control Panel > Security Page > Locked-Down Intranet Zone
Windows Components > Internet Explorer > Internet Control Panel > Security Page > Locked-Down Restricted Sites Zone
Windows Components > Internet Explorer > Internet Control Panel > Security Page > Locked-Down Trusted Sites Zone
Windows Components > Internet Explorer > Internet Control Panel > Security Page > Restricted Sites Zone
Windows Components > Internet Explorer > Internet Control Panel > Security Page > Trusted Sites Zone
Windows Components > Internet Explorer
Windows Components > Internet Explorer > Security Features > Add-on Management
Windows Components > Internet Explorer > Security Features
Windows Components > Internet Explorer > Security Features > Consistent Mime Handling
Windows Components > Internet Explorer > Security Features > MK Protocol Security Restriction
Windows Components > Internet Explorer > Security Features > Notification bar
Windows Components > Internet Explorer > Security Features > Protection From Zone Elevation
Windows Components > Internet Explorer > Security Features > Restrict ActiveX Install
Windows Components > Internet Explorer > Security Features > Restrict File Download
Windows Components > Internet Explorer > Security Features > Scripted Window Security Restrictions

Again I sensed it was down to the security page sections (the ones in bold above). And I was right, so I removed all sub categories that started with Windows Components > Internet Explorer > Internet Control Panel > Security Page and started to add them back one at a time until Windows Components > Internet Explorer > Internet Control Panel > Security Page > Internet Zone broke it.

Now I had 50 or so actual settings to test. Again, I might add, no logs or event viewer recordings to look at so I started to enable any setting that had script in the name one at a time. Painful. This was simply because our error above stated “An error has occurred in the script on this page.

Eventually, I narrowed it down to this

Change to this and it works!

Given how long it takes to change something, wait for that change to be processed AND be reported back to the Intune console I can’t quite tell you how long this fix took me to find (nah, its longer than what you’re thinking).

Using Group Policy Search and searching for part of the text “Web sites in less privileged Web content zones” you can see that you can set this is MANY locations in Group Policy so finding the right one in your Group Policies if you’re still domain joined (why though?) and experimenting with enabling it may yield the same results as my Settings Catalog policy tests (update me if it does please!).

Risks

According to my research, the Web sites in less privileged Web content zones can navigate into this zone setting in Internet Explorer (IE) controls the ability of websites from lower security zones to navigate into and interact with content in higher security zones. Erm, ok. This setting is a part of IE’s security features designed to prevent malicious websites from leveraging content in more trusted zones to execute attacks. So what does this mean in laymans terms?

Essentially, when this setting is enabled, it allows websites from less privileged zones (such as the Internet or Restricted zones that we want to keep under control) to navigate into more privileged zones (such as the Local Intranet or Trusted sites zones). This can include accessing resources, executing scripts, or submitting forms within the more privileged zones. When this setting is disabled, it restricts websites in less privileged zones from navigating into more privileged zones. This restriction helps to mitigate cross-zone scripting attacks and prevents potentially malicious websites from leveraging the security context of more trusted zones to perform harmful actions.

The following should be considered by your security teams:

• Cross-Zone Scripting Attacks : Malicious websites from a less privileged zone could exploit vulnerabilities to execute scripts within a higher privileged zone, potentially leading to unauthorised actions.
• Information Disclosure : Websites from less privileged zones may gain access to sensitive information within more privileged zones.
• Elevation of Privileges : Attackers may leverage the trust level of a higher privileged zone to perform actions with elevated permissions.

Disclaimer

It would be foolish of me to write this entire post about what is essentially an old version of the Forticlient app, without highlighting the obvious issue that you should always run the latest version of applications to reduce your security risk. Third party patching is part of your security posture that will come under scrutiny in an audit and you must try to keep up to date with patches and bug fixes. I have not yet tested this using the latest version (as of the time of writing), but, I have read the same error is present anyway. I did not have an option to test it.

I appreciate you taking the time to read my blog.
Your interest and support keep me motivated to create more content.
If you think others might benefit from this content, please consider sharing it
... Jonathan

---

Links and References

Location	Link
Reddit	FortiClient Script Error
Reddit	FortiClient 7.2.4 ‘script error’
Fortinet Community	Windows error FortiClient script error access denied
Fortinet Community	Windows error Forticlient script error access denied on SSO connect
Fortinet Downloads	Obtain the latest versions from here
Microsoft Learn	InternetZoneAllowLessPrivilegedSites CSP
Microsoft Learn	Windows 10 and later Security Baseline - Version 23H2