Below are a list of most common tagging rules and the way to validate and troubleshoot them.
Note that this article will often reference various logs from both FortiClient and FortiClient EMS depending on where the tagging rule is evaluated. Below is a list of log files and where they can be found/retrieved:
FortiClient endpoint control (EC) log: C:\Program Files\Fortinet\FortiClient\logs race\FortiESNAC.log. Tagging rule sets stored by FortiClient: C:\Program Files\Fortinet\FortiClient\logs race\ec\host_verification.plain. FortiClient EMS keep-alive (KA) log file: emslogs\ka_worker.log. FortiClient EMS Active Directory logs: emslogs\adconnector.log
AV Software is installed and running / AV Signature is up to date.
Both tagging rules can apply to FortiClient and 3d party AV and rely on the security software registering with Windows Security Center (WSC).
If the rule does not apply to the endpoint, confirm WSC registration status of the installed AV software using below PowerShell command:
Get-WmiObject -Namespace "root\SecurityCenter2" -Class AntiVirusProduct
Note displayName (AV software name) and productState (enabled/disabled and whether it is up to date).
Example of codes for FortiClient and Windows Defender:
Windows Defender:
393472 = disabled and up to date 397584Â = enabled and out of date 397568 = enabled and up to date
FortiClient:
Example output:
Certificate.
FortiClient is capable of detecting a certificate with Certificate tagging rule that can be configured to detect Common Name (CN) via simple match, regex, and wildcard. Issuer must be specified as is.
If FortiClient is unable to locate the certificate, check Windows user personal certificate and local computer stores. In order to troubleshoot further, complete the following steps:
Locate FortiESNAC.log under C:\Program Files\FortiClient\logs race. Scroll to the very bottom of the log file and filter for the name of the tag (select backward direction). Find the line where FortiClient cannot match the tag (i.e. for the tag named 'Certificate Posture Check', it will be 'rule Certificate Posture Check is not matched').
Evaluate FortiClient certificate verification process right above the 'rule not matched line'.
EMS Management -Â FortiClient installed and Telemetry connected to EMS.
This rule is evaluated on FortiClient EMS server side. If FortiClient fails to get assigned with this tag, make sure its status is Online on FortiClient EMS.
Note that, when expediting the FortiESNAC.log for a FortiClient EMS management rule, it will report 'checkrule unsupported feature=ems_management'. This simply means this rule is evaluated on FortiClient EMS, not on the FortiClient side.
File.
Check FortiESNAC.log and look for the name of the tag used to detect a file. Below is an example of the File rule:
The following are the results of the FortiESNAC.log search:
The rule is not matched as FortiClient is unable to locate the C:\Program Files\Wrong\Path\FileDoesNotExist.txt file.
FortiClient Version.
FortiClient Version is another rule that does not support FortiClient local evaluation and requires FortiClient EMS to do so. Hence, FortiESNAC will show 'checkrule unsupported'.Â
On FortiClient EMS, confirm FortiClient reports the version that meets the rule criteria. There are multiple ways to do this:
Via All Endpoints view:
To confirm whether FortiClient is assigned with this tag and reports it accurately to EMS: within the same view, select View All Security Posture Tags and then View Current Tags.
Vulnerable Devices /Â Common Vulnerabilities and Exposures.
In order for FortiClient to evaluate the Common Vulnerabilities and Exposures and Vulnerable Devices tagging rules, it has to run a vulnerability scan. If the endpoint is vulnerable but FortiClient has not run the vulnerability scan to detect the vulnerability, it will not meet the criteria and consequently will not get tagged.
The following is a scenario where FortiClient is not 'aware' of a vulnerability due to a lack of vulnerability scan results. As a result, it is not getting tagged until the scan is executed.
For the example below, the following rule has been set up.
The scan has not been executed.
FortiClient is not assigned with the 'VP-CVEs' tag, even though it has a vulnerable version of the software installed.
FortiClient executes the scan and detects vulnerable software (Notepad++) that matches the tagging rule.
FortiClient gets tagged.
Note that FortiClient stores vulnerability scan results in the C:\Program Files\Fortinet\FortiClient\logs race\vcm folder. The results of the scan with are recorded in summary.json file while detailed information about each vulnerability including CVE number, software version, severity of vulnerability (low, medium, high) and other information are stored in JSON files identified as unique vulnerability IDs (i.e. 93439).
OS version.
FortiClient uses systeminfo Windows CMD command's output to identify the version of Windows OS and verify whether it meets criteria of the OS Version tagging rule.
Example of a rule requiring endpoint to be having Windows 10 OS or higher:
Output of a Windows CMD systeminfo command:
Detailed evaluation of the 'OS Version >= Windows 10' rule (extracted from C:\Program Files\Fortinet\FortiClient\logs race\FortiESNAC.log):
The above settings result in the endpoint meeting the criteria and being tagged.
Certificate.
FortiClient is capable of checking three certificate stores for both user and computer - Personal, Trusted Root Certification Authorities and Intermediate Certification Authorities.
Below is a scenario of locating a certificate within the user personal store.
Example of a rule:
FortiClient evaluation of the rule (FortiESNAC.log).
The certificate in the personal user certificate store.
When evaluating the rule, FortiClient notes what stores it checks and where it finds the certificate.
Personal Certificate Store ('MY'). Trusted Root Certification Authorities ('ROOT'). Intermediate Certification Authorities ('CA').
When FortiClient is unable to locate the certificate in the above-mentioned stores, it reports the rule is not matching.
On-fabric status.
Even though the evaluation of the On-Fabric Status happens on the client-side, the tagging rule assignment is finalized on the FortiClient EMS server-side. Consequently, the FortiClient endpoint control log, FortiESNAC.log, reports 'checkrule unsupported feature=on_fabric'.Â
This log is normal and does not necessarily mean FortiClient will not get tagged with this rule, but simply that evaluation happens on FortiClient EMS based on the On-Fabric Status FortiClient reports.
FortiClient's On-Fabric Status can be checked under the Endpoints pane.
Refer to On-fabric Detection Rules for more information on configuration and various On-Fabric detection rule types.
Logged in Domain.
A Logged in Domain tagging rule has a specific set of rules that define whether evaluation happens on the endpoint (FortiClient) or server side (FortiClient EMS). These rules are based on priorities of methods of how domain information is reported:
Authenticated user domain. If user verification against domain is configured for FortiClient registration to FortiClient EMS, then that domain will be evaluated against the tagging rule of Logged in Domain. See Invitations. Domain reported by FortiClient. If no user verification via domain is used, then the domain reported by FortiClient will be used (either domain user signed in against), or the workstation's domain.
Another (arguably more reliable) way to verify what domain FortiClient reports to FortiClient EMS is to check the FortiESNAC.log and filter for the 'domain' keyword.
The domain reported by the Domain Controller the endpoint is imported from. FortiClient EMS must be integrated with LDAP to import domain workstations (see Adding endpoints using an AD domain server).
Troubleshooting should be based on the method used to identify user/endpoint domain.
User in AD Group.
By default, evaluation of the User in AD Group rule occurs on FortiClient EMS.
For more information, refer to Security posture tagging rule types.
In this article, the FortiClient EMS (default) rule evaluation will be covered.
In order to troubleshoot user group memberships FortiClient EMS debug diagnostics are required.
Diagnostics can be collected as instructed in Generate Diagnostic Logs.
To start, verify what group information FortiClient EMS has for a user - mouse over the username under the endpoint list and, in the list, look for the group configured for the User in the AD Group tagging rule. This should give a foundational understanding of what group membership information FortiClient EMS has.
In order to analyze tag evaluation further, extract the diagnostic zip file and locate the last (sorted by date) ka_worker log file. Inside that file, filter the name of the tag in question. An entry similar to the one below should appear:
The log file above corresponds to the example rule below:
Tip, filter for 'hostver/host_verification' keyword when searching through the ka_worker log file. This will enable quick search specifically for tag evaluation and verdicts on EMS. To pinpoint what endpoint the evaluation relates to check UID of the FortiClient in question (can be located under FortiClient's Settings tab or on FortiClient EMS endpoints list).
If endpoint does not match the tag even though the signed in user is a member of the desired group, it is worth verifying the adconnector log (located in the same folder as ka_worker). Search for the group and validate and/or username of the user having issues with tag assignment and analyze further.
Related articles:
Troubleshooting Tip: Identifying Criteria Endpoint Does Not Match When Posture Tag is Comprised of Multiple Tagging Rules | 
