What's new in FortiAuthenticator 5.3

FortiAuthenticator 5.3 includes a host of new and expanded features.

Active Directory users password reset

This feature adds the ability to reset an Active Directory user's password from the main login page. The work flow is the same as for resetting a local user's password.

The Password Recovery Options setting is included in the remote LDAP users configuration page.

This feature is available for both self-service and guest portals.

REST API for security question

This feature provides REST API access to the password recovery security question when adding/editing a user. This includes access to add/edit the password security recovery question when adding/editing a remote LDAP user.

Enable Allow password recovery with security question and enter the password recovery question and answer string.

PCI DSS 3.2 2FA

The login flows for RADIUS authentication, SAML IdP, Guest Portals, and GUI Login are updated to meet PCI DSS 3.2 standards regarding multi-FortiAuthenticatortor authentication.

For these new login flows to take effect, go to Authentication > User Account Policies > General and enable PCI DSS 3.2 two-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 will behave the same as the guest portal.

All failed authentications will return the same generic message, so as to not 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, so 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:

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

Guest portals: SmartConnect for Windows

When the user clicks on the SmartConnect button from the post-login portal, the Platform dropdown now includes a Windows option.

The SmartConnect for Windows feature provides an executable file that adds specific network settings to an end-user's Windows device. The SmartConnect profile settings are the same as the ones implemented for iOS and MacOS. The main difference is in how the downloaded executable file is built and packaged, so that it installs seamlessly on Windows devices.

Guest portals: Token self-revocation

This feature is part of the effort to consolidate the self-service and legacy captive portals into the guest portals section. This includes improvements to Token self-provisioning, offered as a pre-login service for guest portals.

When the token self-revocation feature is enabled (under Authentication > Self-service Portal > Token self-provisioning), the guest portal's token verification page will have an additional Lost my token link. Clicking this link provides access to the token self-revocation service page that includes the following options:

Re-provision my FortiToken Mobile
Switch to email token authentication
Disable my account

Device tracking

When enabled, this feature allows end users to self-register their devices, and to have those devices tracked, based on the device MAC.

An unregistered device is granted restricted network access, and is redirected to the FortiAuthenticator guest portal. The user enters valid credentials, and then the FortiAuthenticator detects the unregistered device and offers the user an option to register it. If the user registers the device, it becomes part of their authorized device group and the user is then granted network access on that device (if the user does not register the device, they are redirected to the guest portal login page).

The MAC Devices configuration page (under Authentication > User Management > MAC Devices) offers the option to link a device to a user configuration. Similarly, it is possible to link a device from a user configuration. In either case, names and MAC addresses must be unique.

To fully benefit from this feature, you must use a FortiAuthenticator in conjunction with a FortiGate running FortiOS 6.0+.

Guest Portals: Post-Login

The Guest Portal configuration page (under Authentication > Guest Portals > Portals) offers a new post-login service for device tracking and management. When Device Tracking and Management is enabled, the administrator must specify into which device group to put the self-registered devices, as well as specify the Maximum number of devices per user (up to 20).

When enabled, users have access to a post-login interface where they can add/edit/delete their list of devices. If enabled but the device is not registered, the FortiAuthenticator presents a device registration page after account credential validation.

If the user reaches their device limit, they must select an existing device to replace. If the MAC address is currently associated with a different user, it will be re-assigned to this newly logged-in user with the following warning message:

"Your device had previously been registered by another user. Ownership has now been changed to your account."

MAC Authentication Bypass (MAB)

The existing MAB feature (under Authentication > RADIUS Service > Clients) is enhanced in order to support returning Access-Accept with different RADIUS attributes for unauthorized devices, and also to support explicitly blocking pre-defined groups of devices.

Profiles are applied in descending order based on matching RADIUS attributes. If the profile has no attributes to match, that profile will always be applied before any that follow.

When processing MAB for an authorized device associated with a user, the FortiAuthenticator returns the RADIUS attributes of the authorized device group(s) of which the device is a member as well as the RADIUS attributes from the group memberships of the associated user (if any). Additionally, any RADIUS attributes assigned directly to the associated user are returned.

Self-service URL

When using the device tracking feature, users are no longer redirected by the FortiGate after initial device registration. Instead, the FortiAuthenticator provides a specific URL for each guest portal, as derived from the guest portal name (under Authentication > Guest Portals > Portals).

When the end user navigates to the self-service URL, they must provide valid credentials to get network access, but the login does not trigger the call to the FortiGate's API.

Please note that special characters must be encoded in the self-service URL.

Firmware upgrade

When upgrading to this release, as a result of the device tracking feature, the following occurs:

MAB Unauthorized devices are set to Deny access by default for existing RADIUS clients.
MAB Blocked groups are set to empty by default for existing RADIUS clients.
Device tracking and device management are disabled by default for existing guest portals.
Existing replacement messages are left unchanged for existing guest portals.
New (default) replacement messages are added to existing guest portals.

Self-registration approval enhancements

This feature enhances the self-registration approval process by:

Allowing both users and/or administrators to approve self-registration requests.
(Optionally) Allowing self-registering users to choose the approver that will approve their request.

If Send approval request to an email list is enabled, the FortiAuthenticator sends an approval request to every email address in the list.

If Registrant must select their approver from a list is enabled, the guests are given a dropdown list of approvers to choose from on the self-registration page. The FortiAuthenticator sends an approval request to that approver's email address. The list of approvers is the union of all the users/administrators who are a member of the specified groups. Local, remote LDAP, and remote RADIUS groups are supported.

The self-registration page is a customizable replacement message. The default replacement message contains a new optional field for the self-registering guest to select an approver. The list of approvers comes from the groups specified in the configuration. For local groups, remote RADIUS groups, and remote LDAP groups with a list of imported remote LDAP users, the dropdown list is populated with the explicit list of group members.

Each approver in the dropdown list is designated as "Lastname, Firstname". In cases where first and last name are not available, an approver is designated as "username" instead. Disabled user accounts are excluded from the list. User accounts without a configured email address are also excluded from the list.

Groups for administrators

Local/remote user accounts with administrator or sponsor roles can now be entered into groups. This feature provides the following benefits:

Group filtering of administrators.
A single account for individuals needing both administrator and user roles.
Inclusion of RADIUS attributes from groups in RADIUS Access-Accept responses.

FortiToken Mobile: Transfer tokens from old to new device

This feature allows users to securely transfer FortiToken Mobile tokens from one mobile device to another. Changing devices requires the user to install new tokens on their new device (since the unique device ID is used to form the seed decryption key).

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

The new 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:

The end user selects a new FortiToken Mobile menu option: Initiate Token Transfer.
FortiToken Mobile requests a new "Token Transfer Request" service in FortiCare, and includes the token data.
FortiCare stores the token data and creates a Transfer Activation Code.
FortiCare signals back to FortiToken Mobile on the old device that "Transfer Initialization" is complete.
On the old device, FortiToken Mobile sends a request to FortiAuthenticator for the Transfer Activation Code.
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.
FortiAuthenticator sends either email or SMS to the end user with the transfer code (in QR form for email).
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).
FortiToken Mobile receives the token data from FortiCare and installs the token(s) on the new device.

All tokens are deleted on the old device once the transfer is complete.

Windows agents enhancements

FortiAuthenticator 5.3 sees the following Windows agent enhancements.

Configurable default domain

When configuring two-factor authentication in the FortiAuthenticator Agent for Microsoft Windows, you can now select a Default Domain at Logon Screen. The options are None, Most Recent, and a populated list of available domains (also configurable).

This enhancement is particularly useful for environments that have a single domain (where previously, the user had to manually pick a domain from a dropdown every single login, even in single-domain environments).

Load-balancing HA configurations

Customers with a load-balancing HA configuration can now configure the FortiAuthenticator Agent to try to reach the secondary FortiAuthenticator if the primary is unreachable, with retries occurring in the same order (in round-robin fashion).

Offline token validation at login

You can now view the time remaining for offline token validation when logging in.

For all tokens, FortiAuthenticator downloads enough offline tokens for the configured cache size plus the authentication window size (so if the HOTP cache = 50 and the HOTP window = 10, you initially have 60 tokens remaining; when tokens are displayed but not submitted to FortiAuthenticator, this ends up being fewer than 60 authentication attempts).

TLS 1.2 support

All network communications now take place over TLS 1.2. As a result, the minimum required version of the .NET Framework is now 4.6.0 (previously 4.0). The FortiAuthenticator Agent installer will offer to install TLS 1.2 when it is necessary.

Push logs included in debug logs

Push authentication logs now appear in debug logs for easier access.

DNS statistics

DNS query statistics are now available in the FortiAuthenticator GUI, which can help to improve FSSO troubleshooting and avoid confusion about potentially slow response times from the DNS server.