Webauth: Forcing all users to a login page (11.x)

[Tomas]

This How-to applies to:

• Clavister Security Gateway 11.x.

This document is a quick guide to setting up a test configuration that involves User Authentication to be authorized to do web surfing via the Clavister Security Gateway.

Table of contents

• Objectives with this article
• Configuring User Authentication
• HTML Banner files
• Testing the login/logout procedure
• Troubleshooting

Objectives with this article
In this article, we will set up an environment that will grant web access to users that belong to the local user group TrustedUsers, which is defined and populated in the Local User Database, if the users authenticate themselves as members of that user group.

We use User Authentication via HTTP (WebAuth), but it can easily be upgraded to use HTTPS, which is not covered here.

There are three possible scenarios with this setup:
The user is assumed to not be logged in initially, and tries to open a webpage, say www.clavister.com, then the user is redirected to the login page and after a successful login, either of these options can happen:

• (Default) The user is redirected to the web page s/he was going to in the first place (http://www.clavister.com).
• The user is redirected to a static web page (eg the company who owns the internet connection)
• The user is redirected to a status page, saying that the login was successful. Then s/he have to re-type the URL of a web page to actually get there.

Configuring User Authentication

Creating a Local User Database

Create a new User Database and name it UserDB.

Populate the User Database with a user
Open the UserDB.
Add a New User.
Fill in username (user) and password (clavister).
Type TrustedUsers in the Groups field.

HTML Banner files
You can modify the web authentication pages, for example to include the company logotype (as an external image link), but that is not covered here.
You can also change the Redirection behaviour by opening the file "FormLogin.html" and locate the string %REDIRURL% and change it to a:

• Static url (http://www.clavister.com) to always forward the user to that page after a successful login.
• Empty string ("") to always forward the user to the status page (successful login) after a successful login.

Move the WebUI from port 80 to port 8080

System - Remote Management - Advanced Settings - WebUI HTTP Port, set the value to 8080.


Create a User Authentication rule
Go to Policies - User Authentication.
Add a new Authentication Rule and fill in as follows:

General tab

WebAuthentication_Rule.png (25.11 KiB) Viewed 3100 times

Name: HTTP_Auth
Agent: HTTP
Authentication Source: Local
Interface: Lan
Originator IP: lan_net

Authentication Options tab
Select the Local User Database named UserDB that we created earlier.


Agent Options tab
Use either the default HTTP Banners, or a set that you have created earlier.

Restrictions tab
Set the values for multiple logins and session timeout that matches your requirements.


Create Address Book Objects
Users triggering the WebAuth mechanism would be located on the LAN interface, having an IP Address in the lan_net range.
We therefore add a new object with the same IP address value but with the additional requirement that the user must be authenticated to match this object:

Open the Objects - Address Book and copy the existing lan_net object:
WebUI: Right click on lan_net and use Clone, InControl: Use copy & paste.

Modify the object to these parameters:
Name: lan_net_auth
Network: 192.168.1.0/24
Under the User Authentication tab, enter TrustedUsers in the text field.

IP Policies
We need a minimum of four IP Policies for this scenario:

1.
Action: Allow
Source Interface: Lan
Source Network: Lan_net
Destination Interface: Core
Destination Network: Lan_ip
Service: http-all
Source Address Translation: None

2.
Action: Allow
Source Interface: Lan
Source Network: Lan_net_auth
Destination Interface: Wan
Destination Network: all-nets
Service: All-services
Source Address Translation: NAT

3.
Action: Allow
Source Interface: Lan
Source Network: Lan_net
Destination Interface: Wan
Destination Network: all-nets
Service: DNS-all
Source Address Translation: Nat

4.
Action: Allow
Source Interface: Lan
Source Network: Lan_net
Destination Interface: Wan
Destination Network: all-nets
Service: HTTP
IMPORTANT:Source Address Translation: None
Destination Address Translation: Single IP: Lan_ip

WebAuth_Policies.png (24.93 KiB) Viewed 3100 times

IP Rules Explained

1. Enables users to reach the lan_ip to authenticate logins and logouts. This rule is also needed later when we redirect users from whatever page they are trying to Access to the Web Auth form.

2. Internet Access rule. When a user is authenticated this rule will start to trigger, enabling the user to browse the web etc. lan_net_auth is the Address Book object with User authentication enabled.

3. Enables DNS queries from the client to reach a DNS server. This is needed because if a user tries to open a web page, s/he needs to be able to resolve the IP in order for the web browser to open the corresponding IP address. If you have an internal DNS server, this is of course not required.

4: This address translates all destination IPs users from the lan_net are trying to access, to the lan_ip, where the Web Auth is located.This will rewrite all destination IP’s to a single IP address so they can only reach the Web Auth page.

In Summary: Unless they are authenticated, they will get forwarded to the Login page.


The ordering of the IP Rules is very important as we want the SAT rules to trigger only if the user is not authenticated. When authenticated, IP Rule (2) will trigger.

We are all set now and should be able to test the Default scenario (redirection to the URL the user was going to in the first place).

Save & Activate

Now we are finished, so you can deploy the configuration and make sure there are no error messages.


Testing the login/logout procedure

Login
To successfully test the set-up, the local group "TrustedUsers" must be populated with at least one user. Have you followed this guide, the user test can be used for testing purposes.

Your client PC should be connected to the Lan network with an address in the range specified in the lan_net network.

Now, start your web browser and go to any URL, http://www.clavister.com for example. You should be presented with a login screen. Enter the Username (user) and the Password (clavister) and click Submit.

With the default behaviour, the user is forwarded to the URL entered before the login page interfered.


Logout
In order to logout manually, the user needs to go to the http://<lan_ip>/logout page. This can be done in a variety of ways, the simplest being a shortcut (or favourite or bookmark, depending on your terminology) to this URL, or a link on your intranet.
It is also possible to go to the http://<lan_ip> URL and click on the log out link.

<lan_ip> must of course be replaced by the actual IP address of the Lan interface.

When successful, a message will appear that the user is Logged out. Surfing to any URL will redirect to the login page again.

Troubleshooting
In case the test was not successful, ensure that:

• You allow access to port 80.
• You are trying to login at an allowed time of day (i.e. 08.00-17.00 on a weekday) (schedules are not used in this example).
• The correct privilege information TrustedUsers is defined in both the local user database, and in the source network object.

[mape]

Updated 2016-12-02

[mape]

NOTE Regarding HTTPS Redirects

Some websites such as Youtube use what is known as HTTP Strict Transport Security (HSTS), which is a security policy mechanism that has been in use since a few years back. This enables websites to protect against some forms of attacks such as cookie hijacking and man-in-the-middle attacks. What happens with the login page that you want to show is similar to that, although it is not an attack but meant with good intentions. But from the browser point of view, it doesn't matter. When a visitor tries to go to Youtube, then his or her web browser has preloaded information about Youtube so when your browser is redirected to the Clavister security gateway, the data sent to the browser does not match what the browser expects and it will give you a warning page.

With older web browsers, such as Firefox 38, it is possible for the user to tell the browser to accept this data from the gateway and proceed to the login page, but more recent web browser have strict HSTS control and refuse to give users the option to continue. This is only a problem with websites that use HTTPS together with HSTS. For regular HTTPS sites it is still possible to go through the gateway to the login page. (And of course for plain HTTP).

What this means is that there is no solution for this. Unless you connect to a webpage that doesn't contain HSTS.