Fortinet NSE4_FGT_AD-7.6: FortiSASE User Onboarding and Administration
FortiSASE administration begins with a user and an application path, not a security dashboard. A remote employee can be successfully authenticated yet send traffic directly to the internet outside the intended inspection point; another employee may reach a security point of presence but lack the group, device posture or policy required to use a private application. The initial rollout therefore has to prove both identity and traffic steering. Treating endpoint onboarding as a separate checkbox from policy produces failures that are difficult for users and administrators to explain.
The Fortinet NSE 4 FortiOS 7.6 Administrator exam includes remote-work challenges, secure access service edge (SASE) architecture, FortiSASE components, security capabilities and representative use cases. Those objectives call for an operational mental model of a cloud-delivered network/security service rather than memorization of FortiGate interface commands. FortiSASE has its own service documentation and release lifecycle, and its current portal menus should not be passed off as screenshots of the FortiOS 7.6.0 appliance.
This guide concentrates on making a limited, verifiable onboarding plan: select the right access pattern, connect an identity source, enroll a managed endpoint, bind policies to the actual user group, and test failure handling. Use a dedicated test group first, and confirm the FortiSASE subscription, regions, tenant options, client version and IdP settings available to the actual organization. Never assume production users can be invited safely without confirming who receives the invitation, what access it grants and which controls apply after connection.
Identify the specific remote-work risk before selecting access mode
Hybrid employees connect from home networks, hotels, public Wi-Fi, branch offices and mobile links. Their devices may be managed or unmanaged, and the applications they need might reside in public SaaS, the organization’s private data center, or a cloud virtual network. The traditional assumption that everyone enters through a single on-premises VPN concentrator becomes weak when traffic exits locally or applications run outside the corporate perimeter. Security operations must know which access path applies to each combination of device, user and application.
Begin with a short inventory of users, device ownership, identity method, destination type, required authentication assurance and regulatory constraints. A managed laptop that needs internet SaaS inspection may fit agent-based SIA. A contractor who needs only a single private web application may need a different agentless or application-specific secure-access design. A branch network that must steer many devices can require an edge or IPsec approach rather than installing an endpoint agent on each host. Do not treat these modes as fully equivalent; they differ in scope, enforcement and troubleshooting.
A risk model should include the failure path. If the user’s authentication provider is unavailable, will the system deny access, reuse a still-valid session, or allow a limited recovery path? If a client cannot reach the selected service PoP, will traffic remain protected or fall back to an uninspected internet route? The correct behavior depends on the business role and the permitted service, but it must be documented before a service interruption happens.
Understand FortiSASE as identity, steering, inspection and access
Secure access service edge combines network access and security controls into a distributed service. In FortiSASE, the management tenant configures user identities, groups, security policy, access paths and endpoints, while traffic traverses the relevant service points of presence. The administrator should distinguish Secure Internet Access (SIA), Secure Private Access (SPA) and related SaaS access workflows rather than implying that one client profile provides the same controls for every destination. The actual path is determined by user configuration, steering method and policy, not by the word ‘SASE’ in a licensing contract.
Endpoint steering can send a managed FortiClient device toward the service for applicable traffic, while Fortinet also documents configurations for branch or edge device connectivity and proxy-based use cases. The presence of the agent does not prove that a particular flow was steered. An application can use local breakout, a VPN, a proxy exception, or a different DNS path depending on the user’s configuration. Check the effective endpoint or edge-device connection, policy target, and exit point when validating how traffic is protected.
FortiSASE security profiles may combine web and DNS filtering, antivirus or antimalware protection, application control, intrusion prevention and TLS inspection, subject to purchased features and the policy type. Those controls do not inspect all traffic equally: encrypted flows can restrict visibility without properly configured inspection and certificate trust; application identity can be incomplete early in a session; and security-profile groups must be attached to the appropriate policy. A tenant-wide default is a starting point, not proof that the intended user group or private application receives the right controls.
Create identity and group mappings before sending invitations
Fortinet’s FortiSASE access and authentication documentation distinguishes local identities, LDAP, RADIUS and SSO integrations. SSO can use providers such as Microsoft Entra ID or Okta, depending on the tenant and authentication pattern. Start by defining which IdP owns the user record, how users are grouped, and who may issue invitations. A user who exists in Entra ID or LDAP has not automatically been granted access to every FortiSASE policy; the tenant’s group assignment and application rules still matter.
Use a limited test user from an approved organizational group and verify both successful and failed authentication. The user’s group must map to the intended security and access policy. If a user authenticates successfully but is denied the expected resource, inspect the received user identity and group, the agent’s connection state, source scope and policy order rather than recreating the account. If an unknown or departing user can connect, inspect invitation validity, session refresh and group-removal propagation before allowing more production users.
Identity integrations can involve private LDAP/RADIUS services that reside behind a secure private access hub. Fortinet documents connectivity dependencies for such authentication servers, including appropriate SPA hub routing and firewall policies. In other words, placing a private directory endpoint into the FortiSASE configuration does not make it reachable by magic. Verify that the security PoP can reach the IdP through the approved path and that no emergency routing exception exposes a sensitive service to an unrestricted public network.
Onboard managed endpoints without losing visibility of who joined
The managed endpoint onboarding workflow allows an administrator to use the FortiSASE portal to obtain an appropriate FortiClient installer or send an invitation link to an intended user. Fortinet describes both preconfigured installers, which can include the invitation code, and manual enrollment requiring the code to be entered. The administrator should decide which process suits the device-management system, how invitations expire, and who can recover from enrollment failure. Sending codes by an unverified distribution list is not equivalent to a controlled deployment.
Enrollment should be tested in stages. On one supported managed device, check the installed client version, token acceptance, SSO or local login, effective connection to the appropriate FortiSASE service, policy group and actual network path. Record an ordinary browsing flow and a controlled blocked destination so there is evidence that the service receives and evaluates traffic. Then test a disconnected client, a device whose network changes and a user whose membership has been revoked. Those conditions reveal errors that a successful one-time login does not.
The provider’s onboarding portal can guide initial SIA setup through user SSO, security profile groups and agent policies. Follow that order only after validating tenant-specific policy requirements. For a rollout managed by endpoint administration, package the approved client configuration and distribute it using the organization’s established device-management process. Keep the initial user population small enough that DNS, TLS and application exceptions can be diagnosed rather than hidden under hundreds of simultaneous complaints.
Match internet-security profiles to real user traffic
Secure Internet Access should have a clear rule for traffic classification, destination and inspection. Define an appropriate user group, whether protected browsing must use TLS inspection, the web/DNS categories or application controls required, and how a legitimate business exception is requested. A single aggressively restrictive profile can generate broad bypasses that create less security over time. It is often safer to build an evidence-backed baseline and add targeted controls once the security team understands the actual applications in use.
Inspect certificate trust deliberately. Full TLS decryption can require distributing a trusted inspection CA to managed endpoints and testing applications that use certificate pinning or other restrictions. Users should not be told to ignore certificate warnings without an approved trust model. FortiSASE security profile groups can define different controls for groups or access paths; their capabilities and limitations may vary between Secure Internet Access, secure web gateway and private-access workflows. Validate the product-specific profile settings and policy attachment in the tenant being deployed.
A useful initial inspection test has three cases: a sanctioned SaaS login, a prohibited known-risk category in a controlled test, and a site or application that uses a documented exception. For each, inspect the client routing or proxy behavior, expected source identity, policy, categorization verdict and event log. If the user reports a failure but the service has no record of the flow, first determine whether it was actually steered toward the service. Changing malware or category policy cannot repair an endpoint that never used the inspected path.
Treat private-resource access as a separate policy journey
Secure Private Access is not just a different checkbox on an internet policy. The organization must connect its private application network to the FortiSASE service through an approved SPA hub or other supported method, advertise or configure reachability and define which user/device groups can reach which private hosts. A successful agent connection to an internet security PoP does not prove that the user can reach the private data center. Fortinet’s SPA policy design requires deliberate decisions about source scope, destination, services, logging and return routing.
Define a concrete private-access case, such as a payroll application accessible only from managed devices in the finance group. Specify its actual DNS name, private network endpoint, application ports, authentication requirements, data sensitivity and expected identity signal. Then build a matching private-access policy with a narrowly scoped destination. A rule permitting all remote users to every hub defeats much of the access-control purpose. Firewall-policy matching remains useful background, but the FortiSASE SPA hub and tenant policies must be checked in their own supported administration interface.
Test name resolution, route, tunnel or connector status and application authentication separately. A user can be present in the approved group yet reach the wrong address because split DNS failed; a healthy SPA tunnel may still lack a route for a new private subnet; an allowed TCP connection may fail at the application layer. Keep these causes separate in the log and helpdesk process. During rollout, make sure that internet-access exceptions do not silently give employees a direct unmonitored path to services that were supposed to be reached privately.
Diagnose user onboarding from identity to final application
A repeatable FortiSASE onboarding investigation begins with the user record, expected group and invitation. Then verify the installed endpoint client and registration state, whether authentication succeeded, which PoP or private-access hub the client uses, whether the intended traffic was steered, and which security policy actually matched. Do not begin by turning off inspection. A DNS or route problem can look like a web-filter block; a group mapping error can look like a VPN outage; a stale invite can look like a server-side authentication failure.
For a managed endpoint, collect the client state and a narrow set of timestamps, user identity and connection details appropriate to privacy requirements. Compare a working test user with the failing user. If the agent connection exists but web traffic is not logged, inspect steering/bypass rules. If security events show explicit block, analyze the rule, signature or category decision. If a private application is unreachable, trace the SPA hub and return path. FortiSASE internet-access steering offers a deeper operational view of SIA; it is adjacent technical support, not the same NSE 4 onboarding task.
When a remote worker changes networks or devices, retest authentication and the selected service path. Captive portals, constrained Wi-Fi, DNS redirection, MTU behavior and split-tunnel boundaries can all affect the observed result. Review whether security controls remain active during reconnection and whether old sessions retain access after identity changes. A support playbook should distinguish real security-policy denials from infrastructure connectivity and should record enough detail to avoid repeated speculative exceptions.
Approve production only after access, denial and failure tests
A staged acceptance plan should cover a managed test user accessing normal internet applications, the same user’s deliberate attempt to reach a blocked category, a user outside the approved group, and at least one approved private application if SPA is in scope. For each, document the identity, device posture where used, steering route, expected rule, log result and application outcome. The system should be able to explain both why authorized traffic worked and why unauthorized traffic was refused. ‘The agent appears connected’ is not an adequate release test.
Also simulate a bounded failure: unavailable IdP for a lab user, disconnected service path, stale invitation, device address change or a lost SPA route. Determine whether the observed fallback matches the organization’s intended security decision. If a device silently switches to direct internet access, the result is an inspection gap even if applications work. If every service fails closed, the result may be secure but could require a documented emergency process for business-critical functions. Both outcomes need ownership before organization-wide deployment.
FortiSASE onboarding is successful when operations can trace a user from identity enrollment through client connection and the enforced access decision. That is the concept most relevant to NSE 4: distinguish the components, choose an appropriate SASE use case, configure the expected group and inspection policy, and verify a real network path. This does not require every branch or user to use one architecture; it requires each supported architecture to be safe, observable and explainable.
