Troubleshooting Tip: Identifying Criteria Endpoint Does Not Match When Posture Tag is Comprised of Multiple Tagging Rules

Description

This article describes how to evaluate tagging rule(s) an endpoint is not compliant with when a tag is comprised of multiple criteria.

It is common to have a posture tag comprised of multiple rules. The main difficulty when it comes to troubleshooting with such an approach is identifying when an endpoint does not match the tag, the criteria that an endpoint does not meet. This article focuses on exactly that and only requires access to the endpoint having issues. No access to FortiClientEMS is needed.

Scope

FortiClient. Posture Check. ZTNA. FortiClientEMS.

Solution

Step 1. Verify the current endpoint's posture check status.

In other words, what tags endpoint does and does not match.

This can be done by selecting FortiClient's user avatar icon and checking the Security Posture Tags section (see below):

Or, if disabled in the endpoint profile, can be accomplished by verifying the contents of FortiESNAC.log file located under C:\Program Files\Fortinet\FortiClient\logs race or available as part of FortiClient diagnostic file.

Inside the file, search for the Current tags keyword to validate what are the tags the endpoint is currently assigned with:

[FortiESNAC  467   debug] Current tags: ANIL|SKVuln|SK-OS|Masoud|VP_EMS_MGMT|VP_Compliant

Step 2. Verify tagging rules that the tag in question is comprised of.

FortiClientEMS pushes tag information (their names and rules) to FortiClient, which stores them in host_verification.plain located under C:\Program Files\Fortinet\FortiClient\logs\ec folder.

Tip: Contents of the host_verification.plain are XML, though may require some formatting for better readability (i.e. Online XML Beautifier - BeautifyConverter.com).

Here is an example of a VP_Compliant tag that's configured with the following parameters (endpoint must meet all of them to be tagged):

Below is a representation of the above in the host_verification.plain file:

<rule_flag>15</rule_flag>
                <name>
                    <![CDATA[VP_Compliant]]>
                </name>
                <os>windows</os>
                <criteria>
                    <feature>domain</feature>
                    <criterion>
                        <content>
                            <![CDATA[vpdocs.net]]>
                        </content>
                        <negative>0</negative>
                    </criterion>
                </criteria>
				
<rule_flag>76</rule_flag>
                <name>
                    <![CDATA[VP_Compliant]]>
                </name>
                <os>windows</os>
                <criteria>
                    <feature>ems_management</feature>
                    <criterion>
                        <content>
                            <![CDATA[FortiClient installed and Telemetry connected to EMS]]>
                        </content>
                        <negative>0</negative>
                    </criterion>
                </criteria>
				
<rule_flag>93</rule_flag>
                <name>
                    <![CDATA[VP_Compliant]]>
                </name>
                <os>windows</os>
                <criteria>
                    <feature>fct_version</feature>
                    <criterion>
                        <operator>
                            <![CDATA[>=]]>
                        </operator>
                        <content>
                            <![CDATA[7.4.6]]>
                        </content>
                        <negative>0</negative>
                    </criterion>
                </criteria>

Note the <rule_flag> values as they are critical for the next step.

Step 3. Analyze FortiClient logs to identify a criteria endpoint does not meet.

Once it is clear what rules are included in the tag in question, the next step is to analyze FortiClient evaluation of these rules. For that, earlier mention FortiESNAC.log is needed.

Recall host_verification.plain's <rule_flag> and their values specific to the tag in question. FortiClient checks tagging rules every single KA interval and starts with the highest rule flag number. In the example above, FortiClient starts with rule 93 and checks whether its version meets the criteria (fct_version).

Below is an excerpt of FortiESNAC:

[FortiESNAC  1819   debug] checking rule 93
[FortiESNAC  1639   debug] checkrule unsupported feature=fct_version
[FortiESNAC  1895   debug] rule VP_Compliant is not matched
...
[FortiESNAC  1819   debug] checking rule 76
[1500:4828] [FortiESNAC  1639   debug] checkrule unsupported feature=ems_management
[1500:4828] [FortiESNAC  1895   debug] rule VP_Compliant is not matched


[FortiESNAC  1819   debug] checking rule 15
[FortiESNAC  1895   debug] rule VP_Compliant is matched

Note, since all three are required for the endpoint to get tagged, FortiClient reports "rule VP_Compliant is not matched" until the very last rule is checked.

Tip: Criteria flagged with checkrule unsupported means the criteria is evaluated on the FortiClientEMS server side.

Once the missing rule is identified, proceed with further troubleshooting and verification of why endpoint does not meet the required criteria.

Refer to Security posture tagging rule types for a reference.