IBM Tivoli Composite Application Manager for Application Diagnostics, Version 7.1.0.1
Set up the user ID and password for the data collector with IBM WAS Global Security enabled
Install, configuring, and running the ITCAM for Application Diagnostics on z/OS data collector with Global Security turned on might require additional steps, depending on your security configuration.
If WebSphere Global Security has been turned on, perform the following steps prior to running the setupwas.sh script:
- Make sure the user ID you will use to log on to UNIX System Services (USS) and to run the setupwas.sh script has read and write access to the IBM WAS configuration files. This user ID must also have permission to execute the WebSphere Scripting Client script (wsadmin.sh). It is recommended that you use an administrative user ID (such as WSADMIN) to run the setupwas.sh runtime setup script. If you do not want to use an administrative user ID to run the setupwas.sh runtime setup script, define a user using the same commands that were used to define an administrative userid.
- Make sure the user ID you will use to run setupwas.sh is a member of the same UNIX group as an administrative user ID. This user ID will create the ITCAM for Application Diagnostics runtime directories for the server. This user ID must also have read and write access to these directories. It is recommended that you use an administrative user ID (such as WSADMIN) to run the setupwas.sh runtime setup script. If you do not want to use an administrative user ID to run the setupwas.sh runtime setup script, define a user using the same commands that were used to define an administrative userid.
- Make sure the user ID you will use to run setupwas.sh fulfills the requirements for Secure Sockets Layer (SSL) security.
Background information:
When Global Security is enabled, SSL security is always used by the administrative subsystem to secure administrative commands, the IBM WAS administrative console, and communications between IBM WAS processes (which includes the wsadmin.sh scripting facility). SSL support always provides a mechanism by which the server proves its identity.
In addition, SSL support on IBM WAS for z/OS allows the following ways for a client to prove its identity:
- Basic authentication (also known as SSL Type 1 authentication), in which a client proves its identity to the server by passing a user identity and password known by the target server
- Client certificate support, in which both the server and client supply digital certificates to prove their identities to each other
For the client to authenticate the server, the server (actually, the Controller user ID) must possess a signed certificate created by a certificate authority. The server passes the signed certificate to prove its identity to the client. The client must possess the CA certificate from the same certificate authority that issued the server's certificate. The IBM WAS customization dialogs generate jobs that, amongst other things, define the user IDs for the various IBM WAS regions (Deployment Manager, Node Agent, Server Controller, and Servant tasks). These jobs also specify user IDs that can be used to log on to the IBM WAS administrative console. The RACF customization jobs create key rings for each of these user IDs and connects certificates to them. You may use one of these user IDs to perform the ITCAM for Application Diagnostics data collector setup if it also has the necessary permissions to access the IBM WAS configuration root files mentioned in Step 1.
Procedure:
An administrative user ID (typically WSADMIN, but it could be different) is set up to have the necessary privileges when the cell is configured, so any user ID you use must be set up in the same way. It is recommended that you use an administrative user ID to run the setupwas.sh runtime setup script.
If you cannot use the administrative user ID that was created when the security domain was set up for the cell, you can create a new user ID, or alter your personal user ID, so that it has the same characteristics. Find the jobs BBOSBRAK and BBOCBRAK that defined the WebSphere administrative user ID to RACF and created its keyring. Then use those RACF commands to create a new user ID or update your personal user ID so it has the same characteristics. (Your RACF Administrator will probably need to run the RACF commands for you.)
If you cannot locate the BBOSBRAK and BBOCBRAK jobs that set up the security domain for the cell:
- Find the following information:
- The user ID and group of the IBM WAS Controller or administrator started task
- The name of the CA certificate that was used to sign the controller user ID's server certificate. (If configuring a server in a Network Deployment, find the name of the CA certificate that was used to sign the deployment manager server certificate).
If you don't know the group ID of the Controller or administrator ID, issue the TSO RACF command LISTUSER (LU) for servant task owner. For example:
LU ASCR1 USER=ASCR1 NAME=WAS APPSVR CR OWNER=IBMUSER CREATED=05.043 DEFAULT-GROUP=WSCFG1 PASSDATE=N/A PASS-INTERVAL=N/A ATTRIBUTES=PROTECTED REVOKE DATE=NONE RESUME DATE=NONEThis shows that the group default group name for the ID is WSCFG1.- Define a user ID that you will use exclusively for running the ITCAM for Application Diagnostics setup configuration using the TSO RACF command ADDUSER (AU). For example:
AU ITCAMWS NAME('ITCAM for WAS USER') PASSWORD(password) - OWNER(IBMUSER) DFLTGRP(WSCFG1) UACC(READ) - TSO(ACCTNUM(ACCT#) PROC(GENERAL) - SIZE(200000) MAXSIZE(200000)) - OMVS(HOME(/u/itcam61) PROGRAM(/bin/sh) UID(00001234))The TSO segment for this user profile is required if you intend to run the ITCAM for Application Diagnostics setup from TSO OMVS. This same user ID will be used for the ITCAM for Application Diagnostics Java Management Extensions (JMX) client.- Create a keyring for this user ID, and have the cell signing CA certificate placed on it, as follows:
RACDCERT ID(ITCAMWS) CONNECT - (RING(WASKeyring) LABEL('WebSphereCA') CERTAUTH)Access to keyrings and certificates is protected by RACF by a set of profiles in the FACILITY class. Although the keyring is associated with the user ID, the user must have read authority to the IRR.DIGTCERT.LISTRING profile in order to access its keyring. The user must also have read access to the IRR.DIGTCERT.LIST profile to be able to access its certificate.
- If you selected Use SAF EJBROLE profiles to enforce J2EE roles during security domain setup in the IBM WAS Customization Dialogs, make sure the user ID you will use to run setupwas.sh has read access to the EJBROLE administrator profile. The following administrative roles were defined by the customization jobs:
RDEFINE EJBROLE (optionalSecurityDomainName.) administrator UACC(NONE) RDEFINE EJBROLE (optionalSecurityDomainName.) monitor UACC(NONE) RDEFINE EJBROLE (optionalSecurityDomainName.) configurator UACC(NONE) RDEFINE EJBROLE (optionalSecurityDomainName.) operator UACC(NONE)Ideally, your user ID will be a member of the administrative or Controller ID group, which is already granted permission to these profiles.
- For any RACF classes whose profiles have been added or modified, refresh the RACF cache. To do this, an authorized RACF administrator must issue the following command:
SETROPTS RACLIST(classname) GENERIC(classname) REFRESH- Use the WebSphere Scripting Client directly to see if the user ID is set up correctly. From a USS session, change to the bin directory of IBM WAS and issue the following command:
./wsadmin.sh –user itcamws –password itcamwsYou will see messages similar to the following message if the user ID is set up correctly (This example is from a Network Deployment environment):WASX7209I: Connected to process "dmgr" on node PLEX1Manager using SOAP connector; The type of process is: DeploymentManager WASX7029I: For help, enter: "$Help help"Enter quit to terminate the WebSphere Scripting Client.
Parent topic:
Set up security