Search This Blog

Saturday, April 26, 2014

Linux - Microsoft Active Directory Integration -- An Active Directory-Enblaed Linux Web and E-Mail Security Appliance Using IPTables, Apache, Squid and Postfix

Introduction

This article describes a Linux security appliance integrated with Microsoft Active Directory.  The following article links describe the installation and configuration of each component in detail:
  1. Postfix Mail Gateway to Exchange
  2. Apache Reverse Proxy to Exchange Client Access Server
  3. Seamlessly-Authenticated Squid Proxy Server
In addition to the above services, we will also use FWBuilder to configure a host firewall for the Linux appliance.

Linux Firewall Rules



The Linux kernel includes IPTables, which maintains the tables provided by the Linux kernel firewall, the chains and rules it stores.  These may be configured at the command line or using a variety of front-ends.  For this example network, we will use FWBuilder installed on a management workstation.

FWBuilder provides the administrator a wide range of configurable objects, such as hosts, services, protocols, networks, etc.  This example includes definitions of for the Linux security appliance and its services, an Active Directory Domain Controller and its services, private and DMZ networks and the supported web and mail services.  Eleven rules protect the Linux security appliance and private network services:

0 Allow Established IP sessions
1 Allow the Linux Server to communicate with its loopback address 127.0.0.1
2 Allow Connections from the Management Workstation to the Linux Server Management Services ssh and webmin
3 Allow Connections to the Linux Server HTTP, HTTPS, SMTP and SMTPS ports
4 Allow Connections from the Private Network to the Linux Server Squid and Socks ports
5 Allow Any Connections to from the Linux Server HTTP, HTTPS, SMTP, SMTPS
6 Allow Connections from the Linux Server to the Private Network Squid and Socks ports
7 and 8 Allow Connections between the Linux Server and gateway Router DNS ports
9 and 10  Allow Connections to and from the Linux Server and the Domain Controller using a group of Windows Authentication ports
11  Deny and Log all other traffic






Microsoft Firewall Rules

Managing the Windows Firewall is simple.  Do not change anything.  However, if you wish to apply greater host security, you may specify more restrictive settings.




Windows Active Directory DNS

The authoritative Private Network DNS is maintained on Windows Server Domain Controllers.  However, since the Gateway Router in this example network is a Linux Server with BIND9 DNS installed, we will configure slave zones on the Gateway Router configured for transfers from Windows DNS.


The illustration below depicts the hosts configured in Active Directory DNS.  The cou-gateway and webmail records are manually added because these point to hosts that are not members of the Domain.  The cou-gateway record is for the Linux Gateway router and webmbail points to an address on the Linux Security Appliance that provides Apache reverse proxy connections the the Exchange Client Access Server (CAS).


We also configure Microsoft DNS to allow zone transfers and specify the it notify the slave DNS server on the Gateway Router of any changes.

The illustration below depicts the forward and reverse zones (highlighted in green) maintained as slaves on the Gateway Router.  Each zone specifies the IP address of the Windows Domain Controller as the master server.


 The slave zone on the Gateway Router is synchronized with the Domain Controller.


Microsoft Exchange Configuration

The organization has two Microsoft Exchange Servers: exchange01.mydomain.com is the Mailbox Server and exchange02.mydomain.com is the Hub Transport and Client Access Server.

Although not recommended, exchange01.mydomain.com is also the Domain Controller.  In a live network, you should not install exchange on a Domain Controller.  However, since this example network is running as virtual machines with limited memory, Exchange is running on a Domain Controller.








Testing Client Access
The client web browser is manually configured to use a proxy.pac file maintained on the firewall in the web root directory.


The file is simple for this example:


function FindProxyForURL(url, host) {
    // our local URLs from the domains below example.com don't need a proxy:
    if (shExpMatch(host, "*.mydomain.com"))
    {
        return "DIRECT";
    }

    // All other requests go through port 3128 of cou-firewall.mydomain.com.
    // should that fail to respond, go directly to the WWW:
    return "PROXY cou-firewall.mydomain.com:3128; DIRECT";
}
When the browser is opened, it prompts the user for authentication.  As described in the Squid Proxy Server article, this is an Active Directory Domain Account.  had the client been a Windows Operating System that was a member of the Domain, the users logon credentials would have been seamlessly passed to Active Directory over LDAP (or other application-specific protocols as required and supported by Microsoft Servers).




We will connect to the Linux server -- webmail.mydomain.com -- for Outlook Web Access.  The SSL certificate installed on the Linux Apache Reverse Proxy is self-generated, so the user will be warned the certificate can not be verified.  Simply add an exception for the certificate and proceed to the OWA Logon.
 




OWA will request a domain logon.  Provide the domain\username and password and the authentication will be passed to Active Directory.




Squid Analysis Report Generator

Squid Analysis Report Generator (SARG) is a servicable Squid log analyzer.  It provides information about Sites, Users, Downloads, Denied Accesses (from ACLs) and Authentication Failures.

This information is useful for monitoring and controlling web usage.  Since the web server requires authentication, it also provides verifiable details of specific user activity to support Internet Acceptable Use Policies.  Depending upon your location, this may be very important.  I happen to live in a venue in which there is very strict interpretations of company liability for Hostile Work Environment civil liability.  User-verifiable logging, coupled with an Acceptable Use Policy that requires users to maintain the secrecy of their logon information, will limit liability for unacceptable behavior.








No comments :

Post a Comment