NSE5 Part 2: Initial Configuration and System Settings

NSE5 Part 2: Initial Configuration and System Settings

Part 2 of the NSE5 series. This post covers the first lesson of the official curriculum — bringing a fresh FortiManager up to a usable baseline. It’s procedural, but every setting here turns up later in the exam in some form (ADOM behaviour, install previews, FortiGuard updates, HA elections), so don’t skip it.

What ships in the box

FortiManager runs on a hardened Linux base with a FortiOS-style CLI on top. After power-on, the device boots into a console login on admin with no password. Day-one always begins with these four steps:

1. Set an admin password.
2. Give the management interface a static IP and gateway.
3. Set system time and DNS.
4. Install or verify the FortiGuard / FortiCare entitlements.

Everything else (ADOMs, devices, policy packages) is downstream of those four.

Network — the management interface

config system interface
    edit "port1"
        set ip 10.10.20.10/24
        set allowaccess https ssh ping fgfm
        set service-access fgtupdates fclupdates webfilter-https
    next
end

Two settings that are NSE5-specific and routinely tested:

• allowaccess fgfm — the FGFM (FortiGate-FortiManager) tunnel runs on TCP/541 by default and must be reachable on whatever interface the managed FortiGates dial into. Without fgfm in the access list the tunnel never establishes, even if the device is “registered”.
• service-access — a less obvious knob that says “this interface is allowed to act as a FortiGuard relay for managed devices”. If you intend to push FortiGuard updates from FortiManager out to the fleet (the canonical reason to deploy one), this must be enabled on the egress interface.

Default route:

config system route
    edit 1
        set device "port1"
        set gateway 10.10.20.1
    next
end

Admin access

config system admin user
    edit "admin"
        set password ********
        set rpc-permit read-write
    next
end

config system admin setting
    set admin-https-redirect enable
    set http_port 80
    set https_port 443
    set idle_timeout 15
    set chassis-mgmt enable
end

Two places the exam loves to test:

• rpc-permit — JSON-RPC API access for an admin. Many automation users have read-write here even though their profileid only allows reading. The two are separately enforced; both must permit a write for the call to succeed.
• idle_timeout — applies to GUI sessions. CLI sessions use set admin-timeout under config system global. Different settings, different scopes.

System time and DNS

A FortiManager whose clock has drifted can’t validate FortiGuard certificates and silently stops updating. NTP first:

config system ntp
    set status enable
    set sync_interval 60
    config ntpserver
        edit 1
            set server "pool.ntp.org"
        next
    end
end

Then DNS — separate from the NTP server, despite what muscle memory from FortiGate tells you:

config system dns
    set primary 1.1.1.1
    set secondary 9.9.9.9
end

If you can’t resolve update.fortiguard.net from the FortiManager itself, no FortiGuard feature will work — confirm with:

execute ping update.fortiguard.net
execute traceroute update.fortiguard.net

FortiGuard configuration

FortiGuard on FortiManager is a two-sided thing — receiving updates from Fortinet and redistributing them to managed FortiGates. Both sides are tested:

config fmupdate fds-setting
    set fortiguard-anycast enable
    set fortiguard-anycast-source fortinet
    set umsvc-log info
end

config fmupdate publicnetwork
    set status enable
end

config fmupdate server-override-status
    set mode loose
end

The publicnetwork line is the one most people miss in a fresh lab — without it, the FortiManager can’t reach Fortinet’s CDN even if fortiguard-anycast is enabled.

To verify what’s downloaded so far:

diagnose fmupdate fds-version
diagnose fmupdate fmg-stats
get fmupdate analyzer virusreport

diagnose fmupdate fds-version is the single most useful command for FortiGuard troubleshooting on FortiManager — it lists every database with its current version, build time, and download status.

OFTP — the data feed to FortiAnalyzer

Even if you’re studying for the FortiManager-only exam, the OFTP (Optimised Fabric Transport Protocol) port comes up. OFTP runs on TCP/514 and carries logs from FortiGate to FortiAnalyzer; FortiManager listens on the same port for fabric joining. Confusingly, FGFM (TCP/541) and OFTP (TCP/514) often get swapped in exam questions.

Port	Protocol	What runs on it
TCP/541	FGFM	FortiManager → FortiGate management tunnel
TCP/514	OFTP	FortiGate logs → FortiAnalyzer / fabric handshake
UDP/162	SNMP traps	Outbound only
TCP/8890	FortiGuard updates	FMG → FortiGate redistribution

Memorise that table — at least one question on the exam keys directly off it.

Operation modes

FortiManager has two modes that affect how it interacts with managed FortiGates:

config system global
    set adom-status enable
    set workspace-mode normal
    set offline-mode disable
end

• adom-status — turns ADOMs on. Required for almost everything in the rest of this series. With ADOMs disabled, the FortiManager only manages a single device tree, which limits the GUI dramatically.
• workspace-mode — disabled, normal, or workflow. We come back to this in detail in Part 8; for now, normal is the working default in production.
• offline-mode — when enabled, FortiManager stops talking to managed devices entirely. Useful when restoring from a config backup, dangerous if you forget you turned it on. Exam questions occasionally show “FortiManager registered but not pushing config” — offline-mode enable is one of three things to check.

On-disk file structure

You’ll never directly browse the file system in the exam, but understanding what FortiManager stores explains several behaviours:

• /var/log/ — system logs and the OFTP log feed (when used).
• /var/log/dvm/ — device-manager logs, including the FGFM session log per device.
• /var/log/dlp/ — install-preview logs.
• /drive0/ — config revisions (one per device, retained per the global revision retention setting).
• /drive0/fmgmt/ — the FortiManager database itself.

The exam won’t quiz you on the path, but it will ask “where is the FGFM session log?” — answer: in the device-manager log, accessible via diagnose debug service dvm.

The first three diagnostic commands worth memorising

diagnose system print route
diagnose system print interface
diagnose system print sysinfo

After that, the FortiManager-specific ones:

diagnose dvm device list
diagnose dvm adom list
diagnose fmupdate fds-version
get system status

get system status is the human-readable summary — serial, FortiManager version, hostname, HA state, current ADOM count. It’s the first command to run on any FortiManager you’ve never seen before.

Configuration backup

FortiManager backups are taken from the GUI (System Settings → Dashboard → System Information → Backup) or via CLI:

execute backup all-settings ftp 10.10.20.5 backup.cfg user pass
execute backup all-settings sftp 10.10.20.5 backup.cfg user pass

Two important things:

• all-settings includes ADOMs, policy packages, device databases, scripts, and revision history. Without it (config-only), the backup is small but missing everything that matters.
• The backup file is not encrypted by default. Add set passphrase under config system global if the destination is shared.

Restore is the inverse:

execute restore all-settings ftp 10.10.20.5 backup.cfg user pass

The unit will reboot. Plan for that.

Common exam scenarios

• “FortiManager can register devices but FortiGuard updates fail.” Almost always DNS, NTP, or publicnetwork not enabled — in that order.
• “Admin can log into the GUI but cannot make API calls.” rpc-permit is none or read-only on that admin user.
• “Managed FortiGates show as offline despite being reachable.” fgfm not in allowaccess on the management interface, or offline-mode enable set on FortiManager.

Part 3 covers the FortiManager HA cluster — primary/secondary roles, sync mechanics, and how to recover when the cluster splits.