Description
This article describes how to run FSSO in a dual (or multi) NIC environment.
Quite often, we see issues in FSSO caused by simultaneous use of wired and Wi-Fi connections, especially with docking stations and notebooks/laptop. Less often, this is seen with dual-NIC/dual-LAN standalone workstations.
The root cause of the issue is a single IP A-record in DNS, reflecting only one IP of the existing two addresses.
Since FSSO relies on FortiGate knowing the correct IP for the user and mapping the user info to inbound traffic, traffic that has no user info associated, will not be mapped to FSSO policies.
In Short: (The following behavior seen in Windows Server 2012 R2)
Issue with single IP A DNS record in Microsoft environment is usually caused by DNS and DHCP server setup.
Where DNS is set to be updated only by DHCP, which locks the records.
DHCP also updates the workstation's single A record in DNS with the latest assigned IP.
There is no secondary IP for secondary network interface created in DNS.
** Windows Server 2019 does support same an A-record with 2 different IP addresses. **
For example:
- user booted up with wired NIC (docked notebook for example), got IP from DHCP, then DHCP updated DNS.
- later on workstation connect to Wi-Fi, then DHCP assign new IP for Wi-Fi connection, and also update DNS again.
But in this case, DHCP is not going to add a secondary A-record with Wi-Fi IP alongside to IP from wired connection. DHCP will overwrite the A-record of the wired IP with Wi-Fi IP!
The result is that DNS still contain only one IP for workstation, the one assigned to Wi-Fi (last DHCP offer/assignment).
- If such a workstation comes back to use wired connection (re-docked for example) and first assigned IP, then its wired IP is no longer in FSSO user list.
In result, connection attempts with this wired IP are no longer considered as FSSO authorized by FortiGate.
In detail:
When Collector Agent does DNS resolution of workstation name (as Events from DC mostly do not contain IP but NetBIOS hostname, and so DNS resolution is crucial and needed), or periodic IP check, then workstation name resolves to just one IP from DNS. The Wi-Fi IP, in above-mentioned case, is the last IP assigned by the DHCP server.
Therefore, FSSO user record is created/updated with one IP as Collector Agent, based on latest DNS record, does believe that workstation has just one NIC and IP assigned to it.
To check:
To see if that is the root cause, simply do nslookup on the machine (DC most probably or at least domain-joined) where the Collector Agent is installed to see the currently known IP of the workstation after it connected to wired network, and again when it connects to Wi-Fi.
One IP only will always be visible.
Solution
- MS Workstations by default tries to do DNS update per every interface.
Therefore, the fix is simple, reconfigure DNS to allow both IP addresses being updated from the workstation. So allow DNS updates from workstations. Related document.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc784052(v=ws...
- Above-mentioned will work well for any Collector Agent, regardless of its method, whether polling or DC/TS-Agents is used together with Collector.
If there is possibility to have FortiAuthenticator as Collector Agent, then there is one another, better solution.
And that is SSOMA (Single Sign-On Mobility Agent), which is part of FortiClient, but could be just only FortiClient component running (without any additional VPN,AV,WF functions).
That agent will then report all actually used IP addresses, alongside to all user logons, workstation locks/unlocks to noted FortiAuthenticator. Which then creates respective FSSO records accordingly.
- This also could be solved by setting these dual IP A-records manually, but it is lot less practical or scalable.
However, in a more restrictive environment especially where IP addresses are predictably assigned, for example via DHCP, but semi-statically per MAC address of the client, this might be worth a consideration.
