FireSight docs

Connect a FortiManager

FireSight talks to FortiManager through its JSON-RPC API, authenticated with an API token of a REST API administrator. It reads every management domain (Fortinet: ADOM), FortiGate, policy set (Fortinet: policy package), object and route, and writes approved policies through it.

FortiManager 7.0 or later is assumed.

Why an API token, not a password

FireSight's FortiManager connection only accepts an API token. A token belongs to a dedicated API administrator, can be limited to the FireSight server's address, and doesn't expire or change with someone's password.

An ordinary GUI administrator's user name and password can't be used for the connection, and are often refused by FortiManager's API anyway: for example when the admin signs in through RADIUS, LDAP, TACACS+ or SAML, has two-factor sign-in, must change its password, or has JSON API Access set to None. The export script explains each case when it meets one.

Step 1: create the API administrator on FortiManager

Create a dedicated REST API administrator for FireSight:

  1. Choose or create an admin profile that may change policy packages and objects and install packages in the ADOMs FireSight should manage.
  2. Create an administrator of type REST API admin (user type api) with that profile, access to those ADOMs, and JSON API Access set to Read-Write.
  3. Restrict its trusted hosts to the FireSight server's address.
  4. Generate its API key and copy it. You'll paste it into FireSight.

On the FortiManager CLI, the same looks like this (the profile name and address are placeholders):

config system admin user
  edit firesight
    set user_type api
    set profileid <profile>
    set rpc-permit read-write
    set trusthost1 <firesight-server-ip> 255.255.255.255
  next
end
execute api-user generate-key firesight

Read-only first

To try FireSight against a production FortiManager before allowing changes, use a profile with read-only rights and set rpc-permit read. Sync and audit work; deployments are refused by FortiManager. Keep FIRESIGHT_DEPLOY_MODE=simulate meanwhile.

Step 2: add it in FireSight

  1. Open Settings, Connections, and click Add FortiManager.
  2. Enter a Name (for example FMG Rome), the Host name or IP and the Port (443).
  3. Paste the key into API token, or enter an environment variable name under Or read the token from an environment variable.
  4. Leave Verify the TLS certificate on unless the FortiManager has a self-signed certificate in a lab.
  5. Check the two FortiManager options below, then click Save connection.
  6. Click Test. It shows FortiManager's host name and version, or the error.
  7. Click Sync now.
  8. Check the workspace mode FireSight detected for each ADOM under ADOMs and firewalls.

Hit counts, routes, interfaces, zones, policy routes and SD-WAN are read from each FortiGate through FortiManager's device proxy, so the FortiGates must be reachable from FortiManager. A FortiGate that isn't gives a sync warning, and its hit counters are missing.

Workspace mode

FortiManager can require ADOMs to be locked before changes (workspace mode), or can apply changes directly. FireSight reads each ADOM's setting when it syncs, so ADOMs with and without workspace mode can share one FortiManager.

What FireSight detected What a deployment does
workspace off Changes apply directly: no lock.
workspace on Workspace: lock, commit, unlock: locks the ADOM, makes the change, commits and unlocks, then installs.
workflow mode Workflow mode (not supported): deployment is refused.
couldn't be read Uses the connection's Assume workspace mode if an ADOM's setting can't be read option.

To override the detection for one ADOM, change its Workspace mode in the ADOMs and firewalls table:

Choice Meaning
Detect (…) Default. Use what FireSight read; the brackets show it.
Always lock and commit Always lock, commit and unlock.
Never lock Never lock.

Override it only if the detection is wrong. Workflow mode (approval sessions inside FortiManager) isn't supported: switch the ADOM to workspace or normal mode. If workflow approval isn't actually enforced on that ADOM, an administrator can choose Always lock and commit.

Install On

Install new policies only on the firewalls in the traffic path (Install On) is on by default.

  • On: when a policy package is installed on more firewalls than the traffic crosses, FireSight sets the new policy's Install On to just the firewalls on the path, and installs the package only to them. Unrelated pending changes in the package don't reach other firewalls.
  • Off: the new policy applies to every firewall in the package's scope, and the package is installed to all of them. The request shows Install On isn't limited for this FortiManager, so those firewalls get the policy too.

Turn it off only if your FortiManager practice doesn't allow per-device Install On.

What a deployment does on FortiManager

  1. Saves an ADOM revision (a rollback point in FortiManager).
  2. Locks the ADOM, if it uses workspace mode.
  3. Creates or reuses address and service objects, and adds missing normalised-interface mappings.
  4. Adds the policy and moves it into position.
  5. Commits and unlocks (workspace mode), then installs the package to the firewalls in scope.
  6. Re-syncs the package so audits reflect what is now live.

See Deploy and back out.

Change or remove the token

To replace a token, click Edit, paste the new one into API token and save. To clear it, tick Remove the stored token. When you change the address, FireSight requires the token again.

← Connections Connect a standalone FortiGate →