A contractor brings a personal, non-domain-joined laptop onto the utility's corporate network segment where FSSO is used to identify back-office staff. What happens to that contractor's identity from the FortiGate's perspective?
Select an answer to reveal the explanation.
Short Explanation
FSSO only knows what the domain controller tells it, and a personal laptop that never logs into the domain never generates that story. No logon event means no identity to pass along — the FortiGate is left with a device it can't place in any FSSO-derived group. Some other method, like a captive portal or local login, would have to pick up the slack.
Full Explanation
FSSO's entire mechanism depends on observing an actual domain logon event, so a non-domain-joined device produces no such event and therefore no user-to-IP mapping for the FortiGate to consume; the contractor's traffic is effectively unidentified from an FSSO standpoint unless a separate authentication method (active firewall authentication, a captive portal, or a local account) is layered onto that policy. The FortiGate has no capability to join a device to a domain — domain membership is an Active Directory administrative action performed on the endpoint, entirely outside the FortiGate's authentication role. Substituting a MAC address as a stand-in username is not how FSSO or any FortiGate authentication scheme works; MAC addresses are not treated as user identities in this context. Assuming FSSO applies uniformly regardless of domain membership misunderstands the mechanism's dependency on the domain logon event as its sole identity source. The practical caveat this raises for utilities is that segments mixing domain-joined and personal or vendor devices need a fallback authentication method for the non-domain population, or those devices will simply fail to match any user-group policy and hit the implicit deny. Confirm this by checking whether the contractor's device appears in the FSSO logon list at all.