Troubleshooting Scenario Questions

The LDAP user account is locked

Why it fails: A locked LDAP account fails authentication outright, so FortiAuthenticator would reject the login and no user identity would reach the FortiGate policy at all. It is tempting because lockouts do cause access failures, and would be correct if the user could authenticate but the group membership lookup returned nothing.

FortiAuthenticator is in maintenance mode

Why it fails: Maintenance mode stops FortiAuthenticator serving authentication requests entirely, which would affect every user rather than one LDAP-group member. It is tempting because service outages do break access, and would be correct if all users authenticating through that appliance lost access simultaneously, not just this individual.

The user is using the wrong password

Why it fails: A wrong password would block authentication at FortiAuthenticator itself, so the user would never reach the FortiGate policy or its LDAP group lookup. It is tempting because credential errors are a common login failure, and re-entering the password would be the fix when FortiAuthenticator rejects the user outright.

The FortiManager license has expired.

Why it fails: A 'Modified' status means the device's running configuration diverges from the policy package installed by FortiManager; an expired licence blocks management functions but does not produce that specific status. It tempts because licensing faults do disrupt FortiManager operations, yet the Modified flag reflects configuration drift.

The FortiManager firmware is outdated.

Why it fails: 'Modified' indicates configuration drift between the device and its installed policy package, not a version mismatch on FortiManager itself. It tempts because firmware differences can cause interoperability faults, but the status specifically compares device configuration against the policy package.

The policy package was deleted.

Why it fails: Deleting a policy package removes it from FortiManager entirely, so no package remains to compare against the device; 'Modified' requires an installed package whose contents differ. It tempts because missing packages do break policy installation, but the status itself denotes drift, not deletion.

The ADC management IP

Why it fails: The ADC management IP addresses the appliance itself, not the monitored server's reachability. It is tempting because connectivity faults often stem from addressing, but a failing health check despite an up server points to the health check's probe settings, such as port, protocol, or expected response.

Server RAM utilization

Why it fails: RAM utilisation does not affect FortiADC health check probes; these test TCP, HTTP or ICMP reachability, not host resource headroom. It is tempting because high memory can slow application responses, so it would be worth checking when a server passes its probe but serves requests slowly.

The switch MTU

Why it fails: Switch MTU affects packet fragmentation on the path, not whether FortiADC's health check probe receives a valid response from a server that is already up. MTU is worth checking when large packets are dropped or tunnels fail; here the probe configuration, port, protocol and expected response code should be verified first.

Object Usage.

Why it fails: Object Usage lists where objects are referenced across policies and ADOMs; it never compares FortiManager's database against a FortiGate's running configuration. It tempts for impact analysis before deleting objects, but the installation diff appears in the Install Wizard's preview pane instead.

FortiView.

Why it fails: FortiView presents traffic, threat and session analytics from logs; it holds no configuration comparison data. It tempts because it is a go-to troubleshooting console, but the policy-installation diff is shown in the Install Wizard preview, not in log-driven dashboards.

Device Manager > Revision History.

Why it fails: Revision History stores FortiManager database revisions for rollback and comparison between saved versions, not against a FortiGate's live running configuration. It tempts because it does show configuration diffs, but those are historical FortiManager snapshots, not the device-versus-manager installation diff.

System Settings > Task Monitor.

Why it fails: Task Monitor shows installation task status, progress and any error messages, but not a line-by-line configuration diff. It tempts because failed installs surface there, yet the detailed comparison between FortiManager's policy database and the FortiGate's running configuration is displayed in the Install Wizard preview.

Run a manual report

Why it fails: A manual report aggregates historical log data into a formatted output; it does not replay raw logs against the handler's filter expression, so a non-matching filter stays invisible. Reports suit scheduled compliance or trend summaries, not filter validation. The log preview or test-filter function shows exactly which entries satisfy the criteria.

Rebuild the SQL database

Why it fails: Rebuilding the SQL database reinitialises the log store and destroys existing logs, so it cannot reveal whether entries match the handler's filter. It is a recovery step for corruption or schema faults. Verifying filter matches requires inspecting live log entries against the criteria, not rebuilding storage.

Check the FortiAnalyzer system logs

Why it fails: FortiAnalyzer system logs record daemon, task and administrative events, not the traffic or security logs the handler filters on. They are the right place to diagnose process crashes or task failures. Confirming filter matches needs the log preview showing which raw entries satisfy the handler's criteria.

Session Table Logs

Why it fails: Session table logs record established connections and their state, not the probe result or failure cause, so they cannot explain why a health check failed. They are tempting when connections are absent, but FortiADC health check diagnostics are recorded in the health check or event logs.

Application Traffic Logs

Why it fails: Application traffic logs record requests traversing the virtual server, not the health check probe results, so they cannot reveal why a monitor marked a server down. They are tempting because they show backend responses, but that is for diagnosing application errors, not health check state transitions.

Security Policy Logs

Why it fails: Security policy logs record firewall permit or deny decisions on traffic, not the outcome of health check probes, so they cannot explain why a server was marked down. They are tempting when a policy blocks probe traffic, but that is a security troubleshooting scenario, not health check diagnosis.

SNMP Traps

Why it fails: SNMP traps only report state-change notifications such as a server transitioning down; they carry no detail on the probe's failure cause. They are tempting for alerting on health status, but that is monitoring, whereas the specific failure reason requires the health check log.

Delete and re-add the downstream FortiGate on the root FortiGate.

Why it fails: Deleting and re-adding the downstream FortiGate on the root is premature. The downstream device may not have attempted to join, so it wouldn't be listed to delete. This action is not the next logical step; verifying the downstream's Fabric settings is more appropriate.

Restart the FortiAnalyzer service.

Why it fails: Restarting the FortiAnalyzer service is irrelevant because FortiAnalyzer is not involved in the Fabric topology discovery between FortiGates. The issue is with the Fabric connection between the root and downstream FortiGate, not with logging or analysis. This action would not resolve the missing device.

Reconfigure the root FortiGate's management IP.

Why it fails: Changing the root FortiGate's management IP is unnecessary and could disrupt the existing Fabric. The downstream FortiGate is configured with the correct root IP, so the root's IP is likely correct. The problem lies elsewhere, such as the downstream's Fabric enablement or authorization.

The partner's DMARC policy is set to 'p=reject', which causes FortiMail to quarantine all emails from that domain.

Why it fails: A 'p=reject' policy instructs receivers to reject emails that fail DMARC, but the scenario says emails are marked as spam, not rejected. FortiMail's action depends on its configuration, not solely on the DMARC policy. The policy itself does not cause the failure; it dictates the action. The root cause is the authentication failure, not the policy.

The third-party mailing list is modifying the 'From' header, breaking the DMARC alignment.

Why it fails: DMARC alignment checks the 'From' header domain against the SPF or DKIM authenticated domain. If the mailing list modifies the 'From' header, alignment would fail. However, the scenario states the partner's domain has a valid SPF record, and forwarding typically affects SPF, not the 'From' header unless the list rewrites it. This is not the most likely cause given the details.

FortiMail is not configured to perform DKIM verification, so DMARC cannot pass even if SPF fails.

Why it fails: FortiMail does support DKIM verification and will perform it if enabled. However, even if DKIM is verified, DMARC requires alignment with the 'From' domain. The scenario does not indicate DKIM is disabled. The more likely issue is that DKIM signature is broken by the mailing list, not that FortiMail lacks DKIM verification capability.