Fortinet NSE 6 LAN Edge 7.6 Architect - FCSS_LED_AR-7.6 Practice Questions

Explanation

The problem is a connectivity issue, not an authentication protocol issue. Users on the Guest SSID (10.0.20.0/24) cannot load the captive portal page hosted externally. For the initial portal page load and subsequent authentication to work, clients must be able to reach the FortiAuthenticator (10.0.1.150) and the Windows AD/DNS server (10.0.1.10). Firewall policies in FortiGate are interface-based and control traffic flow between networks.

✅ Why Option D is Correct

The Guest SSID resides on its own subnet (10.0.20.0/24). By default, traffic between different interfaces/subnets on a FortiGate is blocked unless a firewall policy explicitly allows it.
To reach the captive portal server (FortiAuthenticator at 10.0.1.150) and the DNS server (Windows AD at 10.0.1.10), which are on a different subnet (10.0.1.0/24), a firewall policy must exist permitting traffic from the Guest SSID interface (or its source IP range) to the internal network interface where these servers reside.
The current topology does not show such a policy. Creating this policy is the fundamental requirement to establish the initial network path for the captive portal to function.

❌ Why the Other Options Are Wrong

A. Change the SSID security mode to WPA2-Enterprise for authentication.

Why it's wrong: The issue is that users cannot access the login page at all. This is a network reachability problem that occurs before any WPA or 802.1X authentication takes place. Changing the security mode does not solve the underlying routing/firewall block.

B. Disable HTTPS redirection for the captive portal authentication page.

Why it's wrong: While HTTPS redirection can sometimes cause issues if certificates are misconfigured, the core problem described is a complete failure to load the page. The exhibit shows the portal URL is https://.... If the client cannot even route a packet to the server, the protocol (HTTP vs. HTTPS) is irrelevant. The primary barrier is a missing firewall rule.

C. Exclude FortiAuthenticator and Windows AD address objects from filtering.

Why it's wrong: This is a misapplication of a feature. The "Exempt destinations" field in the captive portal configuration is for allowing client access to specific resources (like update servers) before they authenticate. It does not create the necessary firewall policy for clients to reach the authentication servers themselves in the first place. The traffic to the auth servers for the purpose of loading the portal and processing credentials still needs a firewall policy.

📚 Official References

FortiOS Handbook - Captive Portals: The documentation emphasizes that for external captive portals, the FortiGate must be able to communicate with the external portal server, and clients must have network access to it.

FortiAuthenticator Administration Guide - Captive Portal: Details the network requirements for integrating FortiAuthenticator as an external portal server.

Firewall Policy Concept: The principle that inter-VLAN/interface traffic requires an explicit firewall policy is a core tenet of FortiGate operation.

Explanation:

This question tests knowledge of FortiLink auto-discovery requirements for FortiSwitches. When a FortiSwitch connects to a FortiGate, it sends a DHCP request containing a specific Vendor Class Identifier (VCI) string. The DHCP server on the FortiLink interface must match this string to assign an IP address and complete the discovery process.

✔️ Correct Option:

✔️ Option D: The DHCP server setting vci-string is misconfigured.
The exhibit shows the DHCP server configuration uses set vci-string "FortiEthernet". However, FortiSwitches send the VCI string FortiSwitch (or FortiSwitch ) in their DHCP requests. The mismatch prevents the DHCP server from responding, so the FortiSwitch never receives an IP address and remains offline .

❌ Incorrect options:

❌ Option A: The Fortilink interface setting ip-managed-by-fortiipam must be enabled.
This setting (ip-managed-by-fortilink in the exhibit) is used when IP addresses are managed by an external IPAM solution. It is not required for basic FortiLink discovery and DHCP assignment .

❌ Option B: The Fortilink interface has the wrong interface member.
The exhibit shows set member "port4", which is a valid physical port. If the cabling is verified correct, the member configuration is appropriate for a FortiLink aggregate interface .

❌ Option C: The Fortilink interface setting cype must be physical.
The interface type shown is type aggregate, which is correct for FortiLink when using link aggregation. FortiLink supports both physical and aggregate interface types. Changing to physical would not resolve the discovery issue .

🔧 Reference:
→ Fortinet Document Library: VCI pattern matching for DHCP assignment: Official documentation explaining that vci-match enable restricts DHCP service to only clients with matching VCI strings, and vci-string defines which strings are allowed.

Explanation:

This question tests understanding of FortiSwitch quarantine behavior in NAC deployments. When a device is quarantined based on its MAC address, FortiSwitch redirects its traffic to a specific VLAN to limit network access until the device meets security compliance requirements.

🟢 Correct Option:

A. Traffic is sent to an access VLAN
Quarantined devices are placed in a restricted access VLAN, often called a quarantine VLAN. All egress traffic from the device is redirected to this VLAN, preventing full network access while allowing remediation or onboarding procedures.

🔴 Incorrect options:

B. Traffic is assigned to the native VLAN
The native VLAN is used for untagged traffic but does not control quarantine behavior. Placing quarantined devices in the native VLAN would bypass policy enforcement.

C. Traffic is sent as untagged traffic
Traffic tagging does not determine quarantine; FortiSwitch uses VLAN assignment to isolate devices. Untagged traffic alone does not enforce restricted access.

D. Traffic is sent to an allowed VLAN
“Allowed VLAN” implies full network access. Quarantined devices are explicitly isolated, so traffic is not forwarded to standard allowed VLANs.

🔧 Reference:
→ Fortinet FortiSwitch NAC Quarantine Behavior
Confirms that quarantined MAC addresses are redirected to a designated access VLAN to restrict network access until compliance is met.

Explanation:

This question tests the licensing requirements for advanced Security Fabric features on FortiAnalyzer. While a FortiAnalyzer device is required to integrate with the Security Fabric for centralized logging and analytics, using Indicators of Compromise (IOC) rules to detect compromised devices needs an additional specific license beyond the base setup.

✔️ Correct Option:

B. IOC Subscription license
This option is correct because Indicators of Compromise (IOC) functionality on FortiAnalyzer is not included in the base license. The IOC Subscription license enables FortiGuard IOC intelligence updates, allowing FortiAnalyzer to download and apply IOC rules for detecting suspicious IPs, domains, URLs, and malware indicators across the Security Fabric.

❌ Incorrect options:

A. IoT Security Add-on license
This does not satisfy the requirement because the IoT Security Add-on license is designed specifically for discovering, profiling, and securing IoT and OT devices in the network. It provides visibility into IoT asset inventory and risk assessment but has no relation to enabling IOC rules or FortiGuard threat intelligence for compromise detection.

B. IOC detection is included on FAZ-Basic license
This fails as the base FortiAnalyzer license only supports basic logging, reporting, and limited Security Fabric integration. Advanced features like real-time IOC rule processing and automatic FortiGuard IOC package downloads require a separate paid subscription and are not available with the standard FAZ-Basic license.

C. Threat Detection Service license
This is unsuitable because FortiAnalyzer does not offer a generic “Threat Detection Service” license for IOC functionality. Threat-related features on FortiAnalyzer are tied specifically to the IOC Subscription license, which handles Indicators of Compromise intelligence rather than a broad threat detection bundle.

🔧 Reference:
→ Viewing Indicators of Compromise | FortiAnalyzer 7.6
Explains that the IOC service requires a valid subscription license for full FortiGuard updates and rule functionality.

→ How IOC works | FortiAnalyzer 7.4
Describes the licensing requirement for using IOC rules with Security Fabric integration.

Explanation:

This scenario involves configuring FortiGate as a RADIUS Single Sign-On (RSSO) collector. When FortiGate receives RADIUS accounting messages, it must be told exactly which attributes contain the user's identity and their group membership to create a valid login session.

✅ Correct Options:

A. The RADIUS Attribute Value setting configured for an RSSO user group should match the class RADIUS attribute value in the RADIUS accounting message.
For RSSO to function, the "User Group" defined on the FortiGate must have a specific "RADIUS Attribute Value" string. When the RADIUS packet arrives, FortiGate compares the value found in the designated group attribute against this string; if they match, the user is placed into that local RSSO group.

D. The sso-attribute CLI setting in the RSSO agent configuration should be set to Class.
By default, FortiGate may look for group information in different attributes. Since the prompt specifies that group membership is sent in the Class attribute, you must explicitly configure the sso-attribute to "Class" in the CLI so the RSSO agent knows where to extract group data.

E. The rsso-endpoint-attribute CLI setting in the RSSO agent configuration should be set to User-Name.
The rsso-endpoint-attribute defines which attribute in the RADIUS packet represents the user's unique identifier (the endpoint). Since the prompt states the username is in the User-Name attribute, this setting must be explicitly mapped to ensure the session is tied to the correct person.

❌ Incorrect options:

B. RSSO user groups should be assigned to all firewall policies.
While RSSO groups must be used in relevant policies to enforce access control, they do not need to be assigned to "all" firewall policies. This is a design choice, not a technical requirement for the authentication and mapping process to function.

C. Device detection and Security Fabric Connection should be enabled on port3.
The exhibit shows that RADIUS Accounting is already enabled on port3, which allows the interface to listen for the packets. Device detection and Security Fabric Connection are used for asset identification and fabric telemetry, respectively, and are not required for processing RSSO accounting messages.

🔧 Reference:
→ FortiGate RSSO Configuration Guide
This documentation confirms that sso-attribute and rsso-endpoint-attribute are the primary CLI settings used to map RADIUS accounting fields to FSSO/RSSO sessions.

Explanation

✅ B. FortiGuard Threat Intelligence and FortiGuard IoT Detection
This is the correct answer because FortiLink device detection relies on passive fingerprinting and threat context rather than endpoint agents or active scanning. FortiGuard IoT Detection is responsible for identifying connected devices by type, vendor, operating system, and behavior, including unmanaged and IoT devices connected through FortiSwitch. FortiGuard Threat Intelligence complements this by enriching the detected devices with known threat and vulnerability context. Without these two licenses together, FortiGate cannot fully identify devices or assess their risk level through FortiLink.

❌ A. FortiGuard Vulnerability Management and FortiGuard Endpoint Protection
This option is incorrect because Vulnerability Management focuses on infrastructure and asset scanning, not passive device detection through FortiLink. Endpoint Protection applies only to endpoints managed by FortiClient and does not identify unmanaged or IoT devices, which are the primary targets of FortiLink device detection.

❌ C. FortiGuard Threat Intelligence and FortiGuard Endpoint Protection
Although Threat Intelligence is required, Endpoint Protection does not contribute to device fingerprinting or vulnerability detection for devices connected via FortiLink. Without FortiGuard IoT Detection, FortiGate cannot identify device types or behaviors, making this license combination insufficient.

❌ D. FortiGuard Attack Surface Security and FortiGuard IoT Detection
While IoT Detection is relevant, Attack Surface Security is designed to monitor internet-facing assets and external exposure. It does not integrate with internal FortiLink device discovery or contribute to device identification within the LAN.

Official Fortinet References

FortiGuard IoT Detection Overview:
https://www.fortinet.com/products/fortiguard/fortiguard-iot-security

FortiGate 7.6 Administration Guide – Device Detection:
https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/648508/device-detection

Explanation:

This question addresses the security requirements for guest access via a captive portal. By transitioning from HTTP to HTTPS, the administrator ensures that the exchange of user credentials and self-registration data is encrypted, protecting the network from credential sniffing.

✔️ Correct Options:

✅ A. Enable HTTP redirect in the user authentication settings.
Enabling HTTP redirect is a critical step that allows the FortiGate to catch unencrypted web requests from guests and automatically redirect them to the secure portal. This ensures that users do not encounter "page not found" errors when trying to access the login page.

✅ D. Update the captive portal URL to use HTTPS on FortiGate and FortiAuthenticator.
To enforce encryption, the Captive Portal URL must be explicitly configured with the https:// prefix. This change must be consistent across the FortiGate enforcement point and the FortiAuthenticator portal host to maintain a valid and secure redirection flow.

❌ Incorrect options:

❌ B. Create a new SSID with the HTTPS captive portal URL.
Creating a new SSID is an unnecessary administrative overhead. Captive portal settings are attributes of the existing SSID’s security profile or the interface it is mapped to; therefore, the current SSID can simply be modified to support the HTTPS URL without creating a new network.

❌ C. Disable HTTP administrative access on the guest SSID to enforce HTTPS connection.
Administrative access settings (HTTP, HTTPS, SSH) control how an administrator manages the FortiGate device through that specific interface. These settings are entirely separate from the guest traffic plane and have no impact on the captive portal's authentication protocol for end-users.

🔧 Reference:
→ Captive Portal Authentication
This official Fortinet documentation confirms that securing a captive portal involves configuring the redirect logic and updating the portal URL to use the HTTPS protocol.