Untangle Network Policy - Untangle Network Security (2014)

Untangle Network Security (2014)

Chapter 10. Untangle Network Policy

Up to this point, we have learned about different rules. There are the kernel-level rules that evaluate the traffic before being processed by the different applications. The kernel level rules include bypass rules, QoS rules, input filter rules, port forward rules, and so on.

When the traffic is passed to be processed by applications, different rules will be applied on the traffic. The first rule to be applied is the one that evaluates the traffic at the session initiation such as the Firewall rule. If the traffic passes the Firewall rule, it will be scanned by other applications such as Web Filter to determine whether to allow or block the traffic. After that, there are rules that will be applied after fully classifying the traffic, such as the Application Control and Bandwidth Control rules. In addition, each individual application has rules to not scan traffic from a certain website or from certain device.

All the previous rules are based on the traffic criteria. In this chapter, we will learn how we can set rules per user or per time of day. For example, we may want to provide executives with non-restricted access to the Internet, while blocking the remaining employees of the company unless in the break hour.

First, we will need to use Untangle's Directory Connector to identify the logged in user and their Active Directory group membership. Second, we will use the Policy Manager to assign different policies to the different users based on their membership and the time of day.

Untangle's Captive Portal can be used to provide authentication for mobile devices' users and to acknowledge those users with the acceptable use policy (AUP).

Tip

The configurations done in this chapter is assumed to be done on Acme school's headquarter.

The topics that will be covered in this chapter are as follows:

· Untangle's Directory Connector

· Untangle's Captive Portal

· Untangle's Policy Manager

Directory Connector

The main functionality of Untangle's Directory Connector is to allow Untangle NGFW to communicate with Active Directory and Radius servers. Untangle's Directory Connector can be used with Captive Portal to authenticate users or to provide user details (such as the username and the security group) to other Untangle applications such as Policy Manager, Reports, and Rules (that is, username matcher).

Note

Captive Portal must be installed on Untangle NGFW after Directory Connector to work properly. If you have installed Captive Portal first, just uninstall and reinstall it.

The User Notification API

Untangle NGFW deals with clients based on their IP addresses. Thus, the discovered username will need to be mapped to the machine's IP address and stored in the host table so that other applications can use the information about this host.

The User Notification API is a web app that runs on Untangle NGFW. It is used to notify Untangle NGFW that a specific user is logged in to a specific IP address. The API can be updated as follows:

· Manually

· With the User Notification Login Script (UNLS)

· Through an Active Directory Server Login Monitor Agent

· Using a custom script or external program

To enable user notifications, we will need to enable the User Notification API from the Enabled radio button located under Directory Connector Settings | User Notification API. By default, any call from any source to the API is accepted. We can limit this by setting a secret key. Thus, the API will only accept calls that have this secret key as shown in the following screenshot:

The User Notification API

The User Notification API URL is http://<Server_IP>/userapi/registration. The user-machine details can be defined by calling the API with the following arguments:

· ClientIP

· Username

· Hostname

· Action (login, logout)

· SecretKey

For example, if we want to notify Untangle that a user named JDoe is logged in to a machine whose IP address is 192.168.2.70 and its name is JDoe-PC, using the secret key of P@$$w0rd, we will use the following URL (assuming that our Untangle internal IP is 172.16.1.1):

http://172.16.1.1/userapi/registration?action=login&clientIP=172.16.1.106&username=JDoe&hostname=Acme-Client02&secretKey=P@$$w0rd

To remove the mapping, we can use the following URL:

http://172.16.1.1/userapi/registration?action=logout&clientIP=172.16.1.106&username=JDoe&hostname=Acme-Client02&secretKey=P@$$w0rd

The previous actions will appear on the Event Log tab as shown in the following screenshot (the successive login actions will appear as and when updated):

The User Notification API

The previous method is the manual method as it is obviously clear that making users manually visit these URLs is not practical and many users may forget to do this. However, many organizations might want to script this and add it into their login/logout scripts.

Untangle offers two automated ways to update the user-machine details. The first way is by using a login script that sends the username details to Untangle. The second way is by using Login Monitor Agent that is deployed on your DCs, which monitors login events and updates Untangle NGFW. Also, any automated script that uses the previously mentioned arguments will work fine.

UNLS

UNLS is a Visual Basic script that runs at the user login process. The script will get the username and the machine's IP data and send them to Untangle's User Notification API. The script helps to automatically update the mapping between usernames and the machine's IP address.

The UNLS script runs at the user's login and periodically after every 5 minutes. If no updates come to Untangle NGFW for 10 minutes, Untangle NGFW will drop the mapping from the host table. You can download the UNLS script by pressing the Download User Notification Login Script button located under Directory Connector Settings | User Notification API, which will open a new browser window that can also be reached via http://<Untangle_IP>/adpb/ or http://<Untangle_IP>/userapi/. Clicking on the User Notification Login Script link highlighted in blue in the new page will download the UNLS script, as shown in the following screenshot:

UNLS

The downloaded script is preconfigured with server settings. However, some additional settings may be required such as the secret key.

Note

A script that can be used with Mac OS X servers can be found at http://forums.Untangle.com/directory-connector/11157-using-ut-mac-os-x-server-ldap.html.

You can then cloud deploy this login script to your network computers via a group policy. You'll need to copy the script file to the shared NETLOGON folder and then configure a Group Policy Object (GPO) to run this script at user login. The desired configurations can be found underUser Configuration | Windows Settings | Scripts (Logon/Logoff) as shown in the following screenshot:

UNLS

By default, Windows will try to run and complete all login scripts before allowing a user to log in (synchronously). This will cause problems with our script as it runs in loop and thus it never ends, so the user will wait until the login timeout occurs (about 20 minutes) before they can log in to their machine. In addition, the script may never complete with these default settings. Thus, we will need to modify additional GPO settings under Computer Configuration | Policies | Administrative Templates | System | Scripts. We will need to change the Run logon scripts synchronously configuration to Disabled and the Run startup scripts asynchronously configuration to Enabled, as shown in the following screenshot:

UNLS

Also, you will need to make sure that the Domain controller: LDAP server signing requirements setting located under Default Domain Controller Policy | Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Security is set to disabled or none.

We can only monitor the login and update events via the UNLS script. When a user logs out, the event will stop, and thus after 10 minutes, Untangle NGFW will remove the mapping. If we want to immediately remove the mapping and log the logout action, we can use another logoutscript for this purpose.

The new logout script can be the same as the login script but with some modifications:

1. Remove the loop (the Do While True loop).

2. Modify keepLooping to False.

3. Change action to logout.

4. Remove SLEEP_PERIOD = 300000 to prevent logout delay as shown in the following screenshot:

UNLS

We can review the user-machine mapping through the Host Viewer page as shown in the following screenshot:

UNLS

We can review the login and logout events via the Directory Connector events as shown in the following screenshot:

UNLS

The Active Directory Login Monitor Agent

The Active Directory Login Monitor Agent is a new feature in version 10.2 (only works with version 10.2 and higher). It's a tool that will be installed in your Domain Controllers to monitor the login events and will call the User Notification API to update the host table. The Login Monitor Agent has many advantages over the login script method. First, we won't need to create a GPO; also, we will evade the problem of some machines that don't process the group policy. Secondly, as the tool runs on the Domain Controllers, we could use the secret key so that the DC will only be able to update the user mapping. However, the users won't be able to do this as they don't have the secret key.

You can download the Monitoring agent from http://www.Untangle.com/download/LoginMonitorSetup.exe.

Note

Untangle web pages are hosted on Apache servers, so make sure from the capitalization on the URL.

You can install the Monitoring Agent on all of your DCs or only to one of your DCs. The installation process is very simple; after installing the agent, you will need to configure it as follows:

· NGFW IP: This is your Untangle server IP. If you have more than one server, you can add their IPs using the More button.

· Domain: This is the Active Directory domain that we want to record its user's login activity.

· Secret Key: The secret key to be used in communication with the User Notification API.

· Prefix: The protocol to be used in communication with the User Notification API. It can be either HTTP or HTTPS.

· Exempt IP's: Specify certain IPs or IP ranges from which any login activity won't be updated to Untangle NGFW. This can be useful with terminal servers.

· Exempt Users: Specify users whose login activities won't be updated to Untangle NGFW.

After setting the desired configuration, we will need to click on the Save andClose button.

There are some cases where many users connect to Untangle from the same machine IP such as Windows Fast Switching and terminal servers. Untangle is able to deal with the Windows Fast Switching feature by identifying the current active user on the console. As remote desktop(RD) sessions don't have console sessions, Untangle is not able to natively identify them. However, virtual IPs can be used through the Microsoft RD session host to override this limitation.

The Active Directory Login Monitor Agent

Configuring Active Directory Connector

Active Directory Connector allows users to log in to Captive Portal via their Active Directory credentials. Also, it allows Untangle NGFW to query Active Directory about the security groups that specific users belong to so that the User In Group matcher can be used. Untangle NGFW can only run with a single domain; multiple domain environments are not supported at this time.

We can configure Active Directory Connector located under the Directory Connector Settings | Active Directory Connector. First, we will need to enable the Connector, and then fill up the following required data:

· AD Server IP or Hostname: The IP or hostname of one of your Domain Controllers. Using IP is preferred to prevent any DNS issues.

· Port: By default, 389 is used, which is the default port for LDAP. If you have changed this on your Active Directory Settings page, you will need to change it here also.

· Authentication Login: This is the Active Directory user that has the ability to read all user information. You can use the administrator account or a normal account with the read-all user information delegation over the desired organization unit (OU).

· Authentication Password: The password of the user account used as the authentication login.

· Active Directory Domain: The Fully Qualified Domain Name (FQDN) of your domain.

· Active Directory Organization: The Active Directory OU that contains the desired users. By default, this field is blank, which will query Active Directory for all user accounts. If you want to limit it to a specific OU, you can add this OU (for example, to limit a query to the Sales OU that is located under the Users OU, we will use OU=Users and OU=Sales).

All these settings are illustrated in the following screenshot:

Configuring Active Directory Connector

After configuring Active Directory Connector, we can test our settings via the Active Directory Test button. If our settings are correct, we will get the success message as shown in the following screenshot:

Configuring Active Directory Connector

You can query the Active Directory users by clicking on the Active Directory Users button. All of your Active Directory users will be displayed in the box next to the button.

Note

The default setting of Active Directory is to return only 1000 user accounts. So, if your organization users are more than 1000, you will need to run the following commands on your Domain Controller to increase the returned user account to 5000:

ntdsutil.exe

LDAP policies

Connections

Connect to server <Your_Domain_FQDN>

Quit

Set MaxPageSize to 5000

Commit Changes

Quit

Quit

In addition, you can query the security groups those users belong to via the User Group Map button. The user group mapping will be displayed in a new window as shown in the following screenshot:

Configuring Active Directory Connector

By default, Untangle updates the user group mapping every 30 minutes. You can force user group mapping updates before this default period via the Refresh Group Cache button.

Connecting Untangle to a RADIUS server

Untangle is able to communicate with RADIUS servers using Directory Connector. It allows users to authenticate via the RADIUS server. You can configure the connection to RADIUS servers from Directory Connector Settings | RADIUS Connector. You can enable the connector through the Enabled radio button. Then, you'll need to configure the connector settings. The different settings are as follows:

· RADIUS Server IP or Hostname: The IP or hostname of your RADIUS server. Using IP is preferred to prevent any DNS issues.

· Port: By default, 1812 is used, which is the default port. If you have changed this on your RADIUS server, you will need to change it here also.

· Shared Secret: The shared secret configured on the RADIUS server to secure the connection with Untangle.

· Authentication Method: The authentication method used with the RADIUS server. Password Authentication Protocol (PAP) is clear text authentication while Challenge Handshake Authentication Protocol (CHAP) is a more secure method. The specified authenticationmethod should match the method on the RADIUS server.

These settings are illustrated in the following screenshot:

Connecting Untangle to a RADIUS server

You can test your configuration via the RADIUS Test button. You may need to enter user credentials to complete the test. If the authentication is successful, you'll get the following message on your screen:

Connecting Untangle to a RADIUS server

Directory Connector reports

There are different summary reports available for the Directory Connectors. The reports are as follows:

· AD Events: These show a summary about authentication events related to Active Directory such as the number of logins per hour

· Top AD Users: These give the number of logins done by Active Directory users

· Total Sessions: These give the total number of identified and unidentified sessions

· Sessions: These show a summary about the identified and unidentified login events per hour

The following screenshot shows the Top AD Users summary report:

Directory Connector reports

Untangle's Captive Portal

Captive Portal is used to enforce users' authentication before they can use the Internet. This is helpful in many cases, as follows:

· To ensure that users read and accept the AUP before they can access the Internet

· To enforce different Internet usage policies based on the username and/or device type such as wireless connected devices, BYOD, and smartphones

Captive Portal can just be used for acknowledging users, or to enforce users' authentication. Captive Portal can authenticate users against the Untangle NGFW local directory, RADIUS servers, or Active Directory. The ability to authenticate users against RADIUS servers and Active Directory requires the usage of the Directory Connector application.

Untangle's Captive Portal

The working of Captive Portal

When an unauthenticated user requests a website, the DNS query will be resolved as usual and the browser will get the IP address of the site. The browser will send a HTTP request to this IP address. Untangle's Captive Portal application will intercept any HTTP and HTTPS (requires the usage of the HTTPS Inspector application) traffic and redirect it to the Captive Portal page for acknowledging or authentication.

The Captive Portal page will only be displayed if the user was using a web browser. Untangle doesn't have the ability to open a web browser page to authenticate traffic from other sources. For example, your antivirus application won't be able to update its database until you first open a web browser and complete the authentication process. The same is true for your smartphone where all your applications won't be able to connect to the Internet till the Captive Portal authentication does.

Note

Most modern smartphones are able to detect Captive Portals and will display notifications about additional steps that are required to complete the connection to the Internet. However, if the steps didn't get completed in a certain amount of time, the smartphone will fall back to the 3G/4G connection.

Configuring Captive Portal

You have to configure Captive Portal before starting. The configuring of Captive Portal is a really simple process. The required steps are as follows:

1. We need to set up capture rules to define the traffic we want to be captured by Captive Portal (that is, the Captive Portal page will appear for traffic matching a certain criteria while any other traffic will be able to connect normally). For example, we can set traffic from wireless devices to be captured while traffic from wired devices to be passed. We will also capture traffic from students while allowing teachers to bypass Captive Portal.

Note

There is a default capturing rule that will capture traffic from all devices connected to the Untangle NGFW internal interface.

2. We need to configure the server bypass list. We can allow clients to access certain servers without authenticating via Captive Portal. This can be useful if you have web servers in your DMZ. The servers will be listed in Pass Listed Server Addresses.

3. We need to configure the client bypass list. We can allow a certain client (which is included in the capture rule clients range) to connect directly to the Internet without authentication. This can be useful when all clients are located in the same subnet. The clients will be listed inPass Listed Client Addresses.

4. We need to customize the Captive Portal page. In this step, we can configure whether the Captive Portal page will be an informative page or will be used for authentication and against which directory.

Setting traffic capture rules

Traffic capture rules are located under Captive Portal Settings | Capture Rules. There is a default rule that will capture any traffic coming from any device connected to the Untangle NGFW internal interface.

Setting traffic capture rules

The capture rules have the same properties as other rules. We will define a traffic matcher that when met, Captive Portal will capture this traffic. The available matchers are Destination Address, Destination Port, Destination Interface, Source Address, Source Interface, Protocol, Username, Client Hostname, Client in Penalty Box, Server in Penalty Box, Client has exceeded Quota, Server has exceeded Quota, Directory Connector: User in group, HTTP: Client User Agent, and HTTP: Client User OS. The available actions are to capture or pass the traffic.

Common traffic capture rules

In this section, we will review common traffic capture rules. For the complete utilization of the mentioned rules, you may need to utilize the Directory Connector and Policy Manager applications.

One of the most common rules is to pass traffic from authenticated users (in the case of using Directory Connector) and capture traffic from unauthenticated users, which will be useful with guest devices. The matcher to be used in this case is Username is unauthenticated.

Another rule that will be common if you are running a public Wi-Fi is to prohibit devices access to the Internet till they read and accept the AUP. The easiest way to achieve this is by connecting your Wi-Fi access point to Untangle NGFW on an Ethernet port that is different from the wired traffic. The matcher to be used is the Source Interface matcher.

You can also display a custom Captive Portal page to users who are in the penalty box or have exceeded their quota to notify them about that.

Another interesting use will be to run Captive Portal on the traffic coming through the WAN interface. This gives you the ability to authenticate users before they'll be able to use your internal services. For example, when you set a rule on the WAN interface, users try to access theOutlook Web App (OWA). To access their e-mails, we'll need to authenticate against Captive Portal before they are allowed to access the OWA.

HTTP: Client User Agent and HTTP: Client User OS can be used. To define smartphones, we will use *Phone* as the matcher value for iPhone and *android* for Android devices. It's preferred to try to match the traffic using both matchers.

Tip

Review the host table to get the accurate value of the client user agent and client user OS.

Configuring the passed hosts

As mentioned previously, certain hosts can bypass Captive Portal. To bypass traffic directed to a certain external server, we will use Pass Listed Server Addresses, which will be useful if we have our server on another subnet. To bypass traffic from certain hosts to any external destination, we will use Pass Listed Client Addresses. You can find both lists under Captive Portal Settings | Passed Hosts.

Note

You have to define the hosts by their IP; using URL and FQDN is not supported.

You can add the hosts via the Add button. You will need to define the IP address and whether to enable and log this traffic or not. Also, you can add a description, which is recommended. You also have the option to export the host list and import them to another Untangle server.

Configuring the passed hosts

Customizing the captive page

You can configure the captive page settings under Captive Portal Settings | Captive Page. There are two default pages; the basic message page, which can be used to provide the AUP, and the basic authentication page, which can be used to provide user authentication.

You can customize these two pages by modifying the Page Title, Welcome Text, Message Text, and Lower Text fields. The basic message page has an option to include a checkbox that the user must have read and agreed to the AUP. The basic authentication page has two additional fields: Username Text and Password Text. The authentication method to be used with Captive Portal is defined under the User Authentication tab:

Customizing the captive page

In addition, you can upload your custom page to provide additional functionality such as integrating with PayPal and charging users for Internet usage. This requires that you have good knowledge of HTML, Python, and JavaScript.

You can find simple custom pages that can help you to create your own one on http://wiki.Untangle.com/index.php/Captive_Portal#Custom_Pages.

You have the ability to preview how the Captive Portal page will look through the Preview Captive Portal Page button. Also, you can set a redirect URL to which the users will be routed after successful authentication. If you left the Redirect URL field blank, the users will be directed to their original destination.

Note

You must enter the redirect URL in the full form such as http://www.google.com; any other form won't work.

The Enable test to verify that the server root certificate is installed on the client device checkbox is useful with HTTPS traffic. Thus, if Untangle provided the Captive Portal page in HTTPS and the server certificate was not installed on the client, a warning page will be displayed to the client. This option allows Untangle to provide the download link for the root certificate in the Captive Portal page.

Setting the user authentication method

In this section, we will configure the authentication method to be used with the basic authentication page. The available options are as follows:

· Untangle local directory

· RADIUS server

· Active Directory server

· None, which is used with the basic message page

Note

The usage of RADIUS and Active Directory requires the existence of the Directory Connector application.

Under each authentication method, there is a button that will direct you to the directory configuration page. Thus, the Configure Local Directory button will direct you to Config | Local Directory where you can manage the local directory, while the Configure RADIUS andConfigure Active Directory buttons will direct you to the Directory Connector application where you can configure the connection to the RADIUS and Active Directory servers.

Untangle can auto logout devices based on the standard authentication timeout or the idle timeout. The Idle Timeout option is triggered if no traffic is received from the client for the specified time, while the Timeout option is trigged after the specified time has elapsed regardless of whether the device is active or not.

The Allow Concurrent Logins option enables users to log in from different machines using the same credentials. Simultaneously, disable this option if you want users to have one session only, as shown in the following screenshot:

Setting the user authentication method

Reviewing Captive Portal events

The current active sessions can be monitored from Captive Portal Settings | Status. This tab provides the username and the IP address of the machine the user logged in from. It also shows the login time and the total number of user sessions. You are able to enforce user logout through the X button. Anonymous will be the username of any user accessed through the basic message page, while the name of any authenticated user will be displayed as shown in the following screenshot:

Reviewing Captive Portal events

The User Event Logs tab provides an overview of the login/logout activity since the last server restart. The event logs provide the timestamp, username, client IP, the login or logout action, and the authentication method used as shown in the following screenshot:

Reviewing Captive Portal events

The rule event log provides an overview of the traffic that matched a capture rule. The event log provides the timestamp, client IP and port, destination IP and port, and the rule ID of the matched rule, and if the traffic was captured or passed. The passed traffic will only be logged if the log checkbox is selected on the rule, as shown in the following screenshot:

Reviewing Captive Portal events

In addition, we can review the Captive Portal summary from the application faceplate, which gives an overview of the number of allowed/blocked sessions, number of DNS lookups done by the clients, and the number of successful logins done via the Captive Portal page as shown in the following screenshot:

Reviewing Captive Portal events

Reports also provide a good summary of the Captive Portal activity. The available reports are as follows:

· Usage: This shows a summary about the number of login/timeout/logout events per hour.

· Top Captive Portal Users: This shows the top users to authenticate via Captive Portal.

· Top Blocked Clients: This shows the clients who tried to access the Internet before authentication. The sessions will be blocked and the client will be directed to the Captive Portal page.

Reviewing Captive Portal events

Untangle's Policy Manager

Untangle's Policy Manager allows you to set different policies based on the username, date, and time. For example, you can provide teachers with a spam filtering feature and allow them to access Facebook and YouTube anytime and use BitTorrent applications, while completely blocking all of this for students, and for the administrative users, you can allow them to access Facebook and YouTube during break time only.

We have already covered a whole set of applications settings for different users or based on different dates and times. A complete set of applications is known as a rack. So, to set different policies for teachers, students, and administrative users, we will need to use three different racks.

Achieving the desired different polices is very simple with Policy Manager. Without Policy Manager, you have to manually add exceptions on each application, and you may have had to use IP reservation. The whole process will be complex and not practical. In addition, without Policy Manager, you won't be able to set different rules based on the time of day or the day of the week.

In Untangle NGFW, we will need to create policies (or racks) and rules. Policies contain the configuration for an application while the rules contain the routing criteria to different racks.

Configuring Policy Manager policies

Using the previous example, we will need to create three different racks (that is, teachers, students, and administrative). By default, there is a default rack, which we have been using throughout the book. It can be renamed, but not removed.

When a rule is matched, the traffic will be directed to the appropriate rack. However, if no rule is matched, the traffic will be directed to the rack with ID 1, which will probably be your default rack unless you have changed the order. Thus, it's advisable to set the rack with ID 1 to the most restrictive settings.

Tip

You can change the rack IDs by changing the ID field next to each rack. However, you still have to have a rack with ID 1. So, when you change the default rack ID to something else than 1, you have to give another rack the ID 1.

We have two options to deploy our scenario: the first is to use the firewall application on the default rack and configure it to block any traffic, and use three separate racks. The second option is to use the default rack as the students rack as it would be the most restrictive one and just create two additional racks.

Parent and child racks

Instead of configuring the new racks from the beginning, you can use the parent and child racks. The child rack will inherent all settings from the parent rack. However, you can still customize the child rack by adding additional applications that do not exist in the parent rack or change individual application settings. This is useful to replicate Virus Blocker and Spam Blocker settings, which will probably not change between racks, while also having the ability to set different settings for other applications such as Web Filter.

For our scenario, we will use the default rack as the students rack. Create a child rack for the administrative rack with the students rack as the parent rack. The administrative and students racks will have the same settings unless in the break time. We will create a new rack (with no parent) for the teachers. To add a new rack, press the Add button located under Policy Manager Settings | Policies. A new screen will appear from which you can customize your rack settings, as shown in the following screenshot:

Parent and child racks

The different racks will be the same as shown in the following screenshot:

Parent and child racks

Configuring the racks is not done through Policy Manager, but in the rack itself, which we have done in the default rack throughout the book. You can switch between racks from the menu located at the top of the screen:

Parent and child racks

The teachers rack will be empty since we created it as a new rack and didn't use a parent rack. However, you will still find the services part from the rack as it is shared between racks and any change on it is global and not limited to the rack unlike the application part, which is rack dependent. The following screenshot shows the teachers rack after adding the Web Filter, Virus Blocker, and Spam Blocker applications:

Parent and child racks

The administrative rack by default will have the same applications and services as the students rack. However, the applications will be grayed out and you can't configure them from the child rack. Any general modification on the applications will be done from the parent rack.

Instead of using the inherited application settings, you can configure rack-specific settings by adding additional applications, or enable modification to grayed out applications by installing them to the rack (they are available for installation from the apps list).

The students rack has the paid Web Filter and Application Control and Bandwidth Control applications. The following screenshot shows the administrative rack after installing the paid Web Filter and Phish Blocker applications (notice the applications inherited from the parent rack as available for installation):

Parent and child racks

After the illustration of the different rack options, you are able to configure the racks' applications the way you want. For our demo, we will set the students rack to block social networking, allow social networking for teachers anytime, and allow social networking for the administrative rack between 12:00 p.m. and 1:00 p.m. Thus, both the administrative and teachers racks will have social networking enabled in Web Filter.

Configuring Policy Manager rules

After setting up the new racks and completing their configurations, we shall start to set rules that will direct traffic for the appropriate rack. The different available matchers include Destination Address, Destination Port, Destination interface, Source address, Source Interface, Protocol, Username, Time of Day, Day of week, Client Hostname, Client in Penalty Box, Server in Penalty Box, Client has exceeded Quota, Server has exceeded Quota, Directory Connector: User in group, HTTP: Client Use Agent, and HTTP: Client User OS.

Policy Manager will periodically check for traffic criteria changes to redirect the traffic to the new appropriate rack. You can add rules from the Add button located under Policy Manager Settings | Rules. For our scenario, we will need to add the following rules:

· Rules for teachers rack:

o Directory Connector: user in group is a teacher

o Target Rack: teachers

· Rules for administrative rack:

o Directory Connector: user in group is an administrative user

o Time of day is 12:00-13:00

o Target Rack: administrative

· Rules for students and administrative users within business hours:

o Directory Connector: user in group is a student and administrative users

o Target Rack: students

Other traffic that doesn't match the preceding criteria (for example, username is administrator, which is not a member of the preceding groups) will be processed by the default rack and the default rack settings will be applied on it.

The > No Rack Target Rack option will let the traffic assigned to it be processed as if it was generated from the Untangle NGFW server itself. Thus, no restrictions will be applied on it. The rack name will be displayed in the events as a Services rack.

Reviewing the Policy Manager events

The Policy Manager events can help us to diagnose our rules setup and ensure that our policies are working right. You can find the event logs under Policy Manager Settings | Event Log. The main points on the event logs are the username, IP address, and the assigned rack. The following screenshot shows a sample event log:

Reviewing the Policy Manager events

In addition to the preceding event logs, other applications' (which are set as matchers) event logs may be helpful for tracking whether the Active Directory authentication is done correctly or not.

We can also get a summary report about the Policy Manager activities via the Reports application. The available reports are as follows:

· Bandwidth Usage: This gives the average KB/sec per rack and the total amount of downloaded data per rack

· Sessions By Policy: This gives the average and total MB/hour per rack

· Traffic By Policy: This shows the average and total KB/sec per rack

· Top Policies By Sessions: This shows the number of sessions per rack

· Top policies By Bandwidth: This shows the amount of downloaded data per rack

The following screenshot shows the Top Policies By Sessions summary report:

Reviewing the Policy Manager events

Summary

In this chapter, we covered three powerful tools from Untangle that allow us to control user privileges on the network by identifying the user and giving them the appropriate level of access based on their membership details. Directory Connector allowed us to integrate Untangle NGFW with external RADIUS and Active Directory servers to collect user data. Captive Portal allowed us to prohibit any access to the Internet until the user authentication, which greatly helps in public Wi-Fi and guest network scenarios. Policy Manager allowed us to apply different policies and settings on different users based on their criteria such as username and group membership. Also, it allowed us to control these policies based on time.

In the next chapter, we'll cover WAN-related services. Untangle provides two applications to help us to provide highly available, stable, and reliable WAN connection. Untangle's WAN Balancer allows us to provide higher throughput to our network by distributing the load between the different WAN NICs. Untangle's WAN Failover allows Untangle NGFW to provide an undisturbed WAN connection by failing over to one NIC when the second one fails.