FSSO polling connector agent installation

This topic gives an example of configuring a local FSSO agent on the FortiGate. The agent actively pools Windows Security Event log entries on Windows Domain Controller (DC) for user log in information. The FSSO user groups can then be used in a firewall policy.

This method does not require any additional software components, and all the configuration can be done on the FortiGate.

To configure a local FSSO agent on the FortiGate:

1. Configure an LDAP server on the FortiGate
2. Configure a local FSSO polling connector
3. Add the FSSO groups to a policy

Configure an LDAP server on the FortiGate

Refer to Configuring an LDAP server. The connection must be successful before configuring the FSSO polling connector.

Configure a local FSSO polling connector

To configure a local FSSO polling connector:

1. Go to Security Fabric > External Connectors and click Create New.
2. In the Endpoint/Identity section, select Poll Active Directory Server.
3. Fill in the required information.
4. For LDAP Server, select the server you just created.

5. Configure the group settings:

   1. For Users/Groups, click Edit. The structure of the LDAP tree is shown in the Users/Groups window.
   2. Click the Groups tab.
   3. Select the required groups, right-click on them, and select Add Selected. Multiple groups can be selected at one time by holding the CTRL or SHIFT keys. The groups list can be filtered or searched to limit the number of groups that are displayed.
   4. Click the Selected tab and verify that the required groups are listed. To remove a group, right-click and select Remove Selected.
   5. Click OK to save the group settings.

6. Click OK to save the connector settings.

7. Go back to Security Fabric > External Connectors.
8. There should be two new connectors:

   

   • The Local FSSO Agent is the backend process that is automatically created when the first FSSO polling connector is created.
   • The Active Directory Connector is the front end connector that can be configured by FortiGate administrators.

   To verify the configuration, hover the cursor over the top right corner of the connector; a popup window will show the currently selected groups. A successful connection is also shown by a green up arrow in the lower right corner of the connector.

   If you need to get log in information from multiple DCs, then you must configure other Active Directory connectors for each additional DC to be monitored.

Add the FSSO groups to a policy

FSSO groups can be used in a policy by either adding them to the policy directly, or by adding them to a local user group and then adding the group to a policy.

To add the FSSO groups to a local user group:

1. Go to User & Authentication > User Groups and click Create New.
2. Enter a name for the group in the Name field.
3. Set the Type to Fortinet Single Sign-On (FSSO).
4. In the Members field, click the + and add the FSSO groups.

   

5. Click OK.
6. Add the local FSSO group to a policy.

To add the FSSO groups directly to a firewall policy:

1. Go to Policy & Objects > Firewall Policy and click Create New.
2. In the Source field, click the +. In the Select Entries pane, select the User tab.
3. Select the FSSO groups.
4. Configure the remaining settings as required.
5. Click OK.

Troubleshooting

If an authenticated AD user cannot access the internet or pass the firewall policy, verify the local FSSO user list:

# diagnose debug authd fsso list 
----FSSO logons----
IP: 10.1.100.188 User: test2 Groups: CN=group2,OU=Testing,DC=Fortinet-FSSO,DC=COM Workstation: MemberOf: CN=group2,OU=Testing,DC=Fortinet-FSSO,DC=COM
Total number of logons listed: 1, filtered: 0
----end of FSSO logons----

1. Check that the group in MemberOf is allowed by the policy.
2. If the expected AD user is not in list, but other users are, it means that either:
   • The FortiGate missed the log in event, which can happen if many users log in at the same time, or
   • The user's workstation is unable to connect to the DC, and is currently logged in with cached credentials, so there is no entry in the DC security event log.
3. If there are no users in the local FSSO user list:
   1. Ensure that the local FSSO agent is working correctly:

      # diagnose debug enable
      # diagnose debug authd fsso server-status
      
      Server Name			     Connection Status    Version            Address
      -----------			     -----------------    -------            -------
      FGT_A (vdom1) # Local FSSO Agent    connected            FSAE server 1.1    127.0.0.1
      

   The connection status must be connected.

   2. Verify the Active Directory connection status:

      # diagnose debug fsso-polling detail 1
      AD Server Status (connected):
      ID=1, name(10.1.100.131),ip=10.1.100.131,source(security),users(0)
      port=auto username=Administrator
      read log eof=1, latest logon timestamp: Fri Jul 26 10:36:20 2019
      
      polling frequency: every 10 second(s) success(274), fail(0)
      LDAP query: success(0), fail(0)
      LDAP max group query period(seconds): 0
      LDAP status: connected
      
      Group Filter: CN=group2,OU=Testing,DC=Fortinet-FSSO,DC=com+CN=group21,OU=Testing,DC=Fortinet-FSSO,DC=COM

      If the polling frequency shows successes and failures, that indicates sporadic network problems or a very busy DC. If it indicates no successes or failures, then incorrect credentials could be the issue.

      If the LDAP status is connected, then the FortiGate can access the configured LDAP server. This is required for AD group membership lookup of authenticated users because the Windows Security Event log does not include group membership information. The FortiGate sends an LDAP search for group membership of authenticated users to the configure LDAP server.

      FortiGate adds authenticated users to the local FSSO user list only if the group membership is one of the groups in Group Filter.

4. If necessary, capture the output of the local FortiGate daemon that polls Windows Security Event logs:

   # diagnose debug application fssod -1 

   This output contains a lot of detailed information which can be captured to a text file.

Limitations

• NTLM based authentication is not supported.
• If there are a large number of user log ins at the same time, the FSSO daemon may miss some. Consider using FSSO agent mode if this will be an issue. See Public and private SDN connectors for information.
• The FSSO daemon does not support all of the security log events that are supported by other FSSO scenarios. For example, only Kerberos log in events 4768 and 4769 are supported.