User groups

A user group is a list of user identities. An identity can be:

l a local user account (username/password stored on the FortiGate unit l a remote user account (password stored on a RADIUS, LDAP, or TACACS+ server) l a PKI user account with digital client authentication certificate stored on the FortiGate unit l a RADIUS, LDAP, or TACACS+ server, optionally specifying particular user groups on that server l a user group defined on an FSSO server.

Security policies and some types of VPN configurations allow access to specified user groups only. This restricted access enforces Role Based Access Control (RBAC) to your organization’s network and its resources. Users must be in a group and that group must be part of the security policy.

In most cases, the FortiGate unit authenticates users by requesting their username and password. The FortiGate unit checks local user accounts first. If a match is not found, the FortiGate unit checks the RADIUS, LDAP, or TACACS+ servers that belong to the user group. Authentication succeeds when a matching username and password are found. If the user belongs to multiple groups on a server, those groups will be matched as well.

There are four types of FortiGate user groups: Firewall, Fortinet Single Sign-On (FSSO), Guest, and RADIUS Single Sign-On (RSSO) user groups.

Firewall user groups

Firewall user groups are used locally as part of authentication. When a security policy allows access only to specified user groups, users must authenticate. If the user authenticates successfully and is a member of one of the permitted groups, the session is allowed to proceed.

This section includes: l SSL VPN access l IPsec VPN access l Configuring a firewall user group l Multiple group enforcement support l User group timeouts

SSL VPN access

SSL VPN settings include a list of the firewall user groups that can access the SSL VPN and the SSL VPN portal that each group will use. When the user connects to the FortiGate unit via HTTPS on the SSL VPN port (default 10443), the FortiGate unit requests a username and password.

SSL VPN access also requires a security policy where the destination is the SSL interface. For more information, see the FortiOS Handbook SSL VPN guide.

IPsec VPN access

A firewall user group can provide access for dialup users of an IPsec VPN. In this case, the IPsec VPN phase 1 configuration uses the Accept peer ID in dialup group peer option. The user’s VPN client is configured with the username as peer ID and the password as pre-shared key. The user can connect successfully to the IPsec VPN only if the username is a member of the allowed user group and the password matches the one stored on the FortiGate unit.

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

Configuring a firewall user group

A user group can contain:

• local users, whether authenticated by the FortiGate unit or an authentication server l PKI users
• authentication servers, optionally specifying particular user groups on the server

To create a Firewall user group – web-based manager:

1. Go to User & Device > User Groups and select Create New.
2. Enter a name for the user group.
3. In Type, select Firewall.
4. Add user names to to the Members
5. Add authentication servers to the Remote groups

By default all user accounts on the authentication server are members of this FortiGate user group. To include only specific user groups from the authentication server, deselect Any and enter the group name in the appropriate format for the type of server. For example, an LDAP server requires LDAP format, such as:

cn=users,dn=office,dn=example,dn=com

Remote servers must already be configured in User & Device.

6. Select OK.

To create a firewall user group – CLI example:

In this example, the members of accounting_group are User1 and all of the members of rad_ accounting_group on myRADIUS external RADIUS server.

config user group edit accounting_group set group-type firewall set member User1 myRADIUS config match edit 0 set server-name myRADIUS set group-name rad_accounting_group

end

end

Matching user group names from an external authentication server might not work if the list of group memberships for the user is longer than 8000 bytes. Group names beyond this limit are ignored.

server_name is the name of the RADIUS, LDAP, or TACACS+ server, but it must be a member of this group first and must also be a configured remote server on the FortiGate unit.

group_name is the name of the group on the RADIUS, LDAP, or TACACS+ server such as “engineering” or “cn=users,dc=test,dc=com”.

Before using group matching with TACACS+, you must first enable authentication. For example if you have a configured TACACS+ server called myTACS, use the following CLI commands.

config user tacacs+ edit myTACS set authorization enable

next

end

For more information about user group CLI commands, see the Fortinet CLI Guide.

Multiple group enforcement support

Previously, when a user belonged to multiple user groups, this user could only access the group services that were within one group. With multiple group enforcement, a user can access the services within the groups that the user is part of.

For example, userA belongs to user_group1, user_group2, user_group3, and user_group4; previously userA could only access services within one of those four groups, typically the group that matches the first security policy. This can be annoying if HTTP access is in user_group1, FTP access is in user_group2, and email access is in user_group3. Now userA can access services within user_group1, user_group2, user_group3, and user_group4.

This feature is available only in the CLI and is enabled by default. It applies to RADIUS, LDAP, and TACACS+ servers. The new command for this feature is auth-multi-group found in config user settings and checks all groups a user belongs to for authentication.

User group timeouts

User groups can have timeout values per group in addition to FortiGate-wide timeouts. There are essentially three different types of timeouts that are configurable for user authentication on the FortiGate unit — idle timeout, hard timeout, and session timeout. These are in addition to any external timeouts such as those associated with RADIUS servers.

If VDOMs are enabled, the global level user setting authtimeout is the default all VDOMs inherit. If VDOMs are not enabled, user settings authtimeout is the default. The default timeout value is used when the authtimeout keyword for a user group is set to zero.

Each type of timeout will be demonstrated using the existing user group example_group. Timeout units are minutes. A value of zero indicates the global timeout is used.

Membership in multiple groups

When a user belongs to multiple groups in RADIUS groups, the group auth-timeout values are ignored. Instead the global timeout value is used. The default value is 5 minutes, but it can be set from 1 to 43200 minutes (30 days).

config user setting set auth-timeout-type idle-timeout set auth-timeout 300

end

Idle timeout

The default type of timeout is idle timeout. When a user initiates a session, it starts a timer. As long as data is transferred in this session, the timer continually resets. If data flow stops, the timer is allowed to advance until it reaches its limit. At that time the user has been idle for too long, and the user is forced to re-authenticate before traffic is allowed to continue in that session.

To configure user group authentication idle timeout – CLI:

config user settings set auth-timeout-type idle-timeout

end config user group edit example_group set authtimeout 5 //range is 0-43200 minutes (0 = use global authtimeout value)

next

end

Hard timeout

Where the idle timeout is reset with traffic, the hard timeout is absolute. From the time the first session a user establishes starts, the hard timeout counter starts. When the timeout is reached, all the sessions for that user must be re-authenticated. This timeout is not affected by any event.

To configure user group authentication hard timeout – CLI:

config user settings set auth-timeout-type hard-timeout

end config user group edit example_group set authtimeout 43200 //range is 0-43200 minutes (0 = use global authtimeout value)

next

end

Session timeout

The session timeout works much like the hard timeout in that its an absolute timer that can not be affected by events. However, when the timeout is reached existing sessions may continue but new sessions are not allowed until re-authentication takes place.

To configure a user group authentication new session hard timeout – CLI:

config user setting set auth-timeout-type new-session

end

config user group edit example_group set authtimeout 30 //range is 0-43200 minutes (0 = use global authtimeout value)

next end