The Fortinet NSE 6 - LAN Edge 7.6 Architect (FCSS_LED_AR-7.6)

FortiGate and FortiSwitchmust share synchronized timewhen operating in FortiLink mode.

Documented reasons in FortiOS:

Accurate time synchronization is required for logs, authentication events, and fabric correlations.

Why it’s critical:

802.1X EAP and RADIUS timestamp validation

NAC policy enforcement timestamps

Certificate validation

Log correlation in Security Fabric / FortiAnalyzer

Incorrect options:

A: Firmware synchronization does NOT require NTP.

B: Switch-to-switch communication does not depend on NTP.

D: Standalone mode is unrelated to time sync.

In an SD-Branch deployment (FortiGate + FortiSwitch + FortiAP),FortiAIOps:

Collects telemetry and logs from Fabric devices

Usesmachine-learning / AI analyticsto:

Spot anomalies (latency, packet loss, RF issues, misconfigurations)

Highlight root causes

Proposeoptimization recommendations(e.g., channel changes, power tuning, config fixes)

It doesnot:

Automatically disable devices (Afalse)

Replace SD-WAN config or all routing (Cfalse)

Fixallissues with zero human input (Dis marketing fantasy, not reality)

The FortiOS documentation explicitly states that a CSR used for certificate signing must contain accurate and valid fields, especially:

Common Name (CN)

Organization (O)

Country (C)

Public key parameters

According to the FortiGate certificate section:

Incorrect CSR field information can cause the CA to reject the request.

Reasons include:

The CA validates identity and organizational information.

Missing or malformed data invalidates PKI requirements.

The CSR is not corrected automatically by the CA.

Therefore:

✔A is correct.

Options B–D contradict PKI principles:

B is false: CAs do not issue certificates with mismatched identity fields for public trust.

C is false: CSR fields are not only for internal use; they define certificate identity.

D is false: CAs do not auto-correct CSR fields.

The correct answers are A and B.

The LAN Edge 7.6 Architect study guide explains that when LDAP is the back-end server, CHAP, MS-CHAP, and MS-CHAPv2 do not work because the client sends a one-way password hash, while LDAP expects the actual password:

“If FortiGate is configured to authenticate clients using a remote LDAP server, VPN and wireless clients using CHAP schemes are not able to authenticate... The reason is that during CHAP, MS-CHAP, and MS-CHAPv2 authentication, a client sends a one-way hash of the password. However, the LDAP server, which is on the back end, is expecting the password itself.”

The same study guide then gives the two valid solutions:

“Two possible methods that you can use to solve the CHAP and LDAP problem are:”

“Use RADIUS: Change your back-end server from LDAP to RADIUS.”

and

“If you are using Windows AD as your LDAP server, an alternative is to use FortiAuthenticator as an authentication proxy... You must also configure FortiAuthenticator to log in to the Windows domain using the credentials of a Windows administrator. This adds FortiAuthenticator as a trusted device on the Windows AD domain, allowing FortiAuthenticator to proxy the password hash from the client to the Windows server, using NTLM.”

That directly matches:

A. Enable Windows Active Directory domain authentication on FortiAuthenticator.

B. Configure FortiAuthenticator to use RADIUS instead of LDAP as the back-end authentication server.

The study guide also states this explicitly in the FortiAuthenticator LDAP configuration section:

“If you want FortiAuthenticator to relay CHAP, MS-CHAP, and MS-CHAPv2 authentication to a Windows AD server, you must enable Windows Active Directory Domain Authentication and enter the credentials for a Windows administrator.”

And it separately confirms RADIUS as another supported back-end proxy model:

“You can configure FortiAuthenticator to connect to existing RADIUS servers... If the local user database is not used, FortiAuthenticator proxies RADIUS authentication requests.”

Why the other options are incorrect:

C. Incorrect. RADIUS attribute filtering does not solve the CHAP/MS-CHAPv2 versus LDAP hash problem. The issue is the back-end authentication method, not attribute filtering.

D. Incorrect. Changing from MS-CHAPv2 to CHAP does not fix it, because the study guide says the same limitation applies to CHAP, MS-CHAP, and MS-CHAPv2 when LDAP is the back end

Final verified conclusion:

To enable MS-CHAPv2 authentication in this scenario, the two valid solutions are:

A. Enable Windows Active Directory domain authentication on FortiAuthenticator.

B. Configure FortiAuthenticator to use RADIUS instead of LDAP as the back-end authentication server.

In this scenario:

FortiGate + FortiAnalyzer are part of theSecurity Fabric

AnAutomation Stitchis configured:

Trigger:Compromised Host – High(IOC from FortiAnalyzer)

Action:Quarantine on FortiSwitch + FortiAP

A test device10.0.2.1visits a malicious website.

FortiAnalyzer logs show the event, butFortiGate does NOT quarantine the device.

This means theautomation did not receive an IOC trigger, OR theFabric did not classify it as a compromise.

Let ' s evaluate each answer option.

✅C. The malicious website is not recognized as an indicator of compromise (IOC) by FortiAnalyzer.

✔Correct.

For FortiGate to quarantine a device:

FortiAnalyzer must classify the event as aCompromised Host → High / Medium / Critical

FortiAnalyzer must generate anIOC event

FortiGate must receive that IOC through the Fabric

Even though the FAZ log shows:

Action = blocked

Category = Malicious Websites

→ That doesNOTautomatically mean an IOC was generated.

A blocked website event isnot always an IOCunless:

It is included in theIOC database

FAZ’sAnalytics / UTM / IOCengine marks it as a compromise

Thus, if FAZ only logs a “Malicious Website” event butdoes not classify it as an IOC,

In FortiGate captive portal workflows (local or external):

Client connects to SSID / interface that has captive portal enabled.

Client makes an HTTP/HTTPS request.

FortiGate intercepts and redirects to alogin page(local or external URL).

The portal form is submitted viaPOSTback to FortiGate.

To prevent tampering and to tie the POST back to thecorrect user session, FortiGate includes a special hidden parameter in the redirect and expects it in the POST:

The parameter is namedmagic.

The magic value:

Is aunique tokengenerated per captive-portal session.

Encodes/session-links the user’s IP, interface, and session info.

Allows FortiGate to ensure that:

The POST comes from the user who initiated the original request.

The request is not a random or replayed submission.

When troubleshooting:

If the external portal does notpreserve and resendthe magic parameter back to FortiGate exactly as received, authentication fails, and you’ll see errors like “session not found” or “invalid magic”.

Why the other fields are not used for this purpose

A. username– Just the login ID; multiple users can use the same username from different locations, so it can’t uniquely track the browser session.

B. redir– Contains the URL the user originally requested, so they can be sent back there after login. It is not a session integrity token.

D. email– Optional field used in some guest/registration flows; irrelevant to session validation.

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 correct answer is D.

The LAN Edge 7.6 Architect study guide states: “Note that suppression of rogue APs is becoming increasingly more difficult, because new wireless security standards are beginning to mandate management frame protection (802.11w). This requires that clients authenticate management frames as being legitimate, preventing spoofing attacks. Because rogue suppression is a form of spoofing attack, an AP that the client is not connected to is trying to send deauthentication frames and, as a result, 802.11w prevents the client from taking notice of the dedicated monitoring AP.”

This exactly matches option D. Rogue AP suppression relies on spoofed deauthentication behavior, and 802.11w protects management frames, making that suppression method less effective.

Why the other options are incorrect:

A. Incorrect. The study guide does not say 802.11w makes suppression harder because of processing overhead. It specifically points to management frame protection and spoofing prevention

B. Incorrect. The study guide does not mention reduced wireless range as the reason.

C. Incorrect. The issue is not data traffic encryption. The study guide specifically refers to authentication of management frames, not general traffic encryption

The problem states:

FortiGate receivesRADIUS accounting messagesonport3.

User-Nameattribute contains the username.

Classattribute contains the group membership.

Goal: authenticate users through RSSO and map them to the correct user groups.

To achieve this, three critical components must be configured:

✔A. RADIUS Attribute Value in the RSSO group must match the Class attribute

This is mandatory because:

RSSO user groups on FortiGate match users based onthe value inside the RADIUS attribute(usually Class).

For group assignment to work, FortiGate must compare:

RSSO User Group → RADIUS Class Attribute Value

This isexactly how FortiGate maps RSSO users to groups.

✔D. RSSO agent’s sso-attribute must be set to Class

Thesso-attributedefineswhich RADIUS attribute contains the group information.

Because group membership is carried in:

➡Class attribute

You must configure:

config user radius

set sso-attribute Class

end

This tells FortiGate:

" Use the Class attribute to derive user group membership. "

✔E. rsso-endpoint-attribute must be set to User-Name

This identifieswhich RADIUS attributecarries the actualusername.

In this scenario:

RADIUS accounting messages contain the username inUser-Name.

So the correct setting is:

config user radius

set rsso-endpoint-attribute User-Name

end

This ensures the RSSO user object uses the correct username.

❌Incorrect Options Explained

B. Assign RSSO user groups to all firewall policies

Not required.

You only assign them to policies where RSSO authentication is used.

C. Device detection and Security Fabric Connection should be enabled on port3

Totally irrelevant to RSSO.

RSSO only needs RADIUS accounting, not device detection or Fabric services.