FCSS_LED_AR-7.6 Fortinet NSE 6 - LAN Edge 7.6 Architect Questions and Answers

In this design, FortiAuthenticator receivesRADIUS accounting (RSSO) messages, looks up the user in LDAP to get group information, theninjects FSSO logon eventstoward all FortiGate devices.

From the exhibits we know:

FortiAuthenticatoris receiving RADIUS accountingfrom the RADIUS server.

LDAP queries are successful and return group membership.

But FortiGatedoes not receive FSSO logons, so identity-based policies are not applied.

For FortiAuthenticator to create an FSSO logon, the RADIUS accounting record must be correctlyparsed into at least:

Username

Client IP address

These are mapped from the RADIUS attributes in theRADIUS Accounting SSO clientconfiguration (for example, User-Name and Framed-IP-Address). If these are not defined or mapped incorrectly, FortiAuthenticator can see the accounting packet butcannot build a valid FSSO session, so no update is sent to FortiGate.

Thus the most likely root cause is:

✔The RADIUS Username and Client IPv4 attributes are not correctly definedfor that RADIUS Accounting SSO client (optionA).

Other options conflict with the scenario:

B– LDAP is already successfully returning groups.

C– FSSO user group attribute is separate; even without it, FSSO logons would still be created (just without group mapping).

D– The interfaceisreceiving RADIUS accounting, so it is clearly enabled.

The correct answers are A and D.

The study guide explains that in tunnel mode, traffic for local resources at the AP site will hairpin back to FortiGate unless split tunneling is configured:

“In tunnel mode, all traffic from the SSID is sent to the FortiGate Wi-Fi controller. If you locate the AP in a remote office, all the traffic is sent to FortiGate, even if it is destined for a remote office resource. The packets sent to a local resource, such as an office printer, will hairpin, crossing the WAN link needlessly.”

It then gives the fix:

“When you enable split tunneling on an SSID profile, you can configure a different egress point for the traffic. You can split traffic; some traffic is sent to the local network, and some tunnels back to the managing FortiGate... You can configure the subnets in an ACL... You can also configure the AP to automatically add its own subnet to the ACL.”

The next page states:

“The traffic is tunneled or bridged depending on the subnets configured in the split-tunneling-acl list. If the split-tunneling-acl-local-ap-subnet option is enabled, the local subnet of the AP is dynamically added to the list.”

That directly supports:

A: adding the local home subnet to the split tunneling ACL

D: enabling split-tunneling-acl-local-ap-subnet

Why the other options are incorrect:

B. Incorrect. Changing the SSID to local bridging would stop the corporate traffic model shown in the scenario. The employee already can reach company resources, which indicates tunnel mode is working. The issue is only access to a local home printer, which the study guide solves with split tunneling, not by converting the SSID to bridge mode

C. Incorrect. intra-vap-privacy controls host isolation between clients on the same SSID. The problem here is reaching a local subnet resource behind the remote AP, which is a split tunneling issue, not host isolation.

Final verified conclusion:

To allow the remote employee to continue reaching company resources while also accessing the local home printer, the required fixes are:

add the local home subnet to the split tunneling ACL

enable automatic inclusion of the AP local subnet in the split tunneling ACL

So the correct answers are A and D.

The LAN Edge 7.6 Architect Study Guide explicitly confirms that during the ZTP process, after FortiGate retrieves the FortiManager address (via DHCP Option 240 for IP address or Option 241 for FQDN), it contacts FortiManager to initiate a secure tunnel on TCP port 541. If that port is unreachable — due to firewall rules, routing issues, or misconfiguration — the tunnel cannot be established, and registration fails.

The guide also confirms in the device registration section: " During device registration, FortiManager and FortiGate create a secure tunnel on TCP port 541. The tunnel is used for checking device status and configuration, as well as configuration installation. "

Why the other options are wrong:

A is incorrect — ZTP is designed specifically to be automated and does not require manual acceptance for the initial tunnel establishment in the standard ZTP flow.

B is incorrect — ZTP operates over the network (LAN/WAN), not via console cable; it is a network-based provisioning process.

C is incorrect — ZTP ' s entire purpose is to allow devices to be deployed without a pre-loaded configuration on-site; the configuration is pushed by FortiManager after registration.

In FortiLink NAC for LAN Edge:

When a device first connects, it is placed into theonboarding VLAN.

NAC policies then classify the device (by MAC, OS, user, EMS tag, etc.).

If a NAC policy matches, the device may be moved to anaccess VLANorquarantine VLAN.

Ifno NAC policy matches, the device simplystays in the onboarding VLAN.

FortiOS / LAN Edge documentation describes the onboarding VLAN as thedefault VLAN for unknown or unclassified devices, until NAC policy evaluation moves them elsewhere.

Goal: enforce captive portal authentication overHTTPSfor guests.

On FortiGate/FortiAuthenticator captive portal setups:

HTTP redirectis used so that when a guest browses to any HTTP site, their request is redirected to theportal URL.

Theportal URLitself must beHTTPSif you want a secure login page.

FortiOS captive portal and firewall authentication guidelines recommend:

EnablingHTTP redirectso unauthenticated HTTP traffic is transparently sent to the portal.

Configuring theportal URL with HTTPS, often referencing a certificate on FortiGate or FortiAuthenticator.

Therefore:

A. Enable HTTP redirect in the user authentication settings.✔This ensures unauthenticated HTTP requests are redirected to the (now HTTPS) portal.

D. Update the captive portal URL to use HTTPS on FortiGate and FortiAuthenticator.✔This makes the login itself secure (TLS-protected).

Incorrect:

B– You don’t need a new SSID; the same SSID can use HTTPS portal.

C– Disabling HTTP admin access on the SSID doesn’t control the captive portal scheme; HTTPS enforcement is done by the portal configuration and redirect, not by admin-access flags.

The LAN Edge 7.6 Architect Study Guide identifies the following communication mechanisms between FortiGate and FortiSwitch:

C — FortiLink Protocol (Primary Management Protocol): The study guide states: " FortiLink, also known as the switch controller function, allows FortiGate firewalls to remotely manage FortiSwitch devices. FortiLink defines the management interface and remote management protocol between FortiGate and FortiSwitch, enabling seamless control and integration. " FortiLink is the foundational protocol for the entire management relationship.

B — HTTPS (REST API): The study guide confirms: " FortiGate applies the quarantine-related configuration for the quarantined device to FortiSwitch using the FortiSwitch REST API. " FortiGate communicates with FortiSwitch via HTTPS-based REST API calls for specific configuration pushes such as quarantine enforcement, port configuration, and security policy application.

A — SNMP: SNMP is referenced in the study guide as a management protocol used by FortiGate to monitor and gather status information from FortiSwitch devices. SNMP is a standard network management protocol used for monitoring switch status, which aligns with its role in FortiSwitch management.

Why the other options are wrong:

D is incorrect — CAPWAP (UDP 5246/5247) is the protocol used between FortiGate and FortiAP for wireless AP management, NOT between FortiGate and FortiSwitch. The study guide explicitly states: " FortiGate manages FortiAPs using the CAPWAP protocol. "

E is incorrect — IGMP is an IP multicast group management protocol. It plays no role in the management or control channel between FortiGate and FortiSwitch. It is not mentioned in the LAN Edge 7.6 study guide in the context of FortiSwitch management.

From the exhibits and text:

FortiGate →RADIUS→ FortiAuthenticator

FortiAuthenticator →LDAP→ Windows AD

diagnose test authserver radius ... papsucceeds

diagnose test authserver radius ... mschap2fails

This behavior matches a classic limitation documented in FortiOS:

When usingLDAPas the back-end, the RADIUS server must usePAP. CHAP/MS-CHAPv2 arenot supportedwith plain LDAP because the server cannot validate the challenge–response without access to password hashes.

In the Remote LDAP server config on FortiAuthenticator, the option“Windows Active Directory Domain Authentication” is disabled.When this feature isenabled, FortiAuthenticator can talk to AD usingKerberos/NTLMinstead of a simple LDAP bind, whichdoes support MS-CHAPv2for incoming RADIUS authentications.

So to allow MS-CHAPv2 all the way from FortiGate to AD, you must:

Keep FortiGate using RADIUS with MS-CHAPv2 → FortiAuthenticator

EnableWindows Active Directory Domain Authenticationso FortiAuthenticator can properly validate MS-CHAPv2 against AD.

Why the other options are wrong:

A. Change to CHAP– CHAP still cannot be validated over LDAP; docs say LDAP back-ends must usePAP.

C. Manually add users to local DB– That would allow local-DB auth but does not fix MS-CHAPv2 against AD.

D. Use RADIUS attributes on FortiGate– Attributes do not influence the EAP inner method; they don’t fix MS-CHAPv2 failures.

Therefore the configuration change that can realistically fix the MS-CHAPv2 problem isenabling Windows Active Directory Domain Authentication on FortiAuthenticator (B).

From the exhibit, LDAP on FortiGate is correctly configured and tested:

diagnose test authserver ldap FAC-LDAP wifi101 password

authenticate ' wifi101 ' against ' FAC-LDAP ' succeeded!

Group membership(s) - CN=Domain Users,...

So:

LDAP connectivity works

Bind DN, DN, CNID, and credentials are correct(so optionCis eliminated).

Firewall policies do not affect the802.1X / Wi-Fi authentication stepitself, soAis not the root cause.

Nothing in the scenario indicates that AD is enforcing LDAPS-only; the LDAP test already succeeds using the configured parameters, soBis also excluded.

The Wi-Fi supplicant is configured forPEAP with inner authentication = MSCHAPv2.

MSCHAPv2 is achallenge–response mechanism designed for RADIUS, not for LDAP simple bind. FortiGate’s LDAP implementation uses asimple bind (username/password) over LDAP or LDAPS, and it doesnotimplement MSCHAPv2 against LDAP backends.

In Fortinet’s design, if you needPEAP-MSCHAPv2 with Active Directory, you must use:

ARADIUS server(such as Windows NPS or FortiAuthenticator), and

Have FortiGate use RADIUS,notLDAP, as the authentication backend for 802.1X / Wi-Fi users.

Because FortiGate cannot process MSCHAPv2 exchanges directly against an LDAP server, authentication fails when the inner method is MSCHAPv2, even though LDAP works when tested with a simple bind from the CLI.

From the exhibits:

FortiSwitch Ports viewshows:

port2

Mode: Static

Native VLAN: Students

Allowed VLANs: quarantine.fortilink (quarantine)

NAC policy “Training”:

Switch FortiLink: fortilink

Category:Device

Matching criteria:

MAC Address: 70:88:6b:8c:4b:0e (enabled)

Operating System:Linux(enabled)

Switch Controller Action:

Assign VLAN = Students

Bounce Port = enabled

Design intent:

Device with that MAC + OS Linux, when plugged intoport2, should be dynamically moved to VLANStudentsby the NAC policy.

Why it doesn’t work now

On FortiLink NAC,dynamic NAC decisions only apply on ports whose “Access Mode” is set to NAC:

NAC mode = FortiGate controls theonboarding VLAN, evaluates NAC policies, and then dynamically reassigns the switch port VLAN (access, quarantine, etc.).

Static mode(what we see on port2) means the port just uses its configurednative/allowed VLANs, andno NAC classificationhappens.

Right now:

port2 is astatic access portwith Native VLAN = Students.

The NAC policy exists, butFortiSwitch is not in NAC enforcement mode on that port, so the policy is never evaluated for traffic on port2.

Therefore, themissing configurationis:

Setport2toNAC mode(sometimes called “Access mode: NAC” or “NAC LAN edge port”).

Once port2 is changed to NAC mode:

Device initially lands in the onboarding/quarantine VLAN.

FortiGate collects device info (MAC, OS, etc.).

NAC policy “Training” matches MAC + Linux.

Switch controller actionAssign VLAN = Studentsis applied.

Port is bounced (if configured), bringing the device back up in VLAN Students.

Why the other options are wrong

B. MAC or OS misconfigured

Possible in general, but the question asks forwhich configuration is missing, and the exhibits clearly focus on port mode. Also, even with wrong MAC/OS, the port would still be in NAC mode; here NAC isn’t even active.

C. Port Policy mode

Port policy (edge/trunk) is separate from NAC; NAC requires the specificNAC access mode.

D. Students VLAN should be Allowed VLANs instead of Native VLAN

For an access port, having Students as thenative VLANis correct. NAC policy’s Assign VLAN will set that as access VLAN; no need to make it an allowed trunk VLAN.

When FortiAPs connect to FortiGate overIPsec tunnels, this is treated similarly to WAN/MPLS deployments.

In these scenarios, FortiGate must know that CAPWAP must traverse anon-L2transport.

FortiAP profiles include:

set mpls-connection enable

This setting is required so that:

FortiGate can encapsulate CAPWAP inside the transport tunnel

Remote FortiAPs can establish CAPWAP even when behind routed/IPsec networks

Without this option, the FortiGate detects the AP butcannot bring CAPWAP UP, leaving the AP in “discovered/unauthorized” or “offline” state.

Why others are wrong

A. Static route→ Discovery already succeeds, so routing is not the issue.

C. Reduce MTU→ Sometimes useful for IPsec, but not required for CAPWAP establishment.

D. Firmware upgrade→ Firmware mismatch would show “Managed (upgrade required),” not CAPWAP tunnel failure.

Therefore,set mpls-connection enableis the required fix.

The correct answers are A and E.

The LAN Edge 7.6 Architect study guide explicitly states that guest portals on FortiAuthenticator support social login:

“The guest portal ... provides user account and pre-login services ... Social login option”

More importantly, in the portal policy configuration, the guide states:

“The social user login option allows users to authenticate using third-party single sign-on (SSO) services such as Facebook, LinkedIn, and so on. You must configure social login profiles to use this method.”

That directly proves E is required.

The same exact extract also says:

“If you have enabled social users as an authentication type, you will select the social platforms that will be available for user authentication. The options are Facebook, Google, Twitter, Linkedin, Phone number, and Email. For each option, other than phone number and email, you will need to configured a remote open authorization (OAuth) server.”

That directly proves A is required.

Why the other options are incorrect:

B. Incorrect. The study guide explicitly says social login is supported in the guest portal, so it is false to say social media login cannot be used with captive portals

C. Incorrect. Account Login is a different authentication method. The guide says: “Account login means that user credentials are provided by the FortiAuthenticator internal database or remote authentication server.” That is for standard account-based login, not required for social login

D. Incorrect. FortiAuthenticator internal database can be used for account login, but the question asks specifically for visitors authenticating with existing social media accounts. That uses social login profiles and OAuth servers, not the internal database as the primary source

Final verified conclusion:

To enable captive portal authentication using social media accounts, you must:

configure social login profiles

configure a remote OAuth server for each selected social platform

So the correct answers are A and E.