I85PREP
⌘ K
Fortinet NSE 5 study materials
Fortinet NSE 5 study resources

FSSO Group Policy Denying a Quarter of Logins After a DC Build

Fortinet NSE 5 · Put your knowledge to work in context.

All case studies

FSSO Group Policy Denying a Quarter of Logins After a DC Build

A retail chain uses a FortiGate 100F with FSSO to gate access to an ERP application. The FSSO collector agent runs on DC1, and DC agents are installed on DC1 and DC3 only. DC2 was promoted last month to spread authentication load. ERP access is controlled by a policy whose source is the FSSO group ERP-Users; the destination is the ERP virtual IP. Since the DC2 build, about 25% of morning logins are denied: those users land on the authentication portal or hit the implicit deny, and the logs show the user was not matched to a group. The same users often succeed after lunch with no change on the FortiGate. Separately, the two RDS session hosts publishing the ERP client show only one identity at a time in diagnose debug authd fsso list even when a dozen users are connected. The collector agent's group filter does include ERP-Users, and the FortiGate can reach the collector on TCP 8000.

1. Explain the 25% denial and give the fix options, including what evidence would confirm the diagnosis.

Read the worked answer

FSSO is an identity feed, not authentication. The collector only knows about logons that are reported to it - either by a DC agent installed on each domain controller, or by polling each DC's security event log.

  • With DC agents on DC1 and DC3 only, logons authenticated by DC2 are never reported, so those users have no FSSO entry.
  • The policy that requires ERP-Users then has no matching identity, so the session falls through to the portal/implicit deny.
  • The 25% tracks the share of users whose logon lands on DC2; 'works after lunch' is a later unlock or logon hitting a covered DC, or a cached entry finally appearing.

Fix options

  1. Install the DC agent on DC2 - smallest change, keeps the reporting model uniform. This is the correct fix.
  2. Switch the collector to polling mode against all three DCs - no per-DC agents, but requires remote WMI/event-log access and a service account with the right rights, and it adds polling latency.

Confirming evidence

  • diagnose debug authd fsso server-status - is the collector connected and are the expected DC entries visible?
  • diagnose debug authd fsso list - check a denied user's IP; if it is absent at the moment of denial and appears later, the feed gap is proven.
  • Correlate a denied user's logon time with which DC handled the authentication (4624 events on the DCs).

2. Why do the RDS session hosts collapse to a single identity, and what are the options for handling it?

Read the worked answer

FSSO maps a source IP to a user. A dozen users on one session host all arrive at the FortiGate from the same IP, so the entry for that IP is overwritten by whoever logged on last, or holds the console user.

Options

  1. TS-Agent on each session host - the terminal-server agent reports user-to-session mappings to the collector so the FortiGate can resolve per-user identity even though the packets share an IP. This is the designed solution and requires deployment on every session host.
  2. Don't base the decision on FSSO for that traffic. Terminate users at an authenticating gateway first (per-user SSL VPN portal, or explicit proxy with authentication) and let the ERP policy match the authenticated user rather than the workstation IP.
  3. Separate the RDS farm onto its own policy with narrower permissions, and use application-level authorisation inside the ERP instead of trying to enforce per-user identity at the firewall.

Judgement If option 1 cannot be deployed quickly, do not leave a policy in place that appears per-user but is actually first-come-first-served. Either narrow the RDS policy to what any ERP user would be allowed, or route the RDS hosts through an authenticating proxy. A control that silently grants one user another user's access is worse than a coarser control you can explain.

3. How do you roll this out safely without a repeat of the denials, and what stale-entry behaviour must you plan for?

Read the worked answer

Roll out in observe-then-enforce order

  • Put a duplicate policy above the live one with the FSSO group negated and the action set to deny with logging only, so you can see exactly who would be denied without cutting anyone off. Review for a full working week, including the Monday peak, because DC selection is load-driven.
  • Only then convert it to a real deny and remove the temporary permissive policy.
  • Before enforcing, run a pilot on one store's users, not on a whole DC's population, so a feed gap cannot take out a region.

Stale entries

  • FSSO entries persist until a logoff event or an inactivity timer expires. If the collector is not receiving logoff events (4634), user-to-IP mappings linger, which can silently allow access after the person left and make a new user on the same workstation inherit the previous identity.
  • Set an explicit inactivity/logoff handling policy in the collector, verify with a controlled logon/logoff test, and monitor diagnose debug authd fsso list for entries with implausible ages.
  • In an HA pair the FortiGate's source IP toward the collector must be stable (a dedicated management or reserved address), or the collector will see two clients and per-unit entries will diverge during failover.
  • Finally, document that DC2 must not be rebuilt without the DC agent - the original incident was a process gap, not a FortiGate defect.