Tag Archives: fortinet best place to work

Monitoring authenticated users

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 User & Device > Monitor > Firewall.

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

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

 

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 VPN > 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:

SSO using RADIUS accounting records

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 emits. 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
  • Configuration Overview
  • Configuring the RADIUS server
  • 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

 

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

 

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.

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 System > 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 User & Device > Authentication > 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.

IPsec VPNs and certificates

IPsec VPNs and certificates

Certificate authentication is a more secure alternative to preshared key (shared secret) authentication for IPsec VPN peers. Unlike administrators or SSL VPN users, IPsec peers use HTTP to connect to the VPN gateway configured on the FortiGate unit. The VPN gateway configuration can require certificate authentication before it permits an IPsec tunnel to be established. See Authenticating IPsec VPN users with security certificates on page 535 .

 

Certificate types on the FortiGate unit

There are different types of certificates available that vary depending on their intended use. FortiOS supports local, remote, CA, and CRL certificates.

 

Local certificates

Local certificates are issued for a specific server, or web site. Generally they are very specific, and often for an internal enterprise network. For example a personal web site for John Smith at www.example.com (such as http://www.example.com/home/jsmith) would have its own local certificate.

These can optionally be just the certificate file, or also include a private key file and PEM passphrase for added security.

For information about generating a certificate request, see Generating a certificate signing request on page 526. For information about installing a local certificate, see Obtaining and installing a signed server certificate from an external CA on page 529

 

Remote certificates

Remote certificates are public certificates without a private key. For dynamic certificate revocation, you need to use an Online Certificate Status Protocol (OCSP) server. The OCSP is configured in the CLI only. Installed Remote (OCSP) certificates are displayed in the Remote Certificates list. You can select Import to install a certificate from the management PC.

 

CA root certificates

CA root certificates are similar to local certificates, however they apply to a broader range of addresses or to whole company; they are one step higher up in the organizational chain. Using the local certificate example, a CA root certificate would be issued for all of www.example.com instead of just the smaller single web page.

 

Certificate revocation list

Certificate revocation list (CRL) is a list of certificates that have been revoked and are no longer usable. This list includes certificates that have expired, been stolen, or otherwise compromised. If your certificate is on this list, it will not be accepted. CRLs are maintained by the CA that issues the certificates and includes the date and time when the next CRL will be issued as well as a sequence number to help ensure you have the most current version of the CRL.

 

Certificate signing

The trust in a certificate comes from the authority that signs it. For example if VeriSign signs your CA root certificate, it is trusted by everyone. While these certificates are universally accepted, it is cumbersome and expensive to have all certificates on a corporate network signed with this level of trust.

With self-signed certificates nobody, except the other end of your communication, knows who you are and therefore they do not trust you as an authority. However this level is useful for encryption between two points — neither point may care about who signed the certificate, just that it allows both points to communicate. This is very useful for internal networks and communications.

A general rule is that CA signed certificates are accepted and sometimes required, but it is easier to self-sign certificates when you are able.

For more on the methods of certificate signing see Generating a certificate signing request on page 526.

 

Troubleshooting FSSO

Troubleshooting FSSO

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

Some common Windows AD problems include:

  • General troubleshooting tips for FSSO
  • Users on a particular computer (IP address) can not access the network
  • Guest users do not have access to network

 

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

  • Ensure there is at least 64kbps bandwidth between the FortiGate unit and domain controllers. If there is insufficient bandwidth, some FSSO information might not reach the FortiGate unit. The best solution is to configure traffic shaping between the FortiGate unit and the domain controllers to ensure that the minimum bandwidth is always available.

 

Users on a particular computer (IP address) can not access the network

Windows AD Domain Controller agent gets the username and workstation where the logon attempt is coming from. If there are two computers with the same IP address and the same user trying to logon, it is possible for the authentication system to become confused and believe that the user on computer_1 is actually trying to access computer_2.

Windows AD does not track when a user logs out. It is possible that a user logs out on one computer, and immediate logs onto a second computer while the system still believes the user is logged on the original computer. While this is allowed, information that is intended for the session on one computer may mistakenly end up going to the other computer instead. The result would look similar to a hijacked session.

 

Solutions

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

 

Guest users do not have access to network

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

 

Solution

The group of the guest users was not included in a policy, so they do not fall under the guest account. To give them access, associate their group with a security policy.

Additionally, there is a default group called SSO_Guest_Users. Ensure that group is part of an identity-based security policy to allow traffic.

 

Testing FSSO

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

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: 192.168.1.230 User: ADMINISTRATOR Groups: VLAD-AD/DOMAIN USERS IP: 192.168.1.240 User: ADMINISTRATOR Groups: VLAD-AD/DOMAIN USERS Total number of users logged on: 2

—-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

———– —————– SBS-2003 connected

FortiOS FSSO log messages

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 on page 507. For more information on logging, see the FortiOS Handbook Logging 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 needed, 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.

To enable event logging:

1. Go to Log&Report > Log Config > 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. Select Apply.

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

 

Message ID                      Severity                            Description
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

 

For more information on logging, see the FortiOS Handbook Logging and Reporting guide.

Creating security policies

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 > Policy > IP4 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 pro- files.

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.

 

Enabling guest access through FSSO security policies

You can enable guest users to access FSSO security policies. Guests are users who are unknown to Windows AD 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 UTM profiles that apply to guest users — typically guests have access to a reduced set of services. See Creating security policies on page 548.

Creating Fortinet Single Sign-On (FSSO) user groups

Creating Fortinet Single Sign-On (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 > User Groups and select Create New.

The New User Group dialog box opens.

2. In the Name box, enter a name for the group, FSSO_Internet_users for example.

3. In Type, select Fortinet Single Sign-On (FSSO).

4. In Members, select the required FSSO groups.

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

 

Default FSSO group

SSO_Guest_users is a default user group enabled when FSSO is configured. It allows guest users on the network who do not have an FSSO account to authenticate and have access to network resources. See Enabling guest access through FSSO security policies on page 550.