NSE5 Part 10: Advanced Features and Integrations

NSE5 Part 10: Advanced Features and Integrations

The final post in the NSE5 series. The advanced lesson is a grab-bag — FortiGuard distribution, scripting, the JSON-RPC API, SSO, and the FortiAnalyzer integration. The exam tests these less heavily than the policy or HA lessons, but at least one or two questions on each are likely.

FortiGuard distribution

A FortiManager can act as a FortiGuard distribution server — it pulls updates from Fortinet, then redistributes them locally to managed FortiGates. This saves egress bandwidth and works in air-gapped or restricted networks where FortiGates can’t reach the public internet.

config fmupdate publicnetwork
    set status enable
end

config fmupdate server-override-status
    set mode loose
end

config fmupdate fct-services
    set status enable
    set port 80
end

Three things to know for the exam:

• The relay listens on TCP/8890 by default for FortiGate update requests.
• service-access fgtupdates must be enabled on the interface FortiGates use to fetch.
• Each FortiGate must point at the FortiManager via config system central-management → set include-default-servers disable and the FortiManager set as the override server.

A common scenario: “FortiGate shows FortiGuard licence valid but signatures are stale.” diagnose autoupdate versions on the FortiGate tells you the override server’s reachability — almost always either the override server isn’t reachable on TCP/8890 or include-default-servers is still enabled and FortiGate is silently using the public CDN that’s somehow blocked at the perimeter.

Scripting

A FortiManager script is a block of FortiOS CLI stored in the ADOM and executable against one or many devices. Scripts can be CLI text or TCL (the latter is rarely used outside very specific automation cases).

config dvmdb script
    edit "set-snmp-baseline"
        set type cli
        set target remote_device
        set content "config system snmp community
                       edit 1
                         set name 'baseline'
                       next
                     end"
    next
end

Run via Device Manager → right-click → Run Script, or:

execute fmscript run <script-name> <device-name>

Scripts run outside of installs — they push directly to the FortiGate without going through the policy package or template engine. This bypasses the install preview and the revision system. Use sparingly. The exam asks “what is captured in revision history when a script runs?” — answer: nothing on the FortiManager side. The next time FortiManager retrieves config from the device, the script’s effect appears as an out-of-band change.

Database scripts vs remote scripts

Two target values that change behaviour:

target	Where the script runs
remote_device	Pushed to the FortiGate over FGFM and executed there
device_database	Applied to the FortiManager’s database of the device — staged, not pushed

Database scripts are the safer pattern: the change lands in FortiManager first, you can review it, then install pushes it normally with full revision capture. The exam tests the difference; it almost always wants device_database for production answers.

JSON-RPC API

FortiManager exposes a comprehensive JSON-RPC over HTTPS API. Endpoint:

POST https://<fmg>/jsonrpc
{
  "id": 1,
  "method": "exec",
  "params": [{ "url": "/sys/login/user",
               "data": { "user": "api", "passwd": "..." } }]
}

Returns a session token used by subsequent calls. Every CLI operation has a JSON-RPC equivalent — adding devices, installing packages, retrieving install logs, querying revisions.

Two things the exam tests:

• The admin user must have rpc-permit read-write (Part 2). Without it, calls fail at the auth layer regardless of profile.
• Lock semantics still apply in workspace mode — the API caller must lock before set and commit (save) before unlock.

Single Sign-On

FortiManager supports SSO via SAML and via FortiAuthenticator (which can act as an IdP for SAML or for FortiGate’s FSSO). Configuration:

config system saml
    set status enable
    set service-provider-host fmg.example.com
    set entity-id "fmg-sp"
    set idp-cert "idp-signing-cert"
    set idp-entity-id "https://idp.example.com/"
    set idp-single-sign-on-url "https://idp.example.com/sso"
    set default-profile "Standard_User"
    set default-adom "all_adoms"
end

default-profile and default-adom apply to a federated user the first time they log in — useful for bulk onboarding. Per-user profile and ADOM scope can be overridden via SAML attributes if your IdP can emit them.

Two scenarios that show up:

• “SSO admin can log in but lands in the wrong ADOM.” default-adom set to all_adoms and the IdP isn’t sending an ADOM attribute, or the user’s mapped profile doesn’t restrict.
• “SSO admin can log in but cannot make changes.” rpc-permit none on the federated user mapping (it’s a default for SSO admins in some configs).

Fabric authorisation

A FortiManager can join the Security Fabric alongside a root FortiGate. Once joined, the FortiManager appears in the FortiGate’s fabric topology, can be opened from the topology view, and can receive automation triggers from FortiGate fabric events.

config system csf
    set status enable
    set group-name "office-fabric"
    set group-password ********
    set upstream-ip 10.10.1.1
end

Fabric joining uses OFTP on TCP/514 (Part 2). The exam asks which port — it’s the same port FortiAnalyzer uses for log ingestion, which is why both products typically open TCP/514 on the same management network.

FortiAnalyzer integration

A FortiManager can run with a co-located FortiAnalyzer feature set (in older releases) or integrate with a separate FortiAnalyzer. The integration paths:

Path	Description
FAZ features on FMG	Enable analyser features in config system global → set log-forward-mode. Useful for small deployments.
Separate FAZ + FMG	Two appliances; FMG forwards device-management metadata, FAZ ingests logs directly from devices.
Fabric ADOM	FMG and FAZ share an ADOM for unified visibility (the modern integration).

Configuration to point FortiManager at an external FortiAnalyzer:

config system locallog fortianalyzer setting
    set status realtime
    set server 10.10.20.20
    set serial-number "FAZ-VM0000000000"
    set upload-option realtime
end

upload-option realtime is the standard production setting. store-and-upload batches and uploads at intervals — useful when the WAN to FAZ is constrained.

Operating in regulated environments

Three settings that come up when the exam wraps the lesson in a “the customer is regulated” framing:

config system global
    set fips-mode enable           ; FIPS-CC compliance; restricts crypto and resets the box
    set strong-crypto enable
    set ssh-enc-algo aes256-ctr [email protected]
    set ssh-mac-algo hmac-sha2-512 hmac-sha2-256
end

FIPS mode is a one-way switch on most builds — enabling it factory-resets the device into FIPS-compliant operation. The exam mentions FIPS often enough to be worth knowing the toggle exists.

Series wrap-up

That closes the official NSE 5 / FCP FortiManager Administrator syllabus. Across this ten-part series you’ve now seen the system settings, the HA mechanics, ADOMs, device registration, the template engine, policy packages, the locking and approval models, the diagnostic toolbox, and the integrations.

The single piece of advice I’d repeat from Part 1: build the lab. The five-part FortiManager Lab on Proxmox series gives you the platform; everything in this exam series can be reproduced inside it. Click the GUI, run the equivalent CLI, capture the diagnostic, walk through diagnose dvm proc list and diagnose dvm task list until the output reads like English. Do that, and the exam stops being about memorisation and starts being about pattern recognition.

Good luck on the exam.