Security considerations when adding a base Application Server node to WebSphere Application Server Network Deployment

When adding a node to the cell, you automatically inherit both the user registry and the authentication mechanism of the cell.

When adding a node to a cell, the newly federated node automatically inherits the user registry (Local OS, LDAP or Custom), authentication mechanism (LTPA ), and authorization setting (WebSphere bindings or System Authorization Facility (SAF) EJBROLE profiles) of the existing WebSphere Application Server Network Deployment cell.

For distributed security, all servers in the cell must use the same user registry and authentication mechanism. To recover from a user registry change, you must modify your applications so that the user and group-to-role mappings are correct for the new user registry. See the article on Assigning users and groups to roles.

Another important consideration is the Secure Sockets Layer (SSL) public-key infrastructure. Prior to performing the addNode command with the deployment manager, verify that the addNode command can communicate as an SSL client with the deployment manager. This communication requires that the addNode truststore that is configured in the sas.client.props file contains the signer certificate of the deployment manager personal certificate, as found in the keystore and specified in the administrative console.

• When attempting to run system management commands such as the addNode command, you need to explicitly specify administrative credentials to perform the operation. The addNode command accepts -username and -password parameters to specify the user ID and password, respectively. The user ID and password that are specified must be for an administrative user; for example, a user that is a member of the console users with Administrator privileges or the administrative user ID configured in the user registry. An example of the addNode command follows:

  addNode CELL_HOST 8879 -includeapps -username user -password pass.

  The -includeapps parameter is optional, but this option attempts to include the server applications into the Deployment Manager. The addNode command might fail if the user registries used by WebSphere Application Server and the deployment manager are not the same. To correct this problem, either make the user registries the same or turn off security. If you change the user registries, remember to verify that the users-to-roles and groups-to-roles mappings are correct. See addNode command for more information on the addNode syntax.

  Note: You can also run the addNode command using the WebSphere z/OS® Profile Management Tool or the zpmt command. If you issue the addNode command with security enabled using the WebSphere z/OS Profile Management Tool or the zpmt command, you must use a user ID with authority and specify the -user and -password options.
• Adding a secured remote node through the administrative console is not supported. You can either disable security on the remote node before performing the operation or perform the operation from the command line using the addNode script.
• Before running the addNode command, you must verify that the truststore files on the nodes can communicate with the keystore files from the deployment manager and vice versa. When using the default DummyServerKeyFile and DummyServerTrustFile, you should not see this problem as these are already able to communicate. However, never use these dummy files in a production environment.
• Before running the addNode command, you must verify that the truststore files on the nodes communicate with the keystore files and System Authorization Facility (SAF) keyring that is owned by the deployment manager and vice versa. If you generate the certificates for deployment manager using the same certificate authority as you used for the node agent process, you are successful. The following SSL configurations must contain keystores and truststores that can interoperate:
  • System SSL repertoire that is specified in the administrative console using System Administration > Deployment Manager > HTTP Transports > sslportno > SSL.
  • SSL repertoire for appropriate JMX connector if SOAP is specified System Administration > dmgr > Administration Services > JMX Connectors > SOAPConnector > Custom Properties > sslConfig.
  • SSL repertoire that is specified in NodeAgent System Administrator > Node agents > NodeAgent Server > Administration Services > JMX Connectors > SOAPConnector > Custom Properties > sslConfig.
  Note: WebSphere Application Server for z/OS defines security domains using SAF profile prefixes (previously referred to as z/OS security domains) in the WebSphere z/OS Profile Management Tool or the zpmt command. Use caution when adding a node to a Deployment Manager configuration that defines a different security domain.
• When a client from a previous release tries to use the addNode command to federate to a 7.0 deployment manager, the client must first obtain signers for a successful handshake. For more information, see Obtaining signers for clients and servers from a previous release in the article on Secure installation for client signer retrieval in SSL.
• After running the addNode command, the application server is in a new SSL domain. It might contain SSL configurations that point to keystore and truststore files that are not prepared to interoperate with other servers in the same domain. Consider which servers are intercommunicating and ensure that the servers are trusted within your truststore files.

When you have security problems that are related to the WebSphere Application Server Network Deployment environment, see Troubleshooting security configurations to find additional information about the problem. When trace is needed to solve a problem because servers are distributed, it is often required to gather trace on all servers simultaneously while recreating the problem. This trace can be enabled dynamically or statically, depending on the type of problem that is occurring.