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:

l Firewall authentication example l LDAP dial-in using member-attribute example l RADIUS SSO example l 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

Firewall authentication

set auth-type auto

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		Enter 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 Security Fabric > Fabric Connectors and select Create New.
2. Under SSO/Identity, select Fortinet Single Sign-On Agent.
3. Enter a Name (in this example, WinGroups) 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 (in this example, 10.11.101.160) and Password (in this example, fortinet_canada) 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 See Examples and troubleshooting on page 203.
5. Set Collector Agent AD access mode to Advanced, and select the LDAP Server (in this example, ADserver) you configured previously. See Examples and troubleshooting on page 203.
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 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

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

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

LDAP dial-in using member-attribute example

In this example, users defined in MicroSoft Windows Active Directory (AD) are allowed to set up a VPN connection simply based on an attribute that is set to TRUE, instead of based on their user group. In AD the “Allow Dialin” property is activated in the user properties, and this sets the msNPAllowDialin attribute to “TRUE”.

 

LDAP dial-in using member-attribute example

This same procedure can be used for other member attributes, as your system requires.

To accomplish this with a FortiGate unit, member-attribute must be set. This can only be accomplished through the CLI – the option is not available through the web-based manager.

Before configuring the FortiGate unit, ensure the AD server has the msNPAllowDialin attribute set to “TRUE” for the users in question. If not, those users will not be able to authenticate.

To configure user LDAP member-attribute settings – CLI:

config user ldap edit “ldap_server” set server “192.168.201.3” set cnid “sAMAccountName” set dn “DC=fortilabanz,DC=com,DC=au” set type regular

set username “fortigate@sample.com” set password ****** set member-attr “msNPAllowDialin”

next

end

To configure LDAP group settings – CLI:

config user group edit “ldap_grp” set member “ldap” config match edit 1 set server-name “ldap” set group-name “TRUE”

next

end

next

end

Once these settings are in place, users that are a member of the ldap user group will be able to authenticate.

To ensure your settings are correct, here is the sample output from a diag debug command that shows the authentication process.

When the “Allow Dial-in” attribute is set to “TRUE” the following will likely be in the output:

get_member_of_groups-Get the memberOf groups. get_member_of_groups- attr=’msNPAllowDialin’, found 1 values

get_member_of_groups-val[0]=’TRUE’ fnbamd_ldap_get_result-Auth accepted fnbamd_ldap_get_result-Going to DONE state res=0

fnbamd_auth_poll_ldap-Result for ldap svr 192.168.201.3 is SUCCESS fnbamd_auth_poll_ldap-Passed group matching

If the attribute is not set but it is expected, the following will likely be in the output:

get_member_of_groups-Get the memberOf groups. get_member_of_groups- attr=’msNPAllowDialin’, found 1 values

get_member_of_groups-val[0]=’FALSE’ fnbamd_ldap_get_result-Auth accepted fnbamd_ldap_get_result-Going to DONE state res=0

fnbamd_auth_poll_ldap-Result for ldap svr 192.168.201.3 is SUCCESS fnbamd_auth_poll_ldap-Failed group matching

The only difference between these two outputs is the last line which is either passed or failed based on if the member-attribute is set to the expected value or not.

RADIUS SSO example

A common RADIUS SSO topology involves a medium sized company network of users connecting to the Internet through the FortiGate unit, and authenticating with a RADIUS server. RADIUS SSO authentication was selected because it is fast and relatively easy to configure.

This section includes:

l Assumptions l Topology l Configuring RADIUS l Configuring FortiGate regular and RADIUS SSO security policies l Testing

Assumptions

• VDOMs are not enabled. l The admin super_admin administrator account will be used for all FortiGate unit configuration. l Any other devices on the network do not affect the topology of this example, and therefore are not included. l Anywhere settings are not described, they are assumed to be default values. l A RADIUS server is installed on a server or FortiAuthenticator unit and uses default attributes.
• BGP is used for any dynamic routing. l Authentication event logging under Log & Report has been configured.

Topology

Example.com has an office with 20 users on the internal network. These users need access to the Internet to do their jobs. The office network is protected by a FortiGate-60C unit with access to the Internet through the wan1 interface, the user network on the internal interface, and all the servers are on the DMZ interface. This includes an Ubuntu Linux server running FreeRADIUS. For this example only two users will be configured — Pat Lee with an account name plee, or plee@example.com, and Kelly Green with an account name kgreen, or kgreen@example.com.

RADIUS SSO topology

Configuring RADIUS

Configuring RADIUS includes configuring the RADIUS server such as FreeRADIUS, a radius client on user’s computers, and configuring users in the system. For this example the two users will be Pat Lee, and Kelly Green. They belong to a group called exampledotcom_employees. When it is all configured, the RADIUS daemon needs to started.

The users have a RADIUS client installed on their PCs that allows them to authenticate through the RADIUS server.

FreeRADIUS can be found on the freeradius.org website. For any problems installing FreeRADIUS, see the FreeRADIUS documentation.

Configuring FortiGate interfaces

Before configuring the RADIUS SSO security policy, configure FortiGate interfaces. This includes defining a DHCP server for the internal network as this type of network typically uses DHCP. The wan1 and dmz interfaces are assigned static IP addresses and do not need a DHCP server.

FortiGate interfaces used in this example

Interface	Subnet	Act as DHCP Server	Devices
wan1	172.20.120.141	No	Internet Service Provider
dmz	10.11.101.100	No	Servers, including RADIUS server
internal	10.11.102.100	Yes: x.x.x.110-.250	Internal user network

To configure FortiGate interfaces – web-based manager:

1. Go to Network > Interfaces.
2. Select wan1 to edit.
3. Enter the following information and select OK.

Alias	Internet
Addressing Mode	Manual
IP/Network Mask	172.20.120.141/255.255.255.0
Administrative Access	HTTPS, SSH
Enable DHCP Server	Not selected
Comments	Internet
Administrative Status	Up

4. Select dmz to edit.
5. Enter the following information and select OK.

Alias	Servers
Addressing Mode	Manual
IP/Network Mask	10.11.101.100/255.255.255.0
Administrative Access	HTTPS, SSH, PING, SNMP
Enable DHCP Server	Not selected
Listen for RADIUS Accounting Messages	Select
Comments	Servers
Administrative Status	Up

6. Select internal to edit.
7. Enter the following information and select OK.

Alias	Internal network
Addressing Mode	Manual
IP/Network Mask	10.11.102.100/255.255.255.0
Administrative Access	HTTPS, SSH, PING
Enable DHCP Server	Select
Address Range	10.11.102.110 – 10.11.102.250
Netmask	255.255.255.0
Default Gateway	Same as Interface IP
DNS Server	Same as System DNS
Comments	Internal network
Administrative Status	Up

Configuring a RADIUS SSO agent on the FortiGate unit

To create a 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.

Creating a RADIUS SSO user group

To define a local user group 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.

Configuring FortiGate regular and RADIUS SSO security policies

With the RADIUS server and FortiGate interfaces configured, security policies can be configured. This includes both RADIUS SSO and regular policies, as well as addresses and address groups. All policies require NAT to be enabled.

Security policies required for RADIUS SSO

Seq. No.		From -> To	Type	Schedule	Description
1		internal -> wan1	RADIUS SSO	business hours	Authenticate outgoing user traffic.
2		internal -> wan1	regular	always	Allow essential network services and VoIP.
3		dmz -> wan1	regular	always	Allow servers to access Internet.
Seq. No.	From -> To		Type	Schedule		Description
4	internal -> dmz		regular	always		Allow users to access servers.
5	any -> any		deny	always		Implicit policy denying all traffic that hasn’t been matched.

The RADIUS SSO policy must be placed at the top of the policy list so it is matched first. The only exception to this is if you have a policy to deny access to a list of banned users. In this case, that policy must go at the top so the RADIUS SSO does not mistakenly match a banned user or IP address.

This section includes:

l Schedules, address groups, and services groups l Configuring regular security policies l Configuring RADIUS SSO security policy

Schedules, address groups, and services groups

This section lists the lists that need to be configured before security policies are created. Creating these lists is straight forward, so the essential information has been provided here but not step by step instructions. For more information on firewall related details, see

Schedules

Only one schedule needs to be configured — business_hours. This is a fairly standard Monday to Friday 8am to 5pm schedule, or whatever days and hours covers standard work hours at the company.

Address groups

The following address groups need to be configured before the security policies.

Address Group Name	Interface	Address range included
internal_network	internal	10.11.102.110 to 10.11.102.250
company_servers	dmz	10.11.101.110 to 10.11.101.250

Service groups

The following service groups need to be configured before the security policies. Note that the services listed are suggestions and may include more or less as required.

Service Group Name	Interface	Description of services to be included
essential_network_services	internal	Any network protocols required for normal network operation such as DNS, NTP, BGP.
essential_server_services	dmz	All the protocols required by the company servers such as BGP, HTTP, HTTPS, FTP, IMAP, POP3, SMTP, IKE, SQL, MYSQL, NTP, TRACEROUTE, SOCKs, and SNMP.
user_services	internal	Any protocols required by users HTTP, HTTP, FTP,

The following security policy configurations are basic and only include logging, and default AV and IPS.

Configuring regular security policies

Regular security policies allow or deny access for non-RADIUS SSO traffic. This is essential as there are network services—such as DNS, NTP, and FortiGuard—that require access to the Internet.

To configure regular security policies – web-based manager:

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

Incoming Interface	Internal
Source Address	internal_network
Outgoing Interface	wan1
Destination Address	all
Schedule	always
Service	essential_network_services
Action	ACCEPT
NAT	ON
Security Profiles	ON: AntiVirus, IPS
Log Allowed Traffic	ON
Comments	Essential network services

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

Incoming Interface		dmz
Source Address		company_servers
Outgoing Interface		wan1
Destination Address		all
Schedule		always
Service		essential_server_services
Action		ACCEPT
NAT		ON
Security Profiles		ON: AntiVirus, IPS
Log Allowed Traffic		enable
Comments		Company servers accessing the Internet

4. Select Create New, enter the following information, and select OK.

Incoming Interface	Internal
Source Address	internal_network
Outgoing Interface	dmz
Destination Address	company_servers
Schedule	always
Service	all
Action	ACCEPT
NAT	ON
Security Profiles	ON: AntiVirus, IPS
Log Allowed Traffic	enable
Comments	Access company servers

Configuring RADIUS SSO security policy

The RADIUS SSO policy allows access for members of specific RADIUS groups.

To configure RADIUS SSO security policy:

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

Incoming Interface	Internal
Source Address	internal_network
Source User(s)	Select the user groups you created for RSSO.
Outgoing Interface	wan1
Destination Address	all
Schedule	business_hours
Service	ALL
Action	ACCEPT
NAT	ON
Security Profiles	ON: AntiVirus, Web Filter, IPS, and Email Filter. In each case, select the default profile.

4. Select OK.
5. 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.
6. Select OK.

Testing

Once configured, a user only needs to log on to their PC using their RADIUS account. After that when they attempt to access an Internet website, the FortiGate unit will use their session information to get their RADIUS information. Once the user is verified, they are allowed access to the website.

To test the configuration perform the following steps:

1. Have user ‘plee’ logon to their PC, and try to access an Internet website.
2. The FortiGate unit will contact the RADUS server for user plee’s information. Once confirmed, plee will have access to the website.

Each step generates log entries that enable you to verify that each step was successful.

3. If a step is unsuccessful, confirm that your configuration is correct.

 

Troubleshooting

RADIUS SSO test

Troubleshooting

In the web-based manager, a good tool for troubleshooting is the packet counter column on the security policy page at Policy & Objects > IPv4 Policy. This column displays the number of packets that have passed through this security policy. Its value when you are troubleshooting is that when you are testing your configuration (end to end connectivity, user authentication, policy use) watching the packet count for an increase confirms any other methods you may be using for troubleshooting. It provides the key of which policy is allowing the traffic, useful information if you expect a user to require authentication and it never happens.

This section addresses how to get more information from the CLI about users and user authentication attempts to help troubleshoot failed authentication attempts. diag firewall iprope list

Shows the IP that the computer connected from. This is useful to confirm authorization and VPN settings.

diag firewall iprope clear

Clear all authorized users from the current list. Useful to force users to re-authenticate after system or group changes. However, this command may easily result in many users having to re-authenticate, so use carefully.

diag rsso query ip diag rsso query rsso-key

Queries the RSSO database.

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