Using RACF to manage Datacom External Security for dynamic changes

Products

Datacom Datacom/AD Datacom/DB

Issue/Introduction

When using RACF to manage security settings for Datacom, there are several things that have to be set up correctly to allow you to make dynamic permission changes. These settings will allow you to refresh the security permissions without recycling the Datacom MUF or the user application.

Environment

Release : 15.1

Component : Datacom/DB

Component : Datacom/AD

Component : Common Components and Services

Resolution

This explains the configuration and process necessary to make dynamic RACF security permission changes for Datacom users of External Security.

1. In order to be able to make dynamic changes to your Datacom RACF permissions without needing to recycle the MUF, you need to use the CAIRACF DD statement in your CAS9 proc, containing entries for each RACF class you need, and with these classed defined with FASTAUTH=NO. Without this step, any RACF changes would require the MUF to be recycled following the SETR REFRESH command in order to pick up Dx@ABLE changes.

The short version for this setting is that using RACF FRACHECK (FASTAUTH=YES) causes the CCS processing to load these classes into memory, and to use the memory definition for any security test. Obviously, if you later change the database, these changes would not be reflected in this CCS-loaded memory entry, which would require CCS to delete and then re-list each class in order to rebuild the in-memory profiles (a large performance hit). Therefore, you need to use the standard RACF RACHECK processing (FASTAUTH=NO), which queries the RACF database directly, and which would pick up database changes you make.

Because you are already using so many of the Dx@TABLE entries, we would recommend your CAIRACF DD statement contain all of these Datacom definitions among your other CAIRACF definitions. The default settings for Datacom currently use FASTAUTH=YES, but NO is required if making dynamic changes (note that we also recommend using CICS=NO if dynamic changes could affect CICS processing):

RACFCLASS DTSYSTEM,DT@YSTEM,FASTAUTH=NO,CICS=NO
RACFCLASS DTADMIN,DT@DMIN,FASTAUTH=NO,CICS=NO
RACFCLASS DTUTIL,DT@TIL,FASTAUTH=NO,CICS=NO

RACFCLASS DCTABLE,DC@ABLE,FASTAUTH=NO,CICS=NO
RACFCLASS DFTABLE,DF@ABLE,FASTAUTH=NO,CICS=NO
RACFCLASS DGTABLE,DG@ABLE,FASTAUTH=NO,CICS=NO
RACFCLASS DHTABLE,DH@ABLE,FASTAUTH=NO,CICS=NO
RACFCLASS DPTABLE,DP@ABLE,FASTAUTH=NO,CICS=NO
RACFCLASS DQTABLE,DQ@ABLE,FASTAUTH=NO,CICS=NO
RACFCLASS DRTABLE,DR@ABLE,FASTAUTH=NO,CICS=NO
RACFCLASS DSTABLE,DS@ABLE,FASTAUTH=NO,CICS=NO
RACFCLASS DTTABLE,DT@ABLE,FASTAUTH=NO,CICS=NO
RACFCLASS DXTABLE,DX@ABLE,FASTAUTH=NO,CICS=NO

Once these are in place and active, you will be able to refresh Datacom security. You should also add this to your CAS9 proc:

//CAISSFDG DD SYSOUT=*

to report on the CAIRACF statements and their settings.

If these have not been defined when CAS9 was run at IPL time, you can run a command to refresh CCS security settings and add them. Note: Solution LU06243 (published August 2022) is needed to prevent Datacom MUFs from abending if this command is run while the MUF is active. To refresh CCS security (module SSF), issue this console command:

PRODUCT(CAIRIM) VERSION(CAS9) INIT(CAS9INIT) PARM(REFRESH(SSF))

For more information about this customization of CCS module SSF for use with RACF, please see the Customize CAISSF for RACF or RACF-Compatible Products section of the Common Components and Services for z/OS 15.0 documentation.

2. With the CCS security settings active, you can now make changes to the RACF profiles as needed for the DT@DMIN, DT@TIL, DT@YSTEM, or Dx@ABLE classes. After the permissions have been made, be sure to refresh the RACF local memory definition with these changes. You can use one of these RACF commands:

SETR RACLIST(DT@DMIN) REFRESH
SETR RACLIST(DT@TIL) REFRESH
SETR RACLIST(DT@YSTEM) REFRESH
SETR RACLIST(Dx@ABLE) REFRESH

Completion of this command will refresh the changes in the RACF environment by doing these steps:

Read the RACF DB to rebuild the RACLIST profiles in local memory (member
grouping profiles merged)
Stores RACLISTed profiles in a new Data Space
Updates the in-memory CDT (Class Descriptor Table) to point to the new Data Space
Deletes the old Data Space

Without the SETR commands, RACF will not be aware of the profile changes, because the local memory settings would have been loaded from the database at IPL time, and never again.

3. If the above RACF permission change was made to the Dx@ABLE class, you then need to refresh the Datacom security control blocks (SECURITY RESET command). This only applies to the Dx@ABLE class; changes to the other classes do not need Datacom refresh processing, and this command will not have any effect on security for those classes. To refresh Datacom Dx@ABLE class entries, use this console command (user is optional; specify one user name here, or leave blank to reset all active users):

/F mufstcname,SECURITY RESET {user}

or

DBUTLTY Command

SECURITY OPTION=RESET{,USER=user}

If any one of these above three parts is skipped, the dynamic security change will not happen. However, if you have made the RACF change (step 2, above), it will have been made to the RACF database and then will have been RACLISTED at the next IPL, making the profile setting ready for use. Then, starting the MUF would enable all the Dx@ABLE changes, obviating the need for the RESET command for those entries.

Additional Information

For more information about using External Security with Datacom, please refer to the Security Overview section of the Datacom/DB Core documentation.

As always, please contact Broadcom support for Datacom if you have further questions. Note that when opening a new case, please provide the following:

The output from the Multi-User Facility;

The output from any failed jobs, or screen captures of any user online error;

The result of these RACF commands:

RLIST Dx@ABLE * ALL (for all the "TABLE" classes specified in the MUF SECURITY option)
RLIST DT@DMIN * ALL
RLIST DT@YSTEM * ALL
RLIST DT@TIL * ALL
LU uuuuuuuu ALL (for the Logon ID of the user or job receiving the error)