Courseiva
Authentication and VPN →hardMultiple Select

NSE4 Authentication and VPN Practice Question

A FortiGate is configured with FSSO and Active Directory polling. Users report that they are frequently prompted for authentication even though they are logged into the domain. Which THREE possible causes should the administrator investigate?

⚠ Common exam trap

Candidates often confuse FSSO polling with captive portal or FortiToken, assuming any authentication prompt must involve those technologies, when in fact the issue is a stale IP-to-user mapping caused by DHCP changes or delayed DC polling.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The user's IP address has changed and the FortiGate still has a stale mapping

FSSO with Active Directory polling relies on the FortiGate maintaining a mapping between a user's domain logon and their IP address. If the user's IP address changes (e.g., due to DHCP lease renewal or moving to a different subnet) and the FortiGate still holds the old mapping, the firewall will not recognize the user as authenticated, prompting re-authentication. This is a common issue in dynamic IP environments where the FortiGate's polling interval may not immediately detect the change.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    The user's IP address has changed and the FortiGate still has a stale mapping

    Why this is correct

    In FSSO, the FortiGate associates a username with the source IP address of the workstation at the moment of logon. If the DHCP lease renews or the user moves to a different subnet, the IP changes without a corresponding logoff/logon event, so the FortiGate retains the stale mapping. Traffic from the new IP is therefore not matched to the user's FSSO group policy, causing the user to be treated as unauthenticated.

  • ✗

    The FortiToken server is overloaded

    Why it's wrong here

    FortiToken is a two-factor authentication product used for SSL-VPN, captive portal, and other interactive authentication contexts. FSSO relies on Active Directory logon events and periodic polling of domain controllers; it does not involve token validation at any point. An overloaded FortiToken server would degrade two-factor authentication but cannot prevent FSSO from recognizing an AD user logon.

  • ✓

    The user's workstation is not sending logon events to the domain controller

    Why this is correct

    FSSO's collector agent (or the FortiGate itself when using LDAP polling) reads Windows security event logs on the domain controller, specifically event ID 4624 for successful logons. If the workstation's logon events are not being written to the DC—due to cached credentials, a network fault, or incorrect logon type—the DC never records the event. Consequently, the collector never sends the mapping to the FortiGate, so the user remains unknown to FSSO.

  • ✗

    The captive portal is enabled on the policy

    Why it's wrong here

    Captive portal is an interactive web authentication method that forces users to enter credentials before traffic is allowed. While it also associates users with their IP addresses, it operates separately from FSSO and does not depend on domain controller event monitoring. Enabling captive portal on a policy would challenge the user with a login page, but it would not replace or break the FSSO mapping process, so it cannot be the root cause of FSSO not recognizing the user.

  • ✓

    The FortiGate is not polling the domain controllers correctly

    Why this is correct

    For FSSO to work, the FortiGate must maintain connectivity to the domain controllers (or collector agents) and periodically poll them for logon/logoff events. If the polling interval is too long, the DC is unreachable, the port is blocked, or the polling credentials are invalid, the FortiGate receives no updates. This prevents the FortiGate from learning the user-to-IP mapping, resulting in the user's traffic not matching the FSSO-based policies.

Visual reference

Client DHCP Server 1 Discover (broadcast) 2 Offer (IP: 192.168.1.10) 3 Request (I accept) 4 Acknowledge (lease confirmed) DORA — the four-step DHCP lease process

About these practice questions

This NSE4 question is part of Courseiva's 773-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This NSE4 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE4 exam.