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:

1. In the case of HTTPS proxy, the FortiGate will prompt that endpoint for a certificate.
2. Once the endpoint has provided that certificate, the FortiGate will query the FortiClientEMS server with that certificate’s identifier
3. 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).
4. 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.

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.

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

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

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).

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

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”

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

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.

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

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

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.