FortiManager Drift and SSL Inspection at 20 Gbps
A managed security service provider manages 200 FortiGate 100F/200F devices from one FortiManager 7.2 with 25 ADOMs. A central policy package contains 8,000 objects; each tenant has a VDOM and a unique SSL deep-inspection profile with 250 exempt entries. After local engineers make emergency changes on 12 devices, installs fail with duplicate object errors and 18 devices show out of sync. The provider must standardize SSL inspection for 60,000 users, keep banking and healthcare exempt, support TLS 1.3, and give local engineers a break-glass path without letting them drift. The DC FortiGate 1800F pair must inspect 20 Gbps of HTTPS. The provider has no authority to remove local admin accounts. You are asked to make central management reliable and to design the inspection policy.
1. How would you resolve the duplicate-object install failures and prevent local drift while preserving a break-glass path for local engineers?
Read the worked answer
The duplicate-object error is a workflow failure. FortiManager installs a policy package by pushing objects; if a local engineer created an object with the same name on the FortiGate, the install cannot merge it. First retrieve and reconcile the 12 emergency changes: use Install Preview to see the diff, then either import the needed local objects into the ADOM with a unique naming convention or delete the local duplicates after changing the device policy. Do not simply delete the object on the device; policies may reference it. Assign devices to ADOMs that match the tenant, keep a single policy package per ADOM, and use metadata variables for per-device values such as interface, IP, and SSL profile name. Use ADOM locking or workspaces so only one admin installs at a time. For break-glass, give local engineers a documented procedure: they may change the device, but they must open a ticket and FortiManager must retrieve the configuration within the window; use the unplanned changes view to detect drift. Use Install Preview and revision history before every install. For 8,000 objects, avoid per-device object proliferation: use global objects where possible and object mapping for the few unavoidable differences. A full sync is not the fix; controlled reconciliation and a naming standard are.
2. Design the SSL deep-inspection policy for TLS 1.3, banking/healthcare exemptions, and 20 Gbps at the DC. What performance reality must be considered?
Read the worked answer
Design the SSL profile by risk and category, not one profile for everything. Create a base ssl-ssh-profile with deep inspection for general categories and certificate inspection for exempt categories. Use ssl-exempt entries for banking and healthcare by category and by explicit wildcard domains; document that IP-based exemptions are fragile with CDNs. For TLS 1.3, ensure the FortiOS version and inspection mode support it; if an application uses certificate pinning, exempt it rather than breaking it, and log the exemption. Apply the profile in the internet VDOM policy, not in every tenant VDOM, if traffic is centralized; if tenants inspect locally, attach the profile per tenant policy. Size the 1800F by SSL inspection throughput, not firewall throughput. 20 Gbps of HTTPS is a lab number for some traffic mixes; test with realistic TLS 1.3 and small-object traffic. CP9 accelerates bulk crypto, but certificate handling and policy lookups still consume CPU. Use FortiAnalyzer for logging, but do not log full payloads at 20 Gbps. Exemptions should be reviewed quarterly; every exemption is a blind spot. The goal is consistent policy with a short, auditable exception list.
3. How do you bring the 18 out-of-sync devices back under management without a mass reinstall that could disrupt tenants?
Read the worked answer
Out-of-sync devices are not all the same. Use diagnose dvm device list and the FortiManager GUI to separate config out of sync from policy package out of sync. If the device was changed locally, retrieve the configuration and compare revisions; if the change is legitimate, import it into the ADOM as a new revision, then reinstall the standard package. If the device is out of sync because a previous install failed, fix the failed object first; reinstalling repeatedly will not help. Check ADOM version compatibility with FortiOS 7.2; an ADOM upgrade is one-way, so back up first. Use Install Preview to catch duplicate objects and references before the install. For the 18 devices, group them by failure reason rather than running a bulk install. After reconciliation, enable policy and object consistency checks, and schedule a weekly retrieve-config for break-glass devices. Do not use insecure auto-update to force changes; that can amplify a bad package. The judgement call is to accept a temporary manual exception with a tracked revision, not to disable central management.