Description
This article describes the limitation and the way to use SYSTEM-owned processes in custom host checks for SSL VPN client.
The SYSTEM account is used by the operating system and by services running under Windows.
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. 'set version 7.2.0.0690').
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. Thus, the client may not be able to connect due to the host check failing.
Scope
FortiClient, FortiGate, Windows.
Solution
There are a couple of solutions as described below:
1) Use only the NAME of the system-level process in the custom host check rule.
For example:
Custom host check rule for checking process 'FortiSSLVPNdaemon.exe'.
# config vpn ssl web host-check-software
edit "FortiClient-Test"
set os-type windows
set type av
set version ''
set guid "00000000-0000-0000-0000-000000000000"
config check-item-list
edit 1
set action require
set type process
set target "FortiSSLVPNdaemon.exe"
set version ''
next
end
next
end
2) The client machine should be logged in with the Administrator account.
This should not be a regular administrator account or adding an AD user in the local administrator group may not work.
It should be a built-in Administrator account for administering the computer/domain.
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.
3) Use user-owned Process.
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. As these processes are tied to the user logged into the machine, the version configured in the custom host check rule should take effect and allow/deny the users based on that.
