NSE5 Part 4: Administrative Domains (ADOMs)

NSE5 Part 4: Administrative Domains (ADOMs)

Part 4 of the NSE5 series. ADOMs are the multi-tenancy primitive that everything else on the FortiManager depends on. Get them wrong and policy packages, RBAC, and revision history all behave in ways that look broken but are working as designed. The exam tests this lesson harder than it tests anything else.

What an ADOM is

An ADOM is a scoping container. Every managed device, policy package, object database, script, and revision lives inside one ADOM. Admin users are scoped to one or more ADOMs and cannot see anything outside them. ADOMs are how you carve a single FortiManager into per-customer, per-region, or per-firmware compartments without running multiple appliances.

config system global
    set adom-status enable
end

Once enabled, the GUI gains the ADOM picker in the top bar and the CLI tree gets ADOM-scoped sections under config dvmdb.

You cannot easily turn ADOMs off again on a populated FortiManager — disable wipes ADOM-scoped data. The exam will hint at this with “what is the safe order of operations to disable ADOMs?” — answer is to back up first, then expect to lose ADOM data on disable.

ADOM modes — normal vs advanced

The single setting that most determines how your FortiManager behaves is the ADOM mode:

config system global
    set adom-mode normal
end

Mode	Behaviour
Normal	Each device belongs to exactly one ADOM. Policy packages contain firewall objects only. Simpler to operate.
Advanced	Each device can be in multiple ADOMs (a managed FortiGate’s VDOMs can be in different ADOMs). More flexible, more failure modes.

Almost every production FortiManager ships in normal mode and stays there. Advanced mode exists for managed service providers who hand each customer a single VDOM on a shared FortiGate and want each VDOM in its own ADOM. If the question doesn’t say “MSP” or “VDOM split”, the answer is normal.

ADOM versions and version locking

Every ADOM is locked to a firmware version family. A FortiOS 7.4 ADOM can manage 7.4.x FortiGates only; a 7.2 ADOM manages 7.2.x. You cannot move a 7.2 device into a 7.4 ADOM without upgrading the device first.

This is enforced because policy package syntax and object schemas change across major versions. A 7.4 policy package with new field names cannot be installed onto a 7.2 device.

To create a 7.4 ADOM:

config dvmdb adom
    edit "branch-fw-74"
        set os-ver 7.0       ; major version family is "7.0", "6.4", etc.
        set mr 4             ; minor release: 7.4
        set restricted-prds fos
        set state enable
    next
end

The exam will hand you a managed device on 7.2.5 and an ADOM set to os-ver 7.0 mr 4 and ask if registration succeeds. Answer: no — the device must be 7.4.x to enter that ADOM.

ADOM types — by product

ADOMs aren’t only for FortiGates:

restricted-prds value	Manages
fos	FortiGate / FortiOS
fsw	FortiSwitch (managed by FortiManager rather than by FortiGate)
fap	FortiAP (managed by FortiManager directly)
fct	FortiClient EMS
fpx	FortiProxy
faz	FortiAnalyzer-managed ADOM (when integrated)

A FortiSwitch or FortiAP managed via a FortiGate doesn’t need its own ADOM — it lives inside the parent FortiGate’s ADOM. The ADOM types above are for when those products are managed directly by the FortiManager.

Default ADOMs

A fresh FortiManager with adom-status enable ships with several built-in ADOMs:

• root — system ADOM, contains the FortiManager itself and global objects.
• default — catch-all FortiOS ADOM for unassigned devices.
• rootp — provisioning placeholder for FortiAnalyzer integration.
• Global Database — contains shared header/footer policies and the global object database that ADOMs in advanced mode can inherit from.

You can rename default but you cannot delete root or Global Database. The exam may test this.

Global Database and ADOM inheritance

In advanced mode, ADOMs can pull from the Global Database — a shared object store and a pair of header/footer policy lists that get prepended/appended to every ADOM’s policy package on install. This is how a service provider enforces a “no telnet outbound” rule across every customer without editing 200 policy packages.

The interaction is subtle and exam-relevant:

• Header policies are installed before the ADOM’s own policies — they win on first match.
• Footer policies are installed after — they only match if everything in the ADOM missed.
• The global ADOM’s objects are referenced by ADOM packages, not copied; updating the global object propagates on the next install.

In normal mode, the Global Database is hidden but still exists; it is not active.

Admin profiles and ADOM scope

Admin users are scoped to ADOMs at user level, not at profile level. A profile defines what an admin can do; the ADOM list defines where they can do it.

config system admin user
    edit "tenant-a-admin"
        set profileid "Standard_User"
        set adom "tenant-a"
    next
    edit "global-admin"
        set profileid "Super_User"
        set adom "all_adoms"
    next
end

set adom "all_adoms" is the keyword that grants every ADOM (existing and future). For tenant administrators, list explicit ADOMs by name.

The Standard_User profile is the working default. Super_User bypasses ADOM scoping and most other safety rails — restrict it to a small group of named admins.

Revision history per ADOM

Every install operation captures a revision per ADOM. Revisions are immutable and cumulative — they are how you roll back, not how you snapshot.

diagnose dvm proc list
diagnose dvm device list
diagnose dvm adom list

In the GUI, ADOM revisions are under ADOM Revisions on the System Settings page. Two settings worth knowing:

• Revision retention count — how many revisions are kept before the oldest is purged. Default 25; increase for ADOMs with frequent installs.
• Revision lock — pin a specific revision so it cannot be auto-purged. The exam asks “how do I keep last quarter’s golden config?” — answer: lock it.

ADOM diagnostics

diagnose dvm adom list

Shows every ADOM, its OS version, mode, and the device count. Useful first command when troubleshooting “I can’t see my devices” — almost always the admin is in the wrong ADOM.

diagnose dvm device list

Lists every managed device with its ADOM membership. If a device shows in the wrong ADOM, you can move it (with restrictions — version family must match) via Device Manager → right-click → Move to ADOM.

Common exam scenarios

• “Tenant admin cannot see Device A even though it’s registered.” Wrong ADOM scope on the user, or device is in a different ADOM than the user is allowed to see.
• “Cannot move FortiGate from ADOM-A to ADOM-B.” Version mismatch — ADOM-B is on a different firmware family.
• “Policy package install on ADOM-B picks up an unexpected first rule.” Header policy from the Global Database, advanced mode.
• “ADOM appears greyed out in the picker.” That admin user has no scope for the ADOM, or state disable is set on the ADOM.

Part 5 takes the next logical step — registering FortiGates into an ADOM and the device-lifecycle operations (provisioning, model devices, ZTP, install) that go with it.