Monitoring authenticated users

This section describes how to view lists of currently logged-in firewall and VPN users. It also describes how to disconnect users.

The following topics are included in this section:

l Monitoring firewall users l Monitoring SSL VPN users l Monitoring IPsec VPN users l Monitoring users quarantine

Monitoring firewall users

To monitor firewall users, go to Monitor > Firewall User Monitor.

You can de-authenticate a user by selecting the Delete icon for that entry.

You can filter the list of displayed users by selecting the funnel icon for one of the column titles or selecting Filter Settings.

Optionally, you can de-authenticate multiple users by selecting them and then selecting De-authenticate.

Monitoring SSL VPN users

You can monitor web-mode and tunnel-mode SSL VPN users by username and IP address.

To monitor SSL VPN users, go to Monitor > SSL-VPN Monitor. To disconnect a user, select the user and then select the Delete icon.

The first line, listing the username and IP address, is present for a user with either a web-mode or tunnel-mode connection. The Subsession line is present only if the user has a tunnel mode connection. The Description column displays the virtual IP address assigned to the user’s tunnel-mode connection.

For more information about SSL VPN, see the FortiOS Handbook SSL VPN guide.

 

To monitor SSL VPN users – CLI:

To list all of the SSL VPN sessions and their index numbers:

execute vpn sslvpn list

The output looks like this:

SSL-VPN Login Users:

Index   User   Auth Type   Timeout         From      HTTPS in/out  0       user1  1           256       172.20.120.51   0/0

SSL-VPN sessions:

Index   User   Source IP        Tunnel/Dest IP

0       user2  172.20.120.51    10.0.0.1

You can use the Index value in the following commands to disconnect user sessions:

To disconnect a tunnel-mode user execute vpn sslvpn del-tunnel <index>

To disconnect a web-mode user

execute vpn sslvpn del-web <index> You can also disconnect multiple users:

To disconnect all tunnel-mode SSL VPN users in this VDOM execute vpn ssl del-all tunnel

To disconnect all SSL VPN users in this VDOM execute vpn ssl del-all

Monitoring IPsec VPN users

To monitor IPsec VPN tunnels in the web-based manager, go to Monitor > IPsec Monitor. user names are available only for users who authenticate with XAuth.

You can close a tunnel by selecting the tunnel and right click to select Bring Down.

For more information, see the FortiOS Handbook IPsec VPN guide.

 

Monitoring users quarantine

The user quarantine list shows all IP addresses and interfaces blocked by NAC quarantine. The list also shows all IP addresses, authenticated users, senders, and interfaces blocked by data leak prevention (DLP). The system administrator can selectively release users or interfaces from quarantine or configure quarantine to expire after a selected time period.

All sessions started by users or IP addresses on the user quarantine list are blocked until the user or IP address is removed from the list. All sessions to an interface on the list are blocked until the interface is removed from the list.

You can configure NAC quarantine to add users or IP addresses to the user quarantine list under the following conditions:

• Users or IP addresses that originate attacks detected by IPS – To quarantine users or IP addresses that originate attacks, enable and configure Quarantine in an IPS Filter.
• Users or IP addresses that are quarantined by Data Leak Prevention – In a DLP sensor select Quarantine IP Address as the action to take.

For more information, see FortiOS Security Profiles guide.

Users are viewed from Monitor > Quarantine Monitor.

Delete	Removes the selected user or IP address from the User Quarantine list.
Remove All	Removes all users and IP addresses from the User Quarantine list.
Search	Search the list for a particular IP address.
Source	The FortiGate function that caused the user or IP address to be added to the User Quarantine list: IPS or Data Leak Prevention.
Created	The date and time the user or IP address was added to the Banned User list.
Expires	The date and time the user or IP address will be automatically removed from the User Quarantine list. If Expires is Indefinite, you must manually remove the user or host from the list.

 

SSO using RADIUS accounting records

A FortiGate unit can authenticate users transparently who have already authenticated on an external RADIUS server. Based on the user group to which the user belongs, the security policy applies the appropriate UTM profiles. RADIUS SSO is relatively simple because the FortiGate unit does not interact with the RADIUS server, it only monitors RADIUS accounting records that the server forwards (originating from the RADIUS client). These records include the user’s IP address and user group.

After the initial set-up, changes to the user database, including changes to user group memberships, are made on the external RADIUS server, not on the FortiGate unit.

This section describes:

• User’s view of RADIUS SSO authentication l Configuration overview l Configuring the RADIUS server l Creating the FortiGate RADIUS SSO agent l Defining local user groups for RADIUS SSO l Creating security policies
• Example – webfiltering for student and teacher accounts

User’s view of RADIUS SSO authentication

For the user, RADIUS SSO authentication is simple:

• The user connects to the RADIUS server and authenticates.
• The user attempts to connect to a network resource that is reached through a FortiGate unit. Authentication is required for access, but the user connects to the destination without being asked for logon credentials because the FortiGate unit knows that the user is already authenticated. FortiOS applies UTM features appropriate to the user groups that the user belongs to.

Configuration overview

The general steps to implement RADIUS Single Sign-On are:

1. If necessary, configure your RADIUS server. The user database needs to include user group information and the server needs to send accounting messages.
2. Create the FortiGate RADIUS SSO agent.
3. Define local user groups that map to RADIUS groups.
4. Create a security policy which specifies the user groups that are permitted access.

Configuring the RADIUS server

Configuring the RADIUS server

You can configure FortiGate RSSO to work with most RADIUS-based accounting systems. In most cases, you only need to do the following to your RADIUS accounting system:

• Add a user group name field to customer accounts on the RADIUS server so that the name is added to the RADIUS Start record sent by the accounting system to the FortiOS unit. User group names do not need to be added for all users, only to the accounts of users who will use RSSO feature on the FortiGate unit.
• Configure your accounting system to send RADIUS Start records to the FortiOS unit. You can send the RADIUS Start records to any FortiGate network interface. If your FortiGate unit is operating with virtual domains (VDOMs) enabled, the RADIUS Start records must be sent to a network interface in the management VDOM.

IPv6 RADIUS support

RADIUS authentication is supported with IPv6, allowing administrators to configure an IPv6 RADIUS server on the FortiGate for IPv6 RADIUS authentication traffic to pass between the server and FortiGate.

Syntax

Allow IPv6 access on an interface:

config system interface edit <name> config ipv6 set ip6-allowaccess {ping | https | ssh | snmp | http | telnet | fgfm | capwap} set ip6-address <xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/xxx>

next

next

end

Configure the IPv6 RADIUS server:

config user radius edit <name> set server <xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx> …

next

end

Creating the FortiGate RADIUS SSO agent

Once you define a RADIUS SSO (RSSO) agent, the FortiGate unit will accept user logon information from any RADIUS server that has the same shared secret. You can create only one RSSO agent in each VDOM.

Creating the FortiGate RADIUS SSO agent

Before you create the RSSO agent, you need to allow RADIUS accounting information on the interface that connects to the RADIUS server.

To enable RADIUS access on the interface – web-based manager:

1. Go to Network > Interfaces and edit the interface to which the RADIUS server connected.
2. Select Listen for RADIUS Accounting Messages.
3. Select OK.

To enable RADIUS access on the interface – CLI:

In this example, the port2 interface is used.

config system interface edit port2 set allowaccess radius-acct

end

To create a RADIUS SSO agent:

1. Go to [[[Undefined variable FortiOSGUIVariables.User & Device > Single Sign-On]]] and select Create New.
2. In Type, select RADIUS Single-Sign-On Agent.
3. Select Use RADIUS Shared Secret and enter the RADIUS server shared secret.
4. Select Send RADIUS Responses.
5. Select OK.

To create a RADIUS SSO agent – CLI:

config user radius edit RSSO_Agent set rsso enable

set rsso-validate-request-secret enable set rsso-secret <your secret> set rsso-radius-response enable

end

Selecting which RADIUS attributes are used for RSSO

For RADIUS SSO to work, FortiOS needs to know the user’s endpoint identifier (usually IP address) and RADIUS user group. There are default RADIUS attributes where FortiOS expects this information, but you can change these attributes in the config user radius CLI command.

RSSO information and RADIUS attribute defaults

RSSO Information	RADIUS Attribute	CLI field
Endpoint identifier	Calling-Station-ID	rsso-endpoint-attribute

Creating the FortiGate RADIUS SSO agent

RSSO Information	RADIUS Attribute	CLI field
Endpoint block attribute	Called-Station-ID	rsso-endpoint-blockattribute
User group	Class	sso-attribute
User	Prefix	delegated-IPv6-prefix
User	Prefix	framed-IPv6-prefix

The Endpoint block attribute can be used to block or allow a user. If the attribute value is set to the name of an attribute that indicates whether to block or allow, FortiOS blocks or allows respectively all traffic from that user’s IP address. The RSSO fields are visible only when rsso is set to enable.

The Prefix attributes allow for RSSO to provide a /56 prefix for DSL customers. All devices connected from the same location (/56 per subscriber) can be mapped to the same profile without the need to create multiple /64 or smaller entries.

Override SSO attribute

Prior to FortiOS 5.4, when receiving a new start message with a different group name for the same user, and a different IP address such as for a roaming mobile device, the original process was to override all group name information to the latest group name received from the latest start message.

You can disable this override when needed. The default behavior keeps the original design.

To enable or disable overriding SSO attribute – CLI

config user radius edit <name> set rsso <enable>

set sso-attribute-value-override {enable | disable} Enable/disable override of old attribute value with new value for the same endpoint.

Configuring logging for RSSO

In the config user radius CLI command, you can set the following flags in the rsso-log-flags field to determine which types of RSSO-related events are logged:

• protocol-error — A RADIUS protocol error occurred.
• profile-missing — FortiOS cannot find a user group name in a RADIUS start message that matches the name of an RSSO user group in FortiOS.
• accounting-stop-missed — a user context entry expired without FortiOS receiving a RADIUS Stop message. l accounting-event — FortiOS did not find the expected information in a RADIUS record.
• endpoint-block — FortiOS blocked a user because the RADIUS record’s endpoint block attribute had the value

“Block”. l radiusd-other — Other events, described in the log message.

Defining local user groups for RADIUS SSO

Defining local user groups for RADIUS SSO

You cannot use RADIUS user groups directly in security policies. Instead, you create locally-defined user groups on the FortiGate unit and associate each of them with a RADIUS user group.

To define local user groups for RADIUS SSO:

1. Go to User & Device > User Groups and select Create New.
2. Enter a Name for the user group.
3. In Type, select RADIUS Single Sign-On (RSSO).
4. In RADIUS Attribute Value, enter the name of the RADIUS user group this local user group represents.
5. Select OK.

To define local user groups for RADIUS SSO:

This example creates an RSSO user group called RSSO-1 that is associated with RADIUS user group “student”.

config user group edit RSSO-1 set group-type rsso set sso-attribute-value student

end

Creating security policies

RADIUS SSO uses regular identity-based security policies. The RSSO user group you specify determines which users are permitted to use the policy. You can create multiple policies if user groups can have different UTM features enabled, different permitted services, schedules, and so on.

To create a security policy for RSSO – web-based manager:

1. Go to Policy & Objects > IPv4 Policy.
2. Select Create New.
3. Enter the following information.

Incoming Interface	as needed
Source Address	as needed
Source User(s)	Select the user groups you created for RSSO. See Defining local user groups for RADIUS SSO on page 196.
Outgoing Interface	as needed
Destination Address	all

Example – webfiltering for student and teacher accounts

Schedule	as needed
Service	as needed
Action	ACCEPT
Enable NAT	Selected
Security Profiles	Select security profiles appropriate for the user group.

4. Select OK.

To ensure an RSSO-related policy is matched first, the policy should be placed higher in the security policy list than more general policies for the same interfaces.

5. Select OK.

To create a security policy for RSSO – CLI:

In this example, an internal network to Internet policy enables web access for members of a student group and activates the appropriate UTM profiles.

config firewall policy edit 0 set srcintf internal set dstintf wan1 set srcaddr all set dstaddr “all” set action accept set rsso enable set groups “RSSO-student” set schedule always set service HTTP HTTPS set nat enable set utm-status enable set av-profile students set webfilter-profile students set spamfilter-profile students set dlp-sensor default set ips-sensor default set application-list students set profile-protocol-options “default”

end

Example – webfiltering for student and teacher accounts

The following example uses RADIUS SSO to apply web filtering to students, but not to teachers. Assume that the

RADIUS server is already configured to send RADIUS Start and Stop records to the FortiGate unit. There are two RADIUS user groups, students and teachers, recorded in the default attribute Class. The workstations are connected to port1, port2 connects to the RADIUS server, and port3 connects to the Internet.

Example – webfiltering for student and teacher accounts

Configure the student web filter profile:

1. Go to Security Profiles > Web Filter and select Create New (the “+” button).
2. Enter the following and select OK.

Name	student
Inspection Mode	Proxy
FortiGuard Categories	Enable. Right-click the Potentially Liable category and select Block. Repeat for Adult/Mature Content and Security Risk.

Create the RADIUS SSO agent:

1. Go to Security Fabric > Fabric Connectors and select Create New.
2. Under SSO/Identity, select RADIUS Single Sign-On Agent.
3. Enter a name for the RSSO Agent.
4. Enable Use RADIUS Shared Secret and enter the RADIUS server’s shared secret.
5. Enable Send RADIUS Responses.
6. Select OK.

Define local user groups associated with the RADIUS SSO user groups:

1. Go to User & Device > User Groups and select Create New.
2. Enter the following and select OK.

Name	RSSO-students
Type	RADIUS Single Sign-On (RSSO)
RADIUS Attribute Value	students

3. Select Create New, enter the following and select OK.

Name	RSSO-teachers
Type	RADIUS Single Sign-On (RSSO)
RADIUS Attribute Value	teachers

Create a security policy for students:

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter

Incoming Interface	port1
Source Address	all

Example – webfiltering for student and teacher accounts

Source User(s)	RSSO-students
Source Device Type	All
Outgoing Interface	port3
Destination Address	all
Schedule	always
Service	HTTP, HTTPS
Action	ACCEPT
NAT	ON
Security Profiles	Enable AntiVirus, Web Filter, IPS. In Web Filter, select the student profile.

3. Select OK.

Create a security policy for teachers:

1. Go to Policy & Objects > IPv4 Policy and select Create New. 2. Enter

Incoming Interface	port2
Source Address	all
Source User(s)	RSSO-teachers
Source Device Type	All
Outgoing Interface	port3
Destination Address	all
Schedule	always
Service	ALL
Action	ACCEPT
NAT	ON
Security Profiles	Enable AntiVirus and IPS.

3. Select OK.

 

Troubleshooting FSSO

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

Troubleshooting FSSO

Some common Windows AD problems include:

• General troubleshooting tips for FSSO l Users on a particular computer (IP address) cannot access the network l Guest users do not have access to network l Can’t find the DC agent service l 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

l Ensure each computer has separate IP addresses. l Encourage users to logout on one machine before logging onto another machine. l If multiple users have the same username, change the usernames to be unique. l 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.

Troubleshooting

Can’t find the DC agent 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 DCagent.dll exists in Windows\system32
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.

 

Testing FSSO

Once FSSO is configured, you can easily test to ensure your configuration is working as expected. For additional FSSO testing, see Troubleshooting FSSO on page 189.

1. Logon to one of the stations on the FSSO domain, and access an Internet resource.
2. Connect to the CLI of the FortiGate unit, and if possible log the output.
3. Enter the following command: diagnose debug authd fsso list
4. Check the output. If FSSO is functioning properly you will see something similar to the following:

—-FSSO logons—-

IP: 10.10.20.3 User: ADMINISTRATOR Groups: CN=FORTIOS WRITERS,CN=USERS,DC=TECHDOC,DC=LOCAL Workstation: WIN2K8R2.TECHDOC.LOCAL MemberOf: FortiOS_Writers

IP: 10.10.20.7 User: TELBAR Groups: CN=FORTIOS WRITERS,CN=USERS,DC=TECHDOC,DC=LOCAL Workstation: TELBAR-PC7.TECHDOC.LOCAL

Total number of logons listed: 2, filtered: 0

—-end of FSSO logons—-

The exact information will vary based on your installation.

5. Check the FortiGate event log, for FSSO-auth action or other FSSO related events with FSSO information in the message field.
6. To check server connectivity, run the following commands from the CLI:

FGT# diagnose debug enable

FGT# diagnose debug authd fsso server-status

FGT# Server Name Connection Status Version      ———– —————– ——-

techdoc       connected FSSO 5.0.0241

FortiOS FSSO log messages

There are two types of FortiOS log messages — firewall and event. FSSO-related log messages are generated from authentication events. These include user logon and log off events, and NTLM authentication events. These log messages are central to network accounting policies, and can also be useful in troubleshooting issues. For more information on firewall logging, see “Enabling security logging”. For more information on logging, see the FortiOS Handbook Log and Reporting guide.

Enabling authentication event logging

For the FortiGate unit to log events, that specific type of event must be enabled under logging.

When VDOMs are enabled certain options may not be available, such as CPU and memory usage events. You can enable event logs only when you are logged on to a VDOM; you cannot enable event logs globally.

To ensure you log all the events need, set the minimum log level to Notification or Information. Firewall logging requires Notification as a minimum. The closer to Debug level, the more information will be logged. While this extra information is useful, you must

To enable event logging:

1. Go to Log & Report > Log Settings.
2. In Event Logging, select:

System activity event	All system-related events, such as ping server failure and gateway status.
User activity event	All administration events, such as user logins, resets, and configuration updates.

3. Optionally you can enable any or all of the other logging event options.
4. Select Apply.

Authentication log messages

List of FSSO related log messages

Message ID	Severity	Description
43008	Notification	Authentication was successful
43009	Notification	Authentication session failed
43010	Warning	Authentication locked out
43011	Notification	Authentication timed out
43012	Notification	FSSO authentication was successful
43013	Notification	FSSO authentication failed
43014	Notification	FSSO user logged on
43015	Notification	FSSO user logged off
43016	Notification	NTLM authentication was successful
43017	Notification	NTLM authentication failed

 

Using filters

Logon events are detected by the FSSO CA by monitoring the Security Event logs. Additional logon event filters, such as ServiceName and ServiceID, have been implemented so as to avoid instances of conflicting security events, where existing FSSO logon user information could be overwritten and impact user connectivity.

The problem arises when a scenario such as the following occurs:

Testing

1. User1 logs on to PC1 on 1.1.1.1, which is logged as a successful Kerberos logon event with an ID of 4769.
2. The FortiGate creates an authenticated FSSO user log entry for User1/1.1.1.1.
3. User1 then maps a network drive and uses credentials for User2 to logon to the same PC (PC1).
4. The FortiGate sees this as a separate logon to PC1 by a new user, User2. As a result, the log entry is updated to User2/1.1.1.1.
5. If User2 is a member of a different user group to User1 (i.e. has different access permissions), User1 could lose access to their network resources.

The new filter makes the CA ignore the event log created when User1 mapped a network drive, meaning that the original entry for User1 will not be changed.

Configuring FSSO on FortiGate units

To configure your FortiGate unit to operate with agent-based FSSO, you l Configure any access to LDAP servers that might be necessary. Skip this step if you are using FSSO Standard mode. See Configuring LDAP server access on page 181.

• Specify the Collector agent or Novell eDirectory agent that will provide user logon information. See Specifying your collector agents or Novell eDirectory agents on page 183.
• Add Active Directory user groups to FortiGate user groups. See Creating FSSO user groups on page 184. l Create security policies for FSSO-authenticated groups. See Creating security policies on page 185.
• Optionally, specify a guest security policy to allow guest access. See Enabling guest access through FSSO security policies on page 186.

Configuring LDAP server access

LDAP access is required if your network has a Novell eDirectory agent or a Collector agent using Windows Advanced AD access mode. If you are using FSSO Standard mode, go to Specifying your collector agents or Novell eDirectory agents on page 183.

1. Go to User & Device > LDAP Servers and select Create New.
2. Enter the Server IP/Name and Server Port (default 389).
3. In the Common Name Identifier field, enter sAMAccountName.The default common name identifier is cn.

This is correct for most LDAP servers. However some servers use other identifiers such as uid.

4. In the Distinguished Name field, enter your organization distinguished name. In this example, Distinguished Name is dc=techdoc,dc=local
5. Select Fetch DN, this will fetch the Windows AD directory.
6. Set Bind Type to
7. In the User DN field, enter the administrative account name that you created for FSSO. For example, if the account is administrator, enter “administrator@techdoc.local”.
8. Enter the administrative account password in the Password
9. Optionally select Secure Connection.

l In the Protocol field, select LDAPS or STARTTLS. l In the Certificate field, select the appropriate certificate for authentication.

Note that you need to configure the Windows AD for secure connection accordingly.

10. Select OK.
11. Test your configuration by selecting the Test A successful message confirming the right settings appears.

To configure LDAP for FSSO – CLI example:

config user ldap edit LDAP set server 10.10.20.3 set cnid sAMAccountName set dn dc=techdoc,dc=local set type regular

set username administrator@techdoc.local set password <your_password>

next

end

Specifying your collector agents or Novell eDirectory agents

You need to configure the FortiGate unit to access at least one Collector agent or Novell eDirectory agent. You can specify up to five servers on which you have installed a Collector or eDirectory agent. The FortiGate unit accesses these servers in the order that they appear in the list. If a server becomes unavailable, the next one in the list is tried.

To specify Collector agents – web-based manager:

1. Go to Security Fabric > Fabric Connectors and select Create New.
2. Under SSO/Identity, select Fortinet Single Sign-On Agent.
3. Enter a Name for the Windows AD server. This name appears in the list of Windows AD servers when you create user groups.
4. Enter the Server IP/Name and Password of the server where this agent is installed. Maximum name length is 63 characters. For the collector agent, passwords are only required only if you configured the agent to require authenticated access.

If the TCP port used for FSSO is not the default, 8000, you can change the setting in the CLI using the config user fsso command. See Configuring collector agent settings on page 162.

5. Set Collector Agent AD access mode to Advanced, and select the LDAP Server you configured previously. See Configuring LDAP server access on page 181.
6. Select the Users or Groups or Organizational Units tab to select the users, groups, OU that you want to monitor.
7. Select OK.

To specify the FSSO collector agent – CLI:

In this example, the SSO server name is techdoc and the LDAP server is LDAP.

config user fsso edit techdoc set ldap-server LDAP set password <your_password> set server 10.10.20.3 set port 8000

end

Creating FSSO user groups

You cannot use Windows or Novell groups directly in FortiGate security policies. You must create FortiGate user groups of the FSSO type and add Windows or Novell groups to them.

To create a user group for FSSO authentication – web-based manager:

1. Go to User & Device > User Groups.
2. Select Create New.

The New User Group dialog box opens.

3. In the Name box, enter a name for the group, FSSO_Internet_users for example.
4. In Type, select Fortinet Single Sign-On (FSSO).
5. In Members, select the required FSSO
6. Select OK.

To create the FSSO_Internet-users user group – CLI :

config user group edit FSSO_Internet_users set group-type fsso-service

set member CN=Engineering,cn=users,dc=office,dc=example,dc=com

CN=Sales,cn=users,dc=office,dc=example,dc=com end

Creating security policies

Policies that require FSSO authentication are very similar to other security policies. Using identity-based policies, you can configure access that depends on the FSSO user group. This allows each FSSO user group to have its own level of access to its own group of services

In this situation, Example.com is a company that has its employees and authentication servers on an internal network. The FortiGate unit intercepts all traffic leaving the internal network and requires FSSO authentication to access network resources on the Internet. The following procedure configures the security policy for FSSO authentication. FSSO is installed and configured including the RADIUS server, FSSO Collector agent, and user groups on the FortiGate

For the following procedure, the internal interface is port1 and the external interface connected to the Internet is port2. There is an address group for the internal network called company_network. The FSSO user group is called fsso_group, and the FSSO RADIUS server is fsso_rad_server.

To configure an FSSO authentication security policy – web-based manager:

1. Go to Policy & Objects > IPv4 Policy and select Create New.
2. Enter the following information.

Incoming Interface	port1
Source Address	company_network
Source User(s)	fsso_group
Outgoing Interface	port2
Destination Address	all
Schedule	always
Service	HTTP, HTTPS, FTP, and Telnet
Action	ACCEPT
NAT	ON
UTM Security Profiles	ON for AntiVirus, IPS, Web Filter, and Email Filter, all using default profiles.
Log Allowed Traffic	ON. Select Security Events.

3. Select OK.
4. Ensure the FSSO authentication policy is higher in the policy list than more general policies for the same interfaces.

To create a security policy for FSSO authentication – CLI:

config firewall policy edit 0 set srcintf port1

set dstintf port2 set srcaddr company_network

set dstaddr all set action accept set groups fsso_group set schedule always set service HTTP HTTPS FTP TELNET set nat enable

end

Here is an example of how this FSSO authentication policy is used. Example.com employee on the internal company network logs on to the internal network using their RADIUS username and password. When that user attempts to access the Internet, which requires FSSO authentication, the FortiGate authentication security policy intercepts the session, checks with the FSSO Collector agent to verify the user’s identity and credentials, and then if everything is verified the user is allowed access to the Internet.

Users belonging to multiple groups

Before FSSO 4.0 MR3, if a user belonged to multiple user groups, the first security policy to match any group that user belonged too was the only security policy applied. If that specific group did not have access to this protocol or resource where another group did, the user was still denied access. For example, test_user belongs to group1 and group2. There are two FSSO authentication policies — one matches group1 to authenticate FTP traffic and one matches group2 to authenticate email traffic. The group1 policy is at the top of the list of policies. If test_user wants to access an email server, the first policy encountered for a group test_user belongs to is the group1 policy which does not allow email access and test_user is denied access. This is despite the next policy allowing access to email. If the order was reversed in this case, the traffic would be matched and the user’s traffic would be allowed through the firewall. However if the policy order was reversed, FTP traffic would not be matched.

As of FSSO 4.0 MR3, if a user belongs to multiple groups multiple then attempts to match the group are attempted if applicable. Using the above example, when the attempt to match the group1 policy is made and fails, the next policy with a group that test_user is a member of is attempted. In this case, the next policy is matched and access is granted to the email server.

When configuring this example the only difference between the policies is the services that are listed and the FSSO user group name.

Authenticating through multiple groups allows administrators to assign groups for specific services, and users who are members of each group have access to those services. For example there could be an FTP group, an email group, and a Telnet group.

Enabling guest access through FSSO security policies

You can enable guest users to access FSSO security policies. Guests are users who are unknown to the Windows AD or Novell network and servers that do not logon to a Windows AD domain.

To enable guest access in your FSSO security policy, add an identity-based policy assigned to the built-in user group SSO_Guest_Users. Specify the services, schedule and protection profile that apply to guest users — typically guests receive reduced access to a reduced set of services.

IPv6 support for FSSO

FortiGate FSSO supports connecting to an FSSO agent over IPv6 and collecting and sending IPv6 details about endpoints. This is enforced in the same manner as IPv4 FSSO traffic.

Syntax

config user fsso edit <fsso agent name>

set source-ip6 <IPv6 address for source>

end