You might decide to centralize the configuration of your stand-alone
base application servers by adding them into a 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 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 z/OS Customization
dialog. If you issue the
addNode command with security enabled
using the z/OS Customization dialog or command line, 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 or anytime
sensitive data is being transmitted.
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 domain names
using the z/OS Customization Dialog. 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 6.1 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.