Through implementation of Fortinet's FSSO User Tracking in an enterprise environment I have found a few gotchas and issues that arise due to different types of network design that largely depends on scale. In this post I hope to clearly convey the things I have found during my own implementation and shed some light on what FSSO implementation is best based on your specific network architecture.

TL;DR

Use the FSSO Mobility Agent with either the ForiAnalyzer or FSSO Collector Agent as the Collector. This provides the quickest and most reliable user tracking in any environment. Keep in mind that the FortiAnalyzer will requrie additional licensing (as of writing this article) to accept logs from the FSSO Collector agent.

To understand the nuances, continue reading.

What is FSSO User Tracking

FSSO User Tracking is Fortinets way of passing user authentication information to Fortinets infrastructure (FortiAnalyzer, FortiGates, etc) in a way that the user can be tied to the IP address of the device that they are using. You can use the FortiAuthenticator as a "collector agent" which can aggregate logs from various sources including Windows Event Logs, Fortinet DC Agent forwarder, FortiNAC and Fortinet's FSSO Mobility Agent to name a few.

Why is This Needed?

In my experience the time that this data is needed is when you want to create firewall or web filter policies that are tied to a user in active directory instead of a subnet or specific IP address. This allows your firewall or web filtier policies to correspond to a department or other subset of users instead of a specific machine (IP address). This creates a more seamless environment which allows administrators to control access to internal and external resources across the network in a more comprehensive way.

Tracking Methods

I touched on this a bit in an earlier section of this article but at the end of the day Fortinet infrastructure is able to track users to IP addresses in the following high level process.

1. Agent is installed in a place that has access to authentication attempts along with the hostname of the device the user is on.
   1. Sometimes IP address information is gathered from that specific agent
2. This login data is then sent to a collector (FortiAuthenticator or FSSO Collector Agent)
   1. IP address information is collected directly from agent that passed it to the collector agent, if not DNS lookup is performed on the collector server/agent.
3. User and IP address information is passed to FortiGates configured to poll the FSSO Collector Agent/FortiAuthenticator.

This is a very high level breakdown of the process however it serves as a good conceptualization of what is happening "under the hood".

That all being said what I have found and the reason that I am writing this article is that deciding on what specific agent should be used to collect authentication information (FSSO Mobility Agent, DC Agent, Windows DC Log Polling, FortiNAC Logs, etc.) will likely be dictated by your network infrastructure specifically your DNS and Active Directory infrastructure and it is not inherently straight forward as to what collection method should be chosen in what circumstances. 

Agents Relaying Authentication Information

In this article I will only focus on the AD DC agents and FSSO Mobility Agents for relaying the authentication/IP information to a collector, the reason for this is because that is all I have experience with and during discussions with Fortinet I have been told that those are to be considered the most reliable methods of relaying authentication and IP information.

Both of these collection methods are suppored in the FortiAnalyzer and FSSO Collector Agent for Windows Server so whatever you are using for the collector agent this article should be able to help you.

Issues I have Seen

The biggest Issue I have seen is tracking users when their machine changes subnets, specifically laptops moving wired/wireless, moving site to site, or VPN to onsite. In these cases there are specific instances where when a user changes subnet and depending on your implementation of FSSO it will not be able to track that user to its new IP address and will require time and manual intervention on behalf of the user for FSSO to properly detect the new IP address. Because this is environment dependent based on how the lookups are done described in the process above I have broken down relevant information in regard to environment architecture. 

I would also like to point out that this can happen for desktop computers that don't move subnets, this is rarer but do occur.

Single DNS Single DC

Lets talk about an environment with a single DNS server and single DC, I will assume that the DC and DNS server are the same server. 

This would be a safe environment to use the DC agent logs to process authentications and correlate IP addresses to users.

It should also be safe to allow the DC agent to perform DNS lookups as long as one of the following criteria is met

• the workstation is configured to and has the rights to update its DNS entry
• DHCP will update DNS on behalf of the client always

In this environment it is safe to assume that when the client changes IP addresses the following happens:

1. The client or DHCP server will update the single DNS server of its new IP address
2. An authentication will be processed on the single AD server (same as DNS server)
3. That authentication will be detected by the DC Agent
4. That same server does a DNS lookup and it resolves the new IP address.
   1. This is if the DC agent is configured to do DNS resolution, DNS resolution can be performed on the collector instead which also works and is better in certain circumstances.

Because there is a single DNS server and a single AD server (which ultimately resolves via our single DNS server) we can safely assume that when a client migrates subnets it will update DNS and then perform an authentication with AD. The DC Agent will catch that authentication and if configured to do so will do a name resolution via the single DNS server for the workstation name in the authentication. It will already be updated with the workstations IP address so will resolve properly and send that information to the collector agent. 

If DNS resolution is not configured on the DC agent the collector agent will perform those steps and will get the updated IP address, this is even more reliable as more time has passed from the authentication log and the DNS lookup

At the end of the day, the FortiGate will know of the new IP address and the user will hit any policies that are tied to them directly or a group that they belong to in AD. This environment the DC agent works and is a sufficient solution.

You may instead do the FSSO Mobility agent instead of the DC agent and this will work, you just need to maintain that software on existing workstations and all going forward so it could be a less than ideal option for a smaller environment.

Dual DC Dual DNS

This is where things get a bit tricky and I lean toward recommending the FSSO Mobility agent, however there are ways to get the DC agent to be reliable.

In this I will assume that both DC's in the environment are also DNS servers that sync their updates.

In a windows environment when the workstation changes subnet there is no gaurintee that the DNS sever that is updated by the client or DHCP server will be the same server that processes the authentication request. Because of this if the computer updates DC1's DNS and processes the authentication via DC2, if a DNS sync has not occured AND the DC agent is configured to do the DNS lookup before forwarding to the collector, it will not get the new IP address and the user will not match any of their rules until another authentication has been processed AFTER DNS has synced.

There are 2 ways to get around this

1. Configure the DNS servers for near instant synchronization
2. Offload the DNS lookup to the collector agent and tune DNS to sync as quickly as possible

I recommend option 2 in this case as it gives the most chance of success of the DNS lookup succeeding to resolve the new IP address being there is a delay in DNS lookup as it is being done on the collector which has a few second delay and DNS being tuned to near instant sync, it should be enough time to replicate the DNS update to both servers.

However not all environments are able to do this so at the end of the day in my experience, the way to gaurintee the IP change is detected in all circumstances, use the FSSO Mobility agent on all workstations.

Multiple DC Multiple DNS

At this point I will simply say do not consider the DC agent and use the mobility agent installed on all workstations to sync IP information with the collector in real time. The reason for this is eluded to in the "Dual DC Dual DNS" section. 

In a Windows environment, there is no way to gaurintee that the DNS server being updated during an IP change by the DHCP server or the client will be the DNS sever that is queried by the DC agent OR the Collector Agent. 

Imagine the scenario you have 5 DC's and each of those DC's are DNS servers. When an IP change occures DHCP or your client could update its IP to any one of those 5 servers, and your authentication could be processed on any OTHER one of those servers so DNS lookups on the DC agent is a no go as it will often not have the updated DNS information.

You may think having the FortiAuthenticator/Collector Agent do the DNS lookup will resolve this however in my testing it won't work a large subset of the time becuase you can only configure 2 DNS servers and it could get its update from any one of those 2 and even if your DNS is tuned down there will be a substantial amount of times that the DNS lookup will resolve only the old address.

Because of that in my experience it is way too unreliable in this environment to use anything other than the FSSO Mobility agent. Now the drawback of having to maintain that software on all computers in the organization and the license requirement are likely to be acceptable for organizations that fit this type of environment. The key part here is to make sure you are licensed to collect these logs ahead of time and deploy the FSSO Mobility Agent and you will be just fine.

In conclusion unless you have a single DC and single AD server, budget the extra license cost and use the FSSO Mobility agent for FSSO user tracking. It will save so many headaches and hours of troubleshooting. Hope this article helps you understand more and most importantly saves you time implementing FSSO.