Fortinet black logo

Version:

Version:


Table of Contents

New Features

Download PDF
Copy Link

ZTNA policy access control of unmanaged devices 7.2.1

The ZTNA access proxy can determine whether a client device that does not have FortiClient installed is a mobile device that is considered unmanageable, or is not a mobile device that is considered unknown. The ZTNA access proxy tags the device as either ems-tag-unmanageable or ems-tag-unknown respectively. The FortiGate WAD process achieves this by either matching device TLS fingerprints against a library or learning information from the HTTP User-Agent header if the set user-agent-detect setting is enabled.

The ems-tag-unmanageable and ems-tag-unknown tags allow for ZTNA access control of unmanaged devices using a proxy policy. The accept-unmanageable option for the empty-cert-action setting allows unmanageable clients to continue ZTNA proxy rule processing.

config firewall access-proxy
    edit <name>
        set client-cert enable
        set user-agent-detect {enable | disable}
        set empty-cert-action {accept | block | accept-unmanageable}	
     next
end

user-agent-detect {enable | disable}

Enable/disable detecting the device type by HTTP User-Agent if no client certificate is provided (default = enable).

empty-cert-action {accept | block | accept-unmanageable}

Set the action for an empty client certificate:

  • accept: accept the SSL handshake if the client certificate is empty.
  • block: block the SSL handshake if the client certificate is empty.
  • accept-unmanageable: accept the SSL handshake only if the end point is unmanageable.
config firewall proxy-policy
    edit <id>
        set ztna-ems-tag {ems-tag-unmanageable | ems-tag-unknown}
    next
end

ztna-ems-tag {ems-tag-unmanageable | ems-tag-unknown}

Set the EMS tag names:

  • ems-tag-unmanageable: match any device that is unmanageable.
  • ems-tag-unknown: match any device that is not recognized.

Consider the following use cases.

  • Case 1: if a client device sends a TLS client hello in a mobile pattern, then WAD will try to match its TLS fingerprint with a WAD original library and mark it with an ems-tag-unmanageable tag.
  • Case 2: if WAD cannot match the TLS fingerprint with an original library but user-agent-detect is enabled (under config firewall access-proxy), WAD will try to learn the device type from client request's User-Agent header. If it matches a mobile device, then it is still marked with an ems-tag-unmanageable tag.
  • Case 3: if WAD cannot match the TLS fingerprint with an existing original or temporary library, or cannot learn it from User-Agent header, or user-agent-detect is disabled, then it will mark the device as ems-tag-unknown.

In the access proxy settings, if empty-cert-action is set to accept-unmanageable, then only case 1 and 2 would go through the proxy policy. Case 3 would be denied, and a replacement message page would appear.

Example

To configure ZTNA policy access control of unmanaged devices:
  1. Configure the client certificate actions:
    config firewall access-proxy
        edit "zt1"
            set vip "zt1"
            set client-cert enable
            set user-agent-detect enable
            set auth-portal disable
            set empty-cert-action accept
            set log-blocked-traffic disable
            set add-vhost/domain-to-dnsdb disable
            set decrypted-traffic-mirror ''
        next
    end
  2. Configure the proxy policy with the ems-tag-unmanageable tag:
    config firewall proxy-policy
        edit 1
            set proxy access-proxy
            set access-proxy "zt1"
            set srcintf "port2" "ag2"
            set srcaddr "all"
            set dstaddr "all"
            set ztna-ems-tag "ems-tag-unmanageable"
        next
    end

ZTNA policy access control of unmanaged devices 7.2.1

The ZTNA access proxy can determine whether a client device that does not have FortiClient installed is a mobile device that is considered unmanageable, or is not a mobile device that is considered unknown. The ZTNA access proxy tags the device as either ems-tag-unmanageable or ems-tag-unknown respectively. The FortiGate WAD process achieves this by either matching device TLS fingerprints against a library or learning information from the HTTP User-Agent header if the set user-agent-detect setting is enabled.

The ems-tag-unmanageable and ems-tag-unknown tags allow for ZTNA access control of unmanaged devices using a proxy policy. The accept-unmanageable option for the empty-cert-action setting allows unmanageable clients to continue ZTNA proxy rule processing.

config firewall access-proxy
    edit <name>
        set client-cert enable
        set user-agent-detect {enable | disable}
        set empty-cert-action {accept | block | accept-unmanageable}	
     next
end

user-agent-detect {enable | disable}

Enable/disable detecting the device type by HTTP User-Agent if no client certificate is provided (default = enable).

empty-cert-action {accept | block | accept-unmanageable}

Set the action for an empty client certificate:

  • accept: accept the SSL handshake if the client certificate is empty.
  • block: block the SSL handshake if the client certificate is empty.
  • accept-unmanageable: accept the SSL handshake only if the end point is unmanageable.
config firewall proxy-policy
    edit <id>
        set ztna-ems-tag {ems-tag-unmanageable | ems-tag-unknown}
    next
end

ztna-ems-tag {ems-tag-unmanageable | ems-tag-unknown}

Set the EMS tag names:

  • ems-tag-unmanageable: match any device that is unmanageable.
  • ems-tag-unknown: match any device that is not recognized.

Consider the following use cases.

  • Case 1: if a client device sends a TLS client hello in a mobile pattern, then WAD will try to match its TLS fingerprint with a WAD original library and mark it with an ems-tag-unmanageable tag.
  • Case 2: if WAD cannot match the TLS fingerprint with an original library but user-agent-detect is enabled (under config firewall access-proxy), WAD will try to learn the device type from client request's User-Agent header. If it matches a mobile device, then it is still marked with an ems-tag-unmanageable tag.
  • Case 3: if WAD cannot match the TLS fingerprint with an existing original or temporary library, or cannot learn it from User-Agent header, or user-agent-detect is disabled, then it will mark the device as ems-tag-unknown.

In the access proxy settings, if empty-cert-action is set to accept-unmanageable, then only case 1 and 2 would go through the proxy policy. Case 3 would be denied, and a replacement message page would appear.

Example

To configure ZTNA policy access control of unmanaged devices:
  1. Configure the client certificate actions:
    config firewall access-proxy
        edit "zt1"
            set vip "zt1"
            set client-cert enable
            set user-agent-detect enable
            set auth-portal disable
            set empty-cert-action accept
            set log-blocked-traffic disable
            set add-vhost/domain-to-dnsdb disable
            set decrypted-traffic-mirror ''
        next
    end
  2. Configure the proxy policy with the ems-tag-unmanageable tag:
    config firewall proxy-policy
        edit 1
            set proxy access-proxy
            set access-proxy "zt1"
            set srcintf "port2" "ag2"
            set srcaddr "all"
            set dstaddr "all"
            set ztna-ems-tag "ems-tag-unmanageable"
        next
    end