Fortinet NSE6_FAC-6.4: FortiAuthenticator Administration

The Fortinet NSE6_FAC-6.4 exam represents the FortiAuthenticator 6.4 generation of identity administration. The subject is broader than one authentication protocol because FortiAuthenticator sits between users, directories, firewalls, VPN services, switches, wireless networks, certificates, and applications. The durable topics are local and remote users, LDAP, RADIUS, FortiToken, two-factor authentication, FSSO, guest and self-service portals, PKI, SCEP, 802.1X, SAML, and troubleshooting.

FortiAuthenticator has advanced well beyond version 6.4. Fortinet now teaches FortiAuthenticator 8.0, and the current 8.0 administrator course does not have a certification exam. NSE6_FAC-6.4 therefore belongs to an earlier certification generation, but the identity mechanics remain highly transferable because modern Fortinet access designs still depend on directory integration, RADIUS, MFA, certificates, SSO, and federation.

The most productive preparation method is to follow one transaction from the requesting client to the final enforcement point. Identify which protocol carries the request, which identity source or certificate is consulted, whether a second factor is required, which attributes are returned, and which firewall, switch, wireless controller, VPN, or application consumes the result. The same path becomes the troubleshooting map when a user reports only that authentication failed.

User stores define where identity and group membership come from

FortiAuthenticator can maintain local users and integrate with external LDAP directories. Administrators need to know which identities are authoritative locally, which are queried remotely, how groups are resolved, and what happens when a directory becomes unavailable. A successful LDAP bind does not prove the intended user or group can be found, and finding the user does not prove the policy maps the correct group. Testing should include user lookup, password validation, disabled accounts, expected group membership, and one controlled directory outage.

In day-to-day administration, a login can succeed at one layer while authorization is still wrong because group mapping or directory scope is incorrect. Confirm DNS, routing, bind credentials, search base, user lookup, group resolution, and the final group FortiAuthenticator returns before creating an exception on the consuming device.

A practical lab task is to create two directory groups with intentionally different access outcomes, authenticate one test user from each group, and then break the directory search base to compare the resulting logs. Write down the expected state first, then compare it with the observed result so you can explain the change instead of merely noticing it.

RADIUS turns identity into a network-access decision

RADIUS lets FortiGate, switches, wireless controllers, VPN services, and NAC systems ask FortiAuthenticator to validate a user or device and return authorization attributes. The administrator must understand RADIUS clients, shared secrets, source addresses, user stores, authentication methods, and returned values. The Unit 7 FortiSwitch 7.2 administration and Secure Wireless LAN 6.4 articles show how those returned values become real access on wired and wireless infrastructure.

A frequent mistake is assuming that a correct username and password will not help if the request comes from an unknown RADIUS client or the shared secret is wrong. Trace client definition, request source, shared secret, identity source, credential or certificate result, returned group or VLAN attributes, and final enforcement in that order.

To see the behavior directly, configure one switch or wireless controller as a RADIUS client, return different attributes for two users, and deliberately change the shared secret to see where the transaction fails. Keep the test narrow and identify the specific log, status value, packet, or policy field that proves the result.

Two-factor authentication needs enrollment and recovery as well as policy

FortiToken and other two-factor workflows improve resistance to stolen passwords, but the operational design includes assignment, activation, time synchronization, user education, lost-device handling, replacement, and recovery. A help-desk process that creates a permanent single-factor bypass can undermine the strongest technical configuration. Define who can issue a temporary recovery method, how long it remains valid, and what audit record must exist.

On a production system, the weakest part of MFA is often the recovery workflow rather than the cryptographic token itself. Review token state, activation time, authentication logs, recovery actions, and account history whenever support bypasses the normal second factor.

One useful practice step is to assign and activate a token, simulate a lost phone, use the approved temporary recovery path, replace the token, and finally remove the user. Afterward, undo the test change and verify that the original state returns cleanly without leaving an unintended exception.

FSSO should be understood as a user-to-IP mapping pipeline

Fortinet Single Sign-On can let FortiGate learn user identity from workstation or directory activity so firewall policy follows authenticated users without prompting them repeatedly. The important chain is event collection, user-to-IP mapping, group resolution, FortiAuthenticator state, FortiGate communication, and final policy. A user can log in successfully to Windows while the firewall still sees only an IP address if any one of those steps breaks.

This scenario is easier to reason through once you recognize that a healthy workstation login does not prove the firewall received a valid user mapping. Compare the mapping FortiAuthenticator holds with the identity FortiGate shows, then examine time, service permissions, address changes, and communication between the systems.

Set up a small lab where you capture one healthy user-to-IP mapping, then stop or misconfigure the collection path and observe how the FortiGate policy changes when the identity disappears. The goal is to understand the evidence trail rather than memorize where one version places the setting.

PKI, SCEP, and revocation make certificate trust operational

FortiAuthenticator can act as a certificate authority and support issuance, signing, SCEP enrollment, revocation, and certificate revocation lists. Certificates can authenticate users, devices, services, VPN peers, and 802.1X clients without relying only on passwords. Administrators need to understand trust chains, certificate purpose, validity, subject identity, key usage, private-key protection, and revocation. A certificate can be mathematically valid and still be rejected because the relying system does not trust the chain or the identity does not match policy.

From an operations perspective, successful certificate issuance is only half the lifecycle; expired or revoked credentials can still create security and availability problems. Check issuer trust, subject or SAN identity, validity, intended usage, revocation state, and the relying system’s verification result rather than focusing only on the certificate file.

One effective lab exercise is to issue a certificate, use it successfully, revoke it, update the relevant revocation information, confirm access fails, and then issue a replacement. Capture the baseline before making the change and compare it with the resulting state to prove what actually moved.

Guest portals and self-service require governance and expiration

Portal functions can support guest registration, temporary accounts, password changes, and token-related self-service. A secure design defines who can create an account, whether validation is required, which group the user receives, how long access lasts, and what happens at expiration. Temporary users should not quietly accumulate into a permanent unmanaged identity population simply because nobody tested cleanup behavior.

One recurring failure mode is that a portal that creates accounts reliably but never removes them can become an identity-management problem over time. Inspect creation, sponsor or validation records, group membership, expiration time, authentication history, and deletion or disablement state when reviewing guest access.

A controlled test makes this easier to see: create a guest, complete the normal validation, confirm restricted access, let the account expire, and verify the consuming service rejects further authentication. Limit the test to one variable and record which piece of evidence establishes the conclusion.

SAML and 802.1X extend FortiAuthenticator into application and network federation

SAML lets FortiAuthenticator participate in federated web authentication, while 802.1X lets it support wired and wireless access through RADIUS and EAP. For SAML, understand identity-provider and service-provider roles, redirects, assertions, entity identifiers, signing certificates, attributes, and clock sensitivity. For 802.1X, understand the supplicant, EAP method, server certificate, user or machine identity, and returned access attributes. The identity-aware access model helps connect these flows.

In a working environment, users often describe both federation and 802.1X failures simply as a login problem even though the transaction stages are completely different. For SAML, follow redirect, authentication, assertion, signature, and service-provider acceptance; for 802.1X, follow supplicant, certificate trust, RADIUS result, and network enforcement.

A good rehearsal is to complete one SAML login and one 802.1X login, then deliberately break certificate trust in each flow and compare the resulting evidence. Restore the original configuration and confirm the system returns to its baseline state with no residual bypass.

Use 6.4 as durable identity training, then map it to the current product

The related FortiAuthenticator 6.1 and 6.5 administration articles show surrounding versions, while Fortinet now teaches FortiAuthenticator 8.0. Use the current Fortinet certification structure for present-day planning instead of treating NSE6_FAC-6.4 as an active target. The durable value remains LDAP, RADIUS, MFA, FSSO, portals, PKI, SCEP, 802.1X, SAML, and troubleshooting.

The situation becomes clearer once you recognize that version-specific navigation ages much faster than the identity transactions and trust relationships behind it. Compare current FortiAuthenticator documentation with the older workflow and note which concepts remain unchanged even when feature placement or terminology moves.

Create a focused lab where you build one end-to-end identity lab that authenticates a directory user with MFA, returns a RADIUS attribute, issues and revokes a certificate, maps FSSO identity, and completes a SAML login. Focus on the observable control path, not the exact menu location in this release.