If the above solutions are not satisfactory, then use a process that is not a SYSTEM-owned process such as FortiTray.exe or FortiClient.exe. Once the client machine is logged in with the built-in administrator account, the version of the process in the custom host check rule should take effect and allow/deny users based on that.

It should be a built-in Administrator account for administering the computer/domain. This should not be a regular administrator account or adding an AD user in the local administrator group may not work. There are a couple of solutions as described below:ġ) Use only the NAME of the system-level process in the custom host check rule.Ĭustom host check rule for checking process 'FortiSSLVPNdaemon.exe'. Thus, the client may not be able to connect due to the host check failing. This is due to the limitation of access permission of Win32 API with normal AD users, where it is only possible to obtain the process name (not the version) as part of the host check process done by FortiClient. Some SYSTEM-owned processes such as 'FortiSSLVPNdaemon.exe' or 'FortiSettings.exe' may not work when used in the custom host check rule, specifically when specifying the allowed version in the rule (i.e. The SYSTEM account is used by the operating system and by services running under Windows. This article describes the limitation and the way to use SYSTEM-owned processes in custom host checks for SSL VPN client.

How to use fortinet vpn client