(ZOS) Specifics about identification and authentication

For identification, each controller and servant start procedure must have its own user ID and define it in the STARTED class. Because we should give differing resource authorizations to each, we should give differing user IDs to controllers and servants.

For identification, each controller and servant start procedure must have its own user ID and define it in the STARTED class. Because we should give differing resource authorizations to each, we should give differing user IDs to controllers and servantsbprac .

Additional user IDs are required for installation. We provide the definitions for these user IDs in our RACF sample. See the customized instructions produced when running the z/OS Profile Management Tool.

• User IDs for controllers and servants.
• A user ID for the Installation Verification Test (IVT) and its application cluster. Our RACF sample uses WSIVT.
• A user ID called WSADMIN used by the Administration application.
• A default local and remote user ID associated with each cluster through the administrative console. We use WSGUEST.

Regarding authentication, an operator starts a cluster using the START command and the controller start procedure. Authentication of the start procedure's user ID is made by virtue of the fact an operator started the start procedure-that is, no password is required. To restrict an operator's ability to start clusters, do so through the OPERCMDS class in RACF.

The WAS installer automatically generates the STARTED class profile to assign the User ID to WebSphere Application Server. If we are not using AUTO UID and AUTO GID in the OMVS segment for the WAS STC User ID, make sure that we have UNIQUE UID and GID assigned to the WAS STC. If they are not unique, we might either have problems starting WAS or in logging in to the administrative console if admin security is enabled.

All WebSphere user ids and groups must have an OMVS segment with a valid and unique UID or GID.

Related:

WAS security for z/OS