z/OS Security Server RACF Security Administrator's Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Automatic direction

z/OS Security Server RACF Security Administrator's Guide
SA23-2289-00

Automatic direction is an extension of command direction and password synchronization that allows some administrative tasks and application updates to be automated between RRSF nodes. Automatic direction keeps already synchronized RACF® profiles synchronized between two or more remote nodes.

Automatic direction includes:
  • Automatic direction of commands, which allows RACF TSO commands that update the RACF database to be automatically directed to remote nodes in order to keep profiles synchronized between the nodes. Commands issued with automatic direction of commands run asynchronously. The results and output from the commands are returned to specified users (not necessarily the command issuer).
  • Automatic password direction, which keeps already synchronized RACF user profiles synchronized between two nodes, with respect to RACF passwords and password phrases.
  • Automatic direction of application updates, which allows updates made by RACF macros to be propagated to the RACF databases of other systems. Updates to the RACF database can be made using:
    • ICHEINTY
    • RACDEF
    • RACROUTE REQUEST=DEFINE
    • RACROUTE REQUEST=EXTRACT,TYPE=REPLACE
    • RACXTRT

    Automatic direction of application updates allows these changes to be automatically sent to selected remote nodes. These updates to remote target nodes take place only after the update has successfully completed on the local node where it is executing and the macro completes with a return code of 0.

    Note: RACF database updates made by the RACDCERT command are candidates for propagation under the control of automatic direction of application updates, even though the RACDCERT command itself is not eligible for automatic command direction. In this case, the individual updates made by RACDCERT might be successful, and propagated to other nodes, even though the RACDCERT command as a whole might fail.
The essential elements of automatic direction are:

Example: Automatic direction of commands

Automatic direction of commands works as follows: Suppose NODEA, NODEB, and NODEC have equivalent profiles in the USER and GROUP classes. All RACF TSO commands that affect USER and GROUP profiles can be automatically directed between the nodes. When an ADDUSER command is issued on NODEA, it can be automatically directed to execute on NODEB and NODEC. When a DELGROUP command is issued on NODEC, it can be automatically directed to NODEB and NODEA.

There might also be special situations where automatic direction can be used to facilitate administrative updates to multiple RACF databases. For example, suppose a university has a production MVS™ system and a test MVS system, each with its own RACF database. At the beginning of each semester, each new student gets a user ID on each MVS system. By temporarily using automatic direction of commands, an administrator can enter ADDUSER commands on the production system and have them automatically directed to the test MVS system.

Example: Automatic password direction

Automatic password direction does the following: NODEA, NODEB, and NODEC have equivalent profiles in the USER class. Password and password phrase changes can be automatically directed to RACF user profiles without the need for established RACLINK PEER PWSYNC associations. When a user's password or password phrase changes on NODEA, a password synchronization request can be automatically directed to execute on NODEB and NODEC.

Example: Automatic direction of application updates

Automatic direction of application updates does the following: An installation-written application that creates profiles in installation-defined class using RACROUTE REQUEST=DEFINE can execute on NODEA and cause profiles to be created on NODEB and NODEC as well as NODEA.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014