I have circa 1000-1500 users daily, most will be ok but I will get a few who are not being authenticated by the Fortigate 600F. The security event logs show up in Domain controllers logs but they do not show up in FSSO.
My setup is
2 Domain Controllers. FSSO installed on both and DC agent installed on both, Advanced mode. External Connectors, FSSO Agent on Windows AD/User Group Source = Local.
My firewall rule is set for internal subnets and users from a specific group in AD. This works 90% of the time. When it does not allow a user web access, the Fortigate logs only show the IP address and not the username (so they get denied), the 'show logon users' on FSSO does not show the User. The only way for me to get the user working again is to remove the 'User' rule on my firewall which is not ideal.
You will then need to inspect the logs and see if you can find events for the affected devices/users.
Similar issues most commonly occur when users login against Windows cached credentials (common with laptops on Wifi). There could also be an issue with DNS resolution, group membership look up and many, many more reasons. Only the logs can tell really.
I'd recommend opening a ticket with Fortinet TAC where you can safely share your debug logs while also specifying the affected workstation hostname/IP , username and exact time of the user's logon attempt.
Thanks, I have enabled all the logs now and I am using them to help diagnose. You are right about DNS. I upgraded my AD domain controllers and DNS scavenging was not turned on which caused issues with the workstation look up etc. However, I still have some issues but working through the logs now.
Great. Feel free to share a snippet of the logs if you find something interesting that you you do not fully understand. But if you get suck and need to share the full log files, it's better to open a support ticket with TAC.
Also if you think that you might be facing issues with DNS resolution, or DNS resolution is slow, I'd recommend disabling the DNS resolution on the DC Agents. The DNS resolution will then be performed by the FSSO Collector agent, which has a more robust way of queuing the requests. I'd say the Collector debug logs are also easier to read.
If you have active support contract, create a ticket - it will be fixed faster. Meanwhile, you did not mention what Polling mode you are using - Win Sec Log polling, or DC Agent. Even there is a DC agent installed in the DCs, polling mode could be different mode, and DC agent logs are irrelevant.
If you are using Polling mode 'DC agent mode', then:
1. enable the logs on both DC agents; 2. Reproduce the issue, and find on which DC your user logged on. Search for logon event in the proper DC agents log. If you find smth on DC agents, go to Collector Agent logs, and search for the logon event there. May be you will find smth interesting. You can search with user account name, workstation, and IP address as well. Could be also override with service, or admin accounts launched the applications.
The issue has now been resolved. It was a combination of the following.
After upgrading my Active Directory Servers, DNS scavenging was not turned back on so IP addresses were not resolving to the correct DNS names (vice versa). I turned DNS scavenging back on.
I had a service running under my account that checked in with workstations across the network which resulted in generating logon events that confused FSSO of who was signed in to the workstations. I changed this to a service account and told FSSO to ignore that user.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.