Shopping cart

Subtotal:

$0.00

NSE7_EFW-7.2 Central management

Central management

Detailed list of NSE7_EFW-7.2 knowledge points

Central Management Detailed Explanation

Central Management simplifies network operations by using FortiManager and FortiAnalyzer to handle device configurations, log analysis, and security policies across large-scale environments.

2.1 FortiManager Functions

FortiManager is a centralized management tool designed to simplify configuration and policy management across multiple FortiGate devices.

2.1.1 Device Management

  • Import FortiGate Configurations:

    • FortiManager can import existing configurations from FortiGate devices, allowing centralized control without starting from scratch.
    • Steps:
      1. Add the FortiGate device to FortiManager:
        • Navigate to Device Manager in FortiManager.
        • Select Add Device and input the FortiGate's IP and credentials.
      2. Import the configuration when prompted.
  • Device Groups:

    • Group multiple FortiGate devices for easier management. Devices in the same group can share settings and policies.
    • Example Use Case:
      • All branch office FortiGate devices can belong to a single group, making updates consistent across locations.

2.1.2 Policy Management

  • Policy Packages:

    • FortiManager allows creating policy packages that can be deployed to multiple devices.
    • Steps:
      1. Go to the Policy & Objects section.
      2. Create a new policy package.
      3. Define rules (e.g., allow/block specific traffic) and apply them to the desired devices.
  • Scripts for Bulk Changes:

    • Use scripts to perform bulk configuration updates, saving time in large deployments.

    • Example:

      • A script to set an NTP server across all devices:

        config system ntp
            set server "pool.ntp.org"
        end
        

2.1.3 Version Control

  • Configuration Snapshots:

    • FortiManager automatically creates snapshots of device configurations whenever changes are made. These snapshots allow you to track changes and revert to previous versions if needed.
  • Rollbacks:

    • If a change causes issues, you can roll back to a stable version using the snapshot history.
    • Steps:
      1. Go to the Revision History for a device.
      2. Select a previous configuration version and click Restore.

2.1.4 Local FortiGuard Server

  • Purpose:
    • Cache FortiGuard signature updates (antivirus, IPS, web filtering) locally instead of fetching them from the cloud, improving update speed.
    • Steps to Configure:
      1. Enable the local FortiGuard server in FortiManager.
      2. Configure devices to use FortiManager as their FortiGuard update source.

2.2 FortiAnalyzer Functions

FortiAnalyzer is a logging and analytics platform that collects data from FortiGate devices to provide insights into network performance and security.

2.2.1 Log Storage and Analysis

  • Log Collection:

    • FortiAnalyzer collects logs such as:
      • Traffic Logs: Monitor data flows across the network.
      • Event Logs: Record system events like logins or configuration changes.
      • User Activity Logs: Track user behavior and access.
  • Dashboards:

    • Visualize data through interactive dashboards, showing trends in traffic, threats, and system performance.
    • Example:
      • A dashboard can display the top 10 sources of blocked traffic, helping identify potential threats.

2.2.2 Report Generation

  • Custom Report Templates:

    • Create tailored reports to meet organizational needs, such as compliance audits or security reviews.
    • Example:
      • Generate a report highlighting web filtering activities over the past week.
  • Automated Reports:

    • Schedule reports to be generated and emailed automatically at specific intervals (e.g., daily, weekly).

2.3 Global Policy and Management

Global management capabilities allow administrators to create security rules and configurations that apply to multiple devices or domains, reducing redundancy.

2.3.1 Global Policy Configuration

  • Centralized Rules:

    • Define a global policy set in FortiManager that applies to all connected devices or specific groups.
    • Benefits:
      • Avoid redundant configurations.
      • Ensure consistency across devices and locations.
  • Use Case:

    • A global policy might include rules for:
      • Blocking access to high-risk websites.
      • Enforcing SSL inspection for all traffic.

2.3.2 Integrated Management

  • Combining FortiManager and FortiAnalyzer:
    • FortiManager handles configuration and policy management, while FortiAnalyzer provides logs and analytics.
    • Together, they enable centralized visibility and control over the network.

Step-by-Step Example Workflow

Here’s an example of how FortiManager and FortiAnalyzer might be used in a real scenario:

  1. Device Configuration:
    • Add a new FortiGate device to FortiManager and import its settings.
    • Assign it to a device group.
  2. Policy Deployment:
    • Create a policy package for the device group, defining rules to allow business-critical traffic and block unauthorized access.
    • Deploy the policy package to all devices in the group.
  3. Log Analysis:
    • FortiAnalyzer collects logs from these devices.
    • Use dashboards to identify unusual traffic patterns.
  4. Report Generation:
    • Generate a report summarizing detected threats and policy violations.

Why Central Management Matters

In environments with multiple FortiGate devices, managing each one individually becomes inefficient. FortiManager and FortiAnalyzer allow you to:

  • Save time through automation.
  • Maintain consistency across devices.
  • Gain deeper insights into network performance and security.

If you’re new to FortiManager and FortiAnalyzer, start by adding a single device to FortiManager, explore the policy creation process, and view logs in FortiAnalyzer to get hands-on experience.

Central Management (Additional Content)

1. Administrative Domains (ADOMs)

What Are ADOMs?

ADOMs (Administrative Domains) are logical containers in FortiManager that allow multiple customers, business units, or regions to be managed independently within the same FortiManager instance.

Why Use ADOMs?

  • To isolate device configurations, policies, and logs.
  • Ideal for:
    • Managed Service Providers (MSPs) who manage multiple clients.
    • Enterprises with multiple departments needing policy separation.
    • Multi-tenant environments requiring strict separation of management tasks.

Key Features:

  • Separate policy packages and object databases per ADOM.
  • Role-based access control (RBAC) can be applied per ADOM.
  • Logging and reporting are also isolated by ADOM when integrated with FortiAnalyzer.

How to Enable ADOMs:

  1. Enable in the Global Settings:
config system global
   set adom-mode advanced
end
  1. Create ADOMs via GUI or CLI:
config system admin adom
   edit "CustomerA"
   next
   edit "DeptB"
   next
end
  1. Assign devices to each ADOM individually after import.

2. Policy Package Status Check

FortiManager verifies the synchronization status between policy packages and the configurations currently on managed FortiGate devices.

Color Indicators:

  • Green – The policy package is fully installed and matches the device configuration.
  • Red – The policy package has changes that have not been installed yet.
  • Orange – There is a partial mismatch, possibly due to manual changes made directly on the device.

Exam Scenario:

You may be asked: "How can an administrator identify if the policy configuration on FortiGate is out-of-sync with FortiManager?"

Answer: By checking the color-coded policy status indicator under the Device Manager or Policy & Objects sections.

Common Causes of Mismatch:

  • Manual configuration changes on the device.
  • A policy package was edited but not reinstalled.
  • Device or ADOM synchronization issues.

3. FortiManager CLI Shortcuts and Commands

While most FortiManager tasks are performed via the GUI, certain exam scenarios or advanced workflows may require knowledge of CLI commands.

Check Device and Policy Package Status:

diagnose dvm device list
  • Lists devices and their status within the Device Manager.
  • Shows details like ADOM membership, sync status, and policy status.

Force Policy Installation (Push):

execute fmpolicy push <device-name>
  • Installs the latest policy package to the specified device.
  • Useful when automated push fails or needs to be forced during troubleshooting.

Check ADOM lock status:

diagnose fmupdate adom-lock-status
  • Verifies whether an ADOM is locked by another user or task.

Bonus Tip:

CLI is also used in script-based bulk configuration workflows within FortiManager.

4. FortiAnalyzer Log Forwarding

FortiAnalyzer is primarily used for centralized log collection, analysis, and reporting, but it also supports log forwarding to external systems.

Why Use Log Forwarding?

  • Integration with third-party SIEM platforms (e.g., Splunk, QRadar).
  • Redundancy in log storage or regulatory compliance.
  • Load balancing across multiple log analysis systems.

Key Configuration Areas:

config log fortianalyzer setting
    set status enable
    set reliable enable
    set server "192.168.1.100"
    set enc-algorithm high
end
  • Log format can be set to default or customized.
  • Retry interval and failover servers can be defined.
  • Filters allow selection of only specific log types (e.g., only traffic logs).

Syslog Forwarding Example (via FortiAnalyzer):

config system log-forward
    edit "SIEM"
        set server "10.10.10.10"
        set format syslog
        set mode reliable
    next
end

Summary Table:

Topic Description
ADOM Logical domains to separate devices, policies, logs across tenants or units
Policy Status Check Color-coded sync indicators for policy packages before deployment
FortiManager CLI Commands Useful for script execution, sync troubleshooting, and device monitoring
FortiAnalyzer Log Forwarding Sends logs to third-party SIEM or syslog servers with filtering and retry control

Frequently Asked Questions

Why can a FortiGate stop connecting to FortiManager after an upgrade?

Answer:

A common cause is certificate validation or authorization behavior changing after the upgrade, not simple IP reachability.

Explanation:

A recent Reddit thread points to FortiManager 7.2.5 certificate-validation changes as the trigger for post-upgrade registration failures, and FortiManager documentation confirms that centrally managed devices must be authorized properly before management works. In practice, admins should verify three things in order: basic reachability on the management path, matching registration/serial expectations, and certificate trust on the FortiManager side. If transport is fine but validation fails, the device may appear reachable yet still remain unauthorized or disconnected. This is a classic exam scenario because it tests whether you distinguish control-plane connectivity from management-plane trust. The right mindset is: ping and routing are necessary, but not sufficient. In central management, authorization state and certificate handling are often the real blockers after upgrades or version changes.

Demand Score: 89

Exam Relevance Score: 92

Why does adding a FortiGate to FortiManager sometimes seem to wipe the existing configuration?

Answer:

Because the onboarding method matters: importing an existing device and low-touch/ZTP-style enrollment do not behave the same way.

Explanation:

This question appears often because admins assume every “add device” workflow preserves the current live config. Community discussion shows that if the manager-driven workflow is used without importing the existing configuration properly, the FortiGate can receive default or staged settings instead of preserving what is on the box. The practical safeguard is to decide the onboarding model first. If the goal is to adopt an already-configured firewall, import its configuration into FortiManager and review mappings before installation. If the goal is zero-touch provisioning, expect templates and metadata variables to define the desired state. The exam point is understanding central management ownership: once FortiManager becomes authoritative, local expectations must match the selected workflow. Confusion here causes many real outages because engineers mix “adopt existing config” and “push desired config” as if they were the same operation.

Demand Score: 84

Exam Relevance Score: 90

Why does FortiManager fail to add or register a FortiGate even though the IP address and credentials look correct?

Answer:

Because registration can fail on validation, config parsing, or compatibility issues even when the device is reachable.

Explanation:

Fortinet’s own troubleshooting article on adding FortiGate to FortiManager highlights that the manager may detect invalid data during config loading, and community threads also show registration failures tied to version or SSL-level quirks in lab or trial setups. The important lesson is that successful reachability does not guarantee successful onboarding. When adding a device, FortiManager may reject or choke on a configuration element, ADOM mismatch, or trust-related issue. A good workflow is to check unauthorized devices, review onboarding logs, run the configuration diagnostics Fortinet recommends, and correct the offending config rather than repeatedly retrying registration. For the exam, the right conclusion is that device-add problems are often caused by management compatibility or config validation, not by “bad password” alone. That distinction is exactly what experienced operators use to shorten troubleshooting time.

Demand Score: 82

Exam Relevance Score: 87

Why might FortiManager not detect changes after moving AP management from device-based to centralized management?

Answer:

Because the source of truth has changed, and some settings may no longer be tracked where the admin expects.

Explanation:

A recent Fortinet Community post shows exactly this confusion during migration to centrally managed AP administration. After the shift, engineers often still expect changes to appear under the old device-centric workflow, but FortiManager may now treat the controller templates or central objects as authoritative. That leads to “no changes detected” even though the admin knows something was edited somewhere. The practical fix is to verify which layer owns the AP settings now: local FortiGate, FortiManager object/template, or another central construct. This is exam-relevant because central management is fundamentally about ownership and install scope. If you troubleshoot from the wrong ownership model, every symptom looks misleading. In production, always confirm whether the change should appear as a device diff, a policy package diff, or a template/object change instead.

Demand Score: 74

Exam Relevance Score: 79

NSE7_EFW-7.2 Training Course