WebMarshal v6.x Architecture Guide

Transcription

1 WebMarshal v6.x Architecture Guide October, 2007 Contents New WebMarshal v6.x Architecture 2 WebMarshal v6.x Components 3 WebMarshal Content Processing Node 6 Optional SQL Server 7 Workstation Browsers 8 Network Ports Required 8 WebMarshal Services 9 Software Requirements 9 New Concepts 10 Installation Scenario s 15 Customer Deployment Scenario s 18 This whitepaper firstly introduces the concepts behind the new architecture model for WebMarshal v6.x. The second section of the paper details the individual components and explains how each interacts with the other components. It also discusses the benefits that this new architecture provides and how you can take advantage of them. The third section covers the different installation scenarios for WebMarshal. It presents and discusses different environments where the product could be deployed. The final section looks at different company sizing scenarios, and discusses several different ways that WebMarshal could be implemented for them. These sizing scenarios are based on small, medium, large and enterprise companies. 1

2 New WebMarshal v6.x Architecture The main objectives behind the new architecture of this version were to improve scalability and manageability to meet the requirements and needs of Enterprise size installations and SME organizations looking to deliver redundancy in their Internet access. The main goals were to: Provide a single point of configuration console enterprise-wide Provide a easy to administer scalable model for enterprise-size sites and distributed or redundant deployment Allow the WebMarshal content processing nodes to update their configuration and submit logging information using minimal bandwidth Provide a unified management console enterprise-wide with the ability to manage all user sessions no matter what WebMarshal processing node Server they are connected to Provide rolled up enterprise wide reports, with remote data delivered over low bandwidth links The resulting design introduces a split deployment model where Configuration and policy is managed using a component called an Array Manager and subsequently stored into the File system of the Array Manager in XML files. Configuration and policy is sent from the Array Manager to the WebMarshal processing node servers and is applied on each server. Each of the components can be seen in the expanded diagram below. Note that the components do not require separate servers and SQL is an optional component only required if you need to collect logging data to run reports in the WebMarshal Reporting Console. A decision about the number of servers and which components to install on which servers depends on the existing company infrastructure and size. 2

3 WebMarshal v6.x Components Array Manager Recommendations The location of the Array Manager can affect the performance of the administration and configuration tools used in WebMarshal, but will not necessarily affect the web content processing performance. The recommended locations for the Array Manager are listed below, from most to least preferred:- 1. On a server that is as close as possible to the SQL Server holding the WebMarshal database, and has a LAN speed network connection to it. 2. On the same server as the SQL Server holding the WebMarshal database. This location is preferred because the Array Manager is the only component that actually communicates directly to the WebMarshal database. All the other components communicate to the database through the Array Manager. 3. On the same server as an Active Directory Global Catalog. The Array Manager communicates to the Global Catalog on a regular basis if the installation uses Active directory user groups. The Array Manager can also communicate NDS to an NDS directory server. 4. On a smaller site, the Array Manager, the WebMarshal content processing node and the SQL Database can co-exist on the same server. Configuration Changes As mentioned above, in the new architecture the Array Manager is the point where you define Configuration and Policy. The WebMarshal Console tool connects to the Array Manager (Through TCP port 19100) to retrieve the current configuration, the configuration that is displayed when the Console starts is retrieved from this (default) file location on the Array Manager C:\Program Files\Marshal\WebMarshal\ArrayManager\Policy\ArrayPolicy.Working.xml As policy or configuration information is changed in the console the changes are kept in the memory of the console application and are periodically (every 60 sec) written back to the working policy file (ArrayPolicy.Working.xml). The Array policy that is being used by the live content processing nodes is stored in the ArrayPolicy.xml file, this file is updated from the ArrayPolicy.Working.xml file when you commit any configuration changes in the console. You can revert any configuration changes that have been made since the last time you committed the configuration by selecting the Action\Revert Configuration menu option, this changes the configuration back to the current live in-use configuration by copying the ArrayPolicy.xml file to the ArrayPolicy.Working.xml file. It is the ArrayPolicy.xml file that is replicated to the content processing nodes. The content processing nodes will poll the Array Manager for updates every 1 minute by default, this value can be changed under the Array properties\advanced settings and can be set anywhere from 1 minute to 24 hours. When the content processing nodes find an updated ArrayPolicy.xml file they will download this file to their own configuration directory (C:\Program Files\Marshal\WebMarshal\Node\Policy\) and reload their configuration. All of the data transferred between the Array Manager and the content processing nodes is across one TCP port, by default

4 Supplementary Configuration Data When the content processing nodes check for a new configuration they also check for any updated supplementary configuration data which is stored in the directories under the Array Managers main configuration directory (C:\Program Files\Marshal\WebMarshal\ArrayManager\Policy) The supplementary information covers:- Categories Filtering Lists Quota Usage Templates User groups Most of this supplementary configuration information is a simple Array Manager to Content Processing Node update, i.e. one way from the Array Manager to the node. The exception however is the Quota Usage data, in order for a users quota usage information to be consistent across the entire WebMarshal array, we have to gather the current quota usage data from each node and add that into the central data at the Array Manager, which then gets sent back down to the content processing nodes. This is because if a user has a browsing session open and consumes 10 minutes of their quota then close that session, when they restart another session they may be redirected to a different content processing node by load balancing so that new node needs to be aware of the current up to date quota data. Database communications The WebMarshal optional database is used solely for logging data which is then used to create reports. The Array Manager is the only component that communicates directly to the WebMarshal Database. This communication uses TCP and defaults to the standard SQL port, 1433 by default. You can also use named pipes and shared memory (Shared Memory only supported when the Array Manager and SQL server are on the same server) The data passed between the Array Manager and the WebMarshal database is the logging data passed on from the WebMarshal Node Servers. Communication of logging data between the Node and the Array Manager is compressed to reduce bandwidth and assist in supporting WebMarshal nodes in geographically disparate locations over slow and potentially unreliable links. Corporate Directory Communications User Group Synchronization The Array Manager is also the component that communicates with any corporate directories, as defined by the directory connectors set up under Policy Elements in the WebMarshal Console tool. Depending on the type of connector, the Array Manager communicates with Active Directory natively using ADSI, or with an NDS directory. The Array Manager uses the directory to maintain a list of groups and members referenced in the WebMarshal policy. 4

5 Native Active Directory support provides greater flexibility in queries because the connector has full knowledge of any domains and their trust relationships inside an Active Directory forest; see the new concepts section for further details. The administrator can specify how often each directory is checked for changes to group membership by adjusting the properties of the connector. If any changes have been made the Array Manager refreshes the affected group to ensure it is up to date. The changes to group membership take effect immediately by updating the supplementary configuration data which the content processing nodes check on a regular basis, you do not need to commit any configuration in the WebMarshal console to reflect group membership changes. Session Authentication When a user starts a browsing session they will need to authenticate to the content processing node to validate who they are and supply a password to ensure they are that person. There are two ways of authenticating to WebMarshal, either by the user credentials or by using the workstation IP address. You can have a combination of these by assigning each method to a different proxy port, for example, user authentication on port 8080 and IP address on port Different ports can be bound to separate IP addresses on the server if desired. Authenticating by just using the workstations IP address is simple because the content processing node does not need to contact the corporate directory server to verify the authentication details, and because of this you can install the content processing nodes very securely into the DMZ as they will only need port open to talk to the Array Manager and then port 80 for HTTP traffic and the proxy port depending on what was set. The disadvantage of this however is that you cannot set policy by username or get any information back from the active sessions monitor or from reports by username, it will all be by IP address. The typical authentication method then is by username and WebMarshal supports either Basic Authentication which will prompt the user to enter a username or password when they start a browsing session or WebMarshal also supports integrated windows authentication which uses the credentials of the locally logged on user at the workstation as the authentication credentials. These credentials can come from a NT Domain, an Active Directory or a NDS based directory (transparent authentication with NDS is possible by installing a simple client side application). The content processing node will use the information supplied by the directory connector defined in the WebMarshal console to perform this authentication validation. Therefore if you are using username authentication then each content processing node will need to be able to communicate with the directory controller for the specified directory connector. WebMarshal Console Communications The WebMarshal console connects to the Array Manager through an authenticated encrypted.net remoting interface; therefore the Array Manager must be running in order to start the console. All the communications to and from the Array Manager take place over a single TCP port The console only talks to the Array Manager, never to any Content Processing node directly. Below are a series of events and how the information for those events is populated in the WebMarshal Console:- ACTIVE SESSIONS To populate the Active session information in the console, the Array Manager talks to the Controller service on the content processing node which in turn queries the Engine service to provide the required information for each user session. MALWARE SCANNER INSTALLATION STATUS The Array manager contacts the Controller service on each content processing node and performs a local test of the installed scanners and provides the updated status back to the Array Manager QUOTA USAGE There are two quota files, the master record on the Array Manager and a running copy on the content processing node of the user for which the quota had been defined. When a browsing session ends or times out, the updated quota usage data is 5

6 provided to the local running copy which the local Controller service sends back to the Array Manager to be added to the master record as part of the logging data that is regularly compressed and batched to the Array Manager. URL FILTERING LIST UPDATE STATUS The current updated state of any installed URL filtering lists is sent to the Array Manager by the Controller service on each content processing node as part of a regular heart beat batch of data submitted to the Array Manager every 30 seconds. EVENT LOGS The Event log data for each content processing node is sent by the Controller service when requested by the Array manager, it collects and sends just the information that has been requested by the filter function in the console. CONTENT PROCESSING NODE STATUS This is also part of the regular heart beat data sent to the Array Manager every 30 seconds by the Controller service on each content processing node. Console Conflicts The WebMarshal console supports multiple administrators accessing and changing policy in two ways. For rule updates a timestamp is recorded when an individual rule is being accessed, if two administrators are accessing the same rule then the following applies:- 1. First administrator opens rule and receives a timestamp 2. Second administrator opens rule and receivers a later timestamp 3. Second administrator finishes their changes and saves the rule 4. First administrator then tries to save their changes after the second administrator has already they will receive an error stating that their rule data is out of date; they can then reopen the rule and do their changes again and save the rule successfully. For other policy items like TextCensor scripts they resolve conflict by taking the last data saved as the final update, so the following will take place:- 1. First administrator opens TextCensor script and starts making changes 2. Second administrator opens same script and makes a few small changes and then saves & exits 3. First administrator saves their changes and will overwrite the changes the second administrator has made and the original version the first administrator opened and made changes to will be the finally updated version. WebMarshal Content Processing Node The function of the WebMarshal content processing node is solely to validate users and process their incoming and outgoing HTTP content according to the policy defined by the organization. A WebMarshal content processing node can generate HTTP traffic and management communication. The HTTP traffic generated by the standard processing node function consists of the supplying of any Blocked pages that a user session might get redirected to by policy. The content processing node also acts as a web proxy passing and processing outgoing web requests, downloaded HTTP content and any uploaded HTTP content. All management communication traffic is between the node and the Array Manager using a single TCP port. By default WebMarshal uses port for this purpose, the Array Manager uses back to the Controller on the WebMarshal Content Processing nodes. 6

7 Nodes retrieve configuration from a local XML configuration file that is local on the node itself. The configuration is loaded when the WebMarshal services are started, and reloaded after the node downloads an updated XML configuration file from the Array Manager (This also causes all sessions to be closed and new sessions created if a user is continuing to browse). The outgoing management communication (All coordinated by the Controller service) initiated by the node is:- Delivery of the compressed and batched logging information to the Array Manager to be on-written to the WebMarshal database for reporting purposes, as well as any updated quota data to be written to the master quota record on the Array Manager. Status information covering:- o o o o o o o Active Sessions (on demand) Installed Malware scanner status, in terms of being up to date (On demand) Installed Filtering lists, in terms of being up to date (As part of regular heartbeat to Array Manager) Event Logs (on demand) Overall status of the content processing node itself, in terms of an up to date configuration and WebMarshal services status (As part of regular heartbeat to Array Manager) Windows Perfmon statistics that can be consolidated at the Array Manager for Array wide information (on demand) A WebMarshal content processing node creates one or more log entries for each user browsing session it processes. These log entries are written to a local file queue on each WebMarshal content processing node. A Log Follower process batches this queue content to the Array Manager on a regular basis (typically every 15 seconds, or 100 records per batch). If the Log Follower cannot communicate with the Array Manager, the node continues to store records locally until it can contact the Array Manager. This design provides a highly efficient and fault tolerant method of getting the logging information into the WebMarshal database. Optional SQL Server The SQL database server (SQL 2005 or SQL Express 2005 only are supported) hosts the WebMarshal Database and is now an optional component depending on whether you wish to create reports from the WebMarshal Reporting Console. The database contains the logging information used to generate the WebMarshal reports through the reporting console. As previously described the only components that talks directly to the SQL server is the Array Manager and the WebMarshal Reporting Console. It is good practice to place the Array Manager on the same server as the SQL Server, or as close as possible. For sizing recommendations, please see the WebMarshal v6.0 sizing whitepaper. WebMarshal will have a tool to migrate the contents of an older (3.x) database; you might want to consider this when migrating from an existing installation to WebMarshal v6.x as you will be able to preserve your previous reporting data. 7

8 Workstation Browsers The client workstation browsers need to be configured to communicate through WebMarshal. You do this by configuring the browser proxy settings either at each browser or centrally using an Active Directory group policy, these typical settings are displayed below:- The main settings are the address of the WebMarshal content processing node (Which is the proxy server) or the address of the generic load balanced node, and the proxy port. The proxy port is important as that can decide how the local user authenticates with the WebMarshal content processing node; see above section on User Authentication for more details. Once the workstation browser is configured to use WebMarshal as a proxy all of the external web requests, downloaded content or uploaded content over port 80 are sent or received through the WebMarshal content processing node. The only time when WebMarshal might produce its own web content is when it is serving up a blocked page to the user because of a policy breach for example, or if the user is visiting the quota management web site. Network Ports Required Typically WebMarshal uses the following network protocols and ports:- Standard HTTP port (80) from the content processing nodes to the internet Standard Proxy Ports (8080,8081 etc) from the workstation browsers to the WebMarshal Content Processing nodes WebMarshal Node Management (19101) from the WebMarshal Content Processing nodes (Controller service) to the Array Manager WebMarshal Console (19100) from the WebMarshal console to the Array Manager WebMarshal Controller (19102) from the Array to the Manager WebMarshal Content Processing nodes (Controller service) SQL server communication (Port 1433 by default) between the SQL server and the Array Manager, and the SQL server and the WebMarshal Reporting Console 8

9 Corporate Directory ports, Active Directory native ADSI, NT Domains and NDS standard ports between the Array Manager and the corporate directory server or domain controller, and if user authentication is required, between the corporate directory server or domain controller and the WebMarshal content processing nodes. Note: All ports mentioned above (except HTTP port (80) are defaults and can be changed to meet internal security requirements if desired) WebMarshal Services WebMarshal Array Manager Central point for management and configuration in a WebMarshal Array, present on the Array Manager server for each Array. WebMarshal Node Controller Coordinates communication between the Content Processing nodes and the Array Manager, present on all the content processing nodes WebMarshal Node Engine Performs rule processing on web pages and content accessed through WebMarshal, present on all content processing nodes WebMarshal Node Proxy Retrieves web pages on behalf of users, web pages are then processed by the WebMarshal Node Engine, present on all content processing nodes. Marshal CounterSpy Updater Controls updates for the CounterSpy spyware scanner to ensure it is up to date, present on all content processing nodes Marshal PestPatrol Updater - Controls updates for the PestPatrol spyware scanner to ensure it is up to date, present on all content processing nodes McAfee for Marshal Updater - Controls updates for the McAfee AV scanner to ensure it is up to date, present on all content processing nodes Software Requirements WebMarshal v6.0 has the following minimum software requirements:- Windows Server (Standard or Enterprise) 2003 with SP1, or Windows XP Professional with SP2 Microsoft Visual C SP1 runtimes (Included in WebMarshal installation package) Microsoft XML 6.0 (Included in WebMarshal installation package) Microsoft.Net 2.0 (Included in WebMarshal installation package) For Logging & Reporting Microsoft SQL 2005 or SQL 2005 Express (4GB Limit) (SQL 2005 Express is included in WebMarshal installation package) For NDS authentication, Novell Client 4.91 or higher For Anti-Virus & Spyware scanning, any supported scanning software For URL Filtering Lists, any supported list installers 9

10 New Concepts Server Groups Server groups are a new feature of WebMarshal v6.x and they are used to organize content processing nodes into groups that have common configurations, typically site type settings like upstream proxies and so on. When you define multiple server groups in the WebMarshal Console they appear as a new node item under the Array Servers menu node as you can see below:- You can then select each server group and either accept the global array settings or override any or all of the settings, the following items can be defined for a Server Array:- Member Servers (Content Processing Nodes) Local Address Tables Ports & Authentication Forward Proxy Server Content Filter Bypass Settings Advanced Settings o Services selected for full logging o Policy poll delay (Interval that Array Manager is checked for any updated configuration Rule Containers and individual rules can also be attached to server groups allowing an administrator to effectively have different levels of policy depending on for example level of social acceptance between different countries 10

11 Rule Containers Rule containers are used to organize individual rules into groups that might be applied by geography or department, or in fact attached to one or more server groups. There is no limit to the hierarchal depth that you can use rule containers as one rule containers can contain either additional rule containers or rules. This is an example of how rule containers might be used:- 11

12 Delegated Console Administration WebMarshal v6.0 has introduced delegated administration for the WebMarshal Console, it works by defining user or group accounts and their respective security settings using the WebMarshal Security Tool, and then when the WebMarshal console is started, the local logged on user account is used to define what security settings are applied to the console session. The available security settings are:- Full Access: Includes all permissions Connect to Console: Allows the user to run the WebMarshal Console View Policy: Allows the user to view Access Policy and Policy Elements Modify Policy: Allows the user to change Access Policy and Policy Elements Modify Array Membership: Allows the user to add and remove Processing Servers from the WebMarshal Array Modify Security: Allows the user to change security settings as described here These settings are the initial ones offered in WebMarshal v6.0, Marshal is intending on extending them in future versions. An example of the WebMarshal Security Tool is below:- 12

13 Active Directory Connectors WebMarshal v6.x now supports a native Active Directory connector; this extends the previous NT Domain connector by having knowledge of the hierarchal organization of an AD directory. Below are a series of scenarios that explain practically what is now possible and what is not possible using the new connector:- SCENARIO 1 Domains: DOMAIN1 Domain Relationship: Single domain. Users: DOMAIN1\USER1 WebMarshal is joined to DOMAIN1. DOMAIN1\User1 is able to authenticate to WebMarshal. SCENARIO 2 Domains: DOMAIN2 Domain Relationship: Users: DOMAIN1 DOMAIN2 is a sub-domain of DOMAIN1 DOMAIN2\USER1 WebMarshal is joined to DOMAIN1. DOMAIN2\User1 is able authenticate to WebMarshal. SCENARIO 3 Domains: DOMAIN1 DOMAIN2 DOMAIN3 Domain Relationship: DOMAIN2 and DOMAIN3 are sub-domains of DOMAIN1 Users: DOMAIN3\USER1 WebMarshal is joined to DOMAIN2. DOMAIN3\User1 is able to authenticate to WebMarshal. SCENARIO 4 Domains: DOMAIN1 DOMAIN2 Domain Relationship: DOMAIN1 and DOMAIN2 are independent domains, with a two way trust between them. Users: DOMAIN2\USER1 WebMarshal is joined to DOMAIN1. DOMAIN2\User1 is able to authenticate to WebMarshal. 13

14 SCENARIO 5 Domains: DOMAIN1 DOMAIN2 Domain Relationship: DOMAIN1 and DOMAIN2 are independent domains, with a one way trust between them. DOMAIN1 trusts DOMAIN2. Users: DOMAIN2\USER1 WebMarshal is joined to DOMAIN1. DOMAIN2\User1 cannot authenticate to WebMarshal. SCENARIO 6 Domains: DOMAIN1 DOMAIN2 Domain Relationship: DOMAIN1 and DOMAIN2 are independent domains, with a one way trust between them. DOMAIN2 trusts DOMAIN1. Users: DOMAIN2\USER1 WebMarshal is joined to DOMAIN1. DOMAIN2\User1 cannot authenticate to WebMarshal. SCENARIO 7 Domains: DOMAIN2 DOMAIN3 DOMAIN1 Domain Relationship: DOMAIN1 and DOMAIN2 are independent domains, with a two way trust between them. DOMAIN3 is a sub-domain of DOMAIN2. No explicit relationship exists between DOMAIN3 and DOMAIN1. Users: DOMAIN3\USER1 WebMarshal is joined to DOMAIN1. DOMAIN3\User1 cannot authenticate to WebMarshal. 14

15 Installation Scenario s When planning a WebMarshal installation, you can choose to install a single server or an array of processing servers. NOTE: This version of WebMarshal does not support the Web Filter plug-in installation to Microsoft Internet Security and Acceleration (ISA) Server. You can configure WebMarshal as a chained proxy on the same server as ISA Server. Single Server or Array You should consider an Array installation of WebMarshal if the following requirements apply: High or growing Web usage volume: An Array allows you to add WebMarshal content processing nodes to provide additional capacity. Multiple Web gateways at separate locations with the same access policies and centralized reporting. A WebMarshal Array Manager can manage policy for multiple gateways over WAN connections, with a single TCP port required for connectivity in many cases. Redundancy: Each WebMarshal content processing node can continue to process requests independently if other nodes or the Array Manager fails. NOTE: To maintain session logging correctly, each client must use a single processing server for an entire browsing session. One way to achieve this requirement is to set up Microsoft Windows Network Load Balancing using the NLB Client Single Affinity setting, or a similar setting in alternative load balancing software or appliances. The WebMarshal content processing nodes can be installed in any one of these three scenarios; in each of these cases you can configure a single WebMarshal server or an array of servers. 1. Standalone non-caching proxy server In this scenario, all Web requests are passed to the WebMarshal server, and all responses are returned from the Web through the WebMarshal server. Firewall rules should be configured to restrict Web traffic to only originating from the WebMarshal server so that users cannot bypass WebMarshal. 15

16 2. Chained to another Proxy Server running on another Physical Server In this scenario, all Web requests are passed to the WebMarshal server. WebMarshal delivers the requests to the other server, and all responses are returned from the Web through the other server to WebMarshal and then to the clients. Firewall rules should be configured to restrict Web traffic so that users cannot bypass WebMarshal. Access rules on the other proxy server should be configured to allow traffic only from the WebMarshal server. NOTE: In any chained installation, WebMarshal must be the first server in the chain (the client browsers must connect to WebMarshal directly). If WebMarshal is not the first server in the chain, the WebMarshal access policy will not be applied correctly. 16

17 3. Chained to another Proxy Server running on the same Physical Server If WebMarshal is installed on the same server as another proxy server, each must use a different port. Configure WebMarshal using the WebMarshal Configuration Wizard Forward Proxy page. Be sure the other proxy software is configured appropriately. For example, WebMarshal could be configured to accept requests at the address :8080. The other proxy software might use :8082. The other proxy should only accept requests from WebMarshal. 17

18 Customer Deployment Scenario s This final section looks at some typical actual customer sites and shows how you might integrate WebMarshal v6.x. This section is divided up into four different size companies: Small Company 200 Users, single site Medium Company 750 users, single site Large Company 3000 users, multiple sites, 1 Internet Gateway Enterprise Company 50,000 users, multiple sites, multiple Internet Gateways The information and guidance provided here is only a guide and is not guaranteed to meet every customer s specific needs. Please contact a Marshal Representative for detailed guidance about your specific situation. This section does not provide hardware sizing guidelines. For more information on hardware sizing, please refer to the WebMarshal 6.0 Sizing whitepaper. Small Company The first example is a small company with 200 users at a single site. The company has a firewall device which connects through a router to the internet. The firewall has only two security domains, Public (Un-trusted) and the Internal Network (Trusted). The company uses a Microsoft Small business server environment. The integrated Exchange server is the internal server, and the integrated Microsoft ISA server is their web access server. WebMarshal is installed on this same server along with the other required resources such as IIS and the Domain Controller. This solution is based on a single server providing all of these functions which is realistic for a site with only 200 users. In this scenario, remember to configure WebMarshal use the ISA server as an upstream proxy and for the workstations to be set to contact WebMarshal for their proxy requests. 18

19 Medium Company For this example, a medium company is defined as having 750 users in a single site. They have a firewall device which connects through a router to the internet. The firewall has only two security domains, Public (Un-trusted) and the Internal Network (Trusted). The organization uses two main servers. One is used as a Domain Controller, File & Print server and also has ISA server installed just for caching. The second server runs all the Content Security products with WebMarshal content processing node, WebMarshal Array Manager and SQL Express 2005 together. This medium company has two servers, with the load split between them. The configuration is defined as:- Firewall only accepts web requests from ISA ISA only accepts web requests from WebMarshal WebMarshal accepts proxy requests from workstation browsers and forwards those requests upstream through ISA (In case content can be supplied from its cache). Workstations proxy settings set to point to WebMarshal 19

20 Large Company The Large Company is defined as 3000 users spread across multiple sites. They have one central point for Internet access where all main Internet traffic is received and sent. The remote sites utilize ATM based Wide Area Networks (WAN) for connectivity with the main office. The larger remote sites have local ADSL based internet connections just used for local web traffic. This large company uses a mixture of centrally installed WebMarshal Content Processing nodes in an array for the head office staff and also to support the small branch offices that also connect through head office for their internet access. All workstations in these two sites are configured to connect to the load balancer for proxy access; the load balancer has been configured to allow stateful sessions to ensure users connect through the same WebMarshal content processing node for the duration of their browsing session. The large branch offices have their own internet connections and therefore have locally installed WebMarshal content processing nodes; these connect back to the central head office Array Manager for configuration updates and to submit logging data, but do allow the local large branch office users to connect to the internet through their local internet connections. These users then are configured to use their local WebMarshal content processing node as their proxy. 20

21 Enterprise Company For this last example an Enterprise company is defined as having 50,000 employees spread over several countries, and multiple office locations in each country. As such they have multiple points for Internet access where internet traffic is routed. These multiple points are set up to load balanced between each other based on load and location. All the sites are joined to each other by an Internet based VPN solution. There is one main office for each country that handles the core services for that country such as Internet access but all the core services in each country are managed from the world headquarters. The HQ office has its own WebMarshal infrastructure to support its own local users, all the administration for this installation is performed locally with the local Array Manager; all reporting is for the HQ site only. Each regional office also has a WebMarshal installation for that regions use, the branch offices connect to the regional office for all Internet access. The regional administration is performed using the region s Array manager, all reporting is for that region only. In this example we have three separate, independent WebMarshal arrays. (Diagram for this configuration is on the following page). 21

22 22

23 THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE AGREEMENT OR A NON-DISCLOSURE AGREEMENT. EXCEPT AS EXPRESSLY SET FORTH IN SUCH LICENSE AGREEMENT OR NON-DISCLOSURE AGREEMENT, MARSHAL LIMITED PROVIDES THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME JURISDICTIONS DO NOT ALLOW DISCLAIMERS OF EXPRESS OR IMPLIED WARRANTIES IN CERTAIN TRANSACTIONS; THEREFORE, THIS STATEMENT MAY NOT APPLY TO YOU. This document and the software described in this document may not be lent, sold, or given away without the prior written permission of Marshal, except as otherwise permitted by law. Except as expressly set forth in such license agreement or non-disclosure agreement, no part of this document or the software described in this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of Marshal. Some companies, names, and data in this document are used for illustration purposes and may not represent real companies, individuals, or data. This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of this document. Marshal may make improvements in or changes to the software described in this document at any time Marshal Limited, all rights reserved. U.S. Government Restricted Rights: The software and the documentation are commercial computer software and documentation developed at private expense. Use, duplication, or disclosure by the U.S. Government is subject to the terms of the Marshal standard commercial license for the software, and where applicable, the restrictions set forth in the Rights in Technical Data and Computer Software clauses and any successor rules or regulations. Marshal, MailMarshal, the Marshal logo, WebMarshal, Security Reporting Center and Firewall Suite are trademarks or registered trademarks of Marshal Limited or its subsidiaries in the United Kingdom and other jurisdictions. All other company and product names mentioned are used only for identification purposes and may be trademarks or registered trademarks of their respective companies. Marshal s Worldwide and EMEA HQ Marshal Limited, Renaissance 2200, Basing View, Basingstoke, Hampshire RG21 4EQ United Kingdom Phone: +44 (0) Fax: +44 (0) emea.sales@marshal.com Americas Marshal Inc Peachtree Dunwoody Road NE, Suite 770, Atlanta, GA USA Phone: Fax americas.sales@marshal.com info@marshal.com Asia-Pacific Marshal Software (NZ) Ltd Suite 1, Level 1, Building C Millennium Centre 600 Great South Road Greenlane, Auckland New Zealand Phone: Fax: apac.sales@marshal.com 23