Security considerations when registering a base Application Server node with the administrative agent

Security considerations when registering a base Application Server node with the administrative agent

We might decide to centralize the control of the stand-alone base application servers by registering them with the administrative agent. If the base application server is currently configured with security, some issues require consideration. These security considerations apply to the use of the registerNode command and the deregisterNode command.
The goal of the registerNode command is to take a stand-alone base node and convert it into one that is managed by the administrative agent. The main parameter of the registerNode command is profilePath, which specifies where on the local machine the administrative agent can find the node. The portsFile parameter contains keys to determine which ports the administrative agent listens to, on behalf of the base node. The format is the same as that for manageProfiles command line.
The registerNode command is run from the administrative agent itself. It is used to register a node with an administrative agent. It is required that the administrative agent be on the same system as the node being registered. The registerNode command is only valid on a base node. If a node has been federated to a deployment manager the registerNode command fails with an error.
First, the exchange signers process for profile registration processes the default secure sockets layer (SSL) configuration, in which it obtains the root certificate signers from the NodeDefaultRootStore of the administrative agent and stores them in the NodeDefaultTrustStore of the target profile. Next, the process obtains the root certificate signers from the target profile's NodeDefaultRootStore and stores them in the NodeDefaultTrustStore of the administrative agent. The signers are stored in the target profiles trust store using the alias prefix "agent_signer", and are stored in the administrative agents trust store using the alias prefix "<profileName>_signer".
Next, the exchange signers process for profile registration processes the RSAToken authentication configuration, in which it obtains the root certificate signers from the NodeRSATokenRootStore of the administrative agent and stores them in the NodeRSATokenTrustStore of the target profile. Next, the process obtains the root certificate signers from the target profile's NodeRSATokenRootStore and stores them in the NodeRSATokenTrustStore of the administrative agent. The signers are stored in the target profile's trust store using the alias prefix "agent_signer", and are stored in the administrative agents trust store using the alias prefix "<profileName>_signer".
In addition, the registration process stores all root certificate signers (SSL and RSAToken) from the administrative agent into the target profile's client trust store (ClientDefaultTrustStore by default).
The deregisterNode command activates the de-registration process which removes all signers exchanged during the registration process from both the administrative agent and base profile. The base node's configuration is retained, except that it is marked as not registered with an administrative agent. This command is only valid for a previously registered base node.
The following issues require consideration when running the registerNode command with security:

When attempting to run system management commands such as the registerNode command, we need to explicitly specify administrative credentials to perform the operation. The registerNode command accepts -username and -password parameters to specify the user ID and password, respectively. The user ID and password specified must be for an administrative user; for example, a user that is a member of the console users with Administrator privileges or the admin ID configured in the user registry. An example of the registerNode command follows:
registerNode -profilePath /WebSphere/AppServer/profiles/default -host localhost -connType SOAP -port 8877 -username WSADMIN -password ADMINPWD

Before registering to an administrative agent, a node must have administrative security enabled or disabled.

Once a node is registered, we cannot enable or disable the administrative security for that node (or any other registered node) until the node has been de-registered.

Proper understanding of the security interactions between distributed servers greatly reduces problems that are encountered with se cure communications. Security adds complexity because additional function needs management. The administrative agent provides a way of managing additional function while preserving security.
(zos)
Special consideration for z/OS: Under z/OS, an administrative agent's controller user ID must have as its default Unix System Services configuration group the configuration group for the application server(s) that it will administer. The administrative agent's servant user ID must be connected to the same group. The simplest way to ensure this is to specify a single configuration group ID when configuring the administrative agent and its application server(s).
When a System Authorization Facility (SAF) local registry is used for administrative security, the user ID used to invoke the registerNode.sh and deregisterNode.sh commands must have administrative privileges for the administrative agent and must also be connected to the Unix System Services configuration group for the administrative agent and its application server(s).
When SAF keyrings are used for certificate storage, signers are not exchanged during registration. We must verify the server certificates for the administrative agent and the application servers that it will administer share a common signer and that this common signer is on the keyring of the administrator user ID used to invoke registerNode.sh or deregisterNode.sh.
The keyring used during registration or deregistration is the one associated with the administrative agent.

Related concepts

Overview: Securing