Lorem ipsum dolor sit amet:

24h / 365days

We offer support for our customers

Mon - Fri 8:00am - 5:00pm (GMT +1)

Get in touch

Cybersteel Inc.
376-293 City Road, Suite 600
San Francisco, CA 94102

Have any questions?
+44 1234 567 890

Drop us a line

About us

Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec.

Chapter 3. External Configuration Files

3. External Configuration Files

ReportServer has only two (external) config files which hold information on the database connection as well as information on available authentication methods. All other configuration is done from within ReportServer. The file (in directory WEB-INF/classes) holds information on the database connection that is used by ReportServer. The configuration file (in the same directory) holds information about available authentication schemes, as well as, cryptography related properties.

By default the external configuration files are located in WEB-INF/classes and thus within the web-apps folder. It is advisable to move these files to an external location as this allows easier upgrades to future versions. For a detailed description of how to use an external configuration dir see Chapter 5.


ReportServer uses the Java Persistence API (JPA) to abstract from the actual database system when storing application data. The necessary configuration is made in the config file.


Note that to configure the JPA/Hibernate settings, we are not editing the standard JPA configuration file (usually called persistence.xml) but a ReportServer properties file.

3.1.1. Connection properties

ReportServer supports all databases that are supported by Hibernate. A list of the database systems supported by Hibernate can be found on the hibernate webpages . We recommend to run ReportServer on one of the following databases for which we now give example configurations:

Example config for MySQL

Note the custom dialect

Example config for MariaDB

# MariaDB

Example config for PostgreSQL

# PostgreSQL

Example config for Oracle

# Oracle
# Select ONE of the following dialects depending on your Oracle version

Example config for SQL Server

# SQL Server

Note, that the JDBC driver corresponding to your database must be copied to the directory

path_to_webapps/reportserver/WEB-INF/lib or to your external-configuration directory.

3.1.2. Connection Pool (C3P0) Settings

Hibernate uses the C3P0 connection pool. The following properties allow to configure C3P0 as used by Hibernate. Note that this does not have any effect on the connection pool used by ReportServer for handling reporting.


See also

The most commonly used properties are:

Property Description
acquire_increment Defines how many connections are acquired simultaniously by c3p0, if all connections currently in the pool are busy.
idle_test_period If not zero, C3P0 will test idle connections in this intervall.
timeout Number of seconds a pooled connection can remain idle before it is discarded. Zero means that idle connections are never discarded.
max_size Maximum number of connections in the pool.
max_statements Maximal size of the statement cache. Zero means that statements should not be cached.
min_size The minimum number of connections to be kept in the pool.


The config file contains settings which are needed at ReportServer startup time as well as settings concerning cryptographic functionality. All properties are stored as attribute value pairs.

Excerpt from the file

	rs.crypto.pbe.passphrase = The Passphrase
	rs.crypto.pbe.keylength = 128

3.2.1. Crypto settings

Passwords (such as, for example, datasource passwords ) that are stored in ReportServer will be encrypted. ReportServer uses AES and password based encryption. For this, you need to configure the following properties:

-- rs.crypto.pbe.salt

the salt that is used on key generation by the password based encryption method. This value should be set to a long random string.

-- rs.crypto.pbe.keylength

The key size used. Keep in mind that key sizes over 128 require the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. For more information, see

For secure storage of user passwords ReportServer uses the salted HMAC construction.

-- rs.crypto.passwordhasher.hmac.passphrase

Defines the static part of the salt for the salted HMAC construction. This value should be set to a long random string.

3.2.2. Authentication settings

ReportServer supports several methods for user authentication. The different methods can also be combined.

-- rs.authenticator.pams

This parameter defines which authentication methods are to be used. The individual values are separated by a colon.

Note that the default PAMs usually come in two variants, one being called Authoritative, e.g. UserPasswordPAMAuthoritative, or LdapPAMAuthoritative. The difference between the two variants (the non-authoritative and the authoritative variant) is how they handle the case where they cannot find the necessary information within the provided list of tokens. The authoritative version then denies access, while the non-authoritative version opts for letting someone else decide (can't tell, let another PAM in the list decide). More details on this can be found in the Script Guide.

The following authenticator modules are available

This is the standard mechanism and allows users to authenticate using a username and password. Note: with this authentication method username and password are sent to the server in the clear. Thus, this method should only be used over a secure channel (such as TLS/SSL). If you are not in a secured environment choose the ChallengeResponsePAM instead.

With this method you can restrict the set of IP addresses that can access ReportServer. The allowed address ranges are configured in rs.authenticator.iprestriction.addresses. The individual values are separated by a colon. Example: rs.authenticator.iprestriction.addresses =

This method will disable authentication and log in all users as root.

This method is similar to the UserPasswordPAM but the password is transmitted securely to the server. In cases where the connection is not secured via SSL this is the recommended authentication method. Note though, that this requires the client browser to perform cryptographic tasks which may be slow on non-up-to-date browsers.

If your organization uses x509 certificates, you can use this method to allow users to log in with their client certificates.

If your organization uses LDAP and you want to allow LDAP authentication, you can use this method to allow users to log in with their LDAP credentials. Note that you previously have to import your LDAP users as described in the Admin Guide:


This parameter allows to enable debug mode for client certificate authentication.

-- rs.authenticator.blockroot

Setting this to true disables direct access using the root user. This is recommended for production environments. Note that you can switch to the root user using sudo if you need to perform administrative tasks (and you have the corresponding privileges). Further information on sudo can be found in the administration guide.

3.2.3. General settings


Setting this to true installs base data if the database is empty, i.e. during a first run. This includes the audit log and other data.


If this property is set to true, scripting is completely disabled, so no scripts are run, including the onlogin and onstartup scripts. Thus, should you find yourself locked out of ReportServer, you can disable any scripts via this property. Since no scripts will be executed you can then login correctly to ReportServer.


You can completely disable the scheduler by setting this property to true. If the property is set to true both in and the analogous property is also set to true in /fileserver/etc/scheduler/, the property set in is taken into account, while the one set in /fileserver/etc/scheduler/ is ignored. This allows you to completely avoid running scheduled jobs if you don't have the possibility to log in and disable the scheduler quickly enough before any jobs are being executed.

InfoFabrik GmbH

Wir wollen, dass alle Unternehmen, Institutionen und Organisationen, die Daten auswerten, selbständig und zeitnah genau die Informationen erhalten, die sie für ein erfolgreiches Arbeiten benötigen.

InfoFabrik GmbH
Klingholzstr. 7
65189 Wiesbaden

+49 (0) 611 580 66 25

Kontaktieren Sie uns

Bitte rechnen Sie 6 plus 7.
Copyright 2007 - 2024 InfoFabrik GmbH. All Rights Reserved.

Auf unserer Website setzen wir Cookies und andere Technologien ein. Während einige davon essenziell sind, dienen andere dazu, die Website zu verbessern und den Erfolg unserer Kampagnen zu bewerten. Bei der Nutzung unserer Website werden Daten verarbeitet, um Anzeigen und Inhalte zu messen. Weitere Informationen dazu finden Sie in unserer Datenschutzerklärung. Sie haben jederzeit die Möglichkeit, Ihre Einstellungen anzupassen oder zu widerrufen.

Datenschutzerklärung Impressum
You are using an outdated browser. The website may not be displayed correctly. Close