Fortiweb Cookbook: Basic setup - adding web site access authentication with local and remote (LDAP) users

Task: Continuing the Basic setup, we want to protect access to some pages, namely the root document "/" and "/treasure" with username and password. For this we want 2 kinds of users: local created on the Fortiweb, and remote residing in the Active Directory of the company. Even though it is insecure, the password is sent in clear text, we will use Basic HTTP Authentication for now because in the next episode we will enable HTTPS protocol.

NOTE: The Fortinet call it "authentication offloading" meaning it to be used for a web site that does not have its own authentication.

Solution:

Step 1. Let's create local user "Joe Doe" with username joedoe.
User -> Local User -> Create New ..

Additionally (not shown here), I create user "John Silver" with account johns to be allowed access to /treasure part of the website.

Step 2. Create Remote Authentication Server to authenticate AD users.
Fortiweb can work with AD/LDAP server in clear text LDAP protocol, which sends usernames/passwords in CLEAR TEXT, and therefore is not recommended. And it can communicate securely using either STARTTLS or LDAPS protocol. STARTTLS (port 389, encryption built-in) is newer but LDAP functionality is the same as with LDAPS (port 636, usual LDAP protocol wrapped in SSL). I will be using LDAPS here. For encrypted communication to work, Fortiweb has to have SSL certificate of the AD Domain Controller against which it tries to authenticate users. So first step is to import AD DC certificate into Fortiweb.

I will be using local/file importing AD-CA-cert.cer.

The result should look like:

Here, after importing AD-CA-cert.cer, Fortiweb renamed it to CA_Cert_1.

Now we can create and configure Remote Server: User -> Remote Server -> LDAP Server -> Create New.

Here:
192.168.13.82 - Active Directory Domain Controller.
636 - port of communication for LDAPS.
cn - Common Name Identifier. This setting defines how users will authenticate themselves, i.e. how they will enter their usernames. The options are:
- cn Use full name as set in AD, e.g. "Tara Addison".
- samaccountname Use account login, e.g. "tara".
- userprincipalname Use account login name + domain, e.g. "tara@nse8.com"

Bind Type - almost always use Regular here, as others are fringe cases.
User DN - username to bind with Active Directory. It is a prevalent opinion that you have to use AD Administrator or equivalent permissions here, but it is not correct - any user which can query the AD tree can be used here. I am using ldap-user that is a regular user created in built-in Users tree.
Password - password of the binding user.
Filter - Additional means of limiting who can authenticate. This filter sets specific groups/objects that can be found by this Remote Server object.

Step 3. Next, we create User Group to include users that will be able to authenticate. Unlike Fortigate, Fortiweb allows to put any type of user in the same group. But... if some user type is not compatible with the type of authentication, those users will be ignored and will fail to authenticate. E.g. For Digest Authentication, which is more secure than Basic one as it doesn't send password in clear text, only LOCAL users are supported. So, if you add Remote Users and Local users to the same User Group in the Digest User Group - local users will work, but Remote will not. Also, Fortiweb does not give you any error on that when configuring.

In this scenario with Basic authentication it works for any type of users so we add both local user and Remote Server users to the same group: User -> User Group -> Create New ..Authe Type: Basic.

Also, I create User Group "Crew" with the only member being "John Silver".

Step 4. Create Authentication Rules to define when Fortiweb is going to require users to authenticate.

Here:
User Group - User Group created earlier.
User Realm - Fortiweb requires us to set it, even if not used for anything later.
Auth Path - This is the URL that accessing it by a user will trigger Fortiweb to ask for username/password. This URL has to be EXACT match - no wildcards/regex is understood. I create 2 Authentication Rules here for 2 different server locations: "/" and "/treasure".

I do the same for the 2nd rule for John Silver access to the /treasure part of the website.
The resulting 2 rules should look like:

Step 5. Combine the created before 2 rules into a policy.No surprises here, just pick the Authentication Rules I created and set Alert Type to "All" to log both successful and failed authentications.

Step 6. I create a new Web Protection Profile by first cloning the Alert Only one (as you cannot change pre-built profiles) and then adding only authentication policy to it: Policy -> Web Protection Profile -> Inline Protection Profile -> Clone ....

I will name the new policy Custom-Alert-Only, and add the Authentication Policy auth-pol-yurisk-com.

Step 7. Finaly, I will set the Web Protection Profile in the Server Policy srv-policy-yurisk-com: Policy -> Server Policy -> Edit ...

Verification

For verification let's enter the website:

Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.