Required hardware and software

The business logic is managed by the application server. The load is determined by both the number of users and also the number of server requests. To ensure optimal operation, we recommend that the following hardware resources are made available:

  • At least Windows Server 2012 R2 (current patch level is mandatory!)
  • Recommended Windows Server 2016
  • At least 2 x CPU
  • Min. 8 GB RAM
  • Min. 40 GB hard disk space
  • Current .net library (current minimum requirement is version 4.6.2)
  • Firewall release
  • Windows Management Framework 4.0 must be installed! (Windows update KB2819745)

The application server requires that the following ports are enabled:

  • Port 443 HTTPS to connect to the MATESO license server
  • Port 11011 TCP for communication with the clients or the Web server IIS
  • Port 11014 TCP for the backup service
  • Port 11016 TCP for the webservices (only when using the WebClient)
  • Port 11018 TCP (incoming) for the realtime update
  • Port 1433 TCP for communication with the SQL server

Web server (IIS)

Several web servers can be configured for web access, but at least one is required to use the web access. In the first iteration of version 8, access via WebClient is not yet equipped with all functions. We recommend the following to ensure optimal operation:

  • At least Windows Server 2012 R2 (current patch level is mandatory!)
  • Recommended Windows Server 2016
  • At least 4 x CPU
  • Min. 8 GB RAM
  • Min. 40 GB hard disk space
  • Current .net library (current minimum requirement is version 4.6.1)
  • SSL certificate
  • If necessary, configure firewall access after access (http, or https)

Required users

A user via which the Password Safe server can log in to the SQL server is required for configuration. A user who can execute the Password Safe services is also required. The various configurations are briefly explained here.

Service user

The service user runs the Password Safe server service. The following can be configured here:

  • AD user: It is specified in the format Domain\username along with its associated password
  • *Local user: It is specified in the format .\user name along with its associated password
  • Local system account: It can be activated via a checkbox

Backup service user

In principle, the backup service is run by the service user. In expert mode, however, it may be another user. A backup service user has the same requirements as a service user.

User for the SQL configuration instance

The user for the SQL configuration instance logs on to the SQL server to create the Password Safe databases. You can use an AD user or a local SQL user for this purpose. The following options are available:

  • Service user: If the checkbox is activated, the stored service user is used. Please note that this can only be configured via the checkbox. It is not possible to manually set up the service user again.
  • SQL user: An SQL user may also be used. It is saved on the SQL server according to the configuration.

Configuration examples

Variant 1:
A service user is created in the AD. It will be added as a service user, which can start both the Password Safe server service and the backup service. This user requires rights to start services. This user is then used for the SQL configuration instance (by activating the check box).

Variant 2:
A local user is used as a service user. Specify a local SQL user, secured with a password, as a user for the SQL configuration instance. This could be the default sa user, for example.

Rights for Windows PowerShell

In Password Safe V8, Windows PowerShell scripts are used in several places. These are required, for example, to use the certificate-protected server key or to create the server certificate. Password Reset also uses this functionality. It is therefore absolutely necessary that the Windows security policy allows PowerShell scripts to be executed. You can set this up and check manually as follows:

Open the PowerShell console. Enter Set-ExecutionPolicy RemoteSigned and confirm.

The change to the policy is confirmed in the next step.

The changed policy can be queried via Get-ExecutionPolicy -list.

Click here to return to the Getting Started section

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.