Administrator s Guide

(1)

Administrator’s Guide

Version 4.0

August 2010

Biscom, Inc. | 321 Billerica Rd. | Chelmsford, MA 01824 tel 978-250-1800 | fax 978-250-4449

(2)

Copyright 2010 Biscom, Inc. All rights reserved worldwide. Reproduction or translation of this publication (in part or whole, in any form or by any means) is forbidden without the express written permission of Biscom, Inc.

(3)

Notice

Information furnished by BISCOM, Inc. is believed to be accurate and reliable. However, no responsibility is assumed by BISCOM, Inc. for its use, or any

infringement of patents or other rights of third parties, which may result from its use. No license is granted by implication or otherwise under any patent or patent rights of BISCOM. BISCOM reserves the right to change hardware and software at any time without notice. Information provided in this manual is subject to change without notice.

(4)

Section 1: Introduction

Topics

This Installation Guide is written for system administrators who will be installing, configuring, and maintaining the Biscom Delivery Server application and servers. This guide is for both Windows and Linux versions; places where Windows or Linux specific information differs are noted. This guide will cover the following topics:

Hardware and software requirements

Installing, configuring, and customizing the application Licenses

Starting and stopping the application User management

Backing up the application data API development

Support and troubleshooting

Biscom Delivery Server (BDS) has three types of administrators: Super User, System Administrator, and User Administrator. The primary administrator, who is often the person or persons installing and setting up the system, is typically the Super User. User Administrators have the lowest level of administration, and can create and manage users. System Administrators can modify the system configuration, and Super Users control compliance users and encryption options.

Conventions

The following conventions are used in this guide: Italic

is used for file, variable, and function names. It is also occasionally used for emphasis or to highlight key terms when they are first used or introduced.

Fixed width font

is used for code examples, file names, and other operating system text or commands. If punctuation and other symbols are used with this style, enter them exactly as shown.

Fixed<variable>

is used to show a string that contains both fixed and variable text. The variable text is usually left as a placeholder to indicate an area that the user

(9)

or administrator may customize, such as the directory location in which an application is installed.

$ <command> [ param1 | param2 | param3 ]

is used in Linux environments to indicate that a command or script should be run from a terminal window. Square brackets indicate that a parameter or additional value should be entered – the vertical bar indicates that one parameter or value should be chosen.

This document uses Windows file system conventions, e.g. backslashes denote directory separators. If you are using Linux, you should replace backslashes with forward slashes as appropriate. If there are significant differences in the Windows and Linux information, it will be described separately.

For the purposes of this document, <BDS HOME> will be used as the location on the server where Biscom Delivery Server was installed. For example, this directory may be:

Windows:

C:\Program Files\Biscom Delivery Server

Linux:

(10)

Section 2: Hardware and Software Requirements

Server Hardware

Biscom Delivery Server runs on Microsoft Windows Servers, and certain Linux operating systems. Minimum hardware requirements for BDS are: a machine with a Pentium 4 or higher CPU, 2 GB of RAM, and 50 GB of disk space.

Biscom Delivery Server consists of multiple tiers that run different aspects of the application, including the Web tier, application server tier, and the back-end tier (database and file system). Each tier may be run on separate machines that may be physically located in separate areas of the network for security reasons. The Web tier must reside on a machine that is network accessible to end users who use Biscom Delivery Server through a Web browser, including those who may be external to your network.

We recommend having a dedicated machine or machines for use with Biscom Delivery Server. We do not recommend installing Biscom Delivery Server on existing servers that are currently used for other applications.

Operating System

BDS can be installed on Microsoft Windows Server 2003, Windows Server 2008, RedHat Enterprise Linux 5, and Ubuntu 8.04+. VMware is also supported when running one of the operating systems listed above.

Server Software

You must be an administrator of the server to install Biscom Delivery Server. The BDS installer package ships with several components, including the Java Development Kit, the Apache Web server, Jakarta Tomcat Java application server, PostgreSQL

database, and JK Connector. If you are performing a typical/standard installation, these components will be installed for you.

The Web services interface requires a separate binary called axis2.war that needs to be installed in the web applications folder in the Java application server (Tomcat). This is required when deploying the BDS Outlook add-in, or other automation utilities that require Web services.

If you enable back-end file encryption, a BDS Super User administrator must run the enctool.bat (Windows) or enctool.sh (Linux). Enctool is the encryption tool that administrators use to enable and disable encryption, and manage encryption keys. A VMware appliance is also available that has the BDS components pre-installed and configured.

Database Software

BDS uses a SQL database to store information about the software configuration, users, and package meta-data. Files are not stored in the database however. BDS is compatible with several database packages, including PostgreSQL 8.3, Microsoft SQL

(11)

Server 2005, and MySQL 4.1. This documentation focuses on PostgreSQL, which is the default database installed with BDS.

Linux-Specific Requirements

The Linux installation script uses RPM (RedHat Package Management) to install the components – make sure your Linux distribution supports RPM before starting the installation. Other distributions that are not RPM-compatible may be installed manually. Please contact Biscom technical support for further information and assistance.

The JK Connector bridges the Web server and application server. Because of the differences in Linux operating systems, the connector is compiled from source for each Linux distribution. The compilation requires additional packages that are not included in the BDS distribution. The additional RPMs needed prior to installation: - gcc (for compilation requirements)

- apr-devel - apr-util-devel - httpd-devel

Please make sure your system has the necessary packages installed for your distribution before starting the BDS installer.

Mail Server

BDS uses your existing mail server for email notifications sent to delivery recipients as well as access notification to senders when a recipient has viewed a delivery. In order to send these notifications, BDS must have a mail server configured to send these messages.

After installing BDS, you can configure the mail server on the Server Configuration page in the Web application. See the section on server configuration later in this manual for detailed instructions.

Client Software

Biscom Delivery Server client software includes a web browser and the Outlook Add-in. The Outlook Add-in integrates with Microsoft Outlook seamlessly. Application and operating system requirements for the modules:

Web client: IE 7+, Firefox 2+, and Safari 3+ browsers are supported. If you enable the Java Applet for more robust file uploads and downloads, checkpoint restart, and drag and drop support, the client desktop must have JRE 6 or higher installed. Note: Java 6 Update 20 or higher is the

recommended version of JRE for clients.

Note: If the user’s desktop does not have the proper version of JRE installed, the user will be alerted to this on pages where the Java applet is enabled.

Outlook Add-in: Microsoft Office Outlook 2003, 2007, and 2010 .NET Framework 3.0

(12)

Installing, Uninstalling, and Upgrading Biscom Delivery

Server

Before you install, uninstall, or upgrade your server, make sure you are an

Administrator of the system with permissions to install and run applications. Note that

you should not use the installer for upgrading an existing installation. Installation may destroy data in an existing installation. See the upgrade instructions below if you are upgrading an existing installation and want to preserve any existing data.

Installing Biscom Delivery Server

Windows:

1. Shut down IIS or any other web servers that are currently running.

Note: The Windows installer automatically installs the Apache web server. If you would like to use IIS, see the section on replacing Apache with IIS (p. 22).

2. Install the application.

a. Open the directory where the installer is located, either on a CD or the download location.

b. Double-click the Biscom Delivery Server installer named:

bds-full-<version>.exe and click the Next button to get

(13)

c. Accept the Biscom Software End User License Agreement to proceed.

d. Enter the directory under which to install Biscom Delivery Server.

e. Select Typical or Custom configuration.

i. For Typical installation:

1. Enter the values for the following: a. Application name b. Domain name

(14)

ii. For Custom installation:

1. Select the components to install (all components are selected by default).

2. Enter the values for the following (same as typical installation step):

a. Application name b. Domain name

(15)

3. Enter the Web server (Apache) port if different from the default port 80.

f. Click the Install button to start installing the components and the Biscom Delivery Server application.

Linux:

Note: Unlike the Windows installer, the Linux installer does not include a Web server. Most Linux systems already have a Web server installed. If your system does not to have a Web server pre-installed, install one before installing BDS. Apache 2.0.x compiles JK connector 1.2 to link Apache and Tomcat. Apache version 2.2 and higher can use the mod_proxy.so module to perform the redirect that the JK connector would normally handle.

1. Before starting, make sure the following are set up: a. There is a user named “admin”

b. You have root privileges on the system you’re installing to, as the installer must be run as root.

(16)

2. Obtain the file named:

bds-install-<version>.tar.gz

3. Untar and unzip the file using the following command:

$ tar xvfz bds-install<version>.tar.gz

4. Change directories to the newly created directory:

$ cd bds-installer-<version>

5. Make sure the user you are logged in as has privileges to install software on your system. This is typically an administrator or root.

6. Run the install script:

$ ./install.sh

7. Biscom Delivery Server will be installed to the following directories:

a. Application Server: /usr/local/tomcat b. BDS HOME:

/<home directory of installation user>/bds

Installing the Web services interface

To support the Outlook add-in and desktop client, you must install the Web services interface, axis2.war. Deploying this is as simple as copying the axis2.war file to the default web applications folder in the Java application server. For the default application server Tomcat, copy axis2.war to:

Windows:

<BDS installation

directory>\components\tomcat-5.5\webapps Linux:

/usr/local/tomcat/webapps

To test the successful deployment, from the server on which you installed BDS, start up the application server and point your browser to http://localhost:8080/axis2/ to ensure the Web services application is running. You should see the Apache Software Foundation logo and text indicating the axis2 application has been successfully deployed.

(17)

Installing the Active Directory Connector

BDS uses a client application called the Active Directory Connector (ADC) to enable user authentication using Microsoft Active Directory.

Note: The AD connector is used only when authenticating to an Active Directory server. It is not required to authenticate against an LDAP server.

ADC should be installed on a Windows-based machine by a user who has the proper permissions to install a Windows service, and the service should have appropriate rights or permissions to your AD server. Typically, the ADC can be installed on the same machine on which you’ve installed BDS (e.g. the application server), but it can also be installed on a machine that has the ability to connect to both the BDS machine as well as the AD server.

If you are experiencing issues connecting to your AD server with the built-in connector, follow the steps below to install the ADC on your Windows machine.

1. Download the BDS AD Connector installer to the machine on which you will be installing the software.

2. Verify that this machine has access to the AD server.

3. Double-click the installer and follow the prompts. The installer will create a new service called BDSADConnector.

4. Verify that the service is installed and it has been started. If the service is stopped, start the service up. We recommend you set the Startup type to Automatic to start when the machine starts up.

5. From the machine on which you installed BDS, verify that you can connect to the AD Connector service. The default port for the AD Connector is

65330.

6. To configure the connection, follow the instructions in the section Manage Users with LDAP or Active Directory.

Configuring the Active Directory Connector

The AD Connector configuration file is located in the application data folder for the user associated with running Windows services. To find the exact location of the configuration file, open the Windows Event Viewer, and look for events with

BDSADConnector as the Source. Double-click to open an event and look in the description field for the directory path where the BDS AD Connector is located (it may not exist in every event, so if you do not see the directory path, open another event until you find it). Go to the Application Data directory and edit the ADConnector.conf file. If GC support is required, you must modify the ADConnector.conf file with the following:

(18)

############ AD Connector Configuration ############ port = 65330

groupMembershipInfoMode = queryMode gcLookupXML = <gcLookup>\

<email pattern=”*@biscom.com”>\

<extAuthSrcDomain>biscom.com</extAuthSrcDomain>\ <gc>biscom.com</gc>\

<galDomain>biscom</galDomain>\ </email>\

</gcLookup>

Note: The backslashes used in the gcLookupXML property are used to denote continuation of the value on multiple lines. If you enter the value of the property on a single line, the backslashes are not needed.

gcLookupXML:

o email: Any email addresses that match the pattern specified here will use the global catalog to look up the username. The pattern supports wildcard symbols. Multiple emails can be specified, and must be separated by commas.

o extAuthSrcDomain: This must match the Authentication source name defined in the Server Configuration page in BDS.

o galDomain: This value must match the Domain name (short) value specified in the Manage Exchange Server connections configuration located in the Contact and Group Settings section of the Server Configuration page.

Uninstalling Biscom Delivery Server

Note: Uninstalling Biscom Delivery Server will remove all user data, including all packages and deliveries.

Windows:

1. From the Start menu, go to the Biscom Delivery Server program group, and open the Uninstall Biscom Delivery Server application.

2. Select the components to uninstall (all components are selected by default). 3. Click the Uninstall button. The components will be shut down (if they are

currently running) and uninstalled.

4. After uninstalling the application, you may be asked to reboot the system.

Linux:

1. Log on as the user who installed Biscom Delivery Server initially (e.g. a user with administrator or root privileges who can add/remove software). 2. Change directories to the location you extracted the tar.gz installer.

(19)

3. Run the command:

$ ./uninstall.sh

Upgrading an existing Biscom Delivery Server instance

Upgrading BDS is a non-destructive process. All data will be preserved during the upgrade, but we recommend that you perform a full backup before starting the upgrade. Upgrading BDS involves the following files and an upgrade script:

bds.war: the application biscom-ds.jar: a BDS library biscom-shared.jar: a shared library axis2.war: Web services interface

upgrade.bat (Windows) or upgrade.sh (Linux): a script to perform the upgrade

The upgrade script is able to upgrade from any previous version to the latest version automatically. Follow the instructions below for your operating system.

Note: You should back up your data before performing an upgrade, including the data directory, recycle bin directory, configuration files, custom style sheets and logos, and log files. You should also export and back up all database data. See the section below on backing up your data.

Windows:

1. From your CD or from the download location, find the upgrade files. The files required for upgrading are:

a. bds.war

b. biscom-ds.jar

c. biscom-shared.jar

d. axis2.war

2. Shut down the application server (e.g. Apache Tomcat) through the Manage Services screen. Note that the Web server does not need to be shut down.

3. Delete any cached versions in the following folders under Tomcat (including the folder itself):

(20)

a. <BDS HOME>/components/tomcat-5.5/webapps/bds

b. <BDS HOME>/components/tomcat-5.5/webapps/axis2

c. <BDS HOME>/components/tomcat-5.5/work/Catalina

4. In the existing installation, back up all files in the lib directory (<BDS HOME>/lib).

5. Copy the biscom-ds.jar, biscom-shared.jar, bds.war, and

axi2.war to the lib directory.

6. Open a command window and go to the <BDS HOME>/tools directory.

7. Run upgrade.bat.

8. In the Manage Services screen, restart the application server. 9. Log on to the Web application and go to the System and User

Administration > Server Information page and verify the version

number.

Linux:

1. Log on as the administrative user who initially installed the application. 2. From your CD or from the download location, find the upgrade files. The

files required for upgrading are:

a. bds.war

b. biscom-ds.jar

c. biscom-shared.jar

d. axis2.war

3. Shut down the application server (e.g. Apache Tomcat):

$ su <- must be logged in as root

$ /etc/init.d/tomcat stop

$ ps waux |grep java <- check until the Tomcat

process is no longer running

$ exit <- exit back into the admin

user which installed the application

4. Delete any cached versions in the following folders under Tomcat (including the folder itself)::

$ rm -r /usr/local/tomcat/webapps/bds* $ rm -r /usr/local/tomcat/webapps/axis2* $ rm -r /usr/local/tomcat/work/Catalina

5. In the existing installation, back up all files in the lib directory (<BDS HOME>/lib).

(21)

6. Copy the biscom-shared.jar and biscom-fm.jar upgrade files to the

lib directory.

7. Copy the application bds.war and axis2.war to the webapps directory in Tomcat:

$ cp bds.war /usr/local/tomcat/webapps $ cp axis2.war /usr/local/tomcat/webapps

8. Go to the tools directory and run the upgrade script:

$ cd ~/bds/tools $ ./upgrade.sh

9. Restart the application server:

$ su <- must be logged in as root

$ /etc/init.d/tomcat start

Using IIS as your Web Server on Windows

On Windows servers, IIS can be used instead of Apache. Apache does not need to be uninstalled, but Apache should be shut down through the Computer Management console and startup should be set to manual so it does not start automatically when Windows starts. IIS requires a DLL that will redirect requests from the Web server to the application server.

1. Ensure that IIS is installed and running. From the web server machine, open a web browser and go to the URL http://localhost and verify that the default IIS page comes up.

2. Ensure that BDS is installed and running by accessing BDS through the application server directly. Visit http://localhost:8080/bds and verify BDS is running. Tomcat runs on port 8080.

3. Verify that you have the following files saved in the application server configuration directory (e.g. C:\Program Files\Biscom Delivery Server\components\tomcat-5.5\conf):

a. workers.properties b. uriworkermap.properties c. isapi_redirect.properties d. isapi_redirect.dll

Note: The isapi_redirect.dll binary file is different for 32 and 64-bit platforms. The latest binaries can be found here:

http://www.fightrice.com/mirrors/apache/tomcat/tomcat-connectors/jk/binaries/

4. Open isapi_redirect.properties and update the properties to match your local configuration (e.g. if you selected an installation directory different than the default directory, you will need to update the property values accordingly). Sample file:

(22)

# Configuration file for the Jakarta ISAPI Redirector

# The path to the ISAPI Redirector Extension, # relative to the website

# This must be in a virtual directory with execute

# privileges

extension_uri=/tomcat/isapi_redirect.dll # Full path to the log file for the ISAPI Redirector

log_file=c:\Program Files\Biscom Delivery

Server\components\tomcat-5.5\logs\isapi_redirect.log

# Log level (debug, info, warn, error or trace) log_level=debug

# Full path to the workers.properties file worker_file=c:\Program Files\Biscom Delivery

Server\components\tomcat-5.5\conf\workers.properties

# Full path to the uriworkermap.properties file worker_mount_file=c:\Program Files\Biscom Delivery

Server\components\tomcat-5.5\conf\uriworkermap.properties

5. Open the IIS management program: Control Panel > Administrative Tools -> Internet Information Services. Expand local computer --> Web Sites --> Default Web Site.

6. Create a virtual directory for the default web site: a. Right click the Default Web Site. b. Select New -> Virtual Directory. c. Click Next, enter tomcat as the alias.

d. Click Next, browse to the Tomcat conf directory (that contains the isapi_redirect.dll file), click OK.

e. Click Next, check the Execute checkbox. f. Click Next and finally click Finish. 7. Add an ISAPI filter for the default web site:

a. Right click the Default Web Site. b. Select Properties.

c. Click on the ISAPI Filters tab. d. Click Add...

e. Specify tomcat as the Filter Name

f. Browse and select isapi_redirect.dll in the Tomcat conf directory as the Executable

(23)

h. Click OK again to close the properties.

8. Verify Directory Security settings by opening the properties for the web site: a. Select Directory Security -> Edit Authentication and Access Control. b. Make sure that anonymous access is checked, and all authenticated

access checkboxes are unchecked.

9. On Windows 2003 Server, IIS has a Web Service Extensions folder. Select this folder and open the Add a new Web service extension from the right-click menu or from the links to the left of the list of extensions.

10. Name the extension (e.g. "Tomcat"). a. Add the file isapi_redirect.dll.

b. Check the Set extension status to Allowed checkbox. c. Click OK to add the extension.

11. Ensure IIS and Tomcat are running. Open a browser window and enter the URL: http://localhost/bds/Login.do. If everything is set correctly, the BDS sign in page should come up.

12. To troubleshoot, refer to the ISAPI log file specified in the isapi_redirect.properties file.

Using SSL

Biscom Delivery Server supports the use of SSL (Secure Sockets Layer) to encrypt all transmissions between the client Web browser and the Web server. When Biscom Delivery Server is installed, SSL is not installed by default. SSL must be installed and configured after Biscom Delivery Server is installed. We recommend all users to log on to Biscom Delivery Server using SSL to ensure the highest level of security. SSL installation is independent of the Biscom Delivery Server application. Refer to your Web server documentation or Certificate Authority documentation for information on obtaining and installing an SSL certificate on your Web server. The documentation reviews the steps for creating a certificate request or certificate signing request, but you must submit the request to your Certificate Authority yourself. Different CAs may have different procedures for generating a SSL certificate. Once you have received the SSL certificate, you can continue following the

instructions below to install the certificate on your server.

Installing SSL on IIS for Windows

1. Right click on the Web site that you are setting up to use an SSL Certificate, and select Properties.

(24)

2. Click on the Directory Security tab, then the Server Certificate button.

3. Select Create a new certificate radio button and click Next.

4. Select Prepare the request now, but send it later and click Next.

5. Enter a name for the certificate, this can be any name that is easy for you to refer to and remember. Leave the Bit length as 1024 and make sure Select cryptographic service provider (CSP) for this certificate is unchecked.

(25)

6. Enter your company’s name and organizational unit, then click Next.

7. Enter the common name of the server, this will need to be the exact host name that will be assigned to the server and it will have to match the URL that is entered to visit the site (e.g. for the URL

(26)

download.biscom.com).

8. Enter the correct geographical information, then click Next.

9. The Certificate Request file will be saved to C:\certreq.txt by default. This file must be sent to a certificate authority for signing. They will send

(27)

back a file with the extension .cer.

10. After obtaining the signed .CER file from the Certificate Authority, go back to IIS on the server and right click on the Web site and click properties. 11. Click on the Directory Security tab and then the Server Certificate button. 12. Click Next.

13. Select Process the pending request and install the certificate.

14. Enter the path to the .CER file that was sent to you from the Certificate Authority.

15. Click Next.

The SSL certificate should now be installed on the Web site and ready for use. If you want to strictly use the SSL protocol and not allow standard HTTP connections, in the properties of the Web site – in the Directory Security tab, under Secure Communications, click the Edit button, check off Require secure channel (SSL), and then click OK.

Installing SSL on Apache 2 for Windows

1. Make sure Apache is running and working on port 80 (http). 2. Update the Apache configuration file located here: <BDS HOME>/

/components/Apache-2.0/conf/ssl.conf.

3. Start the Apache server and test the 443 port is working by going to the URL http:/yourdomain.com:443/ -- it won't be encrypted but it should show a valid web page.

4. Get OpenSSL v.1.0 or higher and generate a certificate signing request (CSR).

a. Get OpenSSL here:

(28)

Go to the download section and find the appropriate version of the Win32_OpenSSL installer (e.g. 32- or 64-bit).

Our example will use Apache 2.0.54 and OpenSSL version 1.0.0a. b. Copy: bin\OpenSSL.exe to a working directory

c. Update ServerName and DocumentRoot d. Copy: openssl.cnf to the same working directory 5. Create a test certificate.

a. Open a cmd window and navigate to the working directory that contains openssl.exe

b. Enter command to create the CSR: openssl req -config openssl.cnf -new -out server.csr

When asked for "Common Name (e.g., your website’s domain name)", give the exact domain name of your web server

c. Enter command to remove the passphrase: openssl rsa -in

privkey.pem -out server.key

d. Enter command to generate a certificate: openssl x509 -in server.csr -out server.cert -req -signkey

server.key -days 365

e. Create directories:

i. <BDS HOME>/components/Apache-2.0/conf/ssl.crt ii. <BDS HOME>/components/Apache-2.0/conf/ssl.key f. Copy: server.cert to the ssl.crt folder

g. Copy: server.key to the ssl.key directory 6. Configure Apache and mod_ssl.

a. Copy: mod_ssl.so to <BDS HOME>/components/Apache-2.0/modules

b. Ensure httpd.conf has the line uncommented: LoadModule

ssl_module modules/mod_ssl.so

c. Edit ssl.conf

i. Enter path to the certificate for: SSLCertificateFile conf/ssl/server.crt

ii. Enter path to the key for: SSLCertificateKeyFile conf/ssl/server.key

iii. Copy the jkmount directives from http.conf to ssl.conf so that users can be redirected to the application properly when using HTTPS. Make sure that these jkmount directives go into inside the <VirtualHost _default_:443> element.

7. To generate a valid certificate for use in your production site, you must contact a Certification Authority (CA) such as Verisign, GeoTrust, Comodo, GoDaddy, etc., and provide your CSR.

(29)

Installing SSL on Apache 2 for Linux

Note: These instructions are to be used as a guide only, as actual instructions and procedures may vary slightly depending on your Linux distributions.

1. Make sure Apache is running and working on port 80 (http). 2. Update the Apache configuration file located here:

/etc/httpd/conf/httpd.conf.

a. Update: ServerName <your server domain name>

3. Start the Apache server and test the 443 port is working by going to the URL http:/yourdomain.com:443/ -- it won't be encrypted but it should show a valid web page.

4. Make sure OpenSSL is installed and in your PATH. 5. Create a RSA private key called server.key:

$ openssl genrsa -out server.key 1024

6. Create a Certificate Signing Request (CSR) with the server key (output will be PEM formatted). You will need information such as your company name, location, and hostname for the server on which you will be installing the SSL certificate:

$ openssl req –new –key server.key –out server.csr

7. Use the server.csr file to generate a certificate for use in your production site. You can submit your CSR file to a Certification Authority (CA) such as Verisign, GeoTrust, Comodo, GoDaddy, etc., and provide your CSR. Follow the instructions on their site for proper submission. Once the CSR is signed, you will receive a signed certificate server.crt.

8. Place the returned, certified server.crt file and the previously generated server.key file into the directories referenced by /etc/httpd/conf.d/ssl.conf (with the SSLCertificateFile and SSLCertificateKeyFile directives).

9. Ensure mod_ssl.so exists in the /etc/httpd/modules directory:

LoadModule ssl_module modules/mod_ssl.so

Include /etc/httpd/conf.d/ssl.conf

10. Restart Apache with:

$ service httpd restart

11. You can verify SSL is functioning correctly a number of ways:

$ openssl s_client –connect localhost:443 –state –debug $ curl http://localhost/

$ curl https://localhost/

Troubleshooting SSL:

- Look at the following tutorials:

http://www.thompsonbd.com/tutorials/apachessl.php http://raibledesigns.com/wiki/Wiki.jsp?page=ApacheSSL

- If Apache doesn't start from the Service, look at the Application Log under Event Viewer/Application for useful debugging information.

(30)

Section 3: System and Application Configuration

Biscom Delivery Server uses a properties file named fds.properties to configure several

server settings. Other Biscom Delivery Server configuration is handled through the Web application.

The configuration file is located in the config directory under the location that Biscom Delivery Server was installed, e.g. <BDS HOME>\config\fds.properties.

System Configuration through fds.properties

Any time the configuration file is updated, you will need to restart the application server. See the section below on starting and stopping the application.

The configuration file has the following format:

################ Server Configuration ################ domainName = secure.my-server.com appName = bds docRoot = c:\\apps\\bds\\data protectedRecycleBinDir = c:\\apps\\bds\\recyclebin licenseFile = c:\\apps\\bds\\license\\license.xml ldapConfFilename = c:\\apps\\bds\\config\\ldap.conf ldapDefaultDomain = biscom.com ldapDefaultTimeout = 5

upnAuthUserList = *@corp.my-company.com, *@corp2.my-company.com

upnAuthGalDomain = Biscom

compressionExtExclusionList = zip, rar, jpg compressionExtInclusionList = asp, aspx

Note: The backslash used to separate directory names in Windows must be escaped by using another backslash. Any directory locations using

backslashes must be escaped in the properties files. For Linux, the double backslashes should be replaced with a single forward slash.

These properties can be updated to meet the specific needs of your organization:

domainName: The hostname of the machine that Biscom Delivery Server has been installed on. By default, this value is set to localhost.

appName: The application name. This appears in the URL after the domain name, e.g. https://<domainName>/<appName>.

docRoot: The location of the user data files (note that this is not the Web server document root).

(31)

protectedRecyleBinDir: The location where the system places deleted files (e.g. when a user deletes a package). The system permanently deletes these files periodically using the cleanup process (described later).

licenseFile: The location in which the license file resides. See the section on Licenses for more information.

ldapConfFilename: This points to the LDAP configuration file. This is an internal property and should not be changed by the administrator.

ldapDefaultDomain: The default domain to use if no domain is specified when a user signs into the application. If this is defined, administrators may want to hide the domain field in the sign in page to reduce potential confusion for the user.

ldapDefaultTimeout: The default timeout for LDAP queries.

upnAuthUserList: A comma separated list of users who can use their User Principal Name (UPN) to authenticate against their AD or LDAP server. This value can include patterns using wildcard symbols. When this optional property is defined, matching users can use their UPN to sign in, typically their email addresses, and their AD or LDAP password.

upnAuthGalDomain: To enable users authenticating with their UPN to access the global address list, this property must be defined. The value of this property is the “Domain name (short)” value specified in the Exchange Server connection.

compressionExtExclusionList: When the applet is used for file upload and download, you can define a comma-separated list of extensions for which compression will not apply. For example, you can specify zip, rar, and jpg as file extension. If these file extensions are seen in a filename, the file will not be compressed. Typically, this is for files for which compression will not significantly reduce file size, so the additional computing power used is not efficient. Note: compression is only used when the applet is enabled and used by the client. Compression is applied to files within the client, and is transparent to the end user.

compressionExtInclusionList: You can specify a comma-separated list of extensions that should be compressed that are not covered by the default list of extensions.

Server Configuration through the Application

Several aspects of server configuration are handled through the application’s interface. Most of the configuration is application-specific rather than server-specific. This is covered in the System and User Administration section. Changes to the application configuration do not require a system restart.

(32)

Section 4: Encryption Module

BDS supports back-end encryption for files that are stored in the file system. BDS uses Advanced Encryption Standard (AES), a symmetric key encryption algorithm that is the current NIST-approved encryption algorithm, to encrypt files. Encryption is an optional module and can be enabled or disabled using a command line utility. Key management is also performed using the command line utility.

Encryption and Decryption

When you enable encryption, files that are uploaded and saved in packages are encrypted automatically. When an encrypted file is downloaded, BDS automatically decrypts the file and sends the unencrypted file to the requester.

Keys and Key Management

AES is a symmetric encryption algorithm that uses secret keys to perform the encryption. Managing these keys is an important aspect of encryption, and includes tasks such as key generation, selection, storage, and backup.

The secret keys used to encrypt files are also stored on the file system in an encrypted format. BDS internally manages the encryption of the secret keys. The encrypted keys are stored by default in the <BDS HOME>/kr directory. This location

can be changed using the utility.

When you enable encryption for the first time, a secret key is generated. The generated key will be selected as the default secret key for BDS. You can generate additional keys later, and change the default key to one of the newly generated keys. Additional key management features, such as removing keys, can be found in the utility’s Advanced Options.

Encryption Utility

The encryption utility is a command line tool that is accessible only to BDS users with the Administrator role. The utility is available in the <BDS HOME>/tools directory, and can be started by running enctool.bat on Windows, and enctool.sh on Linux.

Note: Before starting the encryption utility, all BDS components should be shut down.

C:\BDS\tools>enctool.bat

NOTE: All BDS components must be shut down before using this tool. Please verify that all BDS components have been shut down. Then enter C to continue or X to exit. Continue/exit (C/X)? C

(33)

Username: admin1 Password: ******

If sign in succeeds, the user will see the current encryption setting and the main menu:

Encryption is not enabled. Main menu:

1. Enable/Disable encryption 2. Encrypt file system

3. Decrypt file system 4. List keys

5. Create a new key

6. Change key storage location 7. Change the default key 8. Advanced options

9. Exit Option:

Enable/Disable encryption

This menu item will be Enable encryption if the current system is not encrypted. If the system is already encrypted, then the menu will be Disable encryption.

If encryption is enabled, all files uploaded from that point forward will be encrypted. Existing files stored in unencrypted form will not be encrypted automatically. If encryption is disabled, all files uploaded from that point forward, will not be encrypted. Existing files that are encrypted will not be automatically decrypted. Because this option can be toggled at any time, it is possible that some files in the system may be encrypted while others will not. The system handles both encrypted and unencrypted files automatically and no input or maintenance is needed by an administrator.

Encrypt file system

If encryption is enabled, then selecting this option will encrypt all unencrypted files in the file system. This is a potentially lengthy operation, and time considerations should be factored in before selecting this option.

Example:

Are you sure you want to encrypt all unencrypted files (Y/N)? Y

(34)

Processing file 386 of 4828 (8% complete); Time remaining: 1 hr 29 min

When all files have been processed, the following should be displayed:

Encrypted 4828 files. Total time: 1 hr 20 min. Press any key to continue...

Decrypt file system

Decrypting the entire file system will decrypt all encrypted files in the file system. Like the encryption option, this is potentially a lengthy operation and should be considered before proceeding.

Example:

Are you sure you want to decrypt all encrypted files (Y/N)? Y

Processing file 3476 of 4828 (72% complete). Time remaining: 23 min

Decrypted 4828 files. Total time: 41 min. Press any key to continue...

Listing keys

This option lists all existing keys used in the system. The current key used for encryption will be highlighted.

Example:

1. k1 07/04/07 2. k25 12/26/07

3. k1003 01/01/08 default Press any key to continue...

Creating a new key

This option is used to add a key to the system. Keys are generated automatically by the system and no input is required from the user.

Example:

(35)

Press any key to continue...

Changing key storage location

The default storage location is <BDS_HOME>/kr. Use this option to change the location.

Example:

Current directory for keys: C:\BDS

Are you sure you want to change the directory (Y/N)? Y Please enter new directory: D:\SecretKeyLoc

Directory for storing keys updated successfully. Press any key to continue...

Changing the default key

To change the default key used to encrypt files, select the key from the list of keys. When the default key is changed, all files moving forward will be encrypted using the new default key. Existing files will not be re-encrypted. To change all existing files to use the new default encryption key, set the default key here, and then encrypt the entire file system using the Advanced Options menu (see below).

Example:

List of keys:

1. k1 07/04/07 2. k120234 12/26/07

3. k1230 01/01/08 default

Are you sure you want to change the default key (Y/N)? Y Please enter the number of the key you want to select as default: 2

Default key changed to k120234 successfully. Press any key to continue...

Advanced options: encrypt full file system

The encryption option in Advanced Options provides the ability to change the encryption of all files, including existing files encrypted using different keys. (The standard encryption option, described above, only encrypts unencrypted files, and leaves encrypted files alone.)

Example:

(36)

Processing file 3882 of 32357 (12% complete); Time remaining: 9 hr 20 min

Encrypted 32357 files. Total time: 10 hr 29 min. Press any key to continue...

Advanced options: remove a key

Removing keys from the system requires all files encrypted using the key to be decrypted first. If encryption is currently set to “enabled,” the files must also be re-encrypted using the default encryption key. Once all files have been decrypted, the selected key is removed from the system.

Example:

List of keys:

1. k120234 12/26/07

3. k1230 01/01/08 default

Are you sure you want to remove a key (Y/N)? Y

Please enter the number of the key you want to remove: 1 Are you sure you want to remove key k120234 (Y/N)? Y Processing file 3781 of 8795 (43% complete) encrypted using key k120234; Time remaining: 2 hr 23 min

Processed all files encrypted using key k120234. Key k120234 has been removed.

(37)

Section 5: Licenses

Licenses

Biscom Delivery Server installs a 15-day trial license by default, which supports ten Senders and unlimited recipients. Biscom Delivery Server licenses are XML files that contain information on product features and licensed modules. The license requires a valid license key and serial number. These are used in conjunction to verify the validity of the license. Modifying these values (e.g. the product, module, expiration date, maximum senders, or other features) will invalidate the license.

A license will have the following structure:

<?xml version="1.0" encoding="UTF-8"?> <bds-licenses> <license key="001242w120fd87q1a7d110650d3003lep90"> <product>bds</product> <module>base</module> <serial-number>trial</serial-number> <expiration>d30</expiration> </license> </bds-licenses>

To install a new license, obtain the license XML file and place it in the license directory (as specified in the fds.properties configuration file). Open the

fds.properties file and update the value for the licenseFile property by

specifying the name and directory location of the license file. See the section on System and Application Configuration for more information on the fds.properties

file.

After copying the license to the proper license location, stop and restart the application server to enable the new license.

(38)

Section 6: Starting and Stopping the Application

Starting the Application

The installation scripts normally start up the applications upon completion or after a server reboot. But in cases where the application is not running, use the following steps to start the application.

Windows:

1. Log on to the computer with a user that has privileges to start and stop Windows services.

2. Open the Windows Services manager by going to Start Menu > Control Panel. Double-click the Administrative Tools icon, and then double-click the Services icon.

3. Start up the services in the following order if not already started: a. Database (PostgreSQL by default).

b. Web server (Apache2 by default).

c. Application server (Apache Tomcat by default). Biscom Delivery Server should now be running and accessible.

Linux:

1. Log on to the computer as a user that has privileges to start and stop the application server, web server and database server (often an administrator or root).

2. Ensure the Web server is running. This will vary from system to system – use the command you are most comfortable with. For example, the following command may be used:

$ /etc/init.d/httpd [ start | restart ]

3. Ensure the database is running. This will vary from system to system – use the command you are most comfortable with. For PostgreSQL, the following command may be used:

(39)

4. Start up the application server. For Apache Tomcat the following command may be used:

$ /etc/init.d/tomcat [ start | restart]

Biscom Delivery Server should now be running and accessible.

Stopping the Application

To stop the application, simply shut down the application server. Some changes to the configuration will require a restart of the application server. The Web server and database server usually do not need to be shut down and restarted for configuration updates.

Windows:

1. Log on to the computer with a user that has privileges to start and stop Windows services (usually an Administrator of the system).

2. Open the Services manager by going to Start Menu > Control Panel. Double-click the Administrative Tools icon, and then double-click the Services icon.

3. Find the application server (e.g. Apache Tomcat) service and click the Stop button.

4. Optionally stop the PostgreSQL and Apache2 services if desired.

Linux:

1. Log on to the computer as a user that has privileges to start and stop the application server, web server and database server.

2. To stop the application server:

$ /etc/init.d/tomcat stop

3. To stop the Web server:

$ /etc/init.d/httpd stop

4. To stop the database server:

(40)

Section 7: Signing In for the First Time

First Sign In

Now that you’ve completed the initial installation and started up the application, you’re ready to sign in for the first time. Fresh installs of Biscom Delivery Server have a single user preconfigured who has been assigned the Administrator role. The username is admin and the password is admin. This is a temporary password which should be changed as soon as possible.

One of the first tasks is to configure the application to work in your environment – setting default behavior, customizing the look and feel, and setting default

parameters. Once the system is configured properly, the next task is to create users, including other Administrators who can manage the system and users. You can create as many users with Administrator, Report, and Recipient roles. However, you are limited to creating only up to the licensed number of Senders you have

purchased.

The steps to get the server prepared for users to start sending files:

1. Specify an SMTP mail server to use to send delivery and access notifications. This is performed in the Server Configuration section and is described in more detail below.

2. Customize the application with your organization’s messages, logo, etc. The common customization done are:

a. Company name and system b. Logo

c. Text in the sign in page d. Delivery notification message e. Footer text in delivery notifications f. User registration behavior

g. Package settings and restrictions

3. Create users manually (one at a time) or import them from an XML or CSV-compatible spreadsheet. Also, if you are using LDAP or Active Directory, assign users and roles using security groups.

(41)

Section 8: System and User Administration

Administrators have access to system configuration and user management. From the Home page, click the System and User Administration icon or

click the System and User Administration link.

Server Information

Server information contains configuration settings and system statistics including license serial number and key, number of Senders supported by the license, users and roles currently active, pending, and disabled, and the number, size, and status of all packages and deliveries.

Server Configuration

(42)

page. This page contains multiple sections ranging from delivery and package settings, to user registration, user interface, and authentication. Configuration updates are reflected immediately in the application without requiring an application server restart. Any user with the System Administrator or Super User role can update the system configuration by going to System and User Administration > Server Configuration

Server Configuration

Company name: Name of your company.

System name: The system name that is used when a system generated email or other notification is sent to a user. This is used, for example, when a user resets his or her password – the system will notify the user via email, and the email will be signed using the system name.

Administrator email: One or more email addresses of administrators who will receive emails from the system for various notifications.

Time zone: Specify the time zone in which the server resides.

Locale language: The language used for the locale. Currently, en is the only supported language.

Locale country: Currently, US and GB are the only countries supported.

Email and Notification Settings

BDS sends email notifications to recipients of deliveries, as well as to senders when a recipient has viewed a delivery. BDS leverages your existing mail server when sending notifications and you must specify your mail server to enable notification. The mail server configuration is found by signing into the Web application as an Administrator and opening the System and User Administration > Server Configuration page. Enter the mail server information and if required, any authentication information in the Email Notification Settings section.

(43)

Notification mail server: Enter the SMTP server to use for sending out delivery and access notifications.

Notification mail server username: If the mail server used to deliver notifications requires authentication, enter the username for authentication - otherwise, leave this property blank.

Notification mail server password: If mail server authentication is required, use this property to enter the password for authentication - otherwise, leave this property blank.

Confirm notification mail server password: Re-enter the password to confirm.

Notification sender: Sets the notification email address that sends the notification. Set this property to SENDER to use the email address of the user who has sent the delivery.

Notification link protocol: This specifies the protocol used for the delivery URL in the notification email sent to recipients. Set to http by default. Can be set to https if an SSL certificate has been installed on the Web server.

Notify user when password reset by an administrator: Whether to send an email to the user when an administrator resets the user’s password.

Notify user when password reset by user: Whether to send a confirmation email to the user when the user resets his or her own password.

System notification sender: This sets the email address from which system notifications are delivered. For example, this is the email address that Senders receive when a recipient views a delivery. If no value is entered for this property, the email address will be notify@<domain name>.

Populate username for delivery notification links: If set to Yes, the application will populate the username field automatically when recipients click on the delivery link.

(44)

Microsoft Outlook Add-in Settings (OPTIONAL)

These settings are used for the optional SMTP API module only. If purchased, the SMTP API enables applications to send an SMTP message along with commands to create and send deliveries.

Allow SMTP Input (API): Set this to Yes if your server supports the SMTP API. This is an optional module.

Outlook server: The IP address or host name of your mail server used with the SMTP API.

Outlook mail server username: The username to log onto the mail server to retrieve messages sent to the SMTP API.

Outlook mail server password: The password to log onto the mail server to retrieve messages sent from the Outlook Add-in.

Confirm Outlook mail server password: Re-enter the password to confirm.

Note: This is a deprecated configuration for an earlier version of the BDS Outlook in. The later versions of the BDS Outlook add-in do not use this API. To configure the newer BDS Outlook add-add-in, click on the Configure Outlook add-in policies link. The

configuration is described in detail in the section on the BDS Outlook add-in.

For Outlook add-in policies and configuration, see the section on Microsoft Outlook Add-in below.

(45)

Delivery Settings

Default secure message: If text is entered for this property, it will be the default secure message used when creating deliveries.

Note: This secure message does not apply to deliveries created with the Outlook Add-in; the add-in only uses the text entered in the original message.

Default delivery notification message: If text is entered for this property, it will be the default message used for delivery notifications. This message can be change or deleted by senders before sending the delivery out.

Delivery notification footer: If text is entered for this property, it will be appended to the bottom of all notification messages. This message is always sent with the notification message and cannot be deleted by the sender. For example, a privacy policy or confidentiality statement may be entered here.

(46)

List files in delivery notification message: If checked, the e-mail notification message will contain a list of all files sent through BDS. Unchecking this will suppress the file listing.

Delivery expires after (in days): If a number is entered for this property, it is used to calculate and enter a default delivery expiration date when a delivery or express delivery is created. A sender can delete this expiration date before sending the delivery.

Always require recipients to sign in: This setting allows administrators to remove the Require recipients to sign in checkbox as one of the delivery parameters. If set to Yes, senders cannot create no sign-in deliveries, and any existing deliveries that did not require sign in will immediately require users to sign in.

Require recipients to sign in by default: This is the value used in checkboxes for deliveries. For Outlook add-in deliveries, because the sender does not have the option to choose the sign in requirement, this value will be used. For example, if this is set to Yes, then any Outlook add-in deliveries will require sign in; if set to No, the Outlook add-in deliveries will not require sign in.

Enable secure reply: The secure reply feature may be enabled or disabled. When disabled, recipients of deliveries cannot send messages or files back to the sender. When enabled, administrators have the option of showing or hiding the secure reply section. When hidden, the user must click the reply button to open the reply section. If this feature is disabled, all existing deliveries will no longer have the reply option. However, any existing replies will still exist and are accessible by users.

Express Delivery: Show options/Hide Options: You can simplify the express delivery page to show only the most critical sections of the form. You can decide whether to show all delivery options, or hide the delivery options, minimizing the information requested. If delivery options are hidden, users can easily unhide them by clicking a “Show options” link.

Configure limited sender settings: Click this link to go to the limited sender configuration page and define delivery settings for users who do not have the Sender role assigned. If you click this link before updating the configuration, any changes you made will be lost.

Limited Sender Settings

View and update the limited sender settings on this page, including enabling and disabling this feature. Limited sender can be configured to give external users the ability to send files into an organization, but restricts various features that full senders can access. Some of the limitations of a limited sender compared to a full sender:

100MB file size upload limit

Standard file upload, no access to Java applet for drag and drop, checkpoint restart

(47)

Three files maximum can be uploaded per delivery

No notification to the limited sender when a delivery is viewed by recipients Recipients cannot securely reply to a limited sender

No access to detailed delivery reports

Deliveries created by limited senders can be viewed in the Deliveries Sent page, but cannot be edited. Other restrictions may apply, based on the settings defined in this section by an administrator.

Enable limited senders: To enable limited sending for non-Senders, set this value to Yes. This will provide a delivery page with the restrictions settings defined below.

Require sender to sign in: If this is checked, only authenticated users will have the ability to create limited deliveries. If unchecked, the limited delivery capability is available even without signing into the application. This enables administrators to provide the limited delivery form outside the application. Senders using this form will be required to enter their email address before a delivery can be created.

Note: If you do not require senders to sign in, users can

potentially create deliveries and spoof the sender’s email address.

(48)

o Allow user to type in: Select this to permit users to freely enter any email address in the recipient field. Administrators can restrict the recipients to certain domains or even individual email addresses by entering patterns and addresses in the Restrict recipients to text box.

o Use default value: Select this to automatically send deliveries to a specific email address. The recipient can be displayed to the sender (if the Visible checkbox is checked) or hidden.

Message settings: You can show or hide the subject field or message field to the sender. If the subject field is hidden, a default subject message is used. If the message field is hidden, the default secure message defined in the system configuration is used.

File upload settings: You can select the number of file upload slots to display, from zero to three slots. You can also limit the size of the files a limited sender can upload. Maximum size specified applies to each individual file.

Delivery settings: Limited senders do not have the ability to change the delivery options like full senders. Delivery options are pre-defined by the administrator. The delivery options you can configure are: sending an email notification to recipients, requiring recipients to sign into the application to retrieve their delivery, and automatic package deletion (if this is set to 0, then the package will never be deleted).

(49)

File upload slots per page: This sets the number of file upload slots per page when creating deliveries (both normal deliveries of an existing package as well as express deliveries). Valid values are between 1 and 10.

Notify user when added as a package owner or sender: If set to yes, a notification email will be sent to users who are added as an owner or a sender of a package. This informs people if they are given access to edit and/or deliver a package.

Allow users to delete multiple packages: If set to yes, Senders can select and delete multiple packages from the Manage Package list. Senders can only delete packages that they own. Because this can be a potentially dangerous operation that can quickly delete many packages and all associated deliveries, this feature can be disabled by an administrator.

Package deletes after (in days): Define the number of days newly created packages will be valid before being deleted by the system.

Reminder before package deletion (in days): System sends an email reminder to all package owners and senders whose packages will be deleted shortly.

Hide auto-deletion fields if not editable: For users who cannot override the auto-deletion values, the auto-delete fields are displayed but grayed out and uneditable. If this is an uneditable field, some administrators will choose to hide it from the sender.

List of owners who can override deletion: Enter a specific user or user pattern (using wildcards like ? and *) who can override the deletion dates. These users can change the dates for deletion and email reminders, as well as completely override the deletion by deleting the date entirely. Multiple email addresses or patterns should be separated by commas.

Note: Package deletion is permanent and will delete all files, deliveries, replies, and files uploaded through replies. Recipients will no longer see deliveries in their Received Deliveries list for deleted packages, and any delivery notifications links in email will no longer be valid.

Unrestricted senders: If defined, this is the list of Senders that are not subject to the inclusion and exclusion lists. So, if this list contains

*@biscom.com, then all Senders who have an email address matching

@biscom.com are exempt from the inclusion/exclusion rules. A Sender with

email address [email protected] will be subject to the inclusion/exclusion rules. If a user has an inclusion or exclusion list defined at the user level (not at this system level), then that takes precedence over their inclusion on this unrestricted senders list, and they will be subject to the inclusion/exclusion restrictions defined for their specific user account.

Default recipient inclusion list: If defined, this is a list of recipients or recipient patterns that are acceptable recipients for all Senders. An

Administrator may override this on a per user basis. If any delivery recipient matches any email or patterns specified in this list, they will be allowed as

Administrator s Guide