Description
This article describes general troubleshooting steps for FSSO.
Scope
FortiGate, FSSO.
Solution
Certain problems are known to occur in some cases when installing, configuring, and working with FSSO.
A selection of these problems is covered in this article, including explanations and solutions.
The following tips are useful in many FSSO troubleshooting situations.
- Ensure all firewalls are allowing the FSSO required ports through.
FSSO has a number of required ports that must be allowed through all firewalls or connections will fail. These include: ports 139, 389 (LDAP), 445, 636 (LDAP) 8000, and 8002.
- Ensure the Collector agent has at least 64kbps bandwidth to the FortiGate.
If the Collector agent does not have this amount of bandwidth, FSSO information may not reach the FortiGate unit, resulting in outages.
The best solution is to configure traffic shaping between the FortiGate and the Collector agent to ensure that minimum bandwidth is always available.
The following scenarios may come up when troubleshooting FSSO related issues:
Users on a particular computer (IP address) cannot access the network.
Windows AD Domain Controller agent gets the username and workstation where the logon attempt is coming from.
If there are two computers with the same IP address and the same user trying to logon, it is possible for the authentication system to become confused and believe that the user on computer_1 is actually trying to access computer_2.
Windows AD does not track when a user logs out.
It is possible that a user logs out on one computer, and immediate logs onto a second computer while the system still believes the user is logged on the original computer.
While this is allowed, information that is intended for the session on one computer may mistakenly end up going to the other computer instead.
The result would look similar to a hijacked session.
The solution to the above query can be:
- Ensure each computer has separate IP addresses.
- Encourage users to logout onto one machine before logging onto another machine.
- If multiple users have the same username, change the usernames to be unique.
- Shorten the timeout timer to flush inactive sessions after a shorter time.
Guest users do not have access to the network.
A group of guest users was created, but they do not have access.
The solution to the above query may be:
- The group of the guest users was not included in a policy, so it is not falling under the guest account. To give them access, associate their group with a security policy.
- Additionally, there is a default group called SSO_Guest_Users. Ensure that the group is part of an identity-based security policy to allow traffic.
Cannot find the DCagent service.
The DCagent service cannot be found in the list of regular windows services.
This is because it has no associated Windows service.
Instead, DCagent is really dcagent.dll and is located in the Windows\system32 folder.
This DLL file is loaded when windows boots up and it intercepts all logon events processed by the domain controller to send these events to the Collector agent (CA).
The solution to the above query can be:
To verify that the DCagent is installed properly.
- Check that DCagent.dll exists in the Windows\system32 folder.
- Check that the registry key. exists: [HKEY_LOCAL_MACHINE\SOFTWARE\Fortinet\FSAE\dcagent]
If both exist, the DCagent is properly installed.
User logon events not received by FSSO Collector agent.
When a warning dialogue is present on the screen on the Collector agent computer, the Collector agent will not receive any logon events.
Once the dialogue has been closed normal operation will resume.
If polling mode is enabled, it is possible the polling interval is too large.
Use a shorter polling interval to ensure the collector agent is capturing all logon events.
On the Polling server, the FSSO user's privilege should have at least read-only or read-and-write access to 'BUILT IN\Event Log Readers'. If not Polling server will not be able to poll the log-in events.
If NetAPI polling mode is enabled, consider switching to Event logs or Event Logs using WMI polling as it provides better accuracy.
Mac OS X users can’t access external resources after waking from sleep mode.
When client computers running Mac OS X (10.6.X and higher) wake up from sleep mode, the user must authenticate again to be able to access external resources.
If the user does not re-authenticate, the user will maintain access to internal websites but will be unable to access any external resources.
This issue is caused by Mac OS X not providing sufficient information to the FSSO.
This results in the FortiGate blocking access to the user because they cannot be authenticated.
The solution to the above query can be:
The security settings on the client computer(s) must be configured to require that a username and password be entered when exiting sleep mode or screen saver.
With this feature enabled in Mac OS X, the FortiGate will receive the authentication information it requires to authenticate the user and allow them access.
Note that if the user reverts their settings to disable the password requirement, this will cause the issue to reappear.
Related articles:
