Specify administrative settings to a secured WAS v6.0 or later

If your WAS environment has global security enabled, you need to communicate the administrative settings from your development environment to the runtime server. On the workbench, you need to specify that security is enabled on the runtime environment, and provide the username and password to the secured server. If you are working with a secured WAS V6.1 or later (including WAS V7.0), you need to establish a trust between the development workbench of this product and the server.

The WAS runtime environment is secured. For information on configuring global security:

For remote secured WAS v6.0 or later, run the redeployFileTransfer.jacl script to see output from the server in the Console view of the workbench. For details, see...

Publishing fails and console output does not display to a secured WAS v6.x

To specify the administrative security settings to a secure local or remote WAS v6.0 or later:

  1. In the Servers view, double-click your WAS. The server editor opens.

  2. Click the

    Overview tab at the bottom of the editor.

  3. Expand the

    Security section.

  4. Select the Security is enabled on this server check box. If this check box is disabled, the remaining security settings are ignored and a warning message displays on the bottom of the workbench:

    Warning: The server is not secured. Consider enabling security on the server.

  5. In the User ID field and Password fields, specify the user name and password for the current active administrative settings defined in the server configuration.

    The specified user must have the following permissions:

    • For WAS v6.1 and V7.0:

      Log on as service

    • For WAS v6.0:

      Log on as service and

      Act as part of the operating system.

    The specified user must be logged on as root.

  6. If you are working with a WAS v6.1 or v7.0 that is secured, the Automatically trust server certificate during SSL handshake check box is by default enabled. If you are not working with a secured WAS v6.1 or v7.0, continue to the next step as this check box is not available.

    Starting in WAS v6.1 release, each profile in the WAS environment contains a unique self-signed certificate that was created when the profile was created. This certificate replaces the default dummy certificate that ships with WAS in releases prior to v6.1. When a profile is federated to a deployment manager, the signer for that self-signed certificate is added to the common truststore for the cell. By default, clients (such as the development workbench) does not trust servers from different profiles in the WAS environment. That is, they do not contain the signer for these servers.

    To assist in establishing this trust between the development workbench and the server, verify the Automatically trust server certificate during SSL handshake check box is selected. This check box specifies that when the workbench communicates to an administrative secured WAS v6.1 or later, the server sends a signer certificate to the workbench. If the certificate is new, the workbench stores the certificate in its truststore file. The location of the truststore file depends on the connection type between the server and the workbench:

    • For a remote method invocation (RMI) connection, the truststore file is located at x:\runtimes\base_v61_stub\etc\trust.p12

    • For a SOAP connection, the truststore file is located at x:\runtimes\base_v61_stub\etc\DummyClientTrustFile.jks
    Where x is the installation directory for the workbench for this product, for example, C:\Program Files\IBM\SDP

    If the Automatically trust server certificate during SSL handshake check box is clear, the server status of the Servers view displays the server as stopped and no connection can be made to the server. Make sure you have selected this check box, otherwise, you need to manually establish the trust between the workbench and the administrative secured WAS v6.1 or later, see Manually exchanging signer certificates to establish a trust between the workbench and the server topic for details.

  7. Select File > Save to save the changes in the server editor.

Note: When enabling administrative security for a server, do not give it a user ID that has the same name as the machine where WAS is installed. Otherwise, the server may fail to start.

Related information

Manually exchanging signer certificates to establish a trust between the workbench and the server

WAS maintenance releases