FortiAuthenticator user self-registration

Facebooktwittergoogle_plusredditpinterestlinkedinFacebooktwittergoogle_plusredditpinterestlinkedin

For this recipe, you will configure the FortiAuthenticator self-service portal to allow users to add their own account and create their own passwords.

Note that enabling and using administrator approval requires the use of an email server, or SMTP server. Since administrators will approve requests by email, this recipe describes how to add an email server to your FortiAuthenticator.  You will create and use a new server instead of the unit’s default server.

Watch the video

1. Creating a self-registration user group

Go to Authentication > User Management > User Groups and create a new user group for self-registering users.

Enter a Name and select OK. Users will be added to this group once they register through the self-registration portal.

2. Editing self-registration settings

Go to Authentication > Self-service Portal > General.

Enter a Site name, add an email signature that you would like appended to the end of outgoing emails, and select OK.

3. Enabling self-registration

Go to Authentication > Self-service Portal > Self-registration and select Enable.

Enable Require administrator approval and Enable email to freeform addresses, enter the administrator’s email address in the field provided, and configure basic account information to be sent to the user by Email.

Open the Required Field Configuration dropdown and enable First name, Last name, and Email address.

4. Creating a new SMTP server

Go to System > Messaging > SMTP Servers and create a new email server for your users.

Enter a name, the IP address of the FortiAuthenticator, and leave the default port value.

Enter the administrator’s email address, account name, and password.

Note that, for the purpose of this recipe, Secure connection will not be set to STARTTLS, as a signed CA certificate would be needed. 

Once created, highlight the new server and select Set as Default.

The new SMTP server will now be used for future user registration.

5. Results – Self-registration

When the user visits the login page, https://<FortiAuthenticator-IP>/auth/register/, they can click the Register button, and is then prompted to enter their information.

They will need to enter and confirm a Username, PasswordFirst name, Last name, and Email address. These are the only required fields, as configured in the FortiAuthenticator earlier.

Select Submit.

The user’s registration is successful, and their information has been sent to the administrator for approval.
When the administrator has enabled the user’s account, 

the user will receive an activation welcome email.

The user’s login information will be listed.

Select the link and log in to the user’s portal.

The user is now logged into their account where they can review their information.

As recommended in the user’s welcome email, the user may change their password. However, this is optional.

6. Results – Administrator approval

After the user requests for registration, in the FortiAuthenticator as the administrator, go to Authentication > User Management > Local Users. The user has been added, but their Status is listed as Unknown.

In the administrator’s email account, open the Approval Required email. In it, the user’s full name will appear in the email’s subject, along with their username.

Select the link to approve or deny the user.

The link will take you to the New User Approval page, where you can review the user’s information and either approve or deny the user’s full registration.

Select Approve.

 

The user has now been approved and activated by the administrator.

This can be confirmed by going back to Authentication > User Management > Local Users. The user’s Status has changed to Enabled.

7. Verifying the results

On the FortiAuthenticator, go to Logging > Log Access > Log to view the successful login of the user and more information.
Adam Bristow

Adam Bristow

Technical Writer at Fortinet
Adam Bristow is a Technical Writer working for the FortiOS technical documentation team. He has a Honours Bachelor of Arts in English and Minor in Film Studies and a graduate certificate in Technical Writing from Algonquin College. Stay tuned for more FortiOS Cookbook videos!
Adam Bristow
  • Was this helpful?
  • Yes   No
Although the FortiAuthenticator can be configured to send emails from the built-in mail server (localhost), this is not recommended. Anti-spam methods such as IP lookup, DKIM, and SPF can cause mail from such ad-hoc mail servers to be blocked. It is highly recommended that email is relayed via an official mail server for your domain.
Alternatively, you can go to System > Messaging > Email Services, set both Administrators and Users to use the new SMTP server, and select Save.
Note that the email may have been marked as Spam.
  • Chad

    Is there a way for clients to auto register and have them get a FortiToken assigned to them from a pool of available tokens?

  • PEL

    Thank you for the reply Adam.
    My apologies, I should have been a little more clear.
    Our customers desire Self-Registration with the AD Security Group restrictions. Many of our customers have the captive portal authentication conditional on a successful AD account login. The desire is to have a Self-Registration conditional on a successful AD account login. At this point, the natural question may be: “Why not continue to use captive portal authentication?” We have not found a method to get around the 24 hour re-authentication when using a captive portal authentication. In addition, some of our customers experience delays with captive portal login during peak login times. With little Self-Registration experience, I was wondering if Self-Registration was different than captive portal, in that once registered always registered (unless an administrator revokes). If so, this would remove the daily login frustration and possibly bring captive portal timeout during peak login times.
    Your thoughts are appreciated.
    PEL

    • Adam Bristow

      Hello PEL,

      If I’m understanding you correctly, your main gripe/concern is the timeout limitation for authenticated users, whether they authenticated through SSO or Captive Portal?
      If this is the case, I believe I found a command that can augment the idle-timeout.
      Authentication timeout can be set to one of three types: idle, hard, or session (under config user setting). The default is idle which is best for your situation, because as long as there is data transferred in the session, the timer will continually reset. It’s only when the timer is reached (i.e. 1440 minutes, or 24 hours, if set to the max value) that the user will have to re-authenticate.

      To augment this idle-timeout, enter the following CLI:
      config system global
      set auth-keepalive
      end

      Enabling this will extend the authentication time of the session through periodic traffic to prevent an idle timeout; this command is set to disable by defaullt.

      While it’s not a full-proof solution, I hope it is of use to you.
      Otherwise, I would recommend contacting Fortinet support at support.fortinet.com.

      Best regards,

      Adam

  • PEL

    Thank you Adam.
    Many of our FortiAuthenticator customers want to leverage the Self-Registration feature without having to approve each request to register a device, by an administrator. Preferably, the desire is to auto-approve and limit the approval against a directory security-group. Example would be, auto-approve a request to self-register if the user, who is attempting to register the device, has a valid Active-Directory account (security-group=domain users). In this way only enterprise users can self-register their device(s) and not Mr. hacker who lives next door.
    Thoughts are appreciated.
    PEL

    • Adam Bristow

      Hello PEL,

      Thank you for your question, I hope I can prove to be of use to you.

      Auto-approval for users who are members of an Active Directory account, to me, sounds possible through use of LDAP filter and RADIUS attribute; in particular, authentication for users that are “MemberOf” (attribute) SSL VPN group in Active Directory.

      First of all, go to Remote Auth. Servers > LDAP. Make sure the LDAP server on the FAC is configured with a Group membership attribute of memberOF, with the Attribute is group attribute checkbox next to it enabled.
      Assuming the FortiAuthenticator is already set up with the remote server for Windows AD, you’ll want to do the following:

      – Go to Authentication > User Groups and create a new user group.
      – Set the Type to LDAP and Specify an LDAP filter.
      – Under LDAP filter, enter a string that searches users with group membership for the security group specified in Active Directory (for example: (memberof=CN=SSLVPN,CN=Users,DC=fortilab,DC=net))
      – Then go to RADIUS Service > Clients and make sure that the Groups filter is enabled with the user group added to it.

      I hope this helps – if not, I would recommend contacing Fortinet support at support.fortinet.com.

      Best regards,

      Adam

  • biju joseph

    In this recipe if it is not mentioned how we can use the authentication on FortiAP SSID by enabling captive portal and pointing the external authentication portal. Also is it required to create RADIUS server on Fortigate and bring the user group, please clarify.

    • Adam Bristow

      Hello Biju,

      If you’d like to know how to configure a FortiAP for external/remote access, please see this other recipe here:

      http://cookbook.fortinet.com/fortiap-remote-access/

      In this instance, incorporating a FortiGate configured with RADIUS users is also not required, as the purpose of the recipe is to show how users may add themselves, with optional administrator approval.

      I hope this answers your question!

      Adam