Category Archives: Administration Guides

FortiGate Managing guest access

Managing guest access

Visitors to your premises might need user accounts on your network for the duration of their stay. If you are hosting a large event such as a conference, you might need to create many such temporary accounts. The FortiOS Guest Management feature is designed for this purpose.

A guest user account User ID can be the user’s email address, a randomly generated string, or an ID that the administrator assigns. Similarly, the password can be administrator-assigned or randomly generated.

You can create many guest accounts at once using randomly-generated User IDs and passwords. This reduces administrator workload for large events.

User’s view of guest access

The user receives an email, SMS message, or printout from a FortiOS administrator listing a User ID and password.
The user logs onto the network with the provided credentials.
After the expiry time, the credentials are no longer valid.

Administrator’s view of guest access

Create one or more guest user groups.

All members of the group have the same characteristics: type of User ID, type of password, information fields used, type and time of expiry.

Create guest accounts using Guest Management.
Use captive portal authentication and select the appropriate guest group.

Configuring guest user access

To set up guest user access, you need to create at least one guest user group and add guest user accounts. Optionally, you can create a guest management administrator whose only function is the creation of guest accounts in specific guest user groups. Otherwise, any administrator can do guest management.

Creating guest management administrators

To create a guest management administrator

Go to System > Administrators and create a regular administrator account. For detailed information see the System Administration
Select Restrict to Provision Guest Accounts.
In Guest Groups, add the guest groups that this administrator manages.

Creating guest user groups

The guest group configuration determines the fields that are provided when you create a guest user account.

Configuring guest user access

To create a guest user group:

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

Name	Enter a name for the group.
Type	Guest
Enable Batch Account Creation	Create multiple accounts automatically. When this is enabled: l User ID and Password are set to Auto-Generate. l The user accounts have only User ID, Password, and Expiration fields. Only the Expiration field is editable. If the expiry time is a duration, such as “8 hours”, this is the time after first login. l You can print the account information. Users do not receive email or SMS notification. See To create multiple guest user accounts automatically on page 72.
User ID	Select one of: l Email — User’s email address l Specify — Administrator assigns user ID l Auto-Generate — FortiGate unit creates a random user ID
Password	Select one of: l Specify — Administrator assigns user ID l Auto-Generate — FortiGate unit creates a random password l Disable — no password
Expire Type	Choose one of: l Immediately — expiry time is counted from creation of account l After first login — expiry time is counted from user’s first login
Default Expire Time	Set the expire time. The administrator can change this for individual users.
Enable Name	If enabled, user must provide a name.
Enable Sponsor	If enabled, user form has Sponsor field. Select Required if required.
Enable Company	If enabled, user form has Company field. Select Requiredif required.
Enable Email	If enabled, user is notified by email.
Enable SMS	If enabled, user is notified by SMS. Select whether FortiGuard Messaging Service or a another SMS provider is used.

Creating guest user accounts

Guest user accounts are not the same as local user accounts created in User & Device > User Definition. Guest accounts are not permanent; they expire after a defined time period. You create guest accounts in User & Device > Guest Management.

To create a guest user account

Go to User & Device > Guest Management.
In Guest Groups, select the guest group to manage.
Select Create New and fill in the fields in the New User

Fields marked Optional can be left blank. The guest group configuration determines the fields that are available.

Select OK.

To create multiple guest user accounts automatically

Go to User & Device > Guest Management.
In Guest Groups, select the guest group to manage.

The guest group must have the Enable Batch Guest Account Creation option enabled.

Select Create New > Multiple Users.

Use the down-pointing caret to the right of Create New.

Enter Number of Accounts.
Optionally, change the Expiration.
Select OK.

Guest management account List

Go to User & Device > Guest Management to create, view, edit or delete guest user accounts.

Create New	Creates a new guest user account.
Edit	Edit the selected guest user account.
Delete	Delete the selected guest user account.
Purge	Remove all expired accounts from the list.
Send	Send the user account information to a printer or to the guest. Depending on the group settings and user information, the information can be sent to the user by email or SMS.
Refresh	Update the list.
Guest Groups	Select the guest group to list. New accounts are added to this group.
User ID	The user ID. Depending on the guest group settings, this can be the user’s email address, an ID that the administrator specified, or a randomly-generated ID.
Expires	Indicates a duration such as “3 hours”. A duration on its own is relative to the present time. Or, the duration is listed as “after first login.”

Guest access in a retail environment

Some retail businesses such as coffee shops provide free WiFi Internet access for their customers. For this type of application, the FortiOS guest management feature is not required; the WiFi access point is open and customers do not need logon credentials. However, the business might want to contact its customers later with promotional offers to encourage further patronage. Using an Email Collection portal, it is possible to collect customer email addresses for this purpose. The security policy grants network access only to users who provide a valid email address.

The first time a customer’s device attempts to use the WiFi connection, FortiOS requests an email address, which it validates. The customer’s subsequent connections go directly to the Internet without interruption.

Creating an email harvesting portal

The customer’s first contact with your network will be with a captive portal which presents a web page requesting an email address. When FortiOS has validated the email address, the customer’s device MAC address is added to the Collected Emails device group.

To create the email collection portal:

Go to WiFi & Switch Controller > SSID and edit your SSID.
Set Security Mode to Captive Portal.
Set Portal Type to Email Collection.
Optionally, in Customize Portal Messages select Email Collection.

You can change the portal content and appearance. See Customizing captive portal pages on page 105.

To create the email collection portal – CLI:

In this example the freewifi WiFi interface is modified to present an email collection captive portal.

config wireless-controller vap edit freewifi set security captive-portal set portal-type email-collect

end

Creating the security policy

You need configure a security policy that allows traffic to flow from the WiFi SSID to the Internet interface but only for members of the Collected Emails device group. This policy must be listed first. Unknown devices are not members of the Collected Emails device group, so they do not match the policy.

To create the security policy:

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

Incoming Interface	freewifi
Source Address	all
Source Device Type	Collected Emails
Outgoing Interface	wan1
Destination Address	all
Schedule	always
Service	ALL
Action	ACCEPT
NAT	On

Select OK.

To create the authentication rule – CLI:

config firewall policy edit 3 set srcintf “freewifi” set dstintf “wan1” set srcaddr “all” set action accept set devices collected-emails

set nat enable set schedule “always” set service “ALL”

end

Checking for harvested emails

In the web-based manager, go to User & Device > Device Inventory. In the CLI you can use the diagnose user device list command. For example,

FGT-100D # diagnose user device list hosts vd 0 d8:d1:cb:ab:61:0f gen 35 req 30 redir 1 last 43634s 7-11_2-int ip 10.0.2.101 ip6 fe80::dad1:cbff:feab:610f type 2 ‘iPhone’ src http c 1 gen 29 os ‘iPhone’ version ‘iOS 6.0.1’ src http id 358 c 1

email ‘yo@yourdomain.com’

vd 0 74:e1:b6:dd:69:f9 gen 36 req 20 redir 0 last 39369s 7-11_2-int ip 10.0.2.100 ip6 fe80::76e1:b6ff:fedd:69f9 type 1 ‘iPad’ src http c 1 gen 5 os ‘iPad’ version ‘iOS 6.0’ src http id 293 c 1

host ‘Joes’s-iPad’ src dhcp email ‘you@fortinet.com’

Fall-through authentication policies

User authentication policies have an implicit fall-through feature that intentionally causes policy matching to fall through to a policy lower on the list that can also match the traffic. In other words the first user policy that is matched in the policy list, based on standard policy criteria, isn’t the only policy that can be matched.

Fall-through is intended to match users in different user groups with different policies. For example, consider an organization with two user groups where one group requires a web filtering profile, while the other requires virus scanning. In this example, you would edit two basic Internet access policies: policy 1 assigning User Group A with a Web Filtering profile, and policy 2 assigning User Group B with an AntiVirus profile. Both policies are also assigned to the same internal subnet, named subnet1.

In this configuration, all users from subnet1 will see an authentication prompt. If the user is found in User Group A, the traffic is accepted by policy 1 and is filtered by the Web Filtering profile. If the user is found in User Group B, the traffic is accepted by policy 2 and is virus scanned.

The fall-through feature is required for users to be matched with policy 2. Without the fall-through feature, traffic would never be matched with policy 2.

FortiGate Users and user groups

Leave a reply

Users and user groups

FortiGate authentication controls system access by user group. By assigning individual users to the appropriate user groups you can control each user’s access to network resources. The members of user groups are user accounts, of which there are several types. Local users and peer users are defined on the FortiGate unit. User accounts can also be defined on remote authentication servers.

This section describes how to configure local users and peer users and then how to configure user groups.

This section contains the following topics:

l Users l User groups

Users

A user is a user account consisting of username, password, and in some cases other information, configured on the FortiGate unit or on an external authentication server. Users can access resources that require authentication only if they are members of an allowed user group. There are several different types of user accounts with slightly different methods of authentication:

User type	Authentication
Local user	The username and password must match a user account stored on the FortiGate unit. Authentication by FortiGate security policy.
Remote user	The username must match a user account stored on the FortiGate unit and the username and password must match a user account stored on the remote authentication server. FortiOS supports LDAP, RADIUS, and TACACS+ servers.
Authentication server user	A FortiGate user group can include user accounts or groups that exist on a remote authentication server.
FSSO user	With Fortinet Single Sign On (FSSO), users on a Microsoft Windows or Novell network can use their network authentication to access resources through the FortiGate unit. Access is controlled through FSSO user groups which contain Windows or Novell user groups as their members.
PKI or Peer user	A Public Key Infrastructure (PKI) or peer user is a digital certificate holder who authenticates using a client certificate. No password is required, unless two-factor authentication is enabled.
IM Users	IM users are not authenticated. The FortiGate unit can allow or block each IM user name from accessing the IM protocols. A global policy for each IM protocol governs access to these protocols by unknown users.
User type	Authentication
Guest Users	Guest user accounts are temporary. The account expires after a selected period of time.

This section includes:

l Local and remote users l PKI or peer users l Two-factor authentication l FortiToken l Monitoring users

Local and remote users

Local and remote users are defined on the FortiGate unit in User & Device > User Definition.

Create New	Creates a new user account. When you select Create New, you are automatically redirected to the User Creation Wizard.
Edit User	Modifies a user’s account settings. When you select Edit, you are automatically redirected to the Edit User page.
Delete	Removes a user from the list. Removing the user name removes the authentication configured for the user. The Delete icon is not available if the user belongs to a user group. To remove multiple local user accounts from within the list, on the User page, in each of the rows of user accounts you want removed, select the check box and then select Delete. To remove all local user accounts from the list, on the User page, select the check box in the check box column and then select Delete.
User Name	The user name. For a remote user, this username must be identical to the username on the authentication server.
Type	Local indicates a local user authenticated on the FortiGate unit. For remote users, the type of authentication server is shown: LDAP, RADIUS, or TACACS+.
Two-factor Authentication	Indicates whether two-factor authentication is configured for the user.
Ref.	Displays the number of times this object is referenced by other objects. Select the number to open the Object Usage window and view the list of referring objects. The list is grouped into expandable categories, such as Firewall Policy. Numbers of objects are shown in parentheses. To view more information about the referring object, use the icons: l View the list page for these objects – available for object categories. Goes to the page where the object is listed. For example, if the category is User Groups, opens User Groups list. l Edit this object – opens the object for editing. l View the details for this object – displays current settings for the object.

To create a local or remote user account – web-based manager:

Go to User & Device > User Definition and select Create New.
On the Choose User Type page select:

Local User

Select to authenticate this user using a password stored on the FortiGate unit.

Remote RADIUS User

Remote TACACS+ User

Remote LDAP User

To authenticate this user using a password stored on an authentication server, select the type of server and then select the server from the list. You can select only a server that has already been added to the FortiGate unit configuration.

Select Next and provide user authentication information. For a local user, enter the User Name and Password.

For a remote user, enter the User Name and the server name.

Select Next and enter Contact Information.

If email or SMS is used for two-factor authentication, provide the email address or SMS cell number at which the user will receive token password codes. If a custom SMS service is used, it must already be configured. See FortiToken on page 56.

Select Next, then on the Provide Extra Info page enter

Two-factor Authentication	Select to enable two-factor authentication. Then select the Token (FortiToken or FortiToken Mobile) for this user account. See Associating FortiTokens with accounts on page 60.
User Group	Select the user groups to which this user belongs.

Select Create.

To create a local user – CLI example:

Locally authenticated user

config user local edit user1 set type password set passwd ljt_pj2gpepfdw end

To create a remote user – CLI example:

config user local edit user2 set type ldap set ldap_server ourLDAPsrv

end

For a RADIUS or TACACS+ user, set type to radius or tacacs+, respectively.

To create a user with FortiToken Mobile two-factor authentication – CLI example:

config user local edit user5 set type password set passwd ljt_pj2gpepfdw set two_factor fortitoken set fortitoken 182937197

end

Remote users are configured for FortiToken two-factor authentication similarly.

To create a user with SMS two-factor authentication using FortiGuard messaging service – CLI example:

config user local edit user6 set type password set passwd 3ww_pjt68dw set two_factor sms set sms-server fortiguard set sms-phone 1365984521

end

Removing users

Best practices dictate that when a user account is no longer in use, it should be deleted. Removing local and remote users from FortiOS involve the same steps.

If the user account is referenced by any configuration objects, those references must be removed before the user can be deleted. See Removing references to users on page 53.

To remove a user from the FortiOS configuration – web-based manager:

Go to User & Device > User Definition.
Select the check box of the user that you want to remove.
Select Delete.
Select OK.

To remove a user from the FortiOS configuration – CLI example:

config user local delete user4444 end

Removing references to users

You cannot remove a user that belongs to a user group. Remove the user from the user group first, and then delete the user.

To remove references to a user – web-based manager

Go to User & Device > User Definition.
If the number in the far right column for the selected user contains any number other than zero, select it.
A more detailed list of object references to this user is displayed. Use its information to find and remove these references to allow you to delete this user.

PKI or peer users

A PKI, or peer user, is a digital certificate holder. A PKI user account on the FortiGate unit contains the information required to determine which CA certificate to use to validate the user’s certificate. Peer users can be included in firewall user groups or peer certificate groups used in IPsec VPNs. For more on certificates, see Certificates overview on page 111.

To define a peer user you need:

a peer username
the text from the subject field of the user’s certificate, or the name of the CA certificate used to validate the user’s certificate

Creating a peer user

The peer user can be configured only in the CLI.

To create a peer user for PKI authentication – CLI example:

config user peer edit peer1 set subject peer1@mail.example.com

set ca CA_Cert_1

end

There are other configuration settings that can be added or modified for PKI authentication. For example, you can configure the use of an LDAP server to check access rights for client certificates. For information about the detailed PKI configuration settings, see the FortiGate CLI Reference.

Two-factor authentication

The standard logon requires a username and password. This is one factor authentication—your password is one piece of information you need to know to gain access to the system.

Two factor authentication adds the requirement for another piece of information for your logon. Generally the two factors are something you know (password) and something you have (certificate, token, etc.). This makes it harder for a hacker to steal your logon information. For example if you have a FortiToken device, the hacker would need to both use it and know your password to gain entry to your account.

Two-factor authentication is available on both user and admin accounts. But before you enable two-factor authentication on an administrator account, you need to ensure you have a second administrator account configured to guarantee administrator access to the FortiGate unit if you are unable to authenticate on the main admin account for some reason.

FortiToken extension to comply with PCI 3.2

With multi-factor-authentication enabled as mandatory (see syntax below), all authentication will collect both username/password and OTP as a second factor before presenting an authentication result. The system will log for each factor.

If a user is not configured with two-factor authentication, any OTP or an empty OTP would make the second factor authentication pass.

FortiOS processes the user and password first and then always collects the second factor (if configured) without any indication of the first factor failing or succeeding. FortiOS accepts the second factor even if the first failed (unknown to the user) and returns a login attempt pass or fail, with no indication of which factor failed.

Syntax

config system global set multi-factor-authentication {optional | mandatory}

end

The methods of two-factor authentication include:

Certificate l Email
SMS
FortiToken

Certificate

You can increase security by requiring both certificate and password authentication for PKI users. Certificates are installed on the user’s computer. Requiring a password also protects against unauthorized use of that computer.

Optionally peer users can enter the code from their FortiToken instead of the certificate.

To create a peer user with two-factor authentication – CLI example

config user peer edit peer1 set subject E=peer1@mail.example.com

set ca CA_Cert_1 set two-factor enable set passwd fdktguefheygfe

end

For more information on certificates, see Certificates overview on page 111.

Email

Two-factor email authentication sends a randomly generated six digit numeric code to the specified email address. Enter that code when prompted at logon. This token code is valid for 60 seconds. If you enter this code after that time, it will not be accepted.

A benefit is that you do not require mobile service to authenticate. However, a potential issue is if your email server does not deliver the email before the 60 second life of the token expires.

The code will be generated and emailed at the time of logon, so you must have email access at that time to be able to receive the code.

To configure an email provider – web-based manager:

Go to System > Advanced and enable Use Custom Email Server under Email Service.
Enter SMTP Server and Default Reply To
If applicable, enable Authentication and enter the SMTP User and Password to use.
Select a Security Mode, options are: None, SMTPS or STARTTLS.
Enter the Port number, the default is 25.
Select Apply.

To configure an email provider – CLI:

config system email-server set server <server_domain-name> set reply-to <Recipient_email_address>

end

To enable email two-factor authentication – web-based manager:

To modify an administrator account, go to System > Administrators. To modify a user account go to User & Device > User Definition.
Edit the user account.
Enable and enter the user’s Email Address.
Select Enable Two-factor Authentication.
Select Email based two-factor authentication.
Select OK.

If Email based two-factor authentication option doesn’t appear after selecting Enable Two-factor Authentication, you need to enable it via the CLI as follows.

To enable email two-factor authentication – CLI:

config user local edit <user_name> set email-to <user_email> set two-factor email end

SMS

SMS two-factor authentication sends the token code in an SMS text message to the mobile device indicated when this user attempts to logon. This token code is valid for 60 seconds. If you enter this code after that time, it will not be accepted. Enter this code when prompted at logon to be authenticated.

SMS two-factor authentication has the benefit that you do not require email service before logging on. A potential issue is if the mobile service provider does not send the SMS text message before the 60 second life of the token expires.

FortiGuard Messaging Service include four SMS Messages at no cost. If you need more, you should acquire a license through support.fortinet.com or via customer service.

If you do not use the FortiGuard Messaging Service, you need to configure an SMS service.

To configure an SMS service – CLI:

config system sms-server edit <provider_name> set mail-server <server_domain-name>

end

To configure SMS two-factor authentication – web-based manager:

To modify an:

l administrator account, go to System > Administrators, or l user account go to User & Device > User Definition.

Edit the user account.
Select SMS and enter the Country Dial Code and Phone Number.
Select Enable Two-factor Authentication. and select the correct Token.
Select OK.

If you have problems receiving the token codes via SMS messaging, contact your mobile provider to ensure you are using the correct phone number format to receive text messages and that your current mobile plan allows text messages.

FortiToken

FortiToken is a disconnected one-time password (OTP) generator. It is a small physical device with a button that when pressed displays a six digit authentication code. This code is entered with a user’s username and password as two-factor authentication. The code displayed changes every 60 seconds, and when not in use the LCD screen is blanked to extend the battery life.

There is also a mobile phone application, FortiToken Mobile, that performs much the same function.

FortiTokens have a small hole in one end. This is intended for a lanyard to be inserted so the device can be worn around the neck, or easily stored with other electronic devices. Do not put the FortiToken on a key ring as the metal ring and other metal objects can damage it. The FortiToken is an electronic device like a cell phone and must be treated with similar care.

Any time information about the FortiToken is transmitted, it is encrypted. When the FortiGate unit receives the code that matches the serial number for a particular FortiToken, it is delivered and stored encrypted. This is in keeping with the Fortinet’s commitment to keeping your network highly secured.

FortiTokens can be added to user accounts that are local, IPsec VPN, SSL VPN, and even Administrators. See Associating FortiTokens with accounts on page 60.

A FortiToken can be associated with only one account on one FortiGate unit.

If a user loses their FortiToken, it can be locked out using the FortiGate so it will not be used to falsely access the network. Later if found, that FortiToken can be unlocked on the FortiGate to allow access once again. See FortiToken maintenance on page 62.

There are three tasks to complete before FortiTokens can be used to authenticate accounts:

Adding FortiTokens to the FortiGate
Activating a FortiToken on the FortiGate
Associating FortiTokens with accounts

In addition, this section includes the following:

l FortiToken maintenance l FortiToken Mobile Push

The FortiToken authentication process

The steps during FortiToken two-factor authentication are as follows.

User attempts to access a network resource.
FortiGate unit matches the traffic to an authentication security policy, and FortiGate unit prompts the user for username and password.
User enters their username and password.
FortiGate unit verifies their information, and if valid prompts the user for the FortiToken code.
User gets the current code from their FortiToken device.
User enters current code at the prompt.
FortiGate unit verifies the FortiToken code, and if valid allows access to the network resources such as the Internet.

The following steps are needed only if the time on the FortiToken has drifted and needs to be re-synchronized with the time on the FortiGate unit.

If time on FortiToken has drifted, FortiGate unit will prompt user to enter a second code to confirm.
User gets the next code from their FortiToken device
User enters the second code at the prompt.
FortiGate unit uses both codes to update its clock to match the FortiToken and then proceeds as in step “Users and user groups” on page 49.

The FortiToken authentication process is illustrated below:

When configured the FortiGate unit accepts the username and password, authenticates them either locally or remotely, and prompts the user for the FortiToken code. The FortiGate then authenticates the FortiToken code. When FortiToken authentication is enabled, the prompt field for entering the FortiToken code is automatically added to the authentication screens.

Even when an Administrator is logging in through a serial or Telnet connection and their account is linked to a FortiToken, that Administrator will be prompted for the token’s code at each login.

Adding FortiTokens to the FortiGate

Before one or more FortiTokens can be used to authenticate logons, they must be added to the FortiGate. The import feature is used to enter many FortiToken serial numbers at one time. The serial number file must be a text file with one FortiToken serial number per line.

Both FortiToken Mobile and physical FortiTokens store their encryption seeds on the cloud, therefore you will only be able to register them to a single FortiGate or FortiAuthenticator.

Because FortiToken-200CD seed files are stored on the CD, these tokens can be registered on multiple FortiGates and/or FortiAuthenticators, but not simultaneously.

To manually add a FortiToken to the FortiGate – web-based manager:

Go to User & Device > FortiTokens.
Select Create New.
In Type, select Hard Token or Mobile Token.
Enter one or more FortiToken serial numbers (hard token) or activation codes (mobile token).
Select OK.

To import multiple FortiTokens to the FortiGate – web-based manager:

Go to User & Device > FortiTokens.
Select Create New.
In Type, select Hard Token.
Select Import.
Select Serial Number File or Seed File, depending on which file you have.
Browse to the local file location on your local computer.
Select OK.

The file is imported.

Select OK.

To import FortiTokens to the FortiGate from external sources – CLI:

FortiToken seed files (both physical and mobile versions) can be imported from either FTP or TFTP servers, or a USB drive, allowing seed files to be imported from an external source more easily:

execute fortitoken import ftp <file name> <ip>[:ftp port] <Enter> <user> <password> execute fortitoken import tftp <file name> <ip> execute fortitoken import usb <file name>

To add two FortiTokens to the FortiGate – CLI:

config user fortitoken edit <serial_number> next

edit <serial_number2> next

end

Activating a FortiToken on the FortiGate

Once one or more FortiTokens have been added to the FortiGate unit, they must be activated before being available to be associated with accounts. The process of activation involves the FortiGate querying FortiGuard servers about the validity of each FortiToken. The serial number and information is encrypted before it is sent for added security.

To activate a FortiToken on the FortiGate unit – web-based manager:

Go to User & Device > FortiTokens.
Select one or more FortiTokens with a status of Available.
Right-click the FortiToken entry and select Activate.
Select Refresh.

The status of selected FortiTokens will change to Activated.

The selected FortiTokens are now available for use with user and admin accounts.

To activate a FortiToken on the FortiGate unit – CLI:

config user fortitoken edit <token_serial_num> set status activate

end

Associating FortiTokens with accounts

The final step before using the FortiTokens to authenticate logons is associating a FortiToken with an account. The accounts can be local user or administrator accounts.

To add a FortiToken to a local user account – web-based manager:

Ensure that your FortiToken serial number has been added to the FortiGate successfully, and its status is Available.
Go to User & Device > User Definition, and edit the user account.
Enter the user’s Email Address.
Enable Two-factor Authentication.
Select the user’s FortiToken serial number from the Token
Select OK.

For mobile token, click on Send Activation Code to be sent to the email address configured previously. The user will use this code to activate his mobile token. An Email Service has to be set under System > Advanced in order to send the activation code.

To add a FortiToken to a local user account – CLI:

config user local edit <username> set type password set passwd “myPassword” set two-factor fortitoken set fortitoken <serial_number> set email-to “username@example.com”

set status enable

end

To add a FortiToken to an administrator account – web-based manager:

Ensure that your FortiToken serial number has been added to the FortiGate successfully, and its status is Available.
Go to System > Administrators, and edit the admin account.

This account is assumed to be configured except for two-factor authentication.

Enter admin’s Email Address.
Enable Two-factor Authentication.
Select the user’s FortiToken serial number from the Token
Select OK.

For mobile token, click on Send Activation Code to be sent to the email address configured previously. The admin will use this code to activate his mobile token. An Email Service has to be set under System > Advanced in order to send the activation code.

To add a FortiToken to an administrator account – CLI:

config system admin edit <username> set password “myPassword” set two-factor fortitoken set fortitoken <serial_number> set email-to “username@example.com”

end

The fortitoken keyword will not be visible until fortitoken is selected for the two-factor option.

FortiToken maintenance

Once FortiTokens are entered into the FortiGate unit, there are only two tasks to maintain them — changing the status,

To change the status of a FortiToken between activated and locked – CLI:

config user fortitoken edit <token_serial_num> set status lock

end

Any user attempting to login using this FortiToken will not be able to authenticate.

To list the drift on all FortiTokens configured on this FortiGate unit – CLI:

# diag fortitoken info

FORTITOKEN DRIFT STATUS

FTK2000BHV1KRZCC 0 token already activated, and seed won’t be returned

FTK2001C5YCRRVEE 0 token already activated, and seed won’t be returned

FTKMOB4B94972FBA 0 provisioned

FTKMOB4BA4BE9B84 0 new

Total activated token: 0

Total global activated token: 0

Token server status: reachable

This command lists the serial number and drift for each FortiToken configured on this FortiGate unit. This command is useful to check if it is necessary to synchronize the FortiGate and any particular FortiTokens.

FortiToken Mobile Push

A command under config system ftm-push allows you to configure the FortiToken Mobile Push services server IP address and port number. The Push service is provided by Apple (APNS) and Google (GCM) for iPhone and Android smartphones respectively. This will help to avoid tokens becoming locked after an already enabled two-factor authentication user has been disabled.

CLI syntax

config system ftm-push set server-ip <ip-address> set server-port [1-65535] Default is 4433. end

Note that the server-ip is the public IP address of the FortiGate interface that the FTM will call back to; it is the IP address used by the FortiGate for incoming FTM calls.

If an SSL VPN user authenticates with their token, then logs out and attempts to reauthenticate again within a minute, a new message will display showing “Please wait x seconds to login again.” This replaces a previous error/permission denied message.

The “x” value will depend on the calculation of how much time is left in the current time step.

CLI syntax

config system interface edit <name> set allowaccess ftm

next end

FortiGate supports when the FortiAuthenticator initiates FTM Push notifications, for when users are attempting to authenticate through a VPN and/or RADIUS (with FortiAuthenticator as the RADIUS server).

Monitoring users

To monitor user activity in the web-based manager, go to Monitor > Firewall User Monitor. The list of users who are logged on is displayed with some information about them such as their user group, security policy ID, how long they have been logged on, their IP address, traffic volume, and their authentication method as one of FSSO, NTLM, or firewall (FW-auth).

From this screen you can de-authenticate all users who are logged on. The de-authenticate button is at the top left of this screen.

To see information about banned users go to Monitor > Quarantine Monitor. Displayed information about users who have been banned includes what application the triggered the ban (Application Protocol), the reason for the ban (Cause or rule), Created, and when the ban expires.

Filtering the list of users

When there are many users logged on, it can be difficult to locate a specific user or multiple users to analyze. Applying filters to the list allows you to organize the user list to meet your needs, or only display some the users that meet your current requirements.

Select settings bottom at the top right of the screen to adjust columns that are displayed for users, including what order they are displayed in. This can be very helpful in locating information you are looking for.

Each column heading has a grey filter icon. Click on the filter icon to configure a filter for the data displayed in that column. Each column has similar options including a field to enter the filtering information, a check box to select the negative of the text in the field, and the options to add more fields, apply the filter, clear all filters, or cancel without saving. To enter multiple terms in the field, separate each of them with a comma. To filter entries that contain a specific prefix, use an * (asterisk).

For example, to create a filter to display only users with an IP address of 10.11.101.x who authenticated using one of security policies five through eight, and who belong to the user group Accounting.

Go to Monitor > Quarantine Monitor.
Enter 11.101.* and select Apply.
Select the filter icon beside Policy ID.
Enter 5-8 and select Apply.
Select the filter icon beside User Group.
Enter Accounting and select Apply.

Login credentials for guest users shown in clear text on GUI and voucher

In FortiOS 5.6.4, login credentials for guest users is displayed/printed in clear text on the GUI and in the voucher. It is also sent in clear text by SMS and email.

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, FSSO, Guest, and RADIUS single sign-on (RSSO) user groups.

Pages: 1 2

Authentication servers FortiGate Methods

2 Replies

Authentication servers

FortiGate units support the use of external authentication servers. An authentication server can provide password checking for selected FortiGate users or it can be added as a member of a FortiGate user group.

If you are going to use authentication servers, you must configure the servers before you configure FortiGate users or user groups that require them.

This section includes the following topics:

l FortiAuthenticator servers l RADIUS servers l LDAP servers l TACACS+ servers l POP3 servers l SSO servers l RSA ACE (SecurID) servers

FortiAuthenticator servers

FortiAuthenticator is an Authentication, Authorization, and Accounting (AAA) server, that includes a RADIUS server, an LDAP server, and can replace the FSSO Collector Agent on a Windows AD network. Multiple FortiGate units can use a single FortiAuthenticator for FSSO, remote authentication, and FortiToken management.

For more information, see the FortiAuthenticator Administration Guide.

RADIUS servers

Remote Authentication and Dial-in User Service (RADIUS) is a broadly supported client-server protocol that provides centralized authentication, authorization, and accounting functions. RADIUS clients are built into gateways that allow access to networks such as Virtual Private Network servers, Network Access Servers (NAS), as well as network switches and firewalls that use authentication. FortiGate units fall into the last category.

RADIUS servers use UDP packets to communicate with the RADIUS clients on the network to authenticate users before allowing them access to the network, to authorize access to resources by appropriate users, and to account or bill for those resources that are used. RADIUS servers are currently defined by RFC 2865 (RADIUS) and RFC 2866 (Accounting), and listen on either UDP ports 1812 (authentication) and 1813 (accounting) or ports 1645 (authentication) and 1646 (accounting) requests. RADIUS servers exist for all major operating systems.

You must configure the RADIUS server to accept the FortiGate unit as a client. FortiGate units use the authentication and accounting functions of the RADIUS server.

FortiOS does not accept all characters from auto generated keys from MS Windows 2008. These keys are very long and as a result RADIUS authentication will not work. Maximum key length for MS Windows 2008 is 128 bytes. In older versions of FSAE, it was 40 bytes.

Microsoft RADIUS servers

Microsoft Windows Server 2000, 2003, and 2008 have RADIUS support built-in. Microsoft specific RADIUS features are defined in RFC 2548. The Microsoft RADIUS implementation can use Active Directory for user credentials.

For details on Microsoft RADIUS server configurations, refer to Microsoft documentation.

RADIUS user database

The RADIUS user database is commonly an SQL or LDAP database, but can also be any combination of:

l usernames and passwords defined in a configuration file l user account names and passwords configured on the computer where the RADIUS server is installed.

If users are members of multiple RADIUS groups, then the user group authentication timeout value does not apply.

RADIUS authentication with a FortiGate unit

To use RADIUS authentication with a FortiGate unit l configure one or more RADIUS servers on the FortiGate unit l assign users to a RADIUS server

When a configured user attempts to access the network, the FortiGate unit will forward the authentication request to the RADIUS server which will match the username and password remotely. Once authenticated the RADIUS server passes the authorization granted message to the FortiGate unit which grants the user permission to access the network.

The RADIUS server uses a “shared secret” key along with MD5 hashing to encrypt information passed between RADIUS servers and clients, including the FortiGate unit. Typically only user credentials are encrypted. Additional security can be configured through IPsec tunnels by placing the RADIUS server behind another VPN gateway.

RADIUS attribute value pairs

RADIUS packets include a set of attribute value pairs (AVP) to identify information about the user, their location and other information. The FortiGate unit sends the following RADIUS attributes.

FortiOS supported RADIUS attributes

RADIUS Attribute	Name	Description	AVP type
1	Acct-Session-ID	Unique number assigned to each start and stop record to make it easy to match them, and to eliminate duplicate records.	44
2	Username	Name of the user being authenticated	1
3	NAS-Identifier	Identifier or IP address of the Network Access Server (NAS) that is requesting authentication. In this case, the NAS is the FortiGate unit.	32
4	Framed-IP-Address	Address to be configured for the user.	8
5	Fortinet-VSA	See Vendor-specific attributes on page 26	26
6	Acct-Input-Octets	Number of octets received from the port over the course of this service being provided. Used to charge the user for the amount of traffic they used.	42
7	Acct-Output-Octets	Number of octets sent to the port while delivering this service. Used to charge the user for the amount of traffic they used.	43
8	NAS-IP-Address	IP address of the Network Access Server (NAS) that is requesting authentication. In this case, the NAS is the FortiGate unit.	4
9	Called-Station-Id	Used to send the telephone number the user called as part of the Access-Request packet.	30
10	Framed-IP-Address	IP address to be configured for the user, by sending the IP address of a user to the RADIUS server in the Access-Request packet.	8
11	Event-Timestamp	Records the time that the event occurred on the NAS. The timestamp is measured in seconds since January 1, 1970 00:00 UTC. Before the Event-Timestamp attribute can be sent in a packet, make sure that the correct time is set on the FortiGate.	55
12	Class	Used in accounting packets and requests for firewall, WiFi, and proxy authentication. The attribute is returned in Access-Access message and is added to all accounting packets.	25

The following table describes the supported authentication events and the RADIUS attributes that are sent in the RADIUS accounting message.

RADIUS attributes sent in RADIUS accounting message

	RADIUS Attributes
Authentication Method	1	2	3	4	5	6	7
Web	X	X	X		X
XAuth of IPsec (without DHCP)	X	X	X		X
XAuth of IPsec (with DHCP)	X	X	X	X	X
PPTP/L2TP (in PPP)	X	X	X	X	X	X	X
SSL-VPN	X	X	X	X	X

External captive portal POST message

In external RADIUS captive portal, the captive portal web page is a script that gathers the user’s logon credentials and sends it back to the FortiGate as a POST message. Session URL parameters are sent from the client in a POST messages, and in the redirect. These parameters are separated by & characters (see examples below):

POST message to redirect server:

http://<redirectserver>/index2.php/?login&post=http://192.168.200.1:1000/fgtau th&magic=02050f889bc21644&usermac=54:26:96:16:a2:45&apmac=00:09:0f:b9:f4:c0&ap ip=127.0.0.1&userip=192.168.200.2

POST message back to the FortiGate: http://FGT_IP_addr:1000/fgtauth

The magic text data, provided in the initial FortiGate request to the web server, contains the username, password parameters:

magic=00050c839182f095&username=<username>&password=<password>

Vendor-specific attributes

Vendor specific attributes (VSA) are the method RADIUS servers and client companies use to extend the basic functionality of RADIUS. Some major vendors, such as Microsoft, have published their VSAs, however many do not.

In order to support vendor-specific attributes (VSA), the RADIUS server requires a dictionary to define which VSAs to support. This dictionary is typically supplied by the client or server vendor.

The Fortinet RADIUS vendor ID is 12356.

The FortiGate unit RADIUS VSA dictionary is supplied by Fortinet and is available through the Fortinet Knowledge Base (http://kb.forticare.com) or through Technical Support. Fortinet’s dictionary for FortiOS 4.0 and up is configured this way:

Fortinet’s VSA’s

VENDOR fortinet 12356

BEGIN-VENDOR fortinet

ATTRIBUTE Fortinet-Group-Name 1 string

ATTRIBUTE Fortinet-Client-IP-Address 2 ipaddr

ATTRIBUTE Fortinet-Vdom-Name 3 string

ATTRIBUTE Fortinet-Client-IPv6-Address 4 octets

ATTRIBUTE Fortinet-Interface-Name 5 string

ATTRIBUTE Fortinet-Access-Profile 6 string

# Integer Translations

END-VENDOR Fortinet

Note that using the Fortinet-Vdom-Name, users can be tied to a specific VDOM on the FortiGate unit. See the documentation provided with your RADIUS server for configuration details.

RADIUS CoA support

As of FortiOS 5.4, RADIUS Change of Authorization (CoA) settings can be configured via the CLI. CoA is a common feature in user authentication that provides the ability to change authentication attributes for sessions even after they have authenticated.

User, user group, and captive portal authentication supports RADIUS CoA, when the back end authentication server is RADIUS. The main use case of this feature is with external captive portal, where it can be used to disconnect hotspot users when their time, credit, or bandwidth has been used up.

The commands below control CoA settings.

Set the name of the FortiAP connected to the FortiGate as a location identifier.

config system global set alias <name>

Set URL of external authentication logout server.

config vdom edit root config wireless-controller vap edit <example> set security captive-portal set external-logout

Set URL of external authentication logout server config vdom edit root config system interface edit <example> set security captive-portal set security-external-logout
Set class name(s) included in an Access-Accept message.

config vdom edit root config user radius edit accounting set class <“A1=aaa” “B2=bbb” “C3=ccc”>

Role-based access control

In role-based access control (RBAC), network administrators and users have varying levels of access to network resources based on their role, and that role’s requirement for access specific resources. For example, a junior accountant does not require access to the sales presentations, or network user account information.

There are three main parts to RBAC: role assignment, role authorization, and transaction authorization. Role assignment is accomplished when someone in an organization is assigned a specific role by a manager or HR. Role authorization is accomplished when a network administrator creates that user’s RADIUS account and assigns them to the required groups for that role. Transaction authorization occurs when that user logs on and authenticates before performing a task.

RBAC is enforced when FortiOS network users are remotely authenticated via a RADIUS server. For users to authenticate, a security policy must be matched. That policy only matches a specific group of users. If VDOMs are enabled, the matched group will be limited to a specific VDOM. Using this method network administrators can separate users into groups that match resources, protocols, or VDOMs. It is even possible to limit users to specific FortiGate units if the RADIUS servers serve multiple FortiOS units.

For more information on security policies, see Authentication in security policies on page 80.

RADIUS password encoding

Certain RADIUS servers use ISO-8859-1 password encoding instead of others such as UTF-8. In these instances, the server will fail to authenticate the user, if the user’s password is using UTF-8.

CLI syntax

config user radius edit <example> set password-encoding <auto | ISO-8859-1>

end

This option will be skipped if the auth-type is neither auto nor pap.

RADIUS accounting start message options

Administrators can now choose between sending accounting start messages to all configured accounting servers, or just the one server that was previously connected.

Syntax

config user radius edit <name> set acct-interim-interval <seconds> set acct-all-servers {enable | disable}

next end

Configuring the FortiGate unit to use a RADIUS server

The information you need to configure the FortiGate unit to use a RADIUS server includes l the RADIUS server’s domain name or IP address l the RADIUS server’s shared secret key.

You can optionally specify the NAS IP or Called Station ID. When configuring the FortiGate to use a RADIUS server, the FortiGate is a Network Access Server (NAS). If the FortiGate interface has multiple IP addresses, or you want the RADIUS requests to come from a different address you can specify it here. Called Station ID applies to carrier networks. However, if the NAS IP is not included in the RADIUS configuration, the IP of the FortiGate unit interface that communicates with the RADIUS server is used instead.

A maximum of 10 remote RADIUS servers can be configured on the FortiGate unit. One or more servers must be configured on FortiGate before remote users can be configured. To configure remote users, see Local and remote users on page 50.

On the FortiGate unit, the default port for RADIUS traffic is 1812. Some RADIUS servers use port 1645. If this is the case with your server, you can either:

Re-configure the RADIUS server to use port 1812. See your RADIUS server documentation for more information on this procedure.

Change the FortiGate unit default RADIUS port to 1645 using the CLI:

config system global set radius-port 1645

end

One wildcard admin account can be added to the FortiGate unit when using RADIUS authentication. This uses the wildcard character to allow multiple admin accounts on RADIUS to use a single account on the FortiGate unit. See Example — wildcard admin accounts – CLI on page 36.

To configure the FortiGate unit for RADIUS authentication – web-based manager:

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

Name	A name to identify the RADIUS server on the FortiGate unit.
Authentication method	If you know the RADIUS server uses a specific authentication protocol, select Specify and select it from the list. Otherwise select Default. The Default option will usually work.
NAS IP	Enter the IP address to be used as the NAS-IP-Address attribute in RADIUS access requests.
Include in every user group	When enabled this RADIUS server will automatically be included in all user groups. This is useful if all users will be authenticating with the remote RADIUS server.
Primary Server	IP/Name: Enter the domain name (such as fgt.exmaple.com) or the IP address of the RADIUS server. Secret: Enter the server secret key, such as radiusSecret. This can be a maximum of 16 characters long. This must match the secret on the RADIUS primary server. Test Connectivity: Test the validity of the IP/Name. Test User Connectivity: Test the validity of the Secret.
Secondary Server	IP/Name: Optionally enter the domain name (such as fgt.exmaple.com) or the IP address of the secondary RADIUS server. Secret: Optionally, enter the secondary server secret key, such as radiusSecret2. This can be a maximum of 16 characters long. This must match the secret on the RADIUS secondary server. Test Connectivity: Test the validity of the IP/Name. Test User Connectivity: Test the validity of the Secret.

Select OK.

To configure the FortiGate unit for RADIUS authentication – CLI example:

config user radius edit ourRADIUS set auth-type auto set server 10.11.102.100 set secret radiusSecret

end

For more information about RADIUS server options, refer to the FortiGate CLI Reference.

Troubleshooting RADIUS

To test the connection to the RADIUS server use the following command: diagnose test authserver radius-direct <server_name or IP> <port number> <secret>

For the port number, enter -1 to use the default port. Otherwise enter the port number to check.

Test results show RADIUS server reachability, NAS client rejection, and invalid User/Password. Test also shows RADIUS Attributes returned from the RADIUS server.

LDAP servers

Lightweight Directory Access Protocol (LDAP) is an Internet protocol used to maintain authentication data that may include departments, people, groups of people, passwords, email addresses, and printers. LDAP consists of a data-representation scheme, a set of defined operations, and a request/response network.

The scale of LDAP servers range from big public servers such as BigFoot and Infospace, to large organizational servers at universities and corporations, to small LDAP servers for workgroups that may be using OpenLDAP.

This document focuses on the institutional and workgroup applications of LDAP.

This section includes:

l Components and topology l LDAP directory organization l Configuring the FortiGate unit to use an LDAP server l Example — wildcard admin accounts – CLI l Example of LDAP to allow dial-in through member-attribute – CLI l Troubleshooting LDAP

Components and topology

LDAP organization starts with directories. A directory is a set of objects with similar attributes organized in a logical and hierarchical way. Generally, an LDAP directory tree reflects geographic and organizational boundaries, with the Domain name system (DNS) names to structure the top level of the hierarchy. The common name identifier for most LDAP servers is cn, however some servers use other common name identifiers such as uid.

When LDAP is configured and a user is required to authenticate the general steps are:

The FortiGate unit contacts the LDAP server for authentication.
To authenticate with the FortiGate unit, the user enters a username and password.
The FortiGate unit sends this username and password to the LDAP server.
If the LDAP server can authenticate the user, the user is successfully authenticated with the FortiGate unit.
If the LDAP server cannot authenticate the user, the connection is refused by the FortiGate unit.

Binding

Binding is the step where the LDAP server authenticates the user. If the user is successfully authenticated, binding allows the user access to the LDAP server based on that user’s permissions.

The FortiGate unit can be configured to use one of three types of binding:

l anonymous – bind using anonymous user search l regular – bind using username/password and then search l simple – bind using a simple password authentication without a search

You can use simple authentication if the user records all fall under one domain name (dn). If the users are under more than one dn, use the anonymous or regular type, which can search the entire LDAP database for the required username.

If your LDAP server requires authentication to perform searches, use the regular type and provide values for username and password.

Supported versions

The FortiGate unit supports LDAP protocol functionality defined in RFC 2251: Lightweight Directory Access Protocol v3, for looking up and validating user names and passwords. FortiGate LDAP supports all LDAP servers compliant with LDAP v3, including FortiAuthenticator. In addition, FortiGate LDAP supports LDAP over SSL/TLS, which can be configured only in the CLI.

FortiGate LDAP does not support proprietary functionality, such as notification of password expiration, which is available from some LDAP servers. FortiGate LDAP does not supply information to the user about why authentication failed.

LDAP user authentication is supported for PPTP, L2TP, IPsec VPN, and firewall authentication.

However, with PPTP, L2TP, and IPsec VPN, PAP (Packet Authentication Protocol) is supported, while CHAP (Challenge Handshake Authentication Protocol) is not.

LDAP directory organization

To configure your FortiGate unit to work with an LDAP server, you need to understand the organization of the information on the server.

The top of the hierarchy is the organization itself. Usually this is defined as Domain Component (DC), a DNS domain. If the name contains a dot, such as example.com, it is written as two parts separated by a comma: dc=example,dc=com.

In this example, Common Name (CN) identifiers reside at the Organization Unit (OU) level, just below DC. The Distinguished Name (DN) is ou=People,dc=example,dc=com.

LDAP object hierarchy

In addition to the DN, the FortiGate unit needs an identifier for the individual person. Although the FortiGate unit GUI calls this the Common Name (CN), the identifier you use is not necessarily CN. On some servers, CN is the full name of a person. It might be more convenient to use the same identifier used on the local computer network. In this example, User ID (UID) is used.

Locating your identifier in the hierarchy

You need to determine the levels of the hierarchy from the top to the level that contain the identifier you want to use. This defines the DN that the FortiGate unit uses to search the LDAP database. Frequently used distinguished name elements include:

uid (user identification) l pw (password) l cn (common name)
ou (organizational unit) l o (organization) l c (country)

One way to test this is with a text-based LDAP client program. For example, OpenLDAP includes a client, ldapsearch, that you can use for this purpose.

Enter the following at the command line: ldapsearch -x ‘(objectclass=*)’

The output is lengthy, but the information you need is in the first few lines:

version: 2

# filter: (objectclass=*) # requesting: ALL

dn: dc=example,dc=com dc: example objectClass: top objectClass: domain

dn: ou=People,dc=example,dc=com

ou: People objectClass: top objectClass: organizationalUnit … dn: uid=tbrown,ou=People,dc=example,dc=com

uid: tbrown cn: Tom Brown

In the output above, you can see tbrown (uid) and Tom Brown(cn). Also note the dn is ou=People, dc=example, dc=com.

Configuring the FortiGate unit to use an LDAP server

After you determine the common name and distinguished name identifiers and the domain name or IP address of the LDAP server, you can configure the server on the FortiGate unit. The maximum number of remote LDAP servers that can be configured is 10.

One or more servers must be configured on FortiGate before remote users can be configured.

To configure the FortiGate unit for LDAP authentication – web-based manager:

Go to User & Device > LDAP Servers and select Create New.
Enter a Name for the LDAP server.
In Server Name/IP enter the server’s FQDN or IP address.
If necessary, change the Server Port The default is port 389.
Enter the Common Name Identifier (20 characters maximum).

cn is the default, and is used by most LDAP servers.

In the Distinguished Name field, enter the base distinguished name for the server using the correct X.500 or LDAP format.

The FortiGate unit passes this distinguished name unchanged to the server. The maximum number of characters is 512.

If you don’t know the distinguished name, leave the field blank and select the Query icon to the right of the field. See Using the query icon on page 35.

In the Distinguished Name field, enter the base distinguished name for the server using the correct X.500 or LDAP format.

The FortiGate unit passes this distinguished name unchanged to the server. The maximum number of characters is 512.

If you don’t know the distinguished name, leave the field blank and select the Query icon to the right of the field.

See Using the query icon on page 35.

In Bind Type, select Regular.
In User DN, enter the LDAP administrator’s distinguished name.
In Password, enter the LDAP administrator’s password.
Select OK.

To verify your Distinguished Name field is correct, you can select the Test button. If your DN field entry is valid, you will see the part of the LDAP database it defines. If your DN field entry is not valid, it will display an error message and return no information.

For detailed information about configuration options for LDAP servers, see the Online Help on your FortiGate unit or the FortiGate CLI Reference.

To configure the FortiGate unit for LDAP authentication – CLI example:

config user ldap edit ourLDAPsrv set server 10.11.101.160

set cnid cn

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 w5AiGVMLkgyPQ set password-expiry-warning enable set password-renewal enable end

password-expiry-warning and password-renewal

In SSLVPN, when an LDAP user is connecting to the LDAP server it is possible for them to receive any pending password expiry or renewal warnings. When the password renewal or expiry warning exists, SSLVPN users will see a prompt allowing them to change their password.

password-expiry-warning allows FortiOS to detect from the OpenLDAP server when a password is expiring or has expired using server controls or error codes. Please note that this is currently not supported for Windows AD LDAP.

password-renewal allows FortiOS to perform the online LDAP password renewal operations the LDAP server expects.

On an OpenLDAP server, when a user attempts to logon with an expired password they are allowed to logon but only to change their password.

When changing passwords on a Windows AD system, the connection must be SSL-protected.

UPN processing method and filter name

The following CLI commands available under config user ldap allow you to keep or strip the domain string of userPrincipalName (UPN) in the token as well as the search name for this kind of UPN.

Principle name peer user mode was only supported with Windows AD, and fnbamd has a hard coded UserAccountControl when doing LDAP authentication. UserAccountControl is a Windows AD specific attribute which doesn’t exist in FortiAuthenticator or OpenLDAP.

To make LDAP query more flexible with different LDAP server versions, account-key-filter has been introduced to replace account-key-name. Enter the UPN attribute as the filter.

CLI syntax:

config user ldap set account-key-processing set account-key-filter

end

Using the query icon

The LDAP Distinguished Name Query list displays the LDAP directory tree for the LDAP server connected to the FortiGate unit. This helps you to determine the appropriate entry for the DN field. To see the distinguished name associated with the Common Name identifier, select the Expand icon next to the CN identifier. Select the DN from the list. The DN you select is displayed in the Distinguished Name field. Select OK and the Distinguished Name you selected will be saved in the Distinguished Name field of the LDAP Server configuration.

To see the users within the LDAP Server user group for the selected Distinguished Name, expand the Distinguished Name in the LDAP Distinguished Name Query tree.

LDAP server Distinguished Name Query tree

Non-blocking LDAP authentication

To support non-blocking LDAP authentication, fnbamd will create its own event-driven connection with LDAP servers over LDAP/LDAPS/STARTTLS, make it non-blocking, do CRL checking if necessary, and compose all LDAP requests using liblber (including bind, unbind, search, password renewal, password query, send request and receive response, and parse response). The whole process is done in one connection.

This doesn’t change any openLDAP implementation but moves some data structure definitions and API definitions from some internal header files to public header files.

Example — wildcard admin accounts – CLI

A wildcard admin account is an administrator account with the wildcard option enabled. This option allows multiple different remote administration accounts to match one local administration account, avoiding the need to set up individual admin accounts on the FortiGate unit. Instead multiple LDAP admin accounts will all be able to use one FortiGate admin account.

The initial benefit of wildcard admin accounts is fast configuration of the FortiGate unit’s administration account to work with your LDAP network. The many to one ratio saves on effort, and potential errors.

The ongoing benefit is that as long as the users on the LDAP system belong to that group, and the test admin user settings don’t change on the FortiGate unit, no other work is required. This point is important as it can help avoid system updates or changes that would otherwise require changes to the LDAP administrator account configuration. Even if a user is added to or removed from the LDAP group, no changes are required on the FortiGate unit.

Two potential issues with wildcard admin accounts are that multiple users may be logged on to the same account at the same time. This becomes an issue if they are changing the same information at the same time. The other potential issue is that security is reduced because multiple people have login access for the same account. If each user was assigned their own account, a hijacking of one account would not affect the other users.

Note that wildcard admin configuration also applies to RADIUS. When configuring for RADIUS, configure the RADIUS server, and RADIUS user group instead of LDAP. When using web-based management, wildcard admin is the only type of remote administrator account that does not require you to enter a password on account creation. That password is normally used when the remote authentication server is unavailable during authentication.

In this example, default values are used where possible. If a specific value is not mentioned, it is set to its default value.

Configuring the LDAP server

The important parts of this configuration are the username and group lines. The username is the domain administrator account. The group binding allows only the group with the name GRP to access.

To configure LDAP server – CLI:

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

set type regular

set username “CN=Administrator,CN=Users,DC=example,DC=COM” set password *

set group-member-check group-object set group-object-filter (&

(objectcategory=group)member=”CN=GRP,OU=training,DC=example,DC=COM”)) next

end

To configure the user group and add the LDAP server – CLI:

config user group edit “ldap_grp” set member “ldap” config match

edit 1 set server-name “ldap_server”

set group-name “CN=GRP,OU=training,DC=example,DC=COM”

end

next end

Configuring the admin account

The wildcard part of this example is only available in the CLI for admin configuration. When enabled, this allows all LDAP group members to login to the FortiGate unit without the need to create a separate admin account for each user. In effect the members of that group will each be able to login as “test”.

To configure the admin account – CLI:

config system admin edit “test” set remote-auth enable set accprofile “super_admin” set wildcard enable set remote-group “ldap_grp”

end

For troubleshooting, test that the admin account is operational, and see Troubleshooting LDAP on page 39.

Example of LDAP to allow dial-in through member-attribute – CLI

In this example, users defined in MicroSoft Windows Active Directory (AD) are allowed to setup a VPN connection simply based on an attribute that is set to TRUE, instead of based on being part of a specific group.

In AD, the “Allow Dial-In” property is activated in the user properties, and this sets the msNPAllowDialin attribute to “TRUE”.

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

Configuring LDAP member-attribute settings

To accomplish this with a FortiGate unit, the member attribute must be set. Setting member attributes can only be accomplished through the CLI using the member-attr keyword – the option is not available through the webbased manager.

Before configuring the FortiGate unit, the AD server must be configured and have the msNPAllowDialin attribute set to “TRUE” for the users in question. If not, those users will not be able to properly authenticate.

The dn used here is as an example only. On your network use your own domain name.

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=fortinet,DC=com,DC=au” set type regular

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

next end

Configuring LDAP group settings

A user group that will use LDAP must be configured. This example adds the member ldap to the group which is the LDAP server name that was configured earlier.

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”

end

Once these settings are in place, users can authenticate.

Pages: 1 2

Types of authentication

Leave a reply

Types of authentication

FortiOS supports two different types of authentication based on your situation and needs: security policy authentication and Virtual Private Network (VPN) authentication.

Security policy authentication is easily applied to all users logging on to a network, or network service. For example if a group of users on your network such as the accounting department who have access to sensitive data need to access the Internet, it is a good idea to make sure the user is a valid user and not someone trying to send company secrets to the Internet. Security policy authentication can be applied to as many or as few users as needed, and it supports a number of authentication protocols to easily fit with your existing network.

VPN authentication enables secure communication with hosts located outside the company network, making them part of the company network while the VPN tunnel is operating. Authentication applies to the devices at both ends of the VPN and optionally VPN users can be authenticated as well.

Security policy authentication

Security policies enable traffic to flow between networks. Optionally, the policy can allow access only to specific originating addresses, device types, users or user groups. Where access is controlled by user or user group, users must authenticate by entering valid username and password credentials.

The user’s authentication expires if the connection is idle for too long, five minutes by default but that can be customized.

Security policies are the mechanism for FSSO, NTLM, certificate based, and RADIUS SSO authentication.

FSSO

Fortinet Single Sign on (FSSO) provides seamless authentication support for Microsoft Windows Active Directory (AD) and Novell eDirectory users in a FortiGate environment.

On a Microsoft Windows or Novell network, users authenticate with the Active Directory or Novell eDirectory at login. FSSO provides authentication information to the FortiGate unit so that users automatically get access to permitted resources. See Introduction to agent-based FSSO on page 147.

NTLM

The NT LAN Manager (NTLM) protocol is used when the MS Windows Active Directory (AD) domain controller can not be contacted. NTLM is a browser-based method of authentication.

The FSSO software is installed on each AD server and the FortiGate unit is configured to communicate with each

FSSO client. When a user successfully logs into their Windows PC (and is authenticated by the AD Server), the

FSSO client communicates the user’s name, IP address, and group login information to the FortiGate unit. The FortiGate unit sets up a temporary access policy for the user, so when they attempt access through the firewall they do not need to re-authenticate. This model works well in environments where the FSSO client can be installed on all AD servers.

In system configurations where it is not possible to install FSSO clients on all AD servers, the FortiGate unit must be able to query the AD servers to find out if a user has been properly authenticated. This is achieved using the NTLM messaging features of Active Directory and Internet Explorer.

Even when NTLM authentication is used, the user is not asked again for their username and password. Internet Explorer stores the user’s credentials and the FortiGate unit uses NTLM messaging to validate them in the Windows AD environment.

Note that if the authentication reaches the timeout period, the NTLM message exchange restarts. For more information on NTLM, see NTLM authentication on page 86 and FSSO NTLM authentication support on page 153.

Certificates

RADIUS SSO

RADIUS Single Sign-On (RSSO) is a remote authentication method that does not require any local users to be configured, and relies on RADIUS Start records to provide the FortiGate unit with authentication information. That information identifies the user and user group, which is then matched using a security policy. See SSO using RADIUS accounting records on page 192.

FortiGuard web filter override authentication

Optionally, users can be allowed the privilege of overriding FortiGuard Web Filtering to view blocked web sites. Depending on the override settings, the override can apply to the user who requested it, the entire user group to which the user belongs, or all users who share the same web filter profile. As with other FortiGate features, access to FortiGuard overrides is controlled through user groups. Firewall and Directory Services user groups are eligible for the override privilege. For more information about web filtering and overrides, see the UTM chapter of this FortiOS Handbook.

VPN authentication

Authentication involves authenticating the user. In IPsec VPNs authenticating the user is optional, but authentication of the peer device is required. This section includes:

l Authenticating IPsec VPN peers (devices) l Authenticating IPsec VPN users l Authenticating SSL VPN users l Authenticating PPTP and L2TP VPN users

Authenticating IPsec VPN peers (devices)

A VPN tunnel has one end on a local trusted network, and the other end is at a remote location. The remote peer (device) must be authenticated to be able to trust the VPN tunnel. Without that authentication, it is possible for a malicious hacker to masquerade as a valid VPN tunnel device and gain access to the trusted local network.

The three ways to authenticate VPN peers are with a pre-shared key, RSA X.509 certificate, or a specific peer ID value.

The simplest way for IPsec VPN peers to authenticate each other is through the use of a pre-shared key, also called a shared secret. The pre-shared key is a text string used to encrypt the data exchanges that establish the VPN tunnel. The pre-shared key must be six or more characters. The VPN tunnel cannot be established if the two peers do not use the same key. The disadvantage of pre-shared key authentication is that it can be difficult to securely distribute and update the pre-shared keys.

RSA X.509 certificates are a better way for VPN peers to authenticate each other. Each peer offers a certificate signed by a Certificate Authority (CA) which the other peer can validate with the appropriate CA root certificate. For more information about certificates, see Certificate-based authentication on page 110.

You can supplement either pre-shared key or certificate authentication by requiring the other peer to provide a specific peer ID value. The peer ID is a text string configured on the peer device. On a FortiGate peer or FortiClient Endpoint Security peer, the peer ID provided to the remote peer is called the Local ID.

Authenticating IPsec VPN users

An IPsec VPN can be configured to accept connections from multiple dynamically addressed peers. You would do this to enable employees to connect to the corporate network while traveling or from home. On a FortiGate unit, you create this configuration by setting the Remote Gateway to Dialup User.

It is possible to have an IPsec VPN in which remote peer devices authenticate using a common pre-shared key or a certificate, but there is no attempt to identify the user at the remote peer. To add user authentication, you can do one of the following:

l require a unique pre-shared key for each peer l require a unique peer ID for each peer l require a unique peer certificate for each peer l require additional user authentication (XAuth)

The peer ID is a text string configured on the peer device. On a FortiGate peer or FortiClient Endpoint Security peer, the peer ID provided to the remote peer is called the Local ID.

Authenticating SSL VPN users

SSL VPN users can be l user accounts with passwords stored on the FortiGate unit l user accounts authenticated by an external RADIUS, LDAP or TACACS+ server l PKI users authenticated by certificate

You need to create a user group for your SSL VPN. Simply create a firewall user group, enable SSL VPN access for the group, and select the web portal the users will access.

SSL VPN access requires an SSL VPN security policy that permits access to members of your user group.

Authenticating PPTP and L2TP VPN users

PPTP and L2TP are older VPN tunneling protocols that do not provide authentication themselves. FortiGate units restrict PPTP and L2TP access to users who belong to one specified user group. Users authenticate themselves to the FortiGate unit by username/password. You can configure PPTP and L2TP VPNs only in the CLI. Before you configure the VPN, create a firewall user group and add to it the users who are permitted to use the VPN. Users are authenticated when they attempt to connect to the VPN. For more information about configuring PPTP or L2TP VPNs, see the FortiGate CLI Reference.

Single sign-on authentication for users

Single sign-on (SSO)means that users logged on to a computer network are authenticated for access to network resources through the FortiGate unit without having to enter their username and password again. FortiGate units directly provide SSO capability for:

l Microsoft Windows networks using either Active Directory or NTLM authentication l Novell networks, using eDirectory

In combination with a FortiAuthenticator unit, the FortiGate unit can provide SSO capability that integrates multiple external network authentication systems such as Windows Active Directory, Novell e-Directory, RADIUS and LDAP. The FortiAuthenticator unit gathers user logon information from all of these sources and sends it to the FortiGate unit.

Through the SSO feature, the FortiGate unit knows the username, IP address, and external user groups to which the user belongs. 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.

User’s view of authentication

From the user’s point of view, they see a request for authentication when they try to access a protected resource, such as an FTP repository of intellectual property or simply access a website on the Internet. The way the request is presented to the user depends on the method of access to that resource.

VPN authentication usually controls remote access to a private network.

Web-based user authentication

Security policies usually control browsing access to an external network that provides connection to the Internet. In this case, the FortiGate unit requests authentication through the web browser.

The user types a username and password and then selects Continue or Login. If the credentials are incorrect, the authentication screen is redisplayed with blank fields so that the user can try again. When the user enters valid credentials, access is granted to the required resource. In some cases, if a user tries to authenticate several times without success, a message appears, such as: “Too many bad login attempts. Please try again in a few minutes.” This indicates the user is locked out for a period of time. This prevents automated brute force password hacking attempts. The administrator can customize these settings if required.

After a defined period of user inactivity (the authentication timeout, defined by the FortiGate administrator), the user’s access expires. The default is 5 minutes. To access the resource, the user will have to authenticate again.

VPN client-based authentication

A VPN provides remote clients with access to a private network for a variety of services that include web browsing, email, and file sharing. A client program such as FortiClient negotiates the connection to the VPN and manages the user authentication challenge from the FortiGate unit.

FortiClient can store the username and password for a VPN as part of the configuration for the VPN connection and pass them to the FortiGate unit as needed. Or, FortiClient can request the username and password from the user when the FortiGate unit requests them.

Social ID data from FortiClient is recorded so that if an email or phone number is changed on FortiClient, the new values are updated on the FortiGate.

The data is sent in KeepAlive messages in the following format:

USR_NAME|<full name for the service account>|USR_

SSL VPN is a form of VPN that can be used with a standard Web browser. There are two modes of SSL VPN operation (supported in NAT/Route mode only):

l web-only mode, for remote clients equipped with a web-browser only l tunnel mode, for remote computers that run a variety of client and server applications.

After a defined period of user inactivity on the VPN connection (the idle timeout, defined by the FortiGate administrator), the user’s access expires. The default is 30 minutes. To access the resource, the user will have to authenticate again.

FortiGate administrator’s view of authentication

Authentication is based on user groups. The FortiGate administrator configures authentication for security policies and VPN tunnels by specifying the user groups whose members can use the resource. Some planning is required to determine how many different user groups need to be created. Individual user accounts can belong to multiple groups, making allocation of user privileges very flexible.

A member of a user group can be:

a user whose username and password are stored on the FortiGate unit l a user whose name is stored on the FortiGate unit and whose password is stored on a remote or external authentication server
a remote or external authentication server with a database that contains the username and password of each person who is permitted access

The general process of setting up authentication is as follows:

If remote or external authentication is needed, configure the required servers.

General authentication settings

Configure local and peer (PKI) user identities. For each local user, you can choose whether the FortiGate unit or a remote authentication server verifies the password. Peer members can be included in user groups for use in security policies.
Create user groups.
Add local/peer user members to each user group as appropriate. You can also add an authentication server to a user group. In this case, all users in the server’s database can authenticate. You can only configure peer user groups through the CLI.
Configure security policies and VPN tunnels that require authenticated access.

For authentication troubleshooting, see the specific chapter for the topic or for general issues see Troubleshooting on page 219.

General authentication settings

Go to User & Device > Authentication Settings to configure authentication timeout, protocol support, and authentication certificates.

When user authentication is enabled within a security policy, the authentication challenge is normally issued for any of the four protocols (depending on the connection protocol):

HTTP (can also be set to redirect to HTTPS) l HTTPS l FTP
Telnet

The selections made in the Protocol Support list of Authentication Settings control which protocols support the authentication challenge. Users must connect with a supported protocol first so they can subsequently connect with other protocols. If HTTPS is selected as a method of protocol support, it allows the user to authenticate with a customized Local certificate.

When you enable user authentication within a security policy, the security policy user will be challenged to authenticate. For user ID and password authentication, users must provide their user names and passwords. For certificate authentication (HTTPS or HTTP redirected to HTTPS only), you can install customized certificates on the unit and the users can also have customized certificates installed on their browsers. Otherwise, users will see a warning message and have to accept a default Fortinet certificate.

Authentication Timeout	Enter a length of time in minutes, from 1 to 4320 (72 hours). Authentication timeout controls how long an authenticated firewall connection can be idle before the user must authenticate again. The default value is 5.
Protocol Support	Select the protocols to challenge during firewall user authentication.
Certificate	If using HTTPS protocol support, select the local certificate to use for authentication. Available only if HTTPS protocol support is selected.
Apply	Select to apply the selections for user authentication settings.

Authentication binds to MAC address

Leave a reply

Authentication binds to MAC address

In previous FortiOS versions, firewall authentication was source IP based, thus there was no action in response to a MAC address change. This was a security flaw that allowed an unauthenticated user to access restricted resources, especially in a WiFi environment where the IP and MAC binding changed frequently.

MAC addresses can now be bound with the user identity so that the MAC address is matched while matching an auth logon.

Two-factor authentication

Leave a reply

Two-factor authentication

A user can be required to provide both something they know (their username and password combination) and something they have (certificate or a random token code). Certificates are installed on the user’s computer.

Two-factor authentication is available for PKI users.

Another type of two-factor authentication is to use a randomly generated token (multi-digit number) along with the username and password combination. One method is a FortiToken — a one-time password (OTP) generator that generates a unique code every 60 seconds. Others use email or SMS text messaging to deliver the random token code to the user or administrator.

When one of these methods is configured, the user enters this code at login after the username and password have been verified. The FortiGate unit verifies the token code after as well as the password and username.

Certificate-based authentication

Leave a reply

Certificate-based authentication

An RSA X.509 server certificate is a small file issued by a certificate authority (CA) that is installed on a computer or FortiGate unit to authenticate itself to other devices on the network. When one party on a network presents the certificate as authentication, the other party can validate that the certificate was issued by the CA. The identification is therefore as trustworthy as the CA that issued the certificate.

To protect against compromised or misused certificates, CAs can revoke any certificate by adding it to a certificate revocation list (CRL). Certificate status can also be checked online using the Online Certificate Status Protocol (OCSP).

RSA X.509 certificates are based on public-key cryptography, in which there are two keys: the private key and the public key. Data encrypted with the private key can be decrypted only with the public key, and the other way round. As the names suggest, the private key is never revealed to anyone and the public key can be freely distributed. Encryption with the recipient’s public key creates a message that only the intended recipient can read. Encryption with the sender’s private key creates a message whose authenticity is proven because it can be decrypted only with the sender’s public key.

Server certificates contain a signature string encrypted with the CA’s private key. The CA’s public key is contained in a CA root certificate. If the signature string can be decrypted with the CA’s public key, the certificate is genuine. Certificate authorities

A CA can be:

l an organization, such as VeriSign Inc., that provides certificate services l a software application, such as Microsoft Certificate Services or OpenSSH

For a company web portal or customer-facing SSL VPN, a third-party certificate service has some advantages. The CA certificates are already included in popular web browsers and customers trust the third-party. On the other hand, third-party services have a cost.

For administrators and for employee VPN users, the local CA based on a software application provides the required security at low cost. You can generate and distribute certificates as needed. If an employee leaves the organization, you can simply revoke their certificate.

Certificates for users

FortiGate unit administrators and SSL VPN users can install certificates in their web browsers to authenticate themselves. If the FortiGate unit uses a CA-issued certificate to authenticate itself to the clients, the browser will also need the appropriate CA certificate.

FortiGate IPsec VPN users can install server and CA certificates according to the instructions for their IPsec VPN client software. The FortiClient Endpoint Security application, for example, can import and store the certificates required by VPN connections.

FortiGate units are also compatible with some Public Key Infrastructure systems. For an example of this type of system, see RSA ACE (SecurID) servers on page 44.

Server-based password authentication

Leave a reply

Server-based password authentication

Using external authentication servers is desirable when multiple FortiGate units need to authenticate the same users, or where the FortiGate unit is added to a network that already contains an authentication server. FortiOS supports the use of LDAP, RADIUS, TACACS+, AD, or POP3 servers for authentication.

When you use an external authentication server to authenticate users, the FortiGate unit sends the user’s entered credentials to the external server. The password is encrypted. The server’s response indicates whether the supplied credentials are valid or not.

You must configure the FortiGate unit to access the external authentication servers that you want to use. The configuration includes the parameters that authenticate the FortiGate unit to the authentication server.

You can use external authentication servers in two ways:

Create user accounts on the FortiGate unit. However, instead of storing each user’s password, specify the server used to authenticate that user. As with accounts that store the password locally, you add these users to appropriate user groups.
Add the authentication server to user groups. Any user who has an account on the server can be authenticated and have the access privileges of the FortiGate user group. Optionally, when an LDAP server is a FortiGate user group member, you can limit access to users who belong to specific groups defined on the LDAP server.