FortiAuthenticator provides access management and single sign on.
Article Id 204756



This article is a step-by-step guide for the following scenario:

FortiGate SSL-VPN users authenticate against FortiAuthenticator via RADIUS, which in turn checks user credentials against LDAP and triggers two-factor authentication.



One of the most common deployments of FortiAuthenticator is to provide additional two-factor authentication for users while still permitting them to use their company credentials.


Such a setup can be handled on FortiGate directly, binding a user to a specific FortiToken to enforce two-factor authentication, see for example.


In an environment with multiple FortiGates, however, this would require a token per user per FortiGate and can quickly run into scaling issues, in addition to the inconvenience of users having multiple tokens to keep straight.




FortiAuthenticator can be leveraged as a single central device to associate users and tokens, and each FortiGate would simply query FortiAuthenticator instead.

The setup is roughly as follows:




 On FortiAuthenticator, the following steps need to be undertaken:

- add FortiTokens, so they can be assigned to users

- add the remote LDAP server

-> optionally, join FortiAuthenticator to the Windows Domain to allow the MSCHAPv2 method to be used

- import users from LDAP and assign the tokens

- create a user group and realm for the LDAP users

- create a RADIUS client and policy for FortiGate(s) to connect




On FortiGate, the following needs to be configured:

- RADIUS server entry pointing back to FortiAuthenticator

- a user group including the RADIUS server

- SSLVPN settings

-> optionally, configure SSLVPN realms/specific modes/etc

- an SSLVPN policy with the user group included




1) FortiAuthenticator – add FortiTokens.

FortiTokens can be added to FortiAuthenticator under Authentication -> User Management -> FortiToken by clicking on ‘Create New’.




The FortiAuthenticator MUST have an internet connection while adding the tokens unless the tokens are FTK211xxxxxx models, as those models are shipped with their seed files on CD, which can also be uploaded to FortiAuthenticator.


Once the tokens are successfully added, they should show in status 'Available' or 'Assigned' if already added to a user:





FortiAuthenticator must have an accurate system clock, otherwise there may be issues with token drift; ensure the unit is pointed to an NTP server it can reach.

NTP settings can be done via System -> Dashboard -> Status, by editing the ‘System Time’ setting in the 'System Information' widget.


More details on FortiToken in FortiAuthenticator:


2) FortiAuthenticator – add LDAP server

The remote LDAP server can be added under Authentication > Remote Auth. Servers > LDAP by clicking on ‘Create New’.

Set the correct IP/FQDN and port, select a bind type and set a user if required.

-> If the LDAP server in question was added to the FortiGate, the settings can be viewed on FortiGate GUI and simply recreated in FortiAuthenticator

-> In this case, the FortiGates ‘CN’ setting becomes the FortiAuthenticator’s ‘Query Element > Username’ setting.


The complete configuration should look something like this:




The connection can be tested by selecting on the 'Browse' button.


If the LDAP server is a Windows AD server and MSCHAPv2 method for the later RADIUS authentication between FortiGate and FortiAuthenticator is desired, the FortiAuthenticator needs to be joined to the Windows domain:




More details on the LDAP server settings and joining a domain can be found here:



Joining a domain is very sensitive to time differences – if the FortiAuthenticator clock and domain controller clock differ more than a few seconds, this will fail. Make sure both FortiAuthenticator and domain controller use the same NTP server.


3) FortiAuthenticator – import users and assign Tokens.


For FortiAuthenticator to prompt token codes, the tokens must be assigned to users. To this end, users must first be imported.


This can be done under Authentication -> User Management -> Remote Users by selecting 'Import':




FortiAuthenticator then browses LDAP and provides a list of possible users to import:




The desired users can be selected here, and confirmed at the bottom of the page.

If the LDAP server has a large user directory, it can take some moments for FortiAuthenticator to load them.


After import, the users will be listed in the Remote Users table. They can be edited with a double-click , and a Token assigned:




If a mobile token is assigned, the user needs to have either an email or SMS set for FortiAuthenticator to send the activation email/SMS.


In addition, FortiAuthenticator may need to have an SMS gateway or SMTP server configured

More details on SMTP server:


More details on SMS gateway:


The whole process (importing users and assigning tokens) can also be automated with a Remote User Sync Rule. This imports users based on specific criteria, automatically assigns

them Tokens, and can also add them to a group automatically.


A guide to Remote User Sync Rules:


4) FortiAuthenticator – Create a user group and realm.


To manage the users more easily, groups and realms need to be configured.

User groups can be configured under Authentication -> User Management -> User Groups by selecting Create New'.


The group should be of type ‘remote LDAP’, and either have an LDAP filter set (such as CN=VPN-Users,OU=Groups,DC=test,DC=lab), or reference the users outright:





After the group has been created, edit it and set a RADIUS Attribute:


Vendor: Fortinet
Attribute: Fortinet-Group-Name
Value: whatever the VPN group should be called on FortiGate.




FortiGate will require this attribute to match the user to a group!


More details on user groups in FortiAuthenticator:


In addition to the user group, FortiAuthenticator requires a realm to be configured; this can be done under Authentication -> User Management -> Realms, by creating a new entry.

Simply assign this realm a name and map it to the VPN server.

The realm should ideally have a name similar or identical to the domain.




5) Create RADIUS client and policy.


To allow FortiGate to connect to FortiAuthenticator in the first place, a RADIUS client and policy are required (in versions 6.0 and below, a RADIUS client and profile instead of policy).

Also, RADIUS must be enabled on the FortiAuthenticator interface.


To check the interface, go to System -> Network -> Interfaces, and edit the interface that is reachable from FortiGate.

Ensure RADIUS is enabled under the section 'Services':




In addition, if FortiToken push notification is desired, ensure the FortiTokenMobile API is enabled.


A RADIUS client can be created under Authentication -> RADIUS Service -> Clients by selecting 'Create New'.

Set up an entry that the FortiGate(s) to use FortiAuthenticator will match:




An entire subnet or IP range can be configured, so multiple units can match the client entry.

The client IP needs to match the FortiGate’s source IP the firewall will use for communication to FortiAuthenticator – typically its outgoing interface.


The secret specified here will need to be set on the FortiGate as well.


A RADIUS policy can be created under Authentication -> RADIUS Service -> Policies.

This associates the client entry created above with the LDAP server, user and groups created previously.


During the configuration steps:

1) RADIUS clients: Select the appropriate client.
2) RADIUS attribute criteria: Skip.


-> The attribute criteria are relevant if requests from the same client should be handled by different policies depending on various characteristics (such as admin vs VPN authentication)
3) Authentication type: Select ‘Password/OTP’, optionally enable ‘Accept EAP’ (that is required for EAP authentication, typically in WiFi or IPSec scenarios).
4) Identity source: Select the LDAP realm created above, then enable group filtering and select the user grou(s) created previously:




-> Optionally, if FortiAuthenticator is joined to the domain, toggle on ‘Use Windows AD Domain Authentication’ to support MSCHAPv2 method.



If no groups are set, authentication will still work, but FortiAuthenticator will NOT send any group attributes, meaning FortiGate will not be able to match the user to any groups either.

5) Authentication factors: Set 'Mandatory password and OTP' or “All configured password and OTP factors”. If ‘Mandatory’ is set, users without a token will FAIL authentication.

-> Optionally, enable/disable push notification support under ‘Advanced options’

6) RADIUS response: Skip.


Save the policy after these steps. This concludes FortiAuthenticator side configuration.


Additional information on push notification:


Additional information on RADIUS policies:


6) FortiGate – RADIUS server entry.

For the FortiGate to authenticate users to against FortiAuthenticator, a RADIUS server entry is required under Users & Authentication -> RADIUS Server.


The entry should contain the FortiAuthenticator’s IP address and shared secret, the same secret as set in FortiAuthenticator RADIUS client:




Set MS-CHAP-v2 as authentication method if the FortiAuthenticator is joined to domain and ‘Windows AD Domain Authentication’ is enabled in the RADIUS policy.

If not, set PAP.

CHAP is NOT supported if FortiAuthenticator forwards the credentials to an LDAP server.


At this point, the connection status should show successful, and user authentication can be tested. There can be issues testing the authentication to GUI as there is no provision to include the token step, but testing credentials via CLI faces no such issue and returns user group information:


(#config vdom)

(#edit <vdom>)

#dia test authserver radius <FortiAuthenticator> <mschap2|pap> <user> <password>




7) FortiGate – User group.

Create a user group on FortiGate under Users & Authentication > User Group.

Set type 'Firewall', add the RADIUS server as Remote Server, and as match set the 'Fortinet-Group-Name' attribute from step 4).




8) FortiGate – SSLVPN settings.


Set up SSLVPN on the FortiGate as desired:

- external interface.

- listening port.

- tunnel IP range.

- authentication/portal mapping.





The authentication/portal mapping setting does not guarantee that members of a specified group can log in. This only happens via policies!


More details on SSL-VPN configuration on the FortiGate:


More details on SSLVPN authentication flow:


9) SSLVPN policy.


After creating the SSL-VPN settings, add an SSL-VPN policy so FortiGate even offers VPN – if there are no policies, SSL-VPN is inactive in general, even with specific VPN settings in place.

The policy needs to contain the SSL-VPN tunnel interface as source interface, and the SSLVPN tunnel range and user group as source address.


The destination can be specific internal IPs or just 'all'.





Destination ‘all’ can only be set if split-tunneling is disabled. This setting is under VPN -> SSL-VPN portals in the individual portals.

If split-tunneling is disabled, ALL traffic from the user, towards internet and intranet, will use the VPN.


Only user groups referenced in an SSLVPN policy like this can successfully connect to SSLVPN!


This concludes the FortiGate side configuration.

With this setup, VPN connections to the FortiGate will require LDAP credentials AND Token, and multiple FortiGates can re-use the FortiAuthenticator setup.

The user can connect to multiple FortiGates with the same credentials and same Token.


Related articles:

Troubleshooting Tip: How to debug FortiAuthenticator Services

Technical Tip: How to run a packet capture with FortiAuthenticator

Technical Tip: Radius authentication with FortiAuthenticator