Examples and Troubleshooting

This chapter provides an example of a FortiGate unit providing authenticated access to the Internet for both Windows network users and local users. The following topics are included in this section:

• Firewall authentication example
• LDAP Dial-in using member-attribute example
• RADIUS SSO example
• Troubleshooting

Firewall authentication example

Example configuration

Overview

In this example, there is a Windows network connected to Port 2 on the FortiGate unit and another LAN, Network_1, connected to Port 3.

All Windows network users authenticate when they logon to their network. Members of the Engineering and Sales groups can access the Internet without entering their authentication credentials again. The example assumes that the Fortinet Single Sign On (FSSO) has already been installed and configured on the domain controller.

LAN users who belong to the Internet_users group can access the Internet after entering their username and password to authenticate. This example shows only two users, User1 is authenticated by a password stored on the FortiGate unit, User2 is authenticated on an external authentication server. Both of these users are referred to as local users because the user account is created on the FortiGate unit.

Creating a locally-authenticated user account

User1 is authenticated by a password stored on the FortiGate unit. It is very simple to create this type of account.

To create a local user – web-based manager:

1. Go to User & Device > User Definition and select Create New.
2. Follow the User Creation Wizard, entering the following information and then select Create:

User Type	Local User
User Name	User1
Password	hardtoguess
Email Address SMS	(optional)
Enable	Select.

To create a local user – CLI:

config user local edit user1 set type password set passwd hardtoguess

end

Creating a RADIUS-authenticated user account

To authenticate users using an external authentication server, you must first configure the FortiGate unit to access the server.

To configure the remote authentication server – web-based manager:

1. Go to User & Device > RADIUS Servers and select Create New.
2. Enter the following information and select OK:

Name	OurRADIUSsrv
Primary Server Name/IP	10.11.101.15
Primary Server Secret	OurSecret
Authentication Scheme	Select Use Default Authentication Scheme.

To configure the remote authentication server – CLI:

config user radius edit OurRADIUSsrv set server 10.11.102.15 set secret OurSecret set auth-type auto

Firewall authentication example

end

Creation of the user account is similar to the locally-authenticated account, except that you specify the RADIUS authentication server instead of the user’s password.

To configure a remote user – web-based manager:

1. Go to User & Device > User Definition and select Create New.
2. Follow the User Creation Wizard, entering the following information and then select Create:

User Type	Remote RADIUS User
User Name	User2
RADIUS server	OurRADIUSsrv
Email Address SMS	(optional)
Enable	Select

To configure a remote user – CLI:

config user local edit User2 set name User2 set type radius

set radius-server OurRADIUSsrv

end

Creating user groups

There are two user groups: an FSSO user group for FSSO users and a firewall user group for other users. It is not possible to combine these two types of users in the same user group.

Creating the FSSO user group

For this example, assume that FSSO has already been set up on the Windows network and that it uses Advanced mode, meaning that it uses LDAP to access user group information. You need to

• configure LDAP access to the Windows AD global catalog l specify the collector agent that sends user logon information to the FortiGate unit l select Windows user groups to monitor
• select and add the Engineering and Sales groups to an FSSO user group

To configure LDAP for FSSO – web-based manager:

1. Go to User & Device > LDAP Servers and select Create New.
2. Enter the following information:

Name	ADserver
Server Name / IP		10.11.101.160
Distinguished Name		dc=office,dc=example,dc=com
Bind Type		Regular
User DN		cn=FSSO_Admin,cn=users,dc=office,dc=example,dc=com
Password		set_a_secure_password

3. Leave other fields at their default values.
4. Select OK.

To configure LDAP for FSSO – CLI”

config user ldap edit “ADserver” set server “10.11.101.160”

set dn “cn=users,dc=office,dc=example,dc=com”

set type regular

set username “cn=administrator,cn=users,dc=office,dc=example,dc=com” set password set_a_secure_password

next

end

To specify the collector agent for FSSO – web-based manager

1. Go to User & Device > Single Sign-On and select Create New.
2. Enter the following information:

Type	Fortinet Single Sign-On Agent
Name	WinGroups
Primary Agent IP/Name	10.11.101.160
Password	fortinet_canada
LDAP Server	ADserver

3. Select Apply & Refresh.

In a few minutes, the FortiGate unit downloads the list of user groups from the server.

To specify the collector agent for FSSO – CLI:

config user fsso edit “WinGroups” set ldap-server “ADserver” set password ENC

G7GQV7NEqilCM9jKmVmJJFVvhQ2+wtNEe9T0iYA5Sa+EqT2J8zhOrbkJFDr0RmY3c4LaoXdsoBczA

1dONmcGfthTxxwGsigzGpbJdC71spFlQYtj set server “10.11.101.160” end

Firewall authentication example

To create the FSSO_Internet-users user group – web-based manager:

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

Name	FSSO_Internet_users
Type	Fortinet Single Sign-On (FSSO)
Members	Engineering, Sales

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 the Firewall user group

The non-FSSO users need a user group too. In this example, only two users are shown, but additional members can be added easily.

To create the firewall user group – web-based manager:

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

Name	Internet_users
Type	Firewall
Members	User1, User2

To create the firewall user group – CLI:

config user group edit Internet_users set group-type firewall set member User1 User2

end

Defining policy addresses

1. Go to Policy & Objects > Addresses.
2. Create the following addresses:

Address Name	Internal_net
Type		Subnet
Subnet / IP Range		10.11.102.0/24
Interface		Port 3
Address Name		Windows_net
Type		Subnet
Subnet / IP Range		10.11.101.0/24
Interface		Port 2

Creating security policies

Two security policies are needed: one for firewall group who connect through port3 and one for FSSO group who connect through port2.

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

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

Incoming Interface	Port2
Source Address	Windows_net
Source User(s)	FSSO_Internet_users
Outgoing Interface	Port1
Destination Address	all
Schedule	always
Service	ALL
NAT	ON
Security Profiles	Optionally, enable security profiles.

3. Select OK.

To create a security policy for FSSO authentication – CLI:

config firewall policy edit 0 set srcintf port2 set dstintf port1 set srcaddr Windows_net set dstaddr all

LDAP Dial-in using member-attribute example

set action accept set groups FSSO_Internet_users set schedule always set service ANY set nat enable

end

To create a security policy for local user authentication – web-based manager

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

Incoming Interface	Port3
Source Address	Internal_net
Source User(s)	Internet_users
Outgoing Interface	Port1
Destination Address	all
Schedule	always
Service	ALL
NAT	ON
Security Profiles	Optionally, enable security profiles.

3. Select OK.

To create a security policy for local user authentication – CLI

config firewall policy edit 0 set srcintf port3 set dstintf port1 set srcaddr internal_net set dstaddr all set action accept set schedule always set groups Internet_users set service ANY set nat enable

end

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!

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:

• Monitoring firewall users
• Monitoring SSL VPN users
• Monitoring IPsec VPN users
• 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.

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!

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

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

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!

Agent-based FSSO

FortiOS can provide single sign-on capabilities to Windows AD, Citrix, Novell eDirectory, or, as of FortiOS 5.4, Microsoft Exchange users with the help of agent software installed on these networks. The agent software sends information about user logons to the FortiGate unit. With user information such as IP address and user group memberships from the network, FortiGate security policies can allow authenticated network access to users who belong to the appropriate user groups without requesting their credentials again.

For Windows AD networks, FortiGate units can provide SSO capability without agent software by directly polling the Windows AD domain controllers. For information about this type of SSO, seeSingle Sign-On to Windows AD on page 133.

The following topics are included:

• Introduction to agent-based FSSO
• FSSO NTLM authentication support
• Agent installation
• Configuring the FSSO Collector agent for Windows AD
• Configuring the FSSO TS agent for Citrix
• Configuring FSSO with Novell networks
• Configuring FSSO Advanced Settings
• Configuring FSSO on FortiGate units
• FortiOS FSSO log messages
• Testing FSSO
• Troubleshooting FSSO

Introduction to agent-based FSSO

Fortinet Single Sign-On (FSSO), through agents installed on the network, monitors user logons and passes that information to the FortiGate unit. When a user logs on at a workstation in a monitored domain, FSSO

l detects the logon event and records the workstation name, domain, and user, l resolves the workstation name to an IP address, l determines which user groups the user belongs to, l sends the user logon information, including IP address and groups list, to the FortiGate unit l creates one or more log entries on the FortiGate unit for this logon event as appropriate.

When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. If the user belongs to one of the permitted user groups associated with that policy, the connection is allowed. Otherwise the connection is denied.

FSSO can also provide NTLM authentication service for requests coming from FortiGate. SSO is very convenient for users, but may not be supported across all platforms. NTLM is not as convenient, but it enjoys wider support. See FSSO NTLM authentication support on page 148.

Introduction to FSSO agents

There are several different FSSO agents that can be used in an FSSO implementation:

• Domain Controller (DC) agent
• eDirectory agent
• Citrix/Terminal Server (TS) agent
• Collector (CA) agent

Consult the latest FortiOS and FSSO Release Notes for operating system compatibility information.

Domain Controller (DC) agent

The Domain Controller (DC) agent must be installed on every domain controller if you will use DC Agent mode, but is not required if you use Polling mode. See FSSO for Windows AD on page 144.

eDirectory agent

The eDirectory agent is installed on a Novell network to monitor user logons and send the required information to the FortiGate unit. It functions much like the Collector agent on a Windows AD domain controller.The agent can obtain information from the Novell eDirectory using either the Novell API or LDAP.

Citrix/Terminal Server (TS) agent

The Citrix/Terminal Server (TS) agent is installed on a Citrix terminal server to monitor user logons in real time. It functions much like the DC Agent on a Windows AD domain controller.

Collector (CA) agent

This agent is installed as a service on a server in the Windows AD network to monitor user logons and send the required information to the FortiGate unit. The Collector agent can collect information from

• Domain Controller agent (Windows AD)
• TS agent (Citrix Terminal Server)

In a Windows AD network, the Collector agent can optionally obtain logon information by polling the AD domain controllers. In this case, DC agents are not needed.

The Collector can obtain user group information from the DC agent or optionally, a FortiGate unit can obtain group information directly from AD using Lightweight Directory Access Protocol (LDAP).

On a Windows AD network, the FSSO software can also serve NT LAN Manager (NTLM) requests coming from client browsers (forwarded by the FortiGate unit) with only one or more Collector agents installed. See FSSO NTLM authentication support on page 148.

The CA is responsible for DNS lookups, group verification, workstation checks, and as mentioned FortiGate updates of logon records. The FSSO Collector Agent sends Domain Local Security Group and Global Security Group information to FortiGate units. The CA communicates with the FortiGate over TCP port 8000 and it listens on UDP port 8002 for updates from the DC agents.

The FortiGate unit can have up to five CAs configured for redundancy. If the first on the list is unreachable, the next is attempted, and so on down the list until one is contacted. See Configuring FSSO on FortiGate units on page 175.

All DC agents must point to the correct Collector agent port number and IP address on domains with multiple DCs.

A FortiAuthenticator unit can act much like a Collector agent, collecting Windows AD user logon information and sending it to the FortiGate unit. It is particularly useful in large installations with several FortiGate units. For more information, see the FortiAuthenticator Administration Guide.

FSSO for Microsoft Exchange Server

As of FortiOS 5.4, FSSO supports monitoring Microsoft Exchange Server. This is useful for situations when the user accesses the domain account to view their email, even when the client device might not be in the domain.

Support for the Exchange server is configured on the Back-end FSSO collector agent. For more information on the collector agent, see Collector agent installation:

1. On the FSSO collector agent, go to Advanced Settings > Exchange Server.
2. Select Add and enter the following information and select OK:

Domain Name	Enter your domain name.
Server IP/Hostname	Enter the IP address or the hostname of your exchange server.
Polling forwarded event log	This option for scenarios when you do not want that CA polls the Exchange Server logs directly. In this case you need to configure event log forwarding on the Exchange server. Exchange event logs can be forwarded to any member server. If you enable this, instead of the IP of the Exchange server configured in the previous step, you must then configure the IP of this member server. CA will then contact the member server.
Ignore Name	Because CA will also check Windows log files for logon events and when a user authenticates to Exchange Server there is also a logon event in Windows event log, which CA will read and this will overwrite the Exchange Server logon event (ESEventLog) on CA. So it is recommended to set the ignore list to the domain the user belongs to. To do so, enter the domain name in the Ignore Name field and select Add.

FSSO for Windows AD

FSSO for Windows AD requires at least one Collector agent. Domain Controller agents may also be required depending on the Collector agent working mode. There are two working modes to monitor user logon activity: DC Agent mode or Polling mode.

Collector agent DC Agent mode versus Polling mode

	DC Agent mode	Polling Mode
Installation	Complex — Multiple installations: one agent per DC plus Collector agent, requires a reboot	Easy — Only Collector agent installation, no reboot required
Resources	Shares resources with DC system	Has own resources
Network load	Each DC agent requires minimum 64kpbs bandwidth, adding to network load	Increase polling period during busy period to reduce network load
Level of Confidence	Captures all logons	Potential to miss a login if polling period is too great

DC Agent mode

DC Agent mode is the standard mode for FSSO. In DC Agent mode, a Fortinet authentication agent is installed on each domain controller. These DC agents monitor user logon events and pass the information to the Collector agent, which stores the information and sends it to the FortiGate unit.

The DC agent installed on the domain controllers is not a service like the Collector agent — it is a DLL file called dcagent.dll and is installed in the Windows\system32 directory. It must be installed on all domain controllers of the domains that are being monitored.

FSSO in DC agent mode

DC Agent mode provides reliable user logon information, however you must install a DC agent on every domain controller. A reboot is needed after the agent is installed. Each installation requires some maintenance as well. For these reasons it may not be possible to use the DC Agent mode.

Each domain controller connection needs a minimum guaranteed 64kpbs bandwidth to ensure proper FSSO functionality. You can optionally configure traffic shapers on the FortiGate unit to ensure this minimum bandwidth is guaranteed for the domain controller connections.

Introduction to agent-based

Polling mode

In Polling mode there are three options — NetAPI polling, Event log polling, and Event log using WMI. All share the advantages of being transparent and agentless.

NetAPI polling is used to retrieve server logon sessions. This includes the logon event information for the Controller agent. NetAPI runs faster than Event log polling but it may miss some user logon events under heavy system load. It requires a query round trip time of less than 10 seconds.

Event log polling may run a bit slower, but will not miss events, even when the installation site has many users that require authentication. It does not have the 10 second limit on NetAPI polling. Event log polling requires fast network links. Event log polling is required if there are Mac OS users logging into Windows AD.

Event log using WMI polling: WMI is a Windows API to get system information from a Windows server, CA is a WMI client and sends WMI queries for user logon events to DC, which in this case is a WMI server. Main advantage in this mode is that CA does not need to search security event logs on DC for user logon events, instead, DC returns all requested logon events via WMI. This also reduces network load between CA and DC.

In Polling mode, the Collector agent polls port 445 of each domain controller for user logon information every few seconds and forwards it to the FortiGate unit. There are no DC Agents installed, so the Collector agent polls the domain controllers directly.

FSSO in Polling mode

A major benefit of Polling mode is that no FSSO DC Agents are required. If it is not possible to install FSSO DC Agents on your domain controllers, this is the alternate configuration available to you. Polling mode results in a less complex install, and reduces ongoing maintenance. The minimum permissions required in Polling mode are to read the event log or call NetAPI.

Collector agent AD Access mode – Standard versus Advanced

The Collector agent has two ways to access Active Directory user information. The main difference between Standard and Advanced mode is the naming convention used when referring to username information.

Standard mode uses regular Windows convention: Domain\Username. Advanced mode uses LDAP convention: CN=User, OU=Name, DC=Domain.

If there is no special requirement to use LDAP— best practices suggest you set up FSSO in Standard mode. This mode is easier to set up, and is usually easier to maintain and troubleshoot.

Standard and advanced modes have the same level of functionality with the following exceptions:

• Users have to create Group filters on the Collector agent. This differs from Advanced mode where Group filters are configured from the FortiGate unit. Fortinet strongly encourages users to create filters from CA.
• Advanced mode supports nested or inherited groups. This means that users may be a member of multiple monitored groups. Standard mode does not support nested groups so a user must be a direct member of the group being monitored.

FSSO for Citrix

Citrix users can enjoy a similar Single Sign-On experience as Windows AD users. The FSSO TS agent installed on each Citrix server provides user logon information to the FSSO Collector agent on the network. The FortiGate unit uses this information to authenticate the user in security policies.

Citrix SSO topology

Citrix users do not have unique IP addresses. When a Citrix user logs on, the TS agent assigns that user a range of ports. By default each user has a range of 200 ports.

FSSO for Novell eDirectory

FSSO in a Novell eDirectory environment works similar to the FSSO Polling mode in the Windows AD environment. The eDirectory agent polls the eDirectory servers for user logon information and forwards the information to the FortiGate unit. There is no need for the Collector agent.

When a user logs on at a workstation, FSSO:

• detects the logon event by polling the eDirectory server and records the IP address and user ID, l looks up in the eDirectory which groups this user belongs to,

 

FSSO NTLM authentication support

• sends the IP address and user groups information to the FortiGate unit.

When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. If the user belongs to one of the permitted user groups, the connection is allowed.

FSSO is supported on the Novell E-Directory 8.8 operating system.

For a Novell network, there is only one FSSO component to install — the eDirectory agent. In some cases, you also need to install the Novell Client.

FSSO security issues

When the different components of FSSO are communicating there are some inherent security features.

FSSO installation requires an account with network admin privileges. The security inherent in these types of accounts helps ensure access to FSSO configurations is not tampered with.

User passwords are never sent between FSSO components. The information that is sent is information to identify a user including the username, group or groups, and IP address.

NTLM uses base-64 encoded packets, and uses a unique randomly generated challenge nonce to avoid sending user information and password between the client and the server.

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!