You might decide to centralize the configuration of your
stand-alone base application servers by adding them into a WebSphere® Application Server, Network Deployment cell. If your base application server is currently configured
with security, some issues require consideration. The major issue
when adding a node to the cell is whether the user registries between
the base application server and the deployment manager are the same.
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.
The following issues require consideration when running the
addNode command
with security:
- 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 Administration >
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 add
node 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 from a previous release" in the
article on Secure installation for client retrieval.
- 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.
Proper understanding of the security interactions between
distributed servers greatly reduces problems that are encountered
with secure communications. Security adds complexity because additional
function needs management. Security needs thorough consideration during
the planning of your infrastructure. This document helps to reduce
the problems that can occur because of inherent security interactions.
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.