Understanding FortiManager ADOM Collaboration Features
FortiManager uses Administrative Domains (ADOMs) to isolate configuration data for different teams or customers. When multiple administrators need to work in the same ADOM, the platform offers two primary collaboration modes: workspace mode and workflow mode. Enabling workflow mode is the recommended way to prevent configuration conflicts because it requires a central approval before any change is committed. This ensures that only one approved revision is installed, eliminating the risk of overlapping edits.
Key Benefits of Workflow Mode
- Changes are saved as drafts until a reviewer approves them.
- Each approved change creates a new revision entry, providing a clear audit trail.
- Administrators can lock an ADOM to enforce the approval process.
In contrast, workspace mode allows simultaneous edits but relies on manual conflict resolution, which can lead to accidental overwrites. For organizations that prioritize change control and compliance, workflow mode combined with the ADOM lock feature is the optimal configuration.
High Availability (HA) Failover in FortiManager
FortiManager HA is designed to be transparent to administrators. When the monitored interface of the primary unit fails, the secondary unit automatically assumes the primary role without any manual intervention. This seamless promotion is similar to an autopilot system that changes lanes without the driver touching the wheel. Because the failover process is automatic, there is no need to re‑configure peer IP addresses or manually promote a secondary device.
What to Expect During a Failover Event
- The secondary FortiManager detects the loss of the primary's heartbeat.
- It promotes itself to primary status and continues serving management traffic.
- All existing sessions, policies, and revisions remain intact.
Administrators should monitor HA status via the dashboard, but no configuration changes are required after the event.
Address Objects and Network Masks
When you create a firewall address object that represents a LAN, FortiManager stores the entire subnet, not just a single host IP. For example, an object named LAN with the network 172.16.5.0/24 will be installed on a remote FortiGate as 172.16.5.0/255.255.255.0. This behavior ensures that all hosts within the LAN can be matched by policies that reference the object.
Common Mistake
New administrators often confuse the host mask /32 with the subnet mask /24. Remember: an address object is a container for a range, so the mask reflects the full network you intend to protect.
Revision History and Device‑Level Configuration
FortiManager maintains a detailed revision history for every change made through its console. Two actions that generate a new revision entry are:
- Editing the device‑level database directly on FortiManager (e.g., modifying interface settings, routing, or system parameters).
- Installing a new configuration revision that includes device‑level changes.
When you revert to a previous revision, the CLI output will indicate which layers of configuration were applied. If the message states that only the device‑level configuration was installed, it means the policy packages and other higher‑level objects were not part of that revert.
Why Device‑Level Reverts Matter
Device‑level changes affect the underlying FortiGate hardware directly. Reverting only this layer is useful when you need to roll back a mis‑configured interface without disturbing the policy logic that governs traffic.
Central Approval for Firewall Policy Changes
To require a central approval before any firewall policy is installed, enable both workflow mode and the ADOM lock feature. Workflow mode captures the change as a draft, while the ADOM lock prevents any other administrator from installing the draft until the designated approver releases the lock.
Step‑by‑Step Configuration
- Navigate to System Settings → ADOM Settings and enable Workflow Mode.
- Activate the ADOM Lock for the relevant ADOM.
- Assign reviewers to the lock so they receive notification of pending changes.
Once approved, the change is committed, a new revision is recorded, and the policy becomes active across all managed devices.
Global Policy Packages and ADOM Inheritance
When a global policy package is assigned to an ADOM (e.g., ADOM1), any new policy package created within that ADOM automatically inherits the global package. FortiManager performs this assignment behind the scenes, ensuring consistency across the domain without requiring manual selection.
Practical Example
Imagine you have a global package called Corporate‑Baseline. After assigning it to ADOM1, you create a new package named Branch‑Office‑Policies. FortiManager instantly links Corporate‑Baseline to Branch‑Office‑Policies, so any updates to the global package propagate to the new package on the next install.
FortiGuard Signature Synchronization Issues
If a FortiGate acting as a client of a local FortiGuard Distribution Server (FDS) fails to recognize a newly pushed IPS signature, the most common cause is a version mismatch between the FortiManager and the FortiGate IPS databases. The FortiGate may be running an older signature set, preventing it from applying the latest updates received from the FDS.
How to Resolve Version Mismatches
- Verify that the FortiGate firmware version matches the signature database version supported by the FDS.
- Force a manual signature refresh from the FortiGate CLI using
execute update-now. - Check the FortiGuard server list to ensure the correct FDS IP is configured.
Keeping firmware and signature versions aligned is essential for effective intrusion prevention.
Best Practices for Managing FortiManager Revisions
Effective revision management reduces the risk of configuration drift and simplifies troubleshooting. Follow these best practices:
- Use descriptive revision comments – include the purpose, affected devices, and ticket numbers.
- Enable automatic backups – schedule daily snapshots of the device‑level database.
- Leverage workflow mode – ensure every change passes through a review process.
- Regularly prune old revisions – retain only the last 20‑30 revisions to conserve storage.
By adhering to these guidelines, administrators can maintain a clean, auditable configuration history while minimizing the chance of accidental overwrites.
Summary of Key Concepts
In this course we covered:
- The distinction between workspace and workflow modes, and why workflow with ADOM lock is essential for conflict‑free collaboration.
- How FortiManager HA failover works transparently, requiring no manual reconfiguration.
- The correct subnet mask for LAN address objects and the common /24 vs /32 confusion.
- What a device‑level only revert indicates and how revision history is created.
- The combination of workflow mode and ADOM lock to enforce central approval for policy changes.
- Automatic inheritance of global policy packages within an ADOM.
- Version mismatch as the primary cause of missing IPS signatures from a local FortiGuard Distribution Server.
Implementing these practices will improve operational efficiency, enhance security posture, and ensure that your FortiManager environment remains robust, auditable, and easy to manage.
