Building a Secure Ecosystem for

Laserfiche

White Paper

April 2018
Table of Contents

Introduction .................................................................................................................................. 4
Protecting Data in Transit ........................................................................................................... 5
Network Architecture ............................................................................................................. 5
Firewalls and DMZs ................................................................................................................ 5
Web Server in DMZ ............................................................................................................. 6
Reverse Proxy ....................................................................................................................... 7
Using Directory Server with a DMZ ................................................................................. 8
Other Resources ................................................................................................................... 8
Encryption ................................................................................................................................. 9
Protecting Data-at-Rest ............................................................................................................. 10
Access Control for Databases and File Systems ................................................................ 10
Minimum Privileges .............................................................................................................. 10
Permissions to SSL Certificate Keys ................................................................................ 11
Laserfiche Server ................................................................................................................ 12
Laserfiche Full-Text Indexing and Search Engine ......................................................... 13
Laserfiche Directory Server .............................................................................................. 14
Forms ................................................................................................................................... 15
Audit Trail ........................................................................................................................... 17
Workflow............................................................................................................................. 18
Encrypting Data-at-Rest ........................................................................................................ 19
Database Encryption.......................................................................................................... 19
Volume Encryption ............................................................................................................ 19
Document Encryption ....................................................................................................... 20
Laserfiche App Encryption and Access Control ............................................................... 20
Electronic Documents ........................................................................................................ 20
Laserfiche Imaged Documents ......................................................................................... 21
Offline Documents ............................................................................................................. 22
Laserfiche Forms Security in the Mobile App ............................................................... 22

2
 Temporary Files ..................................................................................................................... 23
Detecting Unauthorized Modifications .............................................................................. 24
Digital Signatures in the Laserfiche App........................................................................ 24
Commonly Required Procedures for Access Control........................................................... 26
Changing Permissions to a Folder ....................................................................................... 26
Changing Permissions to a Registry Key ........................................................................... 26
Finding and Changing a Service Account .......................................................................... 27
Finding and Changing an Application Pool Identity ....................................................... 27

3
Introduction
While Laserfiche provides sophisticated ways of controlling access to repository
contents through entry access rights, feature rights, privileges, and security tags, a
secure Laserfiche system also requires that you secure your Laserfiche data using access
control measures outside of Laserfiche. In this paper, we cover possible ways to protect
your data, both in transit and when it is at rest. We also touch on security best practices,
such as how to grant the most minimal privileges possible to the Windows accounts
that run Laserfiche services.
Defense in depth is a general security principle that you should adhere to when setting
up a secure ecosystem for Laserfiche. Defense in depth says that rather than having one
single, strong defense that an attacker must overcome to succeed, you should have a
variety of defenses that all must be overcome by the attacker. In the Laserfiche context,
defense in depth means that we secure direct access to the data by using the access
control abilities that are internal to Laserfiche products. We also secure indirect access
to the data, such as through the Windows file system or through SQL Server, by
restricting who can access the data. Finally, we ensure that even if the data is accessed,
it is encrypted and cannot be read without the appropriate keys.

4
Protecting Data in Transit
Network security protects data-in-transit: It ensures that attackers do not gain access to
your data by listening in on data while it is passing between different computers.
Network security can be implemented by having the appropriate network architecture
and ensuring that data is always encrypted when it is transmitted between computers.

Network Architecture
Laserfiche uses an n-tier architecture. A user signs in to a Laserfiche repository using a
client, such as the web client or a mobile application. The client will contact the
Laserfiche Server. The Laserfiche Server will in turn retrieve data from a database
server or from file volumes. Crucially, the web client server never communicates
directly with the file volumes or with the database server.
The same layered architecture applies for applications like Workflow and Forms. If the
web client initiates a business process, the client will communicate with the Workflow
Server. The Workflow Server will then connect to the Workflow SQL database. But once
again, the web client never directly communicates with the SQL Server. Workflow also
does not communicate to repository volumes directly—if it needs to access repository
content, it contacts the Laserfiche Server first, and only the latter communicates directly
with the volumes.
N-tier architecture is good for security, because minimizing the number of direct
connections between computers means that you can configure firewalls between
computers that never have to directly communicate with each other. For example, you
can configure a firewall between the web client server and the Laserfiche Server’s
database server, as the former never has to directly communicate with the latter.

Firewalls and DMZs

A firewall restricts access to a computer, allowing communication only with sources
that are explicitly configured to be exceptions to the rule. Exceptions can be made for
incoming or outgoing data. For computer A to send data to computer B, you will need
to make an outgoing exception for computer A and an incoming exception for computer
B.
Laserfiche products will use port 80 for HTTP data and port 443 for HTTPS data unless
you specify otherwise. You can make port-based rules using this fact.
While exceptions can also be made based on application rather than port, port-based
rules are simpler to configure. This is because incoming requests and outgoing requests
may be handled by different applications even if the requests are for or from the same

5
Laserfiche product. For example, IIS may handle many requests that are for Laserfiche
web applications, while in other cases the application executable may be handling the
requests.
Some Laserfiche products have a public-facing portal that is designed for internet
access. This exposure to users outside the organization’s intranet may require
additional layers of security. A demilitarized zone (DMZ) is one way of providing such
security. A DMZ is an intermediate zone between the internet and an organization’s
intranet. One firewall separates the DMZ from the internet, while another separates it
from the intranet. The public portal is located in the DMZ. It mediates between public
users and servers in the intranet.
Between the intranet and the DMZ, you will typically open only the ports that are
required for your public portal to send the required data to internal servers. This means
that even if the DMZ is compromised, access to the intranet is limited.
Between the DMZ and the internet, you would open a port like 80 or 443 that would let
public users access the portal.
We now describe some common DMZ configurations that are useful for securely
hosting Laserfiche public portals.

Web Server in DMZ

One DMZ configuration you may consider is having your web application server (such
as Forms, WebLink, or the web client) in the DMZ, while having other servers that
aren’t directly accessed by the public in a more secure internal network. A user accesses

6
the web application from the icon marked “Desktop” in the diagram. To do so, they go
through a firewall in which only port 80 or 443 is opened.
There is another firewall between the web server and the internal network, again with
only port 80 or 443 opened. The web server transmits information about the actions that
the user wants performed through this firewall. In this way, the user is able to perform
actions in Workflow or a repository (for example) without direct access to the internal
network.
If you want users in the internal network to also use the web application, you should
have a separate installation of the web application server inside the internal network.
This avoids exposing the data of your internal users in the less secure DMZ.
Note: In this DMZ configuration, Windows authentication for your
external users is typically impossible, as credentials that work for your
internal servers typically will not work for the DMZ server.

Reverse Proxy
In the previous DMZ scenario, you needed two instances of the web application server
if you wanted to serve both internal and external users in a secure manner. If that
configuration would be too costly, you can use a reverse proxy server in the DMZ
instead.

In the diagram above, the entity labeled Web Proxy will appear to users as though it is
the actual web application server. It resides in the DMZ and forwards all requests from
external users to the web application server in the internal network. Responses from the
web application server are forwarded back to the external user through the proxy
server. To the external user, it will appear as though the response came directly from
the web application server.

7
As with the previous scenario, you have a firewall between the DMZ and the internet,
and between the internal network and the DMZ. Only the ports you require are opened
in these firewalls. Unlike the previous scenario, you only need one web application
server, located in the internal network, to serve both external and internal users. There
will be no servers containing sensitive information in the DMZ.

Using Directory Server with a DMZ

Given the difficulties of using Windows authentication in a DMZ setup, using
Laserfiche Directory Server’s single sign-on capability may be a particularly attractive
option. The Directory Server’s security token service (STS) can be located in the DMZ,
keeping the Directory Server itself in the more secure internal network.

An external user would authenticate to the Directory Server STS instance located in the
DMZ. Ports are opened between the DMZ and the internal network to allow for the STS
instance to pass credentials to Directory Server, and to allow the DMZ web server to
communicate with Directory Server and other Laserfiche application servers in the
internal network.

Other Resources
For details on how to configure Laserfiche Forms in various DMZ scenarios, consult the
white paper on Hosting Laserfiche Forms 10 In A Perimeter Network (DMZ).

8
Encryption
To protect data as it passes between computers on a network, you can configure
SSL/TLS encryption on your Laserfiche applications. All Laserfiche products allow you
to configure SSL/TLS between the application server and client computers, between
different application servers, and between application servers and database servers. See
the white paper on Configuring SSL/TLS Encryption in Laserfiche for more details.
Once you have configured SSL or TLS, make sure to block the HTTP port 80 to prevent
any accidental unencrypted connections. In Laserfiche Forms 10.3.1 and later, you can
enable HTTPS redirection on the Forms configuration page. This means that if a user
tries to access a form at a HTTP URL, they will be redirected to the HTTPS version of
that URL.
Laserfiche supports a number of SSL and TLS protocols, up to TLS 1.2. If multiple
encryption protocols are supported by your system, Laserfiche will use the newest
version that is shared by the communicating computers. If you want to explicitly use an
older version of SSL or TLS, you should manually disable the newer versions of SSL or
TLS on the relevant computers. This can be done by editing the computers’ registries.
Consult the Microsoft documentation for more details.
IPsec is an alternative to SSL/TLS for encrypted transmission of data. Depending on
your organization’s needs, IPsec may be easier to manage, as it does not require every
server to have a certificate. Another possible advantage is that IPsec would encrypt all
data transmitted over the network, not just data passed between Laserfiche
applications.

9
Protecting Data-at-Rest
Laserfiche provides various tools for administrators to control access to content through
Laserfiche applications. This content is ultimately stored in a database or file server
somewhere, which may be accessible outside of Laserfiche applications. To protect this
content, you should implement access control on the file system or database and
encrypt files. These measures should also be carried out on the locations where
temporary files are stored. To check for tampering with data-at-rest, you can also use
digital signatures and volume checksums.

Access Control for Databases and File Systems

While Laserfiche application servers need access to their associated databases, your
users do not need such access. Ensure that your users do not have access to databases
like the repository database or the Forms database. Only the Laserfiche application
service accounts need such access.
In addition, only the Laserfiche Server service account needs access to the repository file
system. Users and other Laserfiche applications will access this file system only through
Laserfiche Server, so they should not be granted access. Besides the repository file
system, Laserfiche applications also store temporary files, which you should also ensure
that ordinary users cannot access.
You will have to make some exceptions for users that have to perform tasks related to
maintenance, backups, and troubleshooting. You can create accounts that are
specifically for performing these tasks, and disable them until they are needed.
Service accounts should be used only to run the service, and not for other purposes.
Ordinary users should not be granted direct access to database servers or file systems,
but should access them only through Laserfiche services. In general, access to databases
or file systems should be granted based on the Principle of Least Privilege. This says
that users or service accounts should be granted the lowest levels of privilege that are
sufficient to fulfill their responsibilities.
We will now describe the minimum privileges that service accounts for various
Laserfiche application servers require.

Minimum Privileges
By default, unless you specify otherwise, many Laserfiche application servers run as the
LocalService (NT AUTHORITY\LOCAL SERVICE), LocalSystem (NT
AUTHORITY\SYSTEM) or NetworkService (NT AUTHORITY\NETWORK SERVICE)
accounts. The LocalService account has minimal rights on the local computer and no

10
rights on the network. The Network Service account also has minimal rights on the local
computer, but it acts as the computer on the network. The LocalSystem account has
extensive privileges on the local computer (it is part of the local administrators group)
and acts as the computer on the network. If your service is running only locally and
does not need administrative privileges, it is safer to use LocalService. For a service that
needs to communicate on the network, such as Laserfiche Directory Server,
NetworkService is often the default choice. You should avoid using LocalSystem unless
absolutely necessary.
If want a service to authenticate to another server, such as a remote database, a file
server, or another Laserfiche server, you should not use LocalService. In such a
situation, it may be most convenient to have your service run as a Windows user
account and grant it only the minimum network privileges it needs. If you choose
instead to use the default local machine account, you will have to keep track of every set
of user credentials that the service uses to connect to other servers. In addition, it is
easier to monitor for any misuse of those credentials if the account is a Windows
domain account. See our instructions on how to view or change service accounts.
Web applications often run under an application pool ID. Each web application has its
own application pool, so you can give each application different rights to the local
computer. See our instructions on how to view or change application pool identities.

Permissions to SSL Certificate Keys

If you are using Laserfiche Directory Server single sign-on (SSO), and you have
application servers or Directory Server security token service (STS) instances that are on
different computers from Directory Server, these servers or STS instances will have to
communicate with Directory Server using SSL. In order for SSL to work, the Directory
Server service account and the various applications’ application pool identities must be
granted access to the keys of the SSL certificates. For example, for the web client, the
account that WebAccessAppPool runs as must have Read access to the private key of
the SSL certificate that the computer hosting the web client server is using to encrypt
communications with Directory Server. For Forms, the relevant application pool is
named FormsAppPool.
In addition, if your STS instance is on a different computer from Directory Server, then
the STS application pool (LicenseManagerSTSAppPool) must also be granted access to
the certificate’s private key.
To grant an application pool identity access to a certificate’s key:
1. Find out what user the application pool is running as following our instructions.
2. In the Windows search bar, search for the phrase “certificates.” Click on the
result Manage computer certificates.

11
 3. In the certificate manager, find the relevant SSL certificate. Usually, this will be in
Personal\Certificates. Right-click on the certificate and hover over All Tasks,
then click on Manage Private Keys.
4. If the account that the application pool is using is already listed under Group or
user names, select that user. If it is not listed, carry out the following steps:
a. Click Add….
b. Search for the account of interest in the ensuing dialog. Click OK when
you have found the correct account.
c. Back in the Permissions dialog, select the desired account under Group or
user names.
5. Under Permissions for UserName, select the Allow box next to Read.
6. Click OK to save your changes.
See the white paper on Configuring SSL/TLS Encryption in Laserfiche for more
information on setting up SSL for Laserfiche products.

Laserfiche Server
SQL Server Permissions
To create a repository, the account the Laserfiche Server uses to authenticate to SQL
Server must have the following minimum privileges:
 Either:
o The user it uses to sign in to SQL Server must have the ability to create
databases. This can be done either by adding the user to the Local
Administrators group on the server computer, or by granting the user the
dbcreator role. The latter option is more secure as it minimizes the number
of users with administrative privileges.
 Or:
o You can create the required database manually and have Laserfiche Server
authenticate to SQL Server on an account with the db_owner role. This
user will have access to that particular database but cannot create other
databases.
After a repository has been created, the Laserfiche Server service account requires the
following roles:
 db_ddladmin to create tables for temporary data such as search results.
 db_datawriter to write to the database.
 db_datareader to read from the database.

12
Local Computer Permissions
If the Laserfiche Server service account is not part of the local administrators group, you
will need to check that it has the following permissions:
 It should have the Log on as a service user right on the computer hosting the
Laserfiche Server.
 It should have full control permissions to the following Windows file system
locations:
o The Laserfiche Server installation folder (C:\Program
Files\Laserfiche\Server by default)
o The repository path (specified when you create a repository)
o The locations of repository volumes (also specified on repository creation)
 It should have full control of the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Laserfiche.
You will also need to run the following commands to reserve URLs for the Laserfiche
Server service account if it is not part of the local administrators group. Open the
command prompt as an administrator and enter the following commands:
 netsh http add urlacl url=http://+:80/lf user=DOMAIN\User
 netsh http add urlacl url=http://+:5053/ user=DOMAIN\User
 netsh http add urlacl url=https://+:443/lf user=DOMAIN\User
In the commands, replace DOMAIN\User with the domain name and username of the
service account you want to use.
Note: To use the Repository Creation Wizard in the Laserfiche
Administration Console, the Laserfiche Server service account must have
local administrative rights to the Laserfiche Server computer, regardless of
whether or not you have completed the steps above. We recommend
temporarily running the service using an account with local
administrative rights to use these wizards, then switching to an account
without local administrative rights for normal operation.

Laserfiche Full-Text Indexing and Search Engine

The Laserfiche Full-Text Search service needs Read and Write permissions on the
search catalog folder and its subfolders. If the search catalog is on the same computer as
the service, you can grant the default Local Service account that the service runs as
those permissions. If the catalog is on a network drive, you will have to change the Full-
Text Service to use a domain account with access to that drive.

13
The Full-Text Search service also needs full control permission to the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\LASERFICHE\LFFTS and its subkeys. See
our instructions on how to change permissions to registry keys.
Finally, to grant the Full-Text Search service the correct URL access control lists, launch
the command prompt as an administrator and run the following commands:
 netsh http delete urlacl url=”http://+:LFFTSPort/”
 netsh http add urlacl url=”http://+:LFFTSPort/”
user=Domain\User
Replace LFFTSPort with the port that the Full-Text Search service uses, and
Domain\User with the domain and username of the service account that the Full-Text
Search service uses.

Laserfiche Directory Server

SQL Permissions
To create a licensing site for Directory Server, the account used to sign in to SQL Server
must have the following permissions:
 Create stored procedures
 Create tables
Note: If you do not specify an existing empty database
for Directory Server, then the service account must also be able to create
databases in the specified SQL Server.
For normal operation, the account used to sign in to SQL Server must have sufficient
permissions on the SQL database to:
 Read
 Write
 Create tables
 Execute stored procedures
Non-SQL Permissions
The Directory Server service account should have full control permissions to the
following folders:
 The Directory Server installation folder (C:\Program Files\Laserfiche\Directory
Server by default)
 The Laserfiche ProgramData folder (C:\ProgramData\Laserfiche by default)

14
The service account should also have the Log on as a service user right. The
NetworkService account has this right by default. See the Microsoft documentation for
how to assign this right.
If you are adding Active Directory users in Directory Server, the service account should
also have the rights to query Active Directory.
Permissions for Active Directory Group Synchronization
If you are using Active Directory (AD) groups in Directory Server, the Directory Server
service account will need the following permissions in AD to synchronize AD groups:
 List contents
 Read all properties
 Read permissions
Permissions Required for SSO
If you are using SSO and not Windows authentication with Directory Server, you will
need to ensure that the relevant application pool identities have access to the SSL
certificate’s private key, following the instructions provided earlier.
Application Pool Users
Laserfiche Directory Server uses the application pool users LicenseManagerAppPool
and LicenseManagerSTSAppPool. These users should have the following minimum
rights:
 Read and List folder contents permissions on the Directory Server installation
folder (C:\Program Files\Laserfiche\Directory Server by default).
 Modify, Read, and Write permissions on the Directory Server program data
folder (C:\ProgramData\Laserfiche\LFDS by default).
 If you are authenticating to the Directory Server database using a Windows
account, the application pool users should be able to connect to the database
server, have access to the existing licensing database, and have the rights to
create a database.

Forms
The Forms application uses a few different services. Each of these requires a different
set of privileges to function properly.
Initial Connection
Forms uses a dedicated account to connect to the Laserfiche Server or Directory Server.
Forms generates and stores a random password for this account during configuration,

15
using the configuring user’s connection. This means that the user configuring Forms
must have the Manage Trustee privilege.
SQL Database Creation
Forms uses the FormsAppPool application pool identity and the Forms Routing Service
to connect to SQL. If you are using a Windows account to connect to SQL, ensure that
FormsAppPool and the Forms Routing Service are assigned the same Windows
account.
If the Forms SQL database has not been created yet, you will need to use an account for
FormsAppPool with the ability to create a database. After the database has been created
and configured, you can return to using an account that only has the rights mentioned
in the next point.
SQL Database Privileges after Creation
Once a database has been configured, the account Forms uses to connect to SQL must
have the following rights: db_datareader, db_datawriter, and db_ddladmin.
Other Privileges for FormsAppPool
The Forms application pool identity, FormsAppPool, needs full control over the
following folders:
 The Forms installation folder (C:\Program Files\Laserfiche\Laserfiche Forms by
default)
 The Forms ProgramData folder (C:\ProgramData\Laserfiche Forms by default).
This requirement applies only to Forms 10.1 or later. C:\ProgramData is a
hidden folder, so if you do not see the folder, make sure that Hidden items is
selected under View in the Windows file explorer.
Laserfiche Forms Routing Service
The Forms Routing Service URL must be reserved for the user that the Forms Routing
Service runs as. In addition, the Forms Routing Service needs the following types of
access to folders:
 Read access to the Forms installation folder (C:\Program
Files\Laserfiche\Laserfiche Forms by default)
 Modify access to the Forms ProgramData folder (C:\ProgramData\Laserfiche
Forms by default). C:\ProgramData is a hidden folder, so if you do not see the
folder, make sure that Hidden items is selected under View in the Windows file
explorer.
To grant the Forms Routing Service user access to the Forms Routing Service URL, carry
out the following steps:

16
 1. Launch the command prompt as an administrator.
2. Run the following commands, replacing Domain\User with the service user’s
domain and username:
a. netsh http add urlacl url=http://+:8169/
user=Domain\User listen=yes delegate=yes
b. netsh http add urlacl
url=http://+:8733/Design_Time_Addresses/AutoTriggerSer
viceLib/Service1/user=Domain\User listen=yes
delegate=yes
c. netsh http add urlacl url=http://+:8737/
user=Domain\User listen=yes delegate=yes
d. (For Forms 10.3 or above only) netsh http add urlacl
url=http://+:8739/ user=Domain\User listen=yes
delegate=yes
Laserfiche Notification Hub Service
The Laserfiche Notification Hub Service must be able to access the service URL. You can
grant it access as follows:
1. Launch the command prompt as an administrator.
2. Run the following command, replacing Domain\User with the service user’s
domain and username: netsh http add urlacl url=http://*:8181/
user=Domain\User listen=yes delegate=yes

Audit Trail
Audit Trail requires access to the Audit Trail SQL database. The type of access required
depends on whether it’s during installation, during upgrades, or during normal
operation. In addition, Audit Trail must be running as a Windows or Laserfiche user
that has been granted the Retrieve Audit Data privilege. Audit Trail does not need
direct access to the audit logs in the repository file system—as long as it has the Retrieve
Audit Data privilege, it can access audit data through Laserfiche Server.
During Normal Operation
When Audit Trail is not being installed or upgraded, the only rights it requires in SQL
are db_datareader and db_datawriter.
During Upgrades
When Audit Trail is being upgraded, it needs to change the database schema. The rights
the account it uses to authenticate to SQL Server during this process are db_ddladmin,
db_datareader, and db_datawriter. You may want to permanently assign the account
Audit Trail uses to authenticate to SQL Server the db_ddladmin role if remembering to
assign it every time you want to upgrade is too much trouble.

17
During Installation
If the Audit Trail database has not been created, you can either:
 Manually create a database in SQL and ensure that the Audit Trail signs in to
SQL with db_owner role, or:
 Ensure that the Audit Trail authenticates to SQL with an account that has the
dbcreator role.

Workflow
The Workflow service account, specified in the Workflow Server Login step when you
configured the Workflow Server, runs all individual workflows. If any actions in a
workflow require Windows authentication, these will be done using the Workflow
service account. This means, for example, that you should ensure that the Workflow
service account has the requisite rights to any folders in the Windows file system that
will be accessed by workflows. For the purposes of determining whether running
workflows can access Windows resources, the Windows account that you are using
when you are in the Workflow Designer is irrelevant—only the Workflow service
account matters.
Note: If you want to create scheduled workflows, the Workflow service
account must be able to run Windows Task Scheduler. This usually means
that they must have Windows power user privileges or be part of the local
administrators group—but this may depend on your IT department’s
security regarding Windows scheduled tasks. If you use the Windows
Vista operating system, the Workflow service account must have local
administrative rights.
For Workflow connection profiles, ensure that the Laserfiche users specified in the
connection profiles have the Laserfiche entry access rights and privileges that they need
to carry out the repository tasks in their respective workflows.
Workflow SQL Roles
When you are configuring Workflow Server, the account that Workflow uses to sign in
to SQL Server needs the following roles:
 dbcreator if the Workflow database has not been created yet
 Alternatively, if you have manually created the Workflow database, then the
user just needs the db_owner role on that database.
After configuration, the account that Workflow uses to sign in to SQL Server requires:
 db_datawriter and db_datareader for reading and writing data
 db_ddladmin when Workflow is upgraded

18
Encrypting Data-at-Rest
Laserfiche security, implemented through entry access rights, feature rights, and
privileges, controls access to repository contents when access is attempted through
Laserfiche application interfaces. However, the data is still stored on a file system or
database somewhere that may be accessible by non-Laserfiche methods. Encrypting
these data stores provides an additional layer of security beyond access control of file
systems and databases. If a data store is successfully encrypted, the attacker will not be
able to read the data even if they successfully breach your access control measures.
If you are backing up your data, do not forget to also encrypt those backups. SQL
Server 2014 and later can encrypt data while creating a backup.

Database Encryption
Both Microsoft SQL Server and Oracle support Transparent Data Encryption, in which
they encrypt all the data before writing it to disk. Laserfiche is compatible with
Transparent Data Encryption. However, Laserfiche does not support SQL Server’s
Always Encrypted feature. Laserfiche also does not support cell- or column-level
encryption.

Volume Encryption
For volumes that are still attached to repositories and actively being modified,
Laserfiche recommends using a disk encryption tool like Bitlocker (included in
Enterprise/Pro/Ultimate editions of Windows from Vista and Server 2008 onwards), or a
file system encryption tool like Microsoft’s Encrypting File System. Unlike whole-disk
encryption, file system encryption typically does not encrypt file metadata, so an
attacker would be able to access metadata such as file sizes without decrypting the files.
In addition, file system encryption can slow down system performance as each file will
be encrypted or decrypted in real time when changes are made.
If you use full disk encryption, make sure that you have a good key management
system, and back up your encryption keys.
Whatever encryption tool you use, the user that the Laserfiche Server service runs as
must be able to see through the encryption, as users will be accessing repository content
through this service.
Laserfiche provides an option for you to encrypt archived volumes or volumes that are
being transported. This option is not recommended for volumes that are attached to a
repository and that may be modified. If volumes are encrypted while still attached, you
will have to enter the encryption password every time the Laserfiche Server restarts.

19
Laserfiche’s encryption option lets you choose whether to use an AES-128, AES-192, or
AES-256 encryption algorithm.

Document Encryption
You can encrypt documents and folders with a password while they are being exported
as briefcases or PDFs. This allows them to be transported securely. When exporting as a
briefcase, a 128-bit AES algorithm is used. When exporting as a PDF, a 128-bit RC4
algorithm is used.

Laserfiche App Encryption and Access Control

We recommend using Mobile Device Management (MDM) solutions (Good Software,
MobileIron, etc.) to lock down configuration profiles that can enforce device locks and
detect if a user has disabled the lock. For an additional layer of security, Mobile
Application Management (MAM) solutions such as containerization and app wrapping
can be used together with MDM.
However, even without MDM, Laserfiche and the various mobile operating systems
provide some measure of access control and encryption to protect documents and forms
viewed on a mobile device. The following sections describe how these protections work.

Electronic Documents
You can force any Laserfiche electronic documents that are downloaded from the
Laserfiche app into mobile devices’ local file systems to be encrypted. To do this, select
Encrypt Laserfiche electronic documents stored in devices' local file systems on the
Laserfiche Mobile Server configuration page.
Note: If you use the iOS, Android, or Windows app with Laserfiche
Mobile 9.0 or earlier, electronic documents will be encrypted even though
this option is not available during configuration.
Even if this setting is selected, users can still export Laserfiche electronic documents to
other apps without encrypting them. If you do not want users to export unencrypted
Laserfiche documents to other apps, select the Prevent users from exporting to other
apps and saving copies of offline documents on mobile devices option.
The details of how electronic documents are encrypted if the Encrypt Laserfiche
electronic documents stored in devices' local file systems option is selected differ
depending on the mobile device’s operating system.
In iOS:
If Encrypt Laserfiche electronic documents stored in devices’ local file system is
enabled on the Laserfiche Mobile Server Configuration page, an electronic document

20
(PDF, Office document, etc.) will open in the iOS viewer, and a temporary decrypted
version of the document will be created. This version is protected by iOS device
protection, which encrypts application data. The encryption key is based on the user’s
passcode. If no passcode has been set up for the device, the decrypted version of the file
will be unsecured, but it will not be accessible from other apps. If a passcode is set, the
decrypted version will be protected by iOS encryption after the device locks.
In Android and Windows:
If Encrypt Laserfiche electronic documents stored in devices’ local file system is
configured on the Laserfiche Mobile Server Configuration page, electronic documents
that are saved locally will be encrypted with AES-256 encryption.
When the decrypted document is opened, it will open in the built-in viewer, be saved in
the device’s memory, and be unavailable to other apps. When the document is opened
in a third-party app, a decrypted file that will be accessible to other apps is generated in
the app’s storage area.
The document will be deleted when the user signs out, including when the app is re-
launched. If the abovementioned Prevent users from exporting to other apps and
saving copies of offline documents on mobile devices is enabled, an external viewer
will not retain a copy of the document in its storage area.

Laserfiche Imaged Documents

When opening Laserfiche imaged documents in the app, a local, unencrypted copy of
the image and/or text file is created and opened in the app’s built-in document viewer.
The copy is deleted when the document is closed. If the app stops unexpectedly,
leftover copies are deleted when the app is launched again. On non-rooted devices, data
is stored in the device’s sandbox and hidden from other apps. No external viewers can
be used to open the documents.
iOS and Android offer device encryption with a key that is always unique to the device.
It’s highly recommended to take advantage of this feature if you suspect malicious
users might try to access temporary copies of documents. This type of encryption is
only useful if the device is set to lock when not in use (PIN, passcode, etc.) Data is fully
protected if the device locks. Otherwise, anyone who picks up the device has access to
all the data. However, even without the lock, the encryption will ensure the app will not
run on jail-broken devices.
Windows tablets and phones also offer device-wide security. For more information, see
the Windows 10 Mobile Security Guide. Like in iOS and Android, documents are fully
protected from unauthorized users when a passcode is configured.

21
Laserfiche imaged documents opened using the Laserfiche app for Windows desktop
can be manually encrypted using the following steps:
1. Right-click (or press and hold) a file or folder and press Properties.
2. Press the Advanced button, then select the Encrypt contents to secure data
checkbox.
3. Press OK to close the Advanced Attributes dialog box, press Apply, and then
press OK.

Offline Documents
Documents saved from the repository as offline documents are encrypted like electronic
documents. Newly created offline documents (that were not saved from the repository)
are not encrypted. However, both types can be passcode-protected so people without
the passcode will not be able to access the offline documents. This ensures sensitive
documents will be secure if your device ends up in the wrong hands.
An administrator can require a passcode to be set up and entered when opening files
saved offline. The passcode’s hash is safely stored in a local SQLite database
On the Laserfiche Mobile Configuration page, under Security, the Enable passcode for
offline access option has the following implications:
 If this option is selected, a user will be required to set up and enter a passcode to
access copies of their offline documents. They will be prompted to set up the
passcode when attempting to save a copy of a document offline. They can also
set the passcode up on the Settings page in the app. Users will not be able to turn
the passcode off.
 If this option is not selected, users can choose if they want to passcode protect the
document copies from the Settings page in the app. If the user changes the
passcode, the copies of their offline documents will be removed.

Laserfiche Forms Security in the Mobile App

When opening a form to fill it out in the app, it is not encrypted. However, the form and
its contents will be cleared from the device’s memory when it is submitted or closed. If
a form attachment is opened, it will use the same encryption method used for electronic
documents. The attachment and its contents will be cleared from the device when a user
signs out or the app is closed and reopened.
Copies of offline forms are not encrypted, but can be passcode-protected so users
without the password will not be able to access the offline forms. Once a form is saved
offline and opened, it can be locked so users filling it out will not be able to navigate to
any other form. For example, if you are at a conference and want a user to fill out a
specific survey form, you can open the form, lock it, then let them fill it out. When they

22
have finished, they will be able to fill out only that specific form again. They will not be
able to close the form or navigate to any other form. See the To lock an offline form
section of the Offline Forms topic in the help files for more information on locking
offline forms.
If an offline form has a lookup table associated with it, a Forms administrator can
configure whether a database table is allowed to be saved offline with its form. Sensitive
information (lookup table configuration, lookup table contents, etc.) is encrypted using
AES-256 before it’s brought online and sent to the Laserfiche app.
The Laserfiche app stores offline lookup table contents in a local SQLite database. The
database file is encrypted using an AES encryption algorithm. The encryption key is
stored differently depending on the device:
 iOS: The AES encryption key is stored in KeyChain and managed by the system.
 Android: The AES encryption key is safely stored in a local SQLite database,
encrypted by another key generated from the Android Keystore using either
AES-256 (Android 6.0+) or RSA.
 Windows: The AES encryption key is stored in Credential Locker and is
managed by the system.

Temporary Files
Each Laserfiche application stores temporary files in a different location. You should
implement access control and encryption on these locations.
 Forms temporary files are stored in C:\ProgramData\Laserfiche
Forms\TempFile. Files in this folder can be safely deleted, but the folder itself
should not be deleted.
 Web client temporary files are stored in
C:\ProgramData\Laserfiche\WebAccess\Temp by default, but can be changed by
following the instructions on this troubleshooting page, in the answer to How do
I change the location of the web client tempDirectory?
 For the Windows client, temporary files are stored in the Windows user’s
temporary files folder. By default, this is
C:\Users\Username\AppData\Local\Temp. The temporary files are deleted when
you close the client.
 For Workflow, temporary files that are used as parts of processes are stored in
C:\ProgramData\Laserfiche\WF\ServerData. They can be deleted if there are no
workflows running.

23
Temporary files can be created when you are viewing documents on a mobile device.
How and where these are stored depends on the operating system. See the section on
Laserfiche App Encryption for more details.

Detecting Unauthorized Modifications

Volume checksums and digital signatures are two ways of detecting when repository
contents have been modified outside the Laserfiche interface. Volume checksums are
tracked in the SQL database and updated when repository contents are modified
through a Laserfiche interface. They are not updated when repository contents are
modified directly in the file system, so direct modifications will cause the checksums to
fail to match. Users will be alerted to this mismatch when they view the relevant
document in a Laserfiche client, and you can check for mismatches in the
Administration Console. However, a mismatch may also happen when there is
accidental data loss or corruption, so it does not always indicate direct tampering with
the repository contents.
Note: Volume checksums do not work on volumes that have been
encrypted with Laserfiche’s encryption option (which should not be used
for live volumes anyway). They will work with third party encryption
solutions as long as the Laserfiche Server service account can see through
the encryption.
Digital signatures indicate that a document is authentic and has not been modified since
the signature was applied. Digital signatures are invalidated once a document is
modified, even if it is modified within the Laserfiche interface. After you modify a
document, the changes will be validated only if you apply a new digital signature.

Digital Signatures in the Laserfiche App

The Laserfiche app requires the digital certificates to be present at different places on
the following platforms:
 iOS: The root certificate needs to be installed on the device before the private key
certificate can be imported. Certificate files (pfx/p12 and .cer) can be imported
from third-party applications such as Google Drive, OneDrive, etc.
 Android: The private key certificate (.pfx) must be exported and stored in a
third-party application.
 Windows: The private key certificate needs to be installed under Current User’s
Certificates, along with any certificates in the certificate chain. The signing
certificates in your device's personal certificate store will be available for import.
If you have multiple signing certificates, you can choose the one you want to use.

24
 If you do not have a signing certificate available, or want to use another signing
certificate, contact your administrator.

25
Commonly Required Procedures
for Access Control
This section describes some common procedures for setting access control on databases
and file systems.

Changing Permissions to a Folder

1. In the Windows file explorer, right-click on the folder and select Properties.
2. Go to the Security tab.
3. Click Edit….
4. If the user you want to grant permissions to is already listed under Group or
user names, select that user. If it is not listed, carry out the following steps:
a. Click Add….
b. Search for the user of interest in the ensuing dialog. Click OK when you
have found the desired user.
c. Back in the Permissions dialog, select the desired user under Group or
user names.
5. Under Permissions for UserName, select the Allow boxes for the types of access
you want to grant.
6. Click OK to save your changes.

Changing Permissions to a Registry Key

1. Open the registry editor by typing “regedit” in the Windows search bar and
clicking on the result named regedit.
2. In the registry editor, navigate to the path for the key of interest.
3. Right-click on the key and select Permissions.
4. If the user you want to grant permissions to is already listed under Group or
user names, select that user. If it is not listed, carry out the following steps:
a. Click Add….
b. Search for the user of interest in the ensuing dialog. Click OK when you
have found the desired user.
c. Back in the Permissions dialog, select the desired user under Group or
user names.
5. Under Permissions for UserName, select the Allow boxes for the types of access
you want to grant.
6. Click OK to save your changes.

26
Finding and Changing a Service Account
To grant permissions to a service user, you have to first find out which user the service
runs as. These instructions show you how to do that, and how to change the user the
service runs as.
1. In the Windows search bar, search for “services.”
2. In the search results, click on the desktop app Services.
3. Scroll down until you find the Laserfiche service of interest. Laserfiche services
have names that start with “Laserfiche.”
4. Right-click on the service of interest and select Properties.
5. Go to the Log On tab. This displays the user that the service currently runs as.
6. Select This account. Click Browse to find the account you want, and click OK
when you have found it.
7. Enter the password for the account in both Password and Confirm password.
8. Click OK to save your changes.

Finding and Changing an Application Pool Identity

Laserfiche web applications often use application pools. To grant permissions to an
application pool, you have to first find out which identity the application pool uses.
These instructions show you how to do that, and how to change the application pool’s
identity.
1. Open the Internet Information Services (IIS) Manager.
2. Expand the node corresponding to your web server.
3. Select Application Pools. A list of application pools will display in the main
pane.
4. Right-click on the application pool of interest and select Advanced Settings.

27
 5. Find the line for Identity. This states the user that the application pool runs as.
To change this, click on the “more options” icon ( ).
6. Select either Built-in account or Custom account. If you select the former, choose
from the drop-down list of built-in accounts. If you select the latter, Click Set…
to set the username and password for the custom account.
7. Click OK in the Application Pool Identity dialog, and OK again in the Advanced
Settings dialog.

28
Building a Secure Ecosystem for Laserfiche
May 2018

Author: Leif Hancox-Li

Description:
While Laserfiche security controls users’ access to content through the Laserfiche user interface, you
should ensure that the same content cannot be accessed through non-Laserfiche methods, such as
through intercepting data on a network or directly accessing the Windows file system. This paper
describes how you can protect data in transit and data at rest, in terms of controlling back-door access to
the data, and encrypting the data so that it cannot be read by unauthorized parties even if accessed. It
also describes the minimum permissions required by your Laserfiche service accounts, so that you do not
grant administrative privileges unnecessarily.

Laserfiche
3545 Long Beach Blvd.
Long Beach, CA 90807
U.S.A

Phone: +1.562.988.1688
www.laserfiche.com

Laserfiche, Compulink and Run Smarter are registered trademarks of Compulink Management Center,
Inc. dba Laserfiche. All other trademarks are properties of their respective companies. Due to continuing
product development, product specifications and capabilities are subject to change without notice.

No part of this publication may be reproduced, stored on a retrieval system, or transmitted without the
express prior written consent of the publisher

Laserfiche makes every effort to ensure the accuracy of these contents at the time of publication. They are
for information purposes only and Laserfiche makes no warranties, express or implied, as to the
information herein.

Copyright 2018 Laserfiche

29