Administration & Troubleshooting
The recommended installation of the Workbench does not provide remote access to the Workbench Portal. (Users must use Remote Desktop into the host, then access the Portal through a local browser.) This is to provide a "secure by default" installation, so that any data already on the host, or already streaming live into the host, is not exposed (e.g. on the internet).
It also does not provide any encryption (i.e. SSL) for data coming into the host, e.g. from an upstream Data Hub.
This is the simplest and most-secure way to install, but it is not as convenient as having remote access. If you wish to expose the Portal and the endpoint to remote users, this section will help you do so.
It may help if you look at the default install diagram for reference.
Exposing the Workbench to the network requires careful consideration of the security and usability issues that are relevant for your company, your country/region, your end users, and your Workbench users. Depending on your situation, it may be appropriate to grant remote access - or it may require tightening down every aspect of the deployed configuration. This section will cover some standard scenarios, but it is up to you to decide whether these are appropriate for you, and/or to alter these instructions to follow your company policies.
There are three things that are commonly altered about the default installation:
88rather than the normal HTTP port (
80). You might want to change this, to allow easier access through firewalls. Typically, though, the Data Hub endpoint is installed on port
80, so you'll need to change the Data Hub endpoint to use another port first.
For any remote access to be possible, the IIS configuration must be changed. Performing this step will expose the Portal (and related web services) to the network, so you may wish to turn on authentication and encryption (see the sections below) before performing these steps. If you do not need authentication and encryption, this section can be performed on its own.
To configure IIS:
These changes take effect immediately, no restart is required.
You may also need to open a port on your firewall. If you use Windows Firewall:
88(or the port you chose during installation) into the field for Specific local ports
PreEmptive Analytics Workbench)
Remember to test that you can access the Portal remotely, at e.g.
We recommend using the built-in Windows Authentication feature of IIS to manage users and authentication. If the server is joined to a Windows domain, IIS will grant any domain users access to the Portal. If the server is not joined to the domain, then any Windows user configured on the server host will be granted access to the Portal.
Note: Windows Authentication does not provide a reliably-secure level of encryption for credential exchange. If both the server host and client host are joined to the same domain and are on the same network, then the authentication will use Kerberos, which is sufficient for most purposes. If either host is not on the domain, however, the authentication will fall back to NTLM, which is not sufficient for most purposes. If you are concerned about the security of user authentication credentials and/or of data transmitted to the clients, we recommend that you also configure strong encryption.
Warning: If authentication falls back to NTLM (see previous note), and if the users are behind a proxy that maintains and shares TCP connections, authenticated connections can be shared by multiple users, even unauthenticated ones. For this reason, please configure your proxy to not share TCP connections among clients for this server, or choose an alternate method of authentication.
To switch to Windows Authentication, explicitly configure authentication for the PreEmptive Analytics Workbench Portal site, and for each application under that site:
Then test access from another machine - it should require credentials. Note: if you access the Portal from the host itself, or from a domain account on another machine, you may not be prompted for credentials; it depends on your browser settings.
Note: access may be denied if the user is due to change their password via Windows. If you are having issues logging in that you can't explain, check that the user account is set to not require password changes, or does not require an immediate change.
This section assumes that you want to:
80) for portal users.
At the end of this process, the configuration will look like this:
You might not have the Repository installed on the same host; it is shown here for reference purposes.
You may wish to compare this to the default install diagram.
You must obtain and install a valid SSL certificate. Instructions for doing so are typically provided by the issuing certification authority or your internal Operations department. For example, a popular certificate authority provides instructions for generating a certificate signing request and installing an SSL certificate.
We recommend disabling vulnerable SSL ciphers to prevent exploits, including man-in-the-middle attacks. This can be done by running the latest version of this PowerShell script.
The approach used here is to configure the Data Hub endpoint and the Workbench portal to use SSL on separate ports. We recommend using the default SSL port of
443 for the Workbench Portal and port
413 for the Hub endpoint,
but different port numbers may be used as desired.
httpsas the Type. Change the port from
413(or alternative unused port number). Under SSL certificate, select a valid certificate from the list. Click OK.
httpbinding (i.e. port
88.) Unlike the Workbench Portal, a redirect for this website should not be configured.
httpsas the Type. Under SSL certificate, select a valid certificate from the list. Click OK.
88) or follow the instructions in the section below to add a redirect from HTTP to HTTPS. If planning to create a redirect, the port used for the http binding should be set to
Note: upstream clients (e.g. a public-facing Data Hub) must be changed to use HTTPS to send data to this host, on the correct port (e.g.
413). Data sent to this host's endpoint via HTTP will fail.
Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. This behavior can be disabled by setting response headers.
To protect against DNS rebinding attacks, you can require the Portal application to only accept requests whose Host header contains the complete domain name for the machine.
Further actions in this section require the IIS module, URL Rewrite 2.0.
Note: This solution uses the URL Rewrite 2.0 module, rather than the HTTP Redirect module, because the HTTP Redirect module is too simple to provide the functionality we need. Even though we are using a "rewrite" module, we will actually be using it to do a "redirect".
The URL Rewrite module may already be installed. To check, click on any website (e.g. PreEmptive Analytics Workbench Portal) in IIS Manager and look for URL Rewrite under IIS. If it is there, the module is installed.
If it is not installed, it can be installed from http://www.iis.net/downloads/microsoft/url-rewrite. If IIS Manager is open, it will need to be closed and re-opened before URL Rewrite appears.
To protect against downgrade attacks, you can have the Portal application set the
Strict-Transport-Security response header when using HTTPS.
Add Custom Header for HTTPS
Matches the Pattern
Once SSL is enabled, you need to ensure that data can't be sent over the wire unencrypted. The easiest way to do that is to remove the HTTP binding, but that has the side-effect giving an error message to users who try to access the portal without explicitly typing https://. Instead, we can keep the binding but add a redirect rule, so that any attempt to access the portal via HTTP will be redirected to HTTPS.
The following procedure assumes the PreEmptive Analytics Workbench Portal site has an http binding on port
HTTP to HTTPS
Does Not Match the Pattern
Ensure an instrumented application can send Analytics messages to the Data Hub endpoint using HTTPS from a remote machine (i.e. to
https://<WORKBENCH_HOSTNAME>:413/endpoint). A quick way to
test this is to try that URL in a remote browser. You should see:
Ensure an instrumented application can't send Analytics messages to the Data Hub endpoint using HTTP from a remote machine (i.e. to
http://<WORKBENCH_HOSTNAME>/endpoint). A quick way to
test this is to try that URL in a remote browser. You should just get a
404 error from your browser, saying that the resource was not available.
Ensure the Workbench portal can be accessed using HTTPS from a remote machine (i.e. from
https://<WORKBENCH_HOSTNAME>/). You should see the SSL icon, with no warnings, and you should be prompted for credentials.
Ensure the Workbench portal automatically redirects you to an HTTPS connection, if you try accessing it via HTTP (i.e. from
http://<WORKBENCH_HOSTNAME>/). You should see the SSL icon, with no warnings, and you should be
prompted for credentials.
Note: HTTPS access may not work from the local server, even though it works correctly from a remote host, if you use the fully-qualified domain name while on the server (i.e. to ensure the SSL certificate is valid). This is because
of a security restriction in Windows that helps prevent "loopback attacks." You can use
localhost as the hostname (and accept the SSL warning) or you can follow either
of the suggestions in the linked article.