The RACF subsystem

The RACF® subsystem performs various functions, including enabling remote RACF administration and password synchronization, providing an execution environment for most RACF commands, and supporting functions such as Start of changebypassing the built-in password phrase syntax rulesEnd of change, compliance data collection, and user containment management.

Starting the subsystem is optional, but recommended. It is not necessary for system IPL or most RACF functions, but it is required for the following functions:

  • Issuing RACF commands as operator commands. For more information, see RACF operator commands.
  • Start of changeImplementing RACF options by using the switch profiles that are defined in the OPTAUDIT and OPTRACF classes.End of change
  • Using the R_admin (IRRSEQ00) callable service. When the RACF subsystem is active, it runs commands that are passed to it by R_admin. Applications that use R_admin require the RACF subsystem to be active.
  • RACF remote sharing facility. The RACF subsystem is required for the RACF remote sharing facility to be operational. For more information, see RACF remote sharing facility (RRSF).
  • Using SETROPTS APPLAUDIT with UNIX applications.
  • Collecting compliance data. When the RACF subsystem is active and the system is enabled for collecting SMF type 1154 records, RACF collects and writes compliance data to subtype 83. For more information, see z/OS Security Server RACF Macros and Interfaces.
  • Start of changeManaging user containment. The RACF subsystem is required for user IDs to be added to or removed from containment. After a user ID is contained, the user's access is denied regardless of whether the RACF subsystem is active. For more information, see the description of user ID containment in z/OS Security Server RACF Security Administrator's Guide. End of change
  • Using RACF LU6.2 persistent verification. The RACF subsystem provides a centralized data owner/data server environment for the signed-on lists used by RACF persistent verification. The lists are managed with the RACROUTE REQUEST=SIGNON macro. RACF also provides an execution environment for the RACF persistent verification operator commands DISPLAY and SIGNOFF.
  • Using key generation for the Network Authentication Server (IBM® Kerberos). When a user profile has a KERB segment containing a Kerberos principal name (KERBNAME field) and the user sets a non-expired password, a key is generated and stored in the KERB segment of that user. When the change is because of an application update (for example, TSO or CICS® logon), the RACF subsystem generates the key. If the RACF subsystem is not available, no key generation is performed for the password change.
  • Using password and password phrase enveloping. When the password or password phrase enveloping function is configured, the RACF subsystem creates encrypted envelopes for eligible users when their passwords or password phrases are changed, and controls the retrieval of these envelopes by authorized applications. For details on the enveloping function, see z/OS Security Server RACF Security Administrator's Guide.

    When the enveloping function is configured, during RACF subsystem initialization RACF invokes z/OS® UNIX services to initialize itself as a UNIX process, which requires the OMVS kernel to be initialized. If the OMVS kernel is not initialized, RACF subsystem initialization waits for OMVS initialization to complete. As a result, the RACF subsystem address space might initialize later in the IPL sequence than it would if enveloping was not configured.

    When the enveloping function is configured, an OMVS shutdown can affect the RACF subsystem. Enveloping operations wait for OMVS to be restarted. If enough password or password phrase changes are made while the OMVS kernel is unavailable, the available tasks in the RACF subsystem can be exhausted, affecting other RACF address space functions that would otherwise not be affected by an OMVS shutdown. An OMVS shutdown should not be performed while work is occurring on the system. For information about shutting down OMVS, see z/OS UNIX System Services Planning.

  • Using LDAP event notification. When LDAP event notification is configured, the RACF subsystem contacts the z/OS LDAP server to create a change log entry when a RACF user profile is updated. For more information, see z/OS Security Server RACF Security Administrator's Guide.
Tip: If you activate the RACF subsystem, perform the following tasks to allow the security administrator and system operator to address early startup issues because of RACF access failures:
  1. Define the RACF subsystem as trusted. For more information, see Assigning a user ID to the RACF subsystem.
  2. Verify that the security administrator and the system operator know the correct command prefix for the RACF subsystem. For more information, see Updating the IEFSSNxx member of SYS1.PARMLIB.
  3. Verify that the security administrator has authorization to use the MVS LOGON operator command.

Taking these steps allows the security administrator and system operator to log on to an MVS console and repair RACF profiles.

The RACF subsystem address space is identified as a standard MVS subsystem. The RACF subsystem provides the following services:
  • Automatic start of the RACF subsystem at IPL time.
  • Customization through startup parameters. The RACF subsystem reads startup parameters from the IEFSSNxx member of SYS1.PARMLIB and the PARM keyword on the EXEC statement in the subsystem procedure.
  • Optional subsystem command identifiers. You can choose to use the MVS subsystem convention of assigning a unique subsystem prefix or you can use the unique subsystem name, followed by a blank, as the prefix for the RACF subsystem.

    This unique subsystem name is defined in the IEFSSNxx member of SYS1.PARMLIB.

Only one RACF subsystem can run at a time. If you define more than one RACF subsystem with the same name in IEFSSNxx, only one instance starts. It is possible to define two RACF subsystems with different names, and start the second one after stopping the first, but this is not recommended. If you choose to do this, you must specify PARM=INITIAL on the MVS START command whenever you start a RACF subsystem that has a different name than the one that was previously running.

Start of changeWhen the RACF subsystem is started at IPL time, z/OS assigns a reusable address space identifier (ASID) to the RACF address space: START RACF,SUB=MSTR,REUSASID=YES. This setting makes the ASID available for reuse after the address space ends, preventing it from becoming a "lost" ASID.End of change