Troubleshooting FSSO

When installing, configuring, and working with FSSO some problems are quite common. A selection of these problems follows including explanations and solutions.

Some common Windows AD problems include:

• General troubleshooting tips for FSSO
• Users on a particular computer (IP address) cannot access the network
• Guest users do not have access to network
• Can’t find the DCagent service
• User logon events not received by FSSO Collector agent
• Mac OS X users can’t access external resources after waking from sleep mode

 

General troubleshooting tips for FSSO

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 unit.

If not the Collector agent does not have this amount of bandwidth, information FSSO information may not reach the FortiGate unit resulting in outages. The best solution is to configure traffic shaping between the FortiGate unit and the Collector agent to ensure that minimum bandwidth is always available.

 

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.

 

Solutions

• Ensure each computer has separate IP addresses.
• Encourage users to logout on one machine before logging onto another machine.
• If multiple users have the same username, change the usernames to be unique.
• Shorten timeout timer to flush inactive sessions after a shorter time.

 

Guest users do not have access to network

A group of guest users was created, but they don’t have access.

 

Solution

The group of the guest users was not included in a policy, so they do not fall 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 group is part of an identity-based security policy to allow traffic.

 

Can’t find the DCagent service

The DCagent service can’t 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).

 

Solution

 

To verify that the DCagent is installed properly

1. Check that DCagendll exists in Windows\system32 folder.

2. 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 dialog is present on the screen on the Collector agent computer, the Collector agent will not receive any logon events. Once the dialog 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.

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 web sites, 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.

Solution

The security settings on 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.

 

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!