FortiAuthenticator
FortiAuthenticator provides access management and single sign on.
Markus_M
Staff
Staff
Article Id 274443
Description

 

This article describes best practices for hardening the FortiAuthenticator.

 

Scope

 

FortiAuthenticator all versions.

 

Solution


General considerations:

FortiAuthenticator can act as a server for many protocols like RADIUS and SAML primarily, but also TACACS, openID, OAUTH, and LDAP.
Thus, FortiAuthenticator can be flexibly integrated with various environments. This may require to expose FortiAuthenticator to the Internet.

 

Of the many features that are available, not all may be used though. FortiAuthenticator has to be instructed whether the use of a protocol or feature is expected or not. By default, the FortiAuthenticator will be offering most services, but not all services will be required in every environment.

 

  • It is a best practice to review the requirements of this environment and enable only features/protocols that are needed. Which use cases does the environment have that this product should cover. This will also help in educating end users on what to expect and how certain flows are designed ('open this page, then this screen should appear....').
  • Services should also be split into multiple interfaces, so certain interfaces only are available for the respective user groups. So the admin login via the web server is not available for the external guest users, as an example. The network layout may not enable a firewall like FortiGate to serve a protecting role here.

Splitting services across the interfaces will then also serve in splitting administrative and operational access or end-user access.

  • Firewall policies can help to limit access further, and even more granular would be the FortiWeb that would allow certain URLs only.
  • Reviewing the release notes for known issues, and considerations on upgrades, can help to avoid issues.
  • Check whether FortiAuthenticator is set up with enough memory, according to the datasheet and release notes. This can avoid abnormal behavior in busier times, like the start of the shift. Requests that cannot be processed, will cause a bad user experience, but also logs that will state about timeouts or unfinished login attempts.
  • When reviewing the state of the product, it is a best practice that it operates as it should and has a regular baseline under which regular operation is expected.
  • Disabling unneeded services will have the positive effect of less load on this device (this is not only true for the FortiAuthenticator).
  • Controlling inbound and outbound traffic can also help to reduce the load on any of the processing devices.

 

The following section describes a few different scenarios, which intentionally overlap, but can stand alone on their own.

 

Scenario 1 - VPN authentication via RADIUS:

 

FortiGate offers VPN for remote FortiClient users. Authentication against FortiAuthenticator via RADIUS. FortiAuthenticator offers 2-factor authentication (2FA) with FortiToken Mobile (or FortiToken Hardware) and the end user puts in the OTP token code manually.

FortiAuthenticator is configured to use a domain controller as LDAP backend and also joined to the domain to offer MSCHAPv2 authentication for enabling password changes.

The default network configuration on FortiAuthenticator will look similar to:

Default interface service configDefault interface service config

 

 

 

 

What is required from FortiAuthenticator:

  • Listen to "RADIUS auth" requests from the RADIUS client, the FortiGate.

What is not required from FortiAuthenticator:

  • Any other service.

 

Note as an example, that the service 'LDAP' is not required, because it defines that FortiAuthenticator should listen for LDAP requests. In this case, FortiAuthenticator is the LDAP client and is not to receive requests, but creates them to another LDAP service. Responses to FAC are not needing LDAP service to listen.
The same is true for Syslog - FAC can listen for Syslog messages to use them for FSSO. Disabling this is unrelated to the capability of FortiAuthenticator sending Syslog messages to a syslog server or FortiAnalyzer.

 

To cover this given scenario, the following interface configuration is valid:

 

port1 - minimal settingsport1 - minimal settings

 

 

Scenario 2 - FTM Push:

 

Similar to Scenario 1, but adding FortiToken Mobile-Push notification instead of manual OTP input. Technical note: The “Approve/Deny” popup on FortiToken Mobile causes an HTTPS session from FortiToken Mobile to the FortiAuthenticator Address, stated in GUI -> System -> Administration -> System Access, and there is 'Public IP/FQDN for FortiToken Mobile'. The mobile will resolve this address and then connect to it through the firewall, typically with a VIP or port forwarding to the FortiAuthenticator. Regardless of the address configured, FortiAuthenticator only listens on port 443.

The implication of this is that FortiAuthenticator needs to be reachable from the Internet to receive these responses.
While push notifications offer a good user experience, they will also give a possible intrusion point to the network to be protected.


To reduce the risk, administrative and operational services should be split between interfaces. This is to avoid opening FortiAuthenticator administrative access to the internet FortiAuthenticator while only requiring a server for FortiToken Mobile push responses.

Splitting the interfaces would then as an example allow administrative access on interface port1 while allowing the operational access on port2.

 

minimal administrative access on port1minimal administrative access on port1

 

  Admin access is granted via port1 which is only accessible from inside the managed network.

 

minimal operational access on port2minimal operational access on port2

 

Port2 for push notification will then only need to have 'FortiToken Mobile API (/api/v1/pushauthresp, /api/v1/transfertoken)' enabled.
The IP address provided here must be the address that which FortiGate will forward the FortiToken Mobile Push-sourced HTTPS connections.

 

 

 

Scenario 3 - FTM Push, firewall configuration:

Taking Scenario 2 as a base. However, reviewing the requirements has shown that end users only connect from two countries (the UK and France) and only during certain times of the day (Monday-Friday 9 am-6 pm).

The FortiGate can use geographic address objects as policy objects and as such only allow access from some countries or even block access from certain countries.

A firewall policy allowing the countries France and the UK during certain day times could look like this (yellow highlight):

 

Firewall policies with geography address object and scheduleFirewall policies with geography address object and schedule

 

Here, traffic from the cell phone application FortiToken Mobile would enter wan1. Routing determines that the packets have to go to port 2. Source addresses only match if originating from these two countries. The Schedule will only match during the required shift times.
Traffic outside the schedule will be dropped. That includes FortiToken Mobile push traffic as well as any other traffic.

 

An advanced method to block unwanted addresses is to use a thread feed. FortiGate can pull a list of IP addresses from any source into a firewall address object. This can be a public list of known malware IPs for example. Putting such an object into the source of an inbound policy can help to disallow traffic from these IPs. Adding the object into an outbound policy as a destination object can block connections to these destinations. It is recommended to log this traffic, since the logged cases need investigation (of why a node is contacting an intentionally blocked address).

 

Note:

Geography-based address objects are also suited well for the SSL VPN connection itself. Setting this up can block authentication attempts from unexpected geographic locations. More details in article 191997.

 

Scenario 4 - valid HTTPS/TLS certificates:

 

Most accesses to FortiAuthenticator (or any other service), be it administrative or operational, will require encrypted communication. FortiAuthenticator acts for the administration access, guest portals as well, and FortiToken Mobile push server as a regular TLS server. Browsers, so TLS clients, are set to warn in any case of abnormality.
A working TLS server as an HTTPS web server will be accessible from the end user/admin without any warning. This will be the baseline.

 

Firefox showing a valid certificateFirefox showing a valid certificate

 

Google Chrome showing a valid certificateGoogle Chrome showing a valid certificate

 

Note that if there is a certificate warning, there will be a good reason for this and the users have to understand to not continue any further.

Make sure that any access to the FortiAuthenticator, FortiGate, or any other web server in the environment comes up with a secured connection, and inspect the provided certificate.

As an example, https://fac.forti.lab must resolve to the administrative interface address and present a certificate with the same FQDN in the subject (and SubjectAlternativeName, SAN).

 

This is true for typical websites, like Fortinet but also the captive portal, self-service portal, or admin interface on FortiAuthenticator.
Educating users to ignore certificate warnings can lead to a case in which the certificate changes due to an attack. The end user would still ignore the certificate warning and thus, allow the attacker to proceed to another step. This is an example of such a warning. End users should never see this and not get into the habit of ignoring these.

 

Example for a self-signed certificate on badssl.comExample for a self-signed certificate on badssl.com

 

General technical information about certificates and requirements can be found in this Technical Tip: TLS and the use of Digital Certific... - Fortinet Community.
For generating them and handling debugging on the FortiGate follow this Guide to FortiGate and certificate issues.

 

 

 

 

General Notes:

  1. RADIUS configuration on FortiGate:

A small advisable change is on FortiGate: Do not leave the authentication method as 'default':

 

FGT-RADIUS-Method-DEFAULT.png

 

In case of an Access-Reject, the FortiGate will try again with another method, which will still fail. It will try another method and fail again. Each time, FortiAuthenticator will test against the user database. This is likely an LDAP server, for example, Active-Directory, and the directory will also log a failure count of authentication each time.

Depending on the configuration, a user lockout is done after three consecutive login failures, which automatically happens in this situation when a user entered an incorrect password once.

The order that FortiGate uses is MSCHAPv2, CHAP, and finally PAP.

 

To avoid this, change the Authentication method to the one that works:

FortiGate specific authentication methodFortiGate specific authentication method

 

Use MS-CHAP-v2 if FortiAuthenticator is domain joined, otherwise use PAP.

 

 

  1. Two factor authentication order:

Another layer of security can be added by enabling the option 'PCI DSS 3.2 two-factor authentication' in the GUI under Authentication -> User Account Policies -> General (see screenshot). It will offer the second factor input field, regardless of the first factor, the password being correct or not. It will not give away to an attacker whether the guessed password was correct.

 

pcidss32.png

 

 

 

  1. Interface services explanation:

The interface services can be grouped as follows:

 

Admin Access: This concerns administrative interface. It does not concern any end user facing services (despite restAPI for FAC Agents, which use an admin web access key).

 

Services:

These are mixed and may not be clearly understood as to what they offer. They will depend on the functionality that FortiAuthenticator is required for.
It can be said that if a function is not used in the environment, all related services can be disabled without impacting existing services.

 

FSSO related services:

  • SAML SP SSO (offers a portal with SAML authentication for creating FSSO entries)
  • Kerberos SSO (offers a portal with Kerberos authentication for creating FSSO entries)
  • FortiGate FSSO (connections from FortiGate to the FortiAuthenticator for general FSSO communication)
  • FortiClient FSSO (used for SSO Mobility Agent)
  • Hierarchical FSSO (used for tiering multiple FortiAuthenticators)
  • DC/TS Agent FSSO
  • Syslog (used to create FSSO users with authentication success messages, received via syslog
  • Syslog over TLS
  • SAML IdP SSO
  • RADIUS Accounting SSO (used to create FSSO users with Accounting Start messages)

FortiAuthenticator as Certificate Authority, related services:

  • SCEP (Certificate enrollment protocol)
  • CMP (Certificate enrollment protocol)
  • OCSP (Certificate validity check from client to FAC as issuing CA)
  • CRL (Certificate validity check from client to FAC as issuing CA)

Portal related services - these are a bit more distinct, however can be disabled, if portals are not used.

  • Legacy Self-service Portal
  • Captive Portals
  • OAuth Service (if OpenID is used, this may have to stay enabled)
  • RADIUS Accounting Monitor (used for usage tracking of guest users)

 

The remaining services are more direct.

If SAML is not used, all SAML related services can be disabled.

If TACACS is not used, disable it.

RADSEC will be more specific, if used, it had to be explicitly configured.

LDAPS, LDAP and RADIUS Auth are offering the FortiAuthenticator as a respective server to other nodes. Disabling RADIUS Accounting does not impact RADIUS Auth.

If services are offered on port 80 and 443, the only difference will be TLS encryption. HTTP port 80 should be avoided generally as communication via port 80 is regularly unencrypted.

 

  1. Resource provisioning:

See that FortiAuthenticator as a VM has enough resources. If the web service is overused with SAML and portal queries, FortiAuthenticator needs more resources. The "Available Memory" widget may not be accurate as FortiAuthenticator kills services when it runs out of memory. The result is that it will always have enough memory on display.

A histogram on the hypervisor for memory usage will be helpful to spot these issues.

Following the general sizing guidelines will help to avoid these issues popping up in production:

Fortinet Docs: VM sizing guidelines