Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:


Table of Contents

Handbook

How device identity and trust context is established with FortiClient EMS

Integral to Zero Trust Network Access (ZTNA) is how device identity and trust context is established between FortiClient, FortiClient EMS, and the FortiADC.

Device roles

The following illustrates how the FortiClient, FortiClient EMS, and FortiADC each function and participate in the ZTNA workflow.

FortiClient

FortiClient endpoints provide the following information to FortiClient EMS when they register to the EMS:

  • Device information (network details, operating system, model, and others)
  • Logged on user information
  • Security posture (On-net/Off-net, antivirus software, vulnerability status, and others)

FortiClient requests and obtains a client device certificate from the EMS ZTNA Certificate Authority (CA) when it registers to FortiClient EMS. The client uses this certificate to identify itself to the FortiADC.

FortiClient EMS

FortiClient EMS issues and signs the client certificate with the FortiClient UID, certificate serial number, and EMS serial number. EMS shares its EMS CA certificate with the FortiADC, so that the FortiADC can use it to verify the clients.

FortiClient EMS uses Zero Trust tagging rules to tag endpoints based on the information that it has on each endpoint. The tags are also shared with the FortiADC.

FortiADC

The FortiADC maintains a continuous connection to the EMS server to synchronize endpoint device information, including primarily:

  • FortiClient UID
  • Client certificate SN
  • EMS SN
  • Device credentials (user/domain)
  • Network details (IP and MAC address and routing to the FortiADC)
  • ZTNA tags

When a device's information changes, such as when a client moves from on-net to off-net, or their security posture changes, EMS is updated with the new device information and then updates the FortiADC. The FortiADC's virtual servers can use this information when processing ZTNA traffic. If an endpoint's security posture change causes it to no longer match the ZTNA rule criteria then it will be denied in a new session.

How device identity and trust context is established with FortiClient EMS

Integral to Zero Trust Network Access (ZTNA) is how device identity and trust context is established between FortiClient, FortiClient EMS, and the FortiADC.

Device roles

The following illustrates how the FortiClient, FortiClient EMS, and FortiADC each function and participate in the ZTNA workflow.

FortiClient

FortiClient endpoints provide the following information to FortiClient EMS when they register to the EMS:

  • Device information (network details, operating system, model, and others)
  • Logged on user information
  • Security posture (On-net/Off-net, antivirus software, vulnerability status, and others)

FortiClient requests and obtains a client device certificate from the EMS ZTNA Certificate Authority (CA) when it registers to FortiClient EMS. The client uses this certificate to identify itself to the FortiADC.

FortiClient EMS

FortiClient EMS issues and signs the client certificate with the FortiClient UID, certificate serial number, and EMS serial number. EMS shares its EMS CA certificate with the FortiADC, so that the FortiADC can use it to verify the clients.

FortiClient EMS uses Zero Trust tagging rules to tag endpoints based on the information that it has on each endpoint. The tags are also shared with the FortiADC.

FortiADC

The FortiADC maintains a continuous connection to the EMS server to synchronize endpoint device information, including primarily:

  • FortiClient UID
  • Client certificate SN
  • EMS SN
  • Device credentials (user/domain)
  • Network details (IP and MAC address and routing to the FortiADC)
  • ZTNA tags

When a device's information changes, such as when a client moves from on-net to off-net, or their security posture changes, EMS is updated with the new device information and then updates the FortiADC. The FortiADC's virtual servers can use this information when processing ZTNA traffic. If an endpoint's security posture change causes it to no longer match the ZTNA rule criteria then it will be denied in a new session.