Fortinet Document Library

Version:

Version:

Version:

Version:


Table of Contents

Download PDF
Copy Link

User account policies

General policies for user accounts include lockout settings, password policies, and custom user fields.

General

To configure general account policy settings, go to Authentication > User Account Policies > General.

Configure the following settings:

PCI DSS 3.2 two-factor authentication Enable to always collect all authentication factors before indicating a success or failure.

Enhanced cryptography for storage of local user passwords

Enable to use stronger cryptography for the storage of local user passwords.

Note that this option cannot be disabled after 30 days of being enabled. FortiAuthenticator will send an email remainder to the administrator before the end of the 30-day period.

Expire device login after Login session timeout for Windows machine authentication via 802.1X.
Automatically purge disabled user accounts

Enable to automatically purge disabled user accounts. Select the frequency of the purge in the Frequency field: Hourly, Daily, Weekly, or Monthly. Enter the time of the purge in the Time field: Now to set the time to the current time, or select the clock icon to choose a time: Now, Midnight, 6 a.m., or Noon.

Purge users that are disabled due to the following reasons Set the reason for purging disabled users: Manually disabled, Login inactivity, or Account expired.
Discard stale RADIUS authentication requests Enable to select a time after which RADIUS authentication requests are considered stale and are discarded, from 3 - 360 seconds (or six minutes). The default is set to 8 seconds.
Expire inactive RADIUS accounting session after Enter a time after which RADIUS accounting sessions timeout, from 5 to 1440 minutes (or five minutes to one day). The default is set to 60 minutes.

PCI DSS 3.2 two-factor authentication

The login flows for RADIUS authentication, SAML IdP, Guest Portals, and GUI Login all meet PCI DSS 3.2 standards regarding multi-factor authentication.

In the case where the Bypass FortiToken authentication when user is from a trusted subnet option is enabled (under Authentication > SAML IdP > Service Providers), and the user is logging in from a trusted subnet, the login flow reverts to password-only regardless of the PCI mode.

The GUI login page is hard-coded to Apply two-factor authentication if available (authenticate any user), so it behaves the same as the guest portal.

All failed authentications will return the same generic message, so as not to reveal any clue to an attacker about which piece of information was valid or invalid:

"Please enter correct credentials. Note that the password is case-sensitive."

Remote login to the CLI (i.e. Telnet, SSH) also complies with the new PCI requirements.

Guest portal exception

There is one exception for guest portals. When a user has exceeded their time and/or data usage limit, the FortiAuthenticator shows the "Usage exceeded" replacement message. The best behavior would be to only show the replacement message if the credentials are valid. However, this would require a major change in the internal flow of the current authentication implementation. Instead, the FortiAuthenticator only requires that the account name be valid (not the credentials). The downside is that it opens the door for leaking valid account names. Nonetheless, it is deemed acceptable because:

  1. Account name leakage prevention is not a PCI requirement (just a best practice).
  2. Leaked account names are not usable because they are disabled (due to exceeded usage).
  3. Disabled accounts can't be leveraged to brute-force credentials (in the hope of using them if an account gets re-enabled/usage extended).

Lockouts

For various security reasons, you may want to lock a user’s account. For example, repeated unsuccessful attempts to log in might indicate an attempt at unauthorized access.

Information on locked-out users can be viewed in the Top User Lockouts widget, see Top user lockouts widget.

Currently locked-out users can be viewed in Monitor > Authentication > Locked-out Users, see Authentication.

To configure the user lockout policy:
  1. Go to Authentication > User Account Policies > Lockouts.
  2. Configure the following settings, then select OK to apply any changes:
  3. Enable user account lockout policy Enable user account lockout for failed login attempts and enter the maximum number of allowed failed attempts in the Maximum failed login attempts field.
      Specify lockout period

    Enable to specify the length of the lockout period, from 60 to 86400 seconds (or one minute to one day). After the lockout period expires, the Maximum failed login attempts number applies again.

    When disabled, locked out users are permanently disabled until an administrator manually re-enables them.

    Enable inactive user lockout Select to enable disabling a user account if there is no login activity for a given number of days. In the Lock out inactive users after field, enter the number of days, from 1 to 1825 (or one day to five years), after which a user is locked out.

Passwords

Multiple password policies can be created and implemented for different groups, as opposed to enforcing a global password policy.

When a user is a member of multiple user groups, FortiAuthenticator applies the strictest password policy settings. For example, if two password policies have different password expiry periods, FortiAuthenticator applies the shortest expiry period.

note icon For load-balancing HA (A-A), new password policy settings in user groups must be manually duplicated on the backup unit(s).

You can enforce a minimum length and complexity for user passwords, and can force users to change their passwords periodically.

For information on setting a user’s password, and password recovery options, see Editing a user.

Go to Authentication > User Account Policies > Passwords and select Create New to configure a password policy.

To set password complexity requirements:
  1. Under User Password Complexity, enter the minimum password length in the Minimum length field.
  2. note icon The default length is 8. The minimum length is 0, which means that there is no minimum length but the password cannot be empty.
  3. Optionally, select Check for password complexity and then configure the following password requirements as needed:
  • Minimum upper-case letters
  • Minimum lower-case letters
  • Minimum numeric characters
  • Minimum non-alphanumeric characters
    You can also enable Use non-alphanumeric characters in random passwords and enter the characters in the field provided.
  • Select OK to apply the password length and complexity settings.
  • To set a password change policy:
    1. Under User Password Change Policy, optionally select Enable password expiry, then set the Maximum password age.
    2. The default maximum password age is 90 days. The minimum value allowed is 14 days.

      You can also set the password renewal reminder intervals in the Send password renewal reminder on field available, separating each entry by a comma. The default is every 14, 7, 3, and 1 days.

    3. Optionally, select Enforce password history to prevent users from creating a new password that is the same as their current password or recently used passwords. Then, enter the Number of passwords to remember. New passwords must not match any of the remembered passwords.
    4. For example, if three passwords are remembered (set by default), users cannot reuse any of their three previous passwords.

    5. Optionally, select Enable random password expiry to force randomly generated passwords to expire. Then, enter the number of hours after which a randomly generated password will expire in the Random passwords expire after field.
    6. The default randomly generated password expiry age is 72 hours (or three days). The value can be set from 1 to 168 hours (or seven days).

      You can also set the number of hours users have to set a new password upon receiving a new password email link. The default is 24 hours. The value can be set from 1 to 168 hours (or seven days).

    7. Select OK to create the password policy.

    Custom user fields

    You can configure custom fields to include in the user information of local users. See Local users for information about creating and managing local users.

    To edit custom fields, go to Authentication > User Account Policies > Custom User Fields. A maximum of three custom fields can be added.

    Tokens

    To configure token policy settings, go to Authentication > User Account Policies > Tokens.

    Configure the following settings:

     FortiTokens
      TOTP authentication window size Configure the length of time, plus or minus the current time, that a FortiToken code is deemed valid, from 1 - 60 minutes. The default is set to 1 minute.
      HOTP authentication window size Configure the count, or number of times, that the FortiToken passcode is deemed valid, from 1 - 100 counts. The default is set to 3 counts.
      TOTP sync window size

    Configure the period of time in which the entry of an invalid token can trigger a synchronization, from 5 - 480 minutes. The default is set to 60 minutes.

    If the token is incorrect according to the FortiToken valid window, but exists in the sync window, synchronization will be initiated.

      HOTP sync window size Configure the count, or number of times, that the entry of an invalid token can trigger a synchronization, from 5 - 500 counts. The default is set to 100 counts.

    If the token is incorrect according to the FortiToken valid window, but exists in the sync window, synchronization will be initiated.
      Seed encryption passphrase Passphrase to derive a seed encryption key from, for seed returned when provisioning a FortiToken Mobile via web service (REST API).
    FortiAuthenticator Agent Offline FortiToken Support
      Enable offline support

    Configure to allow the Windows Agent to cache future tokens for users when they are offline. Enable this option to set the following:

    Shared secret: Set the shared secret used in offline support.

    TOTP cache size: Period of time after last login to pre-cache offline TOTP tokens, from 1 - 14 days. The default is set to 7 days.

    HOTP cache size: Period of time after last login to pre-cache offline HOTP tokens, from 1 - 1000 counts. The default is set to 10 counts.

    FortiToken Mobile Transfer
      Enable token transfer feature Enable to let users securely transfer FortiToken Mobile tokens from one mobile device to another. See Transferring FortiToken Mobile tokens from old to new devices below.
    Email/SMS
      Token timeout Set a time after which a token code sent via email or SMS will be marked as expired, from 10 - 3600 seconds (or one hour). The default is set to 60 seconds.

    Transferring FortiToken Mobile tokens from old to new devices

    Changing devices requires the user to install new tokens on their new device because the unique device ID is used to form the seed decryption key.

    caution icon If you wipe data from your device, or upgrade your device, you will need to re-provision your accounts.

    The option to Enable token transfer feature is available under Authentication > User Account Policies > Tokens.

    If it is not enabled, FortiAuthenticator blocks all requests to Transfer Activation Code (see below).

    The process for transferring a token to a new device is as follows:

    1. The end user selects a new FortiToken Mobile menu option: Initiate Token Transfer.
    2. FortiToken Mobile requests a new "Token Transfer Request" service from FortiCare, and includes the token data.
    3. FortiCare stores the token data and creates a Transfer Activation Code.
    4. FortiCare signals back to FortiToken Mobile on the old device that "Transfer Initialization" is complete.
    5. On the old device, FortiToken Mobile sends a request to FortiAuthenticator for the Transfer Activation Code.
    6. FortiAuthenticator retrieves the Transfer Activation Code from FortiCare and signals back to FortiToken Mobile (on the old device) that the Transfer Activation Code request was successful.
    7. FortiAuthenticator sends either an email or SMS to the end user with the transfer code (as a QR code in the case of email).
    8. On the new device, the end user selects  the FortiToken Mobile menu option Complete Token Transfer and enters the transfer code (or scans the QR code).
    9. FortiToken Mobile receives the token data from FortiCare and installs the token(s) on the new device.
    note icon All tokens are removed on the old device after the transfer is complete.

    User account policies

    General policies for user accounts include lockout settings, password policies, and custom user fields.

    General

    To configure general account policy settings, go to Authentication > User Account Policies > General.

    Configure the following settings:

    PCI DSS 3.2 two-factor authentication Enable to always collect all authentication factors before indicating a success or failure.

    Enhanced cryptography for storage of local user passwords

    Enable to use stronger cryptography for the storage of local user passwords.

    Note that this option cannot be disabled after 30 days of being enabled. FortiAuthenticator will send an email remainder to the administrator before the end of the 30-day period.

    Expire device login after Login session timeout for Windows machine authentication via 802.1X.
    Automatically purge disabled user accounts

    Enable to automatically purge disabled user accounts. Select the frequency of the purge in the Frequency field: Hourly, Daily, Weekly, or Monthly. Enter the time of the purge in the Time field: Now to set the time to the current time, or select the clock icon to choose a time: Now, Midnight, 6 a.m., or Noon.

    Purge users that are disabled due to the following reasons Set the reason for purging disabled users: Manually disabled, Login inactivity, or Account expired.
    Discard stale RADIUS authentication requests Enable to select a time after which RADIUS authentication requests are considered stale and are discarded, from 3 - 360 seconds (or six minutes). The default is set to 8 seconds.
    Expire inactive RADIUS accounting session after Enter a time after which RADIUS accounting sessions timeout, from 5 to 1440 minutes (or five minutes to one day). The default is set to 60 minutes.

    PCI DSS 3.2 two-factor authentication

    The login flows for RADIUS authentication, SAML IdP, Guest Portals, and GUI Login all meet PCI DSS 3.2 standards regarding multi-factor authentication.

    In the case where the Bypass FortiToken authentication when user is from a trusted subnet option is enabled (under Authentication > SAML IdP > Service Providers), and the user is logging in from a trusted subnet, the login flow reverts to password-only regardless of the PCI mode.

    The GUI login page is hard-coded to Apply two-factor authentication if available (authenticate any user), so it behaves the same as the guest portal.

    All failed authentications will return the same generic message, so as not to reveal any clue to an attacker about which piece of information was valid or invalid:

    "Please enter correct credentials. Note that the password is case-sensitive."

    Remote login to the CLI (i.e. Telnet, SSH) also complies with the new PCI requirements.

    Guest portal exception

    There is one exception for guest portals. When a user has exceeded their time and/or data usage limit, the FortiAuthenticator shows the "Usage exceeded" replacement message. The best behavior would be to only show the replacement message if the credentials are valid. However, this would require a major change in the internal flow of the current authentication implementation. Instead, the FortiAuthenticator only requires that the account name be valid (not the credentials). The downside is that it opens the door for leaking valid account names. Nonetheless, it is deemed acceptable because:

    1. Account name leakage prevention is not a PCI requirement (just a best practice).
    2. Leaked account names are not usable because they are disabled (due to exceeded usage).
    3. Disabled accounts can't be leveraged to brute-force credentials (in the hope of using them if an account gets re-enabled/usage extended).

    Lockouts

    For various security reasons, you may want to lock a user’s account. For example, repeated unsuccessful attempts to log in might indicate an attempt at unauthorized access.

    Information on locked-out users can be viewed in the Top User Lockouts widget, see Top user lockouts widget.

    Currently locked-out users can be viewed in Monitor > Authentication > Locked-out Users, see Authentication.

    To configure the user lockout policy:
    1. Go to Authentication > User Account Policies > Lockouts.
    2. Configure the following settings, then select OK to apply any changes:
    3. Enable user account lockout policy Enable user account lockout for failed login attempts and enter the maximum number of allowed failed attempts in the Maximum failed login attempts field.
        Specify lockout period

      Enable to specify the length of the lockout period, from 60 to 86400 seconds (or one minute to one day). After the lockout period expires, the Maximum failed login attempts number applies again.

      When disabled, locked out users are permanently disabled until an administrator manually re-enables them.

      Enable inactive user lockout Select to enable disabling a user account if there is no login activity for a given number of days. In the Lock out inactive users after field, enter the number of days, from 1 to 1825 (or one day to five years), after which a user is locked out.

    Passwords

    Multiple password policies can be created and implemented for different groups, as opposed to enforcing a global password policy.

    When a user is a member of multiple user groups, FortiAuthenticator applies the strictest password policy settings. For example, if two password policies have different password expiry periods, FortiAuthenticator applies the shortest expiry period.

    note icon For load-balancing HA (A-A), new password policy settings in user groups must be manually duplicated on the backup unit(s).

    You can enforce a minimum length and complexity for user passwords, and can force users to change their passwords periodically.

    For information on setting a user’s password, and password recovery options, see Editing a user.

    Go to Authentication > User Account Policies > Passwords and select Create New to configure a password policy.

    To set password complexity requirements:
    1. Under User Password Complexity, enter the minimum password length in the Minimum length field.
    2. note icon The default length is 8. The minimum length is 0, which means that there is no minimum length but the password cannot be empty.
    3. Optionally, select Check for password complexity and then configure the following password requirements as needed:
    • Minimum upper-case letters
    • Minimum lower-case letters
    • Minimum numeric characters
    • Minimum non-alphanumeric characters
      You can also enable Use non-alphanumeric characters in random passwords and enter the characters in the field provided.
  • Select OK to apply the password length and complexity settings.
  • To set a password change policy:
    1. Under User Password Change Policy, optionally select Enable password expiry, then set the Maximum password age.
    2. The default maximum password age is 90 days. The minimum value allowed is 14 days.

      You can also set the password renewal reminder intervals in the Send password renewal reminder on field available, separating each entry by a comma. The default is every 14, 7, 3, and 1 days.

    3. Optionally, select Enforce password history to prevent users from creating a new password that is the same as their current password or recently used passwords. Then, enter the Number of passwords to remember. New passwords must not match any of the remembered passwords.
    4. For example, if three passwords are remembered (set by default), users cannot reuse any of their three previous passwords.

    5. Optionally, select Enable random password expiry to force randomly generated passwords to expire. Then, enter the number of hours after which a randomly generated password will expire in the Random passwords expire after field.
    6. The default randomly generated password expiry age is 72 hours (or three days). The value can be set from 1 to 168 hours (or seven days).

      You can also set the number of hours users have to set a new password upon receiving a new password email link. The default is 24 hours. The value can be set from 1 to 168 hours (or seven days).

    7. Select OK to create the password policy.

    Custom user fields

    You can configure custom fields to include in the user information of local users. See Local users for information about creating and managing local users.

    To edit custom fields, go to Authentication > User Account Policies > Custom User Fields. A maximum of three custom fields can be added.

    Tokens

    To configure token policy settings, go to Authentication > User Account Policies > Tokens.

    Configure the following settings:

     FortiTokens
      TOTP authentication window size Configure the length of time, plus or minus the current time, that a FortiToken code is deemed valid, from 1 - 60 minutes. The default is set to 1 minute.
      HOTP authentication window size Configure the count, or number of times, that the FortiToken passcode is deemed valid, from 1 - 100 counts. The default is set to 3 counts.
      TOTP sync window size

    Configure the period of time in which the entry of an invalid token can trigger a synchronization, from 5 - 480 minutes. The default is set to 60 minutes.

    If the token is incorrect according to the FortiToken valid window, but exists in the sync window, synchronization will be initiated.

      HOTP sync window size Configure the count, or number of times, that the entry of an invalid token can trigger a synchronization, from 5 - 500 counts. The default is set to 100 counts.

    If the token is incorrect according to the FortiToken valid window, but exists in the sync window, synchronization will be initiated.
      Seed encryption passphrase Passphrase to derive a seed encryption key from, for seed returned when provisioning a FortiToken Mobile via web service (REST API).
    FortiAuthenticator Agent Offline FortiToken Support
      Enable offline support

    Configure to allow the Windows Agent to cache future tokens for users when they are offline. Enable this option to set the following:

    Shared secret: Set the shared secret used in offline support.

    TOTP cache size: Period of time after last login to pre-cache offline TOTP tokens, from 1 - 14 days. The default is set to 7 days.

    HOTP cache size: Period of time after last login to pre-cache offline HOTP tokens, from 1 - 1000 counts. The default is set to 10 counts.

    FortiToken Mobile Transfer
      Enable token transfer feature Enable to let users securely transfer FortiToken Mobile tokens from one mobile device to another. See Transferring FortiToken Mobile tokens from old to new devices below.
    Email/SMS
      Token timeout Set a time after which a token code sent via email or SMS will be marked as expired, from 10 - 3600 seconds (or one hour). The default is set to 60 seconds.

    Transferring FortiToken Mobile tokens from old to new devices

    Changing devices requires the user to install new tokens on their new device because the unique device ID is used to form the seed decryption key.

    caution icon If you wipe data from your device, or upgrade your device, you will need to re-provision your accounts.

    The option to Enable token transfer feature is available under Authentication > User Account Policies > Tokens.

    If it is not enabled, FortiAuthenticator blocks all requests to Transfer Activation Code (see below).

    The process for transferring a token to a new device is as follows:

    1. The end user selects a new FortiToken Mobile menu option: Initiate Token Transfer.
    2. FortiToken Mobile requests a new "Token Transfer Request" service from FortiCare, and includes the token data.
    3. FortiCare stores the token data and creates a Transfer Activation Code.
    4. FortiCare signals back to FortiToken Mobile on the old device that "Transfer Initialization" is complete.
    5. On the old device, FortiToken Mobile sends a request to FortiAuthenticator for the Transfer Activation Code.
    6. FortiAuthenticator retrieves the Transfer Activation Code from FortiCare and signals back to FortiToken Mobile (on the old device) that the Transfer Activation Code request was successful.
    7. FortiAuthenticator sends either an email or SMS to the end user with the transfer code (as a QR code in the case of email).
    8. On the new device, the end user selects  the FortiToken Mobile menu option Complete Token Transfer and enters the transfer code (or scans the QR code).
    9. FortiToken Mobile receives the token data from FortiCare and installs the token(s) on the new device.
    note icon All tokens are removed on the old device after the transfer is complete.