Top Banner
Enterprise Vault Using Enterprise Vault in a secure Network Best Practice Version 1.0 Glenn Martin Technical Product Manager Mar 27 th 2007
17

Best Practice for Using EV in Secure Networks

Oct 02, 2014

Download

Documents

zuperjotmeil
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Best Practice for Using EV in Secure Networks

Enterprise Vault

Using Enterprise Vault in a secure Network Best Practice Version 1.0

Glenn Martin

Technical Product Manager

Mar 27th 2007

Page 2: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 2 of 17

Table of Contents

TABLE OF CONTENTS 2 

DOCUMENT OVERVIEW 3 Introduction 3 Scope of Document 3 Target Audience 3 Acknowledgements 3 

NETWORK ISOLATION OVERVIEW 4 Industry Trends 4 Enterprise Vault Network Requirement Overview 5 

ENTERPRISE VAULT NETWORK REQUIREMENT DETAIL 6 EV Client Connectivity using RPC 6 EV Client Connectivity using Outlook RPC over HTTP 7 EV Client Connectivity using Outlook Web Access 8 EV Server Connectivity 9 

SECURE NETWORK SCENARIO 10 

MICROSOFT REFERENCES 11 

Server & Domain Isolation Articles 11 

Netbios over TCP/IP 11 

SQL References 12 

Page 3: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 3 of 17

Document Overview

Introduction This best practice document discusses the configuration requirements and considerations

when operating Enterprise Vault servers in networks that use Firewalls to control network

access. With the rise of viruses, worms, malware and other security issues some

organisations have taken the decision to separate their corporate network and isolate

segments that servers are attached to. Firewalls are then used to control what TCP/IP ports

the clients can use to access the applications hosted on the servers. This paper considers the

impact this has on Enterprise Vault and the actions that are required to ensure its smooth

operation in a secure network.

Scope of Document This document is concerned with the network configuration issues to ensure EV operates

correctly in a secure network. This relates specifically to the TCP/IP port requirements that

EV has in order to communicate correctly with clients and other infrastructure components

such as Exchange, SQL and AD servers. The use of IPSEC policies to secure and manage

access to an Enterprise Vault server is outside the scope of this document.

Target Audience This document is aimed at customers, consultants and support staff and it is assumed the

reader has a good understanding about the architecture and operational aspects of an

Enterprise Vault server, Microsoft Exchange as well as Active Directory terminology. This

document also discusses certain networking principles so it’s assumed that the reader is

familiar with TCP/IP fundamentals.

Acknowledgements I would like to acknowledge the contribution that other individuals made towards making this

a successful and informative document. Contributions and feedback came from the following

teams; technical product management, technical field enablement, engineering, development

and the performance team. Thanks to them all.

Page 4: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 4 of 17

Network Isolation Overview

Industry Trends Organisations are starting to take a more aggressive stance to ensure that their core infrastructure is well protected against various forms of malware or other malicious attacks. The extent to which organisations implement a locked down environment will vary but various methods will be used based on the level of protection that an organsation requires. In many typical environments a user workstation can connect to any server which is available on the network. This also means that if the workstation can connect to any server, so can any software that runs on that workstation; more specifically spyware, viruses or Trojans. Whilst almost all organisations take counter measures to avoid users being able to accidentally run malware, it can not guarantee that this won’t occur. Equally, many organisations prohibit the connection of non corporate devices (such as laptops) to their network but can’t always control this. So it is with these thoughts in mind that some organisations are now placing restrictions on network connectivity for servers and workstations. Network Virtualisation Isolating a network using virtual LANs (VLANs) has been a common method of restricting or managing network traffic. This has also been built on in recent years through the use of layer 3 switches to segment networks at an IP level. Organisations will typically use a combination of this technology to group different networks together to optimise network traffic flows. Virtual Private Networks Isolating networks using VPN technology has become widespread to allow such things as connecting remote offices or users to corporate resources across public networks such as the internet. More recently, some organisations are starting to treat their corporate network as an untrusted environment and will use a variety of VPN methods to allow their users to only connect to the server resources they require. Adopting this ensures only properly configured clients are able to connect to the corporate network and access such things as email services. Firewall Control Firewalls have been around a long time and many organisations feel comfortable in using them to protect networks. They will typically be used to create a barrier between the server and workstation networks to control what protocols can be use to communicate with each other. This may even extend to an even more granular level and control exactly what servers an individual or group of workstations can communicate with. More recently, client firewalls have emerged to be a more standard part of the client – these also need careful configuration to ensure the client can access the appropriate servers. IPSec IPSec is an open standard and can provide an integrated network security mechanism which works at the packet level. Packets are encrypted and only exchanged between the server and trusted clients according to policies created on the server. IPSec's other benefit, other than encryption, is verification such as Windows' built-in authentication scheme, Kerberos. Some organisations are choosing to implement IPSec so that non domain member machines can not initiate IP communication unless appropriately configured with IPSec. The use of EV with an IPSec network is outside the scope of this document but the appendix does refer to a number of Microsoft articles which relate to how IPSec can be used to secure workstations and servers within an Active Directory environment.

Page 5: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 5 of 17

Enterprise Vault Network Requirement Overview Enterprise Vault is a complex application that needs to be able to communicate with a variety of servers within an enterprise; additionally the end users of EV also need to be able to access their archived content using a number of different methods. In an open network these complexities do not present significant planning or design issues when building an EV infrastructure. However, as additional networking components or controls are introduced into an EV environment, further consideration is required to ensure that the users can seamlessly communicate with the EV server and that the EV server is able to communicate with the relevant servers and services it requires in order to function normally. The diagram below shows a typical EV deployment and the network connectivity that is required by the various components. This depicts a simple and open network with all the components being able to communicate freely with each other.

This is a high level network diagram; the connection specifics for each component will be broken down into more detail in the next section of this document.

Page 6: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 6 of 17

Enterprise Vault Network Requirement Detail

EV Client Connectivity using RPC The EV client add-in to Outlook uses a combination of RPC and HTTP connections to provide the client with access to the various archive, retrieval and search features. Outlook connects to Exchange using MAPI via RPC calls which has traditionally been direct over the LAN or WAN. This is still the most popular connection method but with OL2003 it is also possible to use RPC over HTTP which encapsulates the RPC calls through a HTTP, this has impact on how EV access is configured and is discussed in more detail later in this document

The diagram below walks through the connection process for Outlook and the EV client.

Page 7: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 7 of 17

EV Client Connectivity using Outlook RPC over HTTP With Outlook 2003, users can access mailboxes on Exchange Server 2003 using Remote Procedure Call (RPC) over HTTP. With this method, the MAPI protocol is used to tunnel Outlook RPC requests inside an HTTP session. This allows remote Outlook 2003 users to connect to their Exchange Server mailbox, without the requirement for Outlook Web Access (OWA) or a virtual private network (VPN) connection. The HTTP session terminates at a server running Internet Information Services (IIS) that has the MS Windows Server 2003 RPC over HTTP Proxy networking component installed. This server is called an RPC proxy server and provides connectivity to Exchange and EV, although the EV client can also connect directly to the EV server via HTTP if a direct network path is available.

Page 8: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 8 of 17

EV Client Connectivity using Outlook Web Access When using Outlook Web Access (OWA) the main requirement for the client browser is to able to communicate on Port 80 or 443. Note that the client only needs to communicate with Exchange and not directly with the EV server. EV requests are proxied via the Exchange server. This diagram shows a firewall or ISA server between the client the Front End server but of course there are other devices that can provide a similar function. The main point being made here is that the client only needs port 80 or 443 access through to the FE infrastructure. The other point to note is that the client needs to be able resolve the FE hostname which would typically be published on external DNS. Whilst this is a typical configuration that would be used to provide OWA access to clients on the Internet, this model can also be used where the corporate network is treated as untrusted.

Page 9: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 9 of 17

EV Server Connectivity This diagram shows the various components that will be found in most types of EV environments. Not all environments will have all the components shown but they are represented here for the sake of completeness. There is a label next to each component with details about the TCP/IP ports which are used for communications to and from the EV server.

Page 10: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 10 of 17

Secure Network Scenario The previous diagrams went into detail at the network level for the various components used within the EV infrastructure. The following diagram shows the overal layout of a network that has been locked down and how users and servers are seperated.There of course variations on how the different components can be seperated but this diagram is intended to convey the concepts of some of the network designs now being implemented by certain organisations.

Page 11: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 11 of 17

Microsoft References

Server & Domain Isolation Articles Server and Domain Isolation TechNet Web site http://www.microsoft.com/sdisolation Introduction to Server and Domain Isolation with Microsoft Windows http://www.microsoft.com/downloads/details.aspx?FamilyID=9a3e2b2b-695d-4ff9-bcb1-5f2f3001845e Server and Domain Isolation Using IPsec and Group Policy Guide http://www.microsoft.com/technet/security/guidance/architectureanddesign/ipsec/default.mspx Server and Domain Isolation Case Studies http://www.microsoft.com/sdisolation Microsoft IT Showcase: Improving Security with Domain Isolation: Microsoft IT Implements IP Security (IPsec) http://www.microsoft.com/downloads/details.aspx?FamilyId=A97DDC48-A364-4756-BB3C-91DA274118FE&displaylang=en

Netbios over TCP/IP Direct hosting of SMB over TCP/IP http://support.microsoft.com/default.aspx/kb/204279

Page 12: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 12 of 17

SQL References

EV obviously has a major dependency on SQL and a clear communication channel is required at all times from the EV to the SQL server. It’s not the intention of this document to specify the best practices for configuring SQL specifically for EV because it’s quite likely that the SQL server being used for EV purposes will also be hosting other databases. Therefore this page has been included to draw the reader to some of the relevant references when considering the network placement of the SQL server within an EV infrastructure

The following paragraphs are extracted from Microsoft’s SQL Online MSDN content.

Prior to Microsoft SQL Server 2000, only one instance of SQL Server could be installed on a computer. SQL Server listened for incoming requests on port 1433, assigned to SQL Server by the official Internet Assigned Numbers Authority (IANA). Only one instance of SQL Server can use a port, so when SQL Server 2000 introduced support for multiple instances of SQL Server, SQL Server Resolution Protocol (SSRP) was developed to listen on UDP port 1434. This listener service responded to client requests with the names of the installed instances, and the ports or named pipes used by the instance. To resolve limitations of the SSRP system, SQL Server 2005 introduces the SQL Server Browser service as a replacement for SSRP, more information can be obtained at the following MS link

http://msdn2.microsoft.com/en-us/library/ms181087.aspx How the SQL Server Browser Works When an instance of SQL Server starts, if the TCP/IP or VIA protocols are enabled for SQL Server, the server is

assigned a TCP/IP port. If the named pipes protocol is enabled, SQL Server listens on a specific named pipe. This port, or "pipe," is used by that specific instance to exchange data with client applications. During installation, TCP

port 1433 and pipe \sql\query are assigned to the default instance, but those can be changed later by the server administrator using SQL Server Configuration Manager.

Because only one instance of SQL Server can use a port or pipe, different port numbers and pipe names are assigned for named instances, including SQL Server Express. By default, when enabled, both named instances and SQL Server Express are configured to use dynamic ports, that is, an available port is assigned when SQL Server starts.

If you want, a specific port can be assigned to an instance of SQL Server. When connecting, clients can specify a specific port; but if the port is dynamically assigned, the port number can change anytime SQL Server is restarted,

so the correct port number is unknown to the client. Upon startup, SQL Server Browser starts and claims UDP port 1434. SQL Server Browser reads the registry, identifies all instances of SQL Server on the computer, and notes the

ports and named pipes that they use. When a server has two or more network cards, SQL Server Browser returns the first enabled port it encounters for SQL Server. SQL Server 2005 and SQL Server Browser support ipv6 and

ipv4. When SQL Server 2000 and SQL Server 2005 clients request SQL Server resources, the client network library sends a UDP message to the server using port 1434. SQL Server Browser responds with the TCP/IP port or named

pipe of the requested instance. The network library on the client application then completes the connection by sending a request to the server using the port or named pipe of the desired instance.

Page 13: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 13 of 17

Cross Forest & OWA

Document ID: 284292 http://support.veritas.com/docs/284292 E-Mail this document to a colleague When Enterprise Vault (EV) is installed into an Active Directory infrastructure with at least one resource domain and at least one logon domain you are unable to access archived items through Outlook Web Access (OWA).

Exact Error Message 201 - Basket restoring The user 'DOMAIN\OWAAnonymous' attempted to restore a message into Exchange mailbox 'user05' and they were not the mailbox owner or an Administrator User 'DOMAIN\OWAAnonymous' failed to restore an item into mailbox 'user05'

Details: When users in the Logon domain attempt to open an archived item in OWA, the item cannot be retrieved. Clicking the yellow banner with the writing "Item is currently unavailable...", a pop up window appears: "201 - Basket restoring". In the EV Event Log, the following warnings appear: Event Type: Warning Event Source: Enterprise Vault Event Category: Retrieval Task Event ID: 2177 Date: 12/07/2006 Time: 15:08:57 User: N/A Computer: CRASH Description: The user 'DOMAIN\OWAAnonymous' attempted to restore a message into Exchange mailbox 'user05' and they were not the mailbox owner or an Administrator Event Type: Warning Event Source: Enterprise Vault Event Category: Retrieval Task Event ID: 2227 Date: 12/07/2006

Page 14: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 14 of 17

Time: 15:08:57 User: N/A Computer: CRASH Description: User 'DOMAIN\OWAAnonymous' failed to restore an item into mailbox 'user05'. SavesetID: 732000000000000~200607121125520000~0~CF813066FE034AF28DD65357F3F0A64 Information on the authentication process 1. The OWA user requests an archived item from Exchange. 2. The IIS process running as the Anonymous OWA user account invokes a directory lookup, which includes the domain\username credentials of the Exchange user making the request. 3. AuthServer.exe performs the Active Directory lookup, calling the Win APIs to look up account SID based on name, running under the context of the Vault Admin account. If the Vault Admin account has no rights in the domain in which the user resides, then the lookup will fail. There are two solutions: 1. Give the Vault Admin rights to perform lookups in the domain (i.e. a trust) 2. Allow pass through authentication "Pass through" authentication works by duplicating the Vault Admin account in the lookup domain with exactly the same username and password. When the lookup requests credentials, authserver supplies the Vault Admin accounts details. If this matches another user in the lookup domain, the lookup will be successful. Workaround 1: Create an account in the logon domain with same name and password as the Vault Service Account that exists in the resource domain. Workaround 2: Create the Vault Service Account and OWA Anonymous account in the Logon domain, and configure the Enterprise Vault services to use this account. Both the suggested workarounds are also suitable for environments where the Resource domain and the Logon domain are Children of a parent domain. Only a mono-directional (one way / non transitive) trust, where the resource forest trusts the logon domain, is required besides the default parent-child trusts between the child and the root domain.

Page 15: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 15 of 17

Document ID: 288088 http://support.veritas.com/docs/288088 E-Mail this document to a colleague The Event ID 2227 will be reported in the Enterprise Vault event log when a user attempts to view an Enterprise Vault archived mail item using Microsoft Exchange OWA (Outlook Web Access).

Exact Error Message The archived item is currently unavailable

Details: Overview: The Event ID 2227 will be reported in the Enterprise Vault event log when a user attempts to view an Enterprise Vault archived mail item using Microsoft Exchange OWA (Outlook Web Access) because the proper registry key has not been set on the Enterprise Vault server by the configuration program. This behavior can be viewed as described below. The OWA user will receive a banner as displayed in Figure (1).

Figure (1) The archived item is currently unavailable.

Click on the "The archived item is currently unavailable." message and the error displayed in Figure (2) will be returned. Figure (2) 201 Basket Restoring

Page 16: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 16 of 17

The following error will be captured in the DTRACE of the shopping service. DTRACE BEGIN: 594 16:33:46.066 [7044] (RetrievalTask) <22332> EV~W Event ID: 2227 User '<unavailable>' failed to restore an item into mailbox 'Phil Earhart'. |SavesetID: 165500000000000~200703301852270000~0~78B298C3007F431EB6533B0A902C209 | 595 16:33:46.082 [7044] (RetrievalTask) <22332> EV~W Event ID: 2270 A queued operation exceeded the retry count and has been discarded|(Retrieval)|m_pIExchangeRestorationAgentUpdate->SavesetAvailable(OriginatingClient = "189F3EE2634E34A44AA9A09B506DD5BEC1c10000EVClusServer",| pISaveset,| AgentParamsSize = 663,| pAgentParams,| NULL,| nRetryCount = 3,| NULL,| PSTFile = "", RestoreAndDelete = "FALSE",| PSTFormat = "UNICODE",| RestoreShortcuts ="FALSE");|HRESULT: 0x80040B36 | DTRACE END: Resolution: Warning: Incorrect use of the Windows registry editor may prevent the operating system from functioning properly. Great care should be taken when making changes to a Windows registry. Registry modifications should only be carried-out by persons experienced in the use of the registry editor application. It is recommended that a complete backup of the registry and workstation be made prior to making any registry changes.

1. Open "Regedit" on the Enterprise Vault Server under the security context of the Vault Service Account (VSA). 2. Create a string value named "AnonymousUser" under the following hive "HKEY_CURRENT_USER\Software\KVS\Enterprise Vault". 3. Set the value to match the user account that was created for the Enterprise Vault OWA anonymous access. Verify that the domain name is placed behind of the account as displayed in Figure (3). Figure (3)

Page 17: Best Practice for Using EV in Secure Networks

Best Practice for Using EV in Secure Networks Page 17 of 17

Related Documents: 276120: DOCUMENTATION: How to run Dtrace to help diagnose issues with Veritas Enterprise Vault (tm) 5.x and 6.x http://support.veritas.com/docs/276120 284292: When Enterprise Vault (EV) is installed into an Active Directory infrastructure with at least one resource domain and at least one logon domain you are unable to access archived items through Outlook Web Access (OWA). http://support.veritas.com/docs/284292