FortiManager

Clarity Transform reads centrally authored firewall policy from FortiManager over its JSON-RPC API, separately from any one managed FortiGate's own installed configuration. Read-only throughout.

Where to find it

Go to Discover → Integrations, then select the FortiManager card. The card's category label is Security. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.

Why we do this

Firewall policy is a complementary axis to observed traffic, and the pair is worth more than either alone. Firewall policy describes every conversation that is permitted to happen.

Device and manager are not the same thing, and where both exist we read both

A firewall holds the policy currently installed on it. The manager holds policy authored centrally, which may include rules not present on any one device. Reading only the device would miss centrally authored intent; reading only the manager would miss anything configured locally.

What we collect

• Policy-package rules, which is where centrally authored policy lives
• Each ADOM's address objects, address groups, service objects and service groups
• Inferred device-to-device relationships, resolved the same way the FortiGate and Palo Alto integrations resolve theirs

What it adds

A policy package assigned to several devices appears here once. Reading only the devices would show the same rule repeatedly with nothing to indicate it is one rule, and would miss anything authored but not yet installed.

Coverage follows the ADOMs the account can see, so a FortiManager split into per-tenant or per-region ADOMs needs an account whose visibility matches the scope of the engagement.

What is deliberately not inferred

• No traffic content, packet captures or firewall logs. Configuration only.
• Nothing is written back to the appliance at any point, and the account used has no permission to do so.
• A rule is not a dependency. A rule is promoted to a CMDB relationship only where both its source and destination resolve to a device or network already discovered, and where it is specific enough to describe a dependency rather than a broad policy. An any-to-any rule is a statement about posture, so it is read and discarded.

Rule order is not evaluated

Firewall evidence means "a rule names this pair and port", not "this traffic would pass". A rule shadowed by a preceding deny still produces evidence. Deny, disabled, negated-address, negated-service and port-less rules are refused before they reach inference, so shadowing is the one case that is not detected. Treat a permitted-only finding as a lead to verify rather than a conclusion.

• Install status is not evaluated. A rule in a policy package may not yet be installed on the devices it is assigned to. Treat a FortiManager-only finding as intent rather than as installed configuration.
• No FortiAnalyzer log data. Configuration only.

What we require

The requirement below is read from rb-pautol-fortimanager-connect.ps1 in the Runbooks repository, which is where it is maintained. If it is wrong, the runbook is what gets corrected and this page follows on the next build.

Access profile required: a custom profile - not a built-in. Restricted_User cannot read policy or the object database at all, and Standard_User carries write permissions discovery should not have. Every field set to read. Discovery reads the ADOM object database and policy packages only; it never writes.

The account also needs rpc-permit: read, which is not covered by the access profile and defaults to none. The FortiManager GUI labels the same setting "JSON API access"; rpc-permit is the CLI name and the authoritative one here. Both names are given because the engineer provisioning the access is looking at one or the other. With the default in place the account authenticates successfully and only then fails on the first real request, returning status -11 on every call - which reads as a broken integration rather than as a missing permission.

Connectivity: the FortiManager JSON-RPC API over HTTPS on TCP 443 from Clarity.

Coverage equals the ADOMs the account can see. On a FortiManager split into per-tenant or per-region ADOMs, an ADOM the account cannot see is an ADOM missing from the discovered policy, with nothing to indicate it was omitted.

FortiManager calls every named login an "admin user" (config system admin user) regardless of privilege, the same generic sense FortiGate and PAN-OS use "administrator" in. Do not let that word read as "privileged" in anything derived from this file - this account cannot change a single setting on the appliance.

Verification before handover

Run these as the system owner before handing the credential over, so a failed discovery run is never the first time anyone finds out.

1. Confirm the API session can be established. This is the check that matters, and it is a two-part answer. The account can authenticate and still be unable to make a single call, because API access is a separate permission that defaults to none. Confirm both: that login succeeds, and that a subsequent request returns data rather than an error.
2. Confirm the ADOMs in scope are visible. List the ADOMs as this account. Coverage equals what it can see, so a missing ADOM here is a missing ADOM in the discovered policy.
3. Confirm a policy package reads. Read the rules of one package. Populated is what you want; an error at this point with a successful login above is the API permission, not the profile.

Configuring the endpoint

On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:

Field	Value
Name	A name for the endpoint
End Point	The FortiManager hostname or IP
Credential	The stored credential for the read-only administrator
Job Schedule	A five-field cron expression, for example 0 2 * * * (daily). Central policy changes more often than a single device's
Enabled	Ticked. The box is unticked when the form opens

The help texts: End Point "FQDN or IP Address of management system for technology e.g. vCenter, Nutanix Prism"; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉 〈hh〉 〈day-of-month〉 〈month〉 〈weekday〉".

The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.

No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.

Removing the access

Delete the account on the appliance. Nothing else is left behind: Clarity creates no objects and holds no session once a run ends. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.

Troubleshooting

Symptom	Cause
Login succeeds and every request then fails	API access is not permitted for the account. It defaults to none, so this is the expected symptom of a profile that was granted read but not API access.
Fewer ADOMs than expected	The account's visibility is scoped. Coverage equals what the account can see.
Rules read but no relationships created	Endpoints do not resolve to discovered devices. Run the hypervisor and operating system integrations first.
A rule here does not exist on the device	Expected where the package has not been installed. FortiManager holds authored policy, the device holds installed policy.