5_3:server_setup_patterns

KB0000220 Server Setup Patterns

Introduction

The PIAB server is a standard ASP.NET and SQL Server web service and browser application. Because of this, it can be configured in a variety of ways, including using single or multiple servers. This document describes some typical setup patterns. Please note that applying these patterns requires knowledge of Windows system administration and .NET administration.

Key Issues

The main issue when creating and using a setup pattern is how to get the authentication correct between the various components of the system. This is simplest when all the components of the server are on a single PC, and more complex when the components are distributed among multiple PCs.

We recommend using Windows authentication and trusted connections throughout, and PIAB can be configured in this way. Please be aware that this requires extra technical work to ensure that the system has correct access to all these components. This is especially the case with a distributed system.

The setup issues include:

  1. How the PIAB client authenticates to IIS
  2. How the web services application authenticates to SQL Server
  3. The location of the PIAB system folders
  4. Ensuring that the search function (Windows Search) can read the correct PIAB system folders

Authentication Schemes

Our recommended scheme is to use Integrated Windows authentication. In this case, IIS is set to use Windows Integrated Authentication, only the user name is stored in the piab database and the user name must match a valid Windows login name. The client's connection settings are switched to use Windows Authentication. This is the preferred mode in an Active Directory environment as it give improved security and simpler user management.

Alternatively PIAB can be configured to use Anonymous Access to IIS. In this mode, any user can connect to the web service but a valid PIAB username/password must be sent with each request to gain access. Credentials are stored in the piab database itself and authentication is perfomed by the application.

Techniques and Technologies

The patterns described here rely on a number of Windows and .Net techniques and technologies with which the administrator should be familiar:

http or https (TLS)

The piab client can communicate with the server via http or https. Using http, information is transimitted in plain text. Using https, the communications are encrypted. To use https, IIS must have a server certificate installed.

IIS Authentication

IIS can be configured to authenticate the client in a number of ways:

  • Anonymous Access
  • Basic Access
  • Integrated Windows Access

In IIS 7 and above you can specify the user that will access system resources, or use the one supplied by the system. This is important when considering permissions to access local and remote resources.

The Web Application User

By default a web application runs in the security context of a local user/group as follows:

OS User
Windows 2016 Server IIS_IUSRS
Windows 2012 Server IIS_IUSRS
Windows 2008 Server IIS_IUSRS
Windows 2003 Server NT AUTHORITY\NETWORK SERVICE
Windows 2000 Server %machinename%\ASPNET

You may need to change the user e.g. to a network user to allow access to remote resources if you are creating a distributed system. You can either do this by changing the identity in IIS (recommended), or using .NET Impersonation.

SQL Server Authentication

Connections can be made to SQL Server via:

  • Trusted Connection (using an authenticated Windows User)
  • Mixed Mode access (username and password supplied)

A Trusted Connection is recommended for improved security. Example connection strings, set in the piabws.cfg file via the 'PROJECT in a box Server' program:

Trusted Mode:

Server=(local);Database=piab;Trusted_Connection=True;

Mixed Mode:

Data Source=(local);Initial Catalog=piab;User ID=foo;Password=bar;

User for Trusted Connection to SQL

The following table shows the different users for the Trusted Connection in different configurations. The first is for a remote SQL Server, and the remainder are for a SQL instance local to the web application.

Configuration Windows Account
Remote SQL Server,
where 'machinename' is the hostname of the Web Application server
%domain%\%machinename%$
Windows 2016 ServerIIS APPPOOL\DefaultAppPool
Windows 2012 ServerIIS APPPOOL\DefaultAppPool
Windows 2008 ServerIIS APPPOOL\DefaultAppPool
Windows 2003 ServerNT AUTHORITY\NETWORK SERVICE
Windows 2000 Server%machinename%\ASPNET
Vista with IISNT AUTHORITY\NETWORK SERVICE
Windows XP Professional%machinename%\ASPNET
Windows 2000 Professional%machinename%\ASPNET

Searching

PIAB can use a 'Simple' built-in search, that doesn't use Windows Services, or 'Windows Search' or 'Indexing Service' that do.

Windows Search

When using 'Windows Search', the PIAB 'doc' folder must be included in the local search, or if using a remote 'doc' share on another Windows server, then this must be indexed remotely and a reference set to the remote index, using appropriate permissions. Setting up remote searches requires Windows Sysadmin expertise and is beyond the scope of this document.

Indexing Service

When using Indexing Service' to perform document searches, the service must contain a catalog called 'piabdoc' that includes the PIAB 'doc' folder (which contains all the project files). If the folder is stored on a file share, then the Indexing Service must be modified to include that share as a UNC path, and appropriate permissions set up to access it.



Pattern 1: Single Server

A single server PC with Windows Server, Anonymous IIS Authentication

This pattern is the default for PIAB installed on single Windows Server. All the files/folders and the SQL Server instance are on the server itself. The PIAB client accesses the web service using anonymous IIS access, and the default local account is used to access file resources and to communication with SQL Server.

Pattern 1

Pattern 1a: Separate Temporary Virtual Directory

As a variation to Pattern 1, a separate temporary virtual directory can be set up in IIS which holds user-session data for the Browser App. By default, this temp folder is held within the 'piabws' IIS application itself. PIAB has it's own garbage collection which always operates, but having a separate temp virtual directory makes this more efficient and keeps the main web application folders clean.

Having set up the temp Virtual Directory in IIS, there is a setting in the PIAB Server Management Tool to identify which folder to use, and the URL to access it via http.

Pattern 1a

Pattern 2: Separate SQL Server

This pattern allows for the SQL Server database to be stored on a separate server. All other resources are local.

Pattern 2

Pattern 3: Three Servers

In this pattern, the application is split over three servers with some application folders stored on a remove server (e.g. another Windows Server or NAS or SAN) of some kind. Integrated Windows Authentication is used between the PIAB client and IIS. The identity running the web application is changed to that of a domain user to allow authentication to remote resources (SQL Server and remote folders).

Pattern 3

Pattern 4: Internal and External Facing Servers

In this pattern, there are now two web servers, one on the internal LAN and one accessible remotely via your gateway. The topology may vary significantly from one organisation to another, so we can only represent these at a high level here.

There is a separate instance of the PIAB server on each web server, however they both connect to the same resources: a SQL Server instance and a file store containing documents and files that need to accessed and maintained in common, typically the 'doc' folder store containing the project files that are checked-out/in. Other static data can be kept on the individual web servers e.g. Browser App stylesheets and static text, or PIAB Method Templates and Reporting Templates. Changes to this data can be done manually - or using synchronisation software. That is your choice.

Authentication

For external access we always recommend a secure VPN, together with Integrated Windows Authentication for PIAB. However this pattern does allow you use different authentication methods on each web server, so you could publish the Browser App as external-facing web app for third party access. We recommend you carefully consider the risks associated with this, which will vary from one organisation to another and with the nature of the data stored in the application.

Mutiple URLs

In this pattern, there will be different URLs for accessing the internal and external facing systems. Many of the features in PIAB, e.g. email notifications, include links that users can follow back into the system to investigate the data in more detail. The Server Management Tool allows multiple URLs to be specified, with descriptions, so that links can be sent that are valid for either location.

Pattern 4

5_3/server_setup_patterns.txt · Last modified: 2019/11/12 15:17 (external edit)

Page Tools