Zero Trust Network Access – Troubleshooting

This post concludes the series on Zero Trust Network Access. This series has covered an overview of ZTNA, all the way to using endpoint posture checking with ZTNA tags and everything in between. In each of these posts, the configuration deployed resulted in an ideal outcome where the functionality matched the desired effect. However, in the real world, we know too often that sometimes deploying a new feature and/or functionality may not always go as we plan. In this blog post, I will highlight how to identify some of the common errors associated with the Zero Trust Network Access (ZTNA) deployment and how to resolve them.

ZTNA Components

As a reminder, the main components that have previously been covered that make up the Fortinet ZTNA solution are:

FortiGate
FortiClientEMS
FortiClient

It is important to understand the role that each component plays within the solution to understand where to look when the common error scenarios are encountered.

ZTNA Access Denied

Invalid ZTNA client certificate

One of the most common errors associated with denied access via ZTNA is “Invalid ZTNA client certificate”. In regards to ZTNA access via the HTTPS Proxy and TCP forwarding methods, client certificates are used to authorize the endpoint on a per session instance. The following workflow occurs upon connection from an endpoint who is trying to access some service behind the FortiGate:

In the case of HTTPS proxy, the FortiGate will prompt that endpoint for a certificate.
Once the endpoint has provided that certificate, the FortiGate will query the FortiClientEMS server with that certificate’s identifier
The FortiClientEMS server will respond to the FortiGate with any information it has regarding that certificate (including the device specific information and any associated ZTNA tags).
The FortiGate will allow or deny based on its defined policy for the ZTNA access

In most cases, this message just means that the FortiGate is performing as expected because anyone that does not have a valid certificate should indeed have its access denied.

Figure 1. – Screenshot of the “Invalid ZTNA client certificate” error

Figure 2. – Screenshot of the log showing “invalid client certificate”

If you have an endpoint that is attempting to access your resources through ZTNA but are encountering this error, here are some components to check:

FortliCientEMS

The FortiClientEMS is responsible for assigning the certificate to the FortiClient which will be used for authorization to the FortiGate. To ensure that the correct certificate has been assigned, first navigate to “Endpoints | All Endpoints” within the FortiClientEMS management interface.

Figure 3. – Screenshot of the “Endpoints | All Endpoints” navigation pane on FortiClientEMS

Once that screen has loaded, find the endpoint in question and click on it to display its details.

Figure 4. – Screenshot of the details from the “Lenny” user in FortiClientEMS

Once the details are shown, validate that a “ZTNA Serial Number” has been assigned to the FortiClient in question.

Figure 5. – Screenshot of the “ZTNA Serial Number” assignment from FortiClientEMS

Important Notes:

As of FortiClientEMS 7.0.4, this assignment only happens for Windows and MacOS users, there is no mobile support for this feature at this time.

Each time the FortiClient is re-registered to the FortiClientEMS, the ZTNA Serial Number will be assigned (and subsequently, a the certificate for that endpoint will be re-provisioned)

If the ZTNA serial number shows assigned to the endpoint, the next step is to check the endpoint to make sure that it has a certificate that matches that serial number.

FortiClient

The FortiClient is automatically provisioned a certificate from the FortiClientEMS upon registration to the FortiClientEMS as its management server. This process does not require any user intervention and happens transparently to the user. After initial registration, it takes on average about five minutes before the certificate has been provisioned and downloaded to the FortiClient. To confirm that the certificate is on the endpoint, open up the Microsoft Management Console (mmc.exe).

Figure 6. – Screenshot of the Microsoft search panel opening the Microsoft Management Console

Once that is open add in the certificate snap-in for the current logged in user.

Figure 7. – Screenshot of the “Add/Remove Snap-In” option

Figure 8. – Screenshot of the “Add or Remove Snap-ins” dialog box

Once you highlight “Certificates” and click “Add”, it will prompt for the context in which to manage the certificates. At this point, select “My user account”

Figure 9. – Screenshot of the managed context certificates

After clicking “Finish” and “OK”, you can browse to the location of your personal certificates where the FortiClient certificate should exist:

Figure 10. – Screenshot of the FortiClient certificate assigned from FortiClientEMS

Important Notes:

If the FortiClientEMS assigned certificate does not exist, you can attempt to have it re-provisioned by unregistering and re-registering the FortiClient to FortiClientEMS.

Once it has been validated the FortiClient has the FortiClientEMS assigned certificate, the next step is to check the FortiGate to make sure it is receiving the proper telemetry from the FortiClientEMS to validate these users.

FortiGate

The FortiGate is the component that is responsible for granting or denying access to a resource based on the policy defined within it. The FortiGate validates the endpoint based on the tag assigned to it. However, the FortiGate does not query the FortiClientEMS for telemetry on the endpoint until an access attempt is made. There are multiple ways to validate the information which the FortiGate receives from FortiClientEMS:

FortiGate WebUI

Once an access attempt has been made, the information from the FortiClient should show up under the “Dashboard | Users & Devices | FortiClient” widget.

Figure 11. – Screenshot of the “Users & Devices” dashboard

Upon accessing the “FortiClient” widget, the information from the FortiClient should be an entry within the list.

Figure 12. – Screenshot of the “FortiClient” widget showing FortiClient entries

In the cases where the FortiClient endpoints do not show up under this dashboard widget, the information can be validated via CLI using the following command:

diagnose endpoint record list

Figure 13. – Screenshot of the output of the “diagnose endpoint record list” command

The information from the client certificate serial number can be aligned with the serial number that is in the personal certificate store within the endpoint. If issues persist after all of this checks out, the next best step would be to proceed to open a ticket with Fortinet TAC.

This concludes the series on Zero Trust Network Access with Fortinet. I hope you found this series useful and as always, please let me know your feedback regarding this information.

Until next time.

3 1 vote

Article Rating