Skip to content

Installing Databridge Administrative Console

Important

Unlike earlier versions of Databridge, the installation of the Administrative Console is a separate install.

Installing the Administrative Console on Windows

Installing the Administrative Console on Windows follows the same proccess as installing the Databridge Clients and Enterprise Server.

To install the Administrative Console

  1. Double click "setup.exe" in the "Console\Windows" directory on the install medium.

    This will load the Micro Focus Databridge Administrative Console installer. Select Continue to proceed.

  2. Accept the terms of the license agreement by clicking the checkbox and select Continue.

  3. If you are customizing your installation use the following tabs to configure as needed:

    • User Information tab: Enter Full name and Organization name.

    • File Location tab: Specify a location for the Databridge program files (or accept the default).

      Warning

      Do not attempt to use a different JRE as we cannot guarantee that the product will work with it.

    • Advanced tab: Select Install to this PC or Create an Administrative install image on a server. There will also be log configuration options that can be disabled in this tab.

  4. When the Administrative Console is successfully installed select the Close button.

    At the end of the installation the installer launches a Java program that checks to see if there is a configuration in the expected place and if not it copies the starter configuration file, which will need to updated before the console can be used. This topic is covered in the section on Setting Up the Administrative Console.

  5. To connect to the Administrative Console server from the browser use the following URL https://hostname:7445 where hostname is the name or IP address of the Administrative Console server.

Note

Updates to the Administrative Console and the JRE will be included in future Hot Fixes, Updates and Service Packs, which will use the same procedures as the original install. The installer will ask you to confirm that you want to remove the product and proceed to uninstalling the old copy of the files and installing new copies.

The configuration files that were updated will be preserved, as uninstalling the Administrative Console will not remove files that the installer did not install. This avoids having to reconfigure anything after installing a Hot Fix, Update or Service Pack.

Installing the Administrative Console on UNIX or Linux

To install the Administrative Console on Linux

  1. Create the directory where the Databridge Administrative Console will be installed.

  2. Copy databridge-container-7.0.0.tar and zulu8.52.0.23-ca-jdk8.0.282-linux_x64.tar.gz to the directory created in step 1.

  3. Extract the files by entering the following commands:

    tar -xvf databridge-container-7.0.0.tar

    tar -xvf zulu8.52.0.23-ca-jdk8.0.282-linux_x64.tar.gz

  4. Move the file using the following command:

    mv zulu8.52.0.23-ca-jdk8.0.282-linux_x64 java

  5. Run the ./postinstall.sh file.

  6. Launch the Administrative Console web service by running bin/server start.

    The following arguments are available:

    bin/server { console | start | stop | restart | status | dump }

To install the Administrative Console on UNIX (Solaris)

  1. Create the directory where the Databridge Administrative Console will be installed.
  2. Copy databridge-container-7.0.0.tar and zulu8.52.0.23-ca-jdk8.0.282-solaris_x64.zip to the directory created in step 1.

  3. Extract the files by entering the following commands:

    tar -xvf databridge-container-7.0.0.tar

    Extract the other file that was copied:

    unzip zulu8.52.0.23-ca-jdk8.0.282-solaris_x64.zip

  4. Move the file using the following command:

    mv zulu8.52.0.23-ca-jdk8.0.282-solaris_x64 java

  5. Run the ./postinstall.sh file.

  6. Launch the Administrative Console web service by running bin/server start.

    The following arguments are available:

    bin/server { console | start | stop | restart | status | dump }

Setting up the Administrative Console

On Windows the services are created through the installation process. On UNIX, you need to run the script server out of the bin directory to create the daemon.

Start the service (or daemon) and connect to 1445 with your browser of choice.

Note

Microsoft Edge, Google Chrome, or Firefox are recommended. Do not use Internet Explorer when running the Databridge Administrative Console.

Sign on using the userid dbridge with the initial password of dbridge. Doing so allows you to update the "container.properties" file from the browser. We recommend using LDAP to control access to the server from browsers. Using LDAP requires setting up a few configuration parameters; then you can start using the Administrative Console.

If you choose not to use LDAP and want to use a simpler, less secure authentication method, you will need to add the userid/password pairs to a file that the authentication service uses in place of LDAP. You cannot edit this file directly because the passwords are obfuscated; you must do this from the Administrative Console.

Caution

Make sure you change the password for the user dbridge as anyone reading this document will know what its default password is.

Upgrading from an older service

Upgrading from an older Client Manager service

When the service starts it examines the permission bits for the various users in its configuration file. It also updates the permission bits for the various users to have values that have the equivalent permissions (permission bits are not exactly the same as in the older console). If there are no userids present, which will be case for a new service that starts without a configuration file, or if the existing users have any deprecated bits set, the service notifies the Administrative Console that it cannot accept any sign-ons until a suitable userid is added to the service's configuration file.

The console signs on to the service using a built-in userid (normally used by the monitor), which allows it to configure things. The console immediately tries to add the current userid to the console to the service's configuration. If it is not present, it is added with the role of Administrator. If the userid happens to already be present, it gets updated to have the ability to Manage Users.

Userids still need to be present in the service's configuration file. This is done to prevent any LDAP userid from automatically gaining access to the service. The authentication is no longer done in the service, with the exception of batch console connections not initiated from a script launched by the service. So you still need to have userids with passwords in the service to support batch console connection from places like the Windows scheduler (or chron in UNIX) or from a command prompt (terminal session in UNIX). Scripts launched by the service can run the bconsole using the token passed to them by the service as the password.

Replacing the self-signed certificate

  1. Create a Certificate Signing Request (CSR) for the Administrative Console server and send it to the CA of your choice. When you receive the signed certificate from the CA, proceed to step 2:

  2. Import the CA-signed certificate/chain into the Administrative Console server’s keystore.

You can accomplish this task using either KeyStore Explorer or the Java Keytool command line instructions. With either tool, if the CA reply contains separate root and intermediate certificate files, import the root certificate into the keystore first, followed by the intermediate certificate.

Using this tool Do this...
Keystore Explorer
  • Open keystore.bcfks in KeyStore Explorer. Use the password changeit
  • If separate root and intermediate certificate files are available, from the tool bar, select Import Trusted Certificate to import certificates.
  • Select the servlet-engine key pair. Right-click and select Import CA Reply to import the file into the key pair.
  • If prompted, enter the password, changeit.
  • Browse to the location where the CA Reply file is stored, select the file, and select Import.
JavaKeytool Windows

These examples use keytool command in the sessionserver\etc directory.

Import Root CA and intermediate certificates

....\java\bin\keytool.exe -importcert -alias rootca -trustcacerts -file -keystore keystore.bcfks –storetype bcfks -storepass changeit

..\..\java\bin\keytool.exe -importcert -alias intermediateca -trustcacerts -file <IntermediateCA.cer> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

Import CA reply

..\..\java\bin\keytool.exe -importcert -alias servlet-engine -trustcacerts -file <CertChainFromCA.p7b> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

UNIX

Import Root CA and intermediate certificates

../../java/bin/keytool -importcert -alias rootca -trustcacerts -file <RootCA.cer> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider<br><br>../../java/bin/keytool -importcert -alias intermediateca -trustcacerts -file <IntermediateCA.cer> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

Import CA Reply

../../java/bin/keytool -importcert -alias servlet-engine -trustcacerts -file <CertChainFromCA.p7b> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

Replacing the self-signed certificate with certificate reply from Certificate Authority

  1. Create a Certificate Signing Request (CSR) for the Administrative Console server and send it to the CA of your choice. When you receive the signed certificate from the CA, proceed to step 2.

  2. Import the CA-signed certificate/chain into the Administrative Console server’s keystore.

    You can accomplish this task using either KeyStore Explorer or the Java Keytool command line instructions. With either tool, if the CA Reply contains separate root and intermediate certificate files, import the root certificate into the keystore first, followed by the intermediate certificate.

    Using this tool Do this...
    Keystore Explorer 1. Open keystore.bcfks in KeyStore Explorer. Use the password changeit.

    2. If separate root and intermediate certificate files are available, from the tool bar, select Import Trusted Certificate to import certificates.

    3. Select the servlet-engine key pair. Right-click and select Import CA Reply to import the file into the key pair.

    4. If prompted, enter the password, changeit.

    5. Browse to the location where the CA Reply file is stored, select the file, and click Import.
    JavaKeytool Windows

    These examples use keytool command in the sessionserver\etc directory.

    Import Root CA and intermediate certificates

    ..\..\java\bin\keytool.exe -importcert -alias rootca -trustcacerts -file <RootCA.cer> -keystore keystore.bcfks –storetype bcfks -storepass changeit<br><br>..\..\java\bin\keytool.exe -importcert -alias intermediateca -trustcacerts -file <IntermediateCA.cer> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

    Import CA Reply

    ..\..\java\bin\keytool.exe -importcert -alias servlet-engine -trustcacerts -file <CertChainFromCA.p7b> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

    UNIX

    Import Root CA and intermediate certificates

    ../../java/bin/keytool -importcert -alias rootca -trustcacerts -file <RootCA.cer> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

    ../../java/bin/keytool -importcert -alias intermediateca -trustcacerts -file <IntermediateCA.cer> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

    Import CA Reply

    ../../java/bin/keytool -importcert -alias servlet-engine -trustcacerts -file <CertChainFromCA.p7b> -keystore keystore.bcfks –storetype bcfks -storepass changeit -providername BCFIPS -providerpath ../lib/bc-fips-*.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider

Choosing an Authentication Method

The first time the console is run use the dbridge for the User Name and Password. Once signed, select the hamburger icon () on the left-side of the header, this will expand a left-side menu. Select Authentication to load the relevant settings as seen in the screenshot below.

You can chose the desired authentication mode using the drop down titled Authentication type, the available options are LDAP (default) and Simple authentication.

Setting up LDAP

To setup LDAP parameters for your site you will need to contact your IT personnel and ask them to provide you with the information needed.

Tip

Here a few simple steps you can have your IT services perform.

Remote desktop to your site's network authentication server and open an elevated Command Prompt (or have someone authorized perform this task).

  1. To search the entire domain use the first line returned from a dsquery* command as the base DN. To limit the scope of the base DN, one can use an OU. Running a dsquery OU will provide a list of Organizational Units from which the base DN can be selected. Enter this information into the Search base DN input field in the dialog.

    Example

    "CN=example, CN=com" or "OU=DBUser, CN=example, CN=com"

  2. To get the value to be entered in the Administrator DN input field "dsquery user -name username`", where username is the userid of an administrator on the authentication server. Copy the output line, and paste it into the Administrator DN input field.

  3. Enter the hostname of the network authentication server into the Host Name input field.

  4. Enter the password for the administrator's you selected in step 2 into the Administrator password input field.

  5. Ensure that the default port of 389 is correct for your site.

  6. Select Save.

    Your changes will only take effect after restarting the service. At this point, you will be able to connect to the Administrative Console from a browser using your network credentials though this alone is not enough to gain access to the Client Managers.

    For access to the Client Manager(s), userids will need to be granted access to a Client Manager. To do this use Manage Users in the Client Manager page. To do this, assign a predefined role to the user (Administrator, Operator, User, or Custom). You can customize the permissions for each user, it is recommended to start with a predefined role and then customize as needed.

Caution

How do you gain access to the Client Manager to assign roles?

When upgrading from previous versions the userids and roles will be honored in the new Administrative Console. If this is not the case, dbridge will be available from the Client Manager configuration file to get initial access to the Client Manager page with permissions to the Manage Users page. As a backup, in the case that neither of the afformentioned options are available the dbridge userid and password is automatically added as an administrator for hte first sign-on to the Client Manager following an upgrade. The service automatically detects if there was an upgrade the first time it is started.

Creating Userid/Password Pairs

With the Simple authentication type selected, the administrator will need to add the userid/password pairs as seen in the screenshot below.

Enter as many userid/password pairs as needed. Users can access this dialog in the same way as an administrator, but they will only be able to view and change their own password. Userids and passwords are stored in the file osp-users.csv in the sub-directory microservices\auth-service of the install directory for the Administrative Console, and all passwords are encrypted.

Userids assigned with Simple authentication behave in the same manner as the LDAP userids. Userids must be registered with each Client Manager in exactly the same way as LDAP users.

For access to the Client Manager(s), userids will need to be granted access to a Client Manager. To do this use Manage Users in the Client Manager page. To do this, assign a predefined role to the user (Administrator, Operator, User, or Custom). You can customize the permissions for each user, it is recommended to start with a predefined role and then customize as needed.