These are some of the questions that we most frequently hear about RACF. They have been culled from user group meetings, the RACF-L mailing list, and customer briefings. You can find FAQs for these topics:

If you would like to to nominate a FAQ for inclusion in this list, please e-mail markan@us.ibm.com.

Digital Certificates

RACF has extensive support for digital certificates. RACDCERT is the RACF command that allows you to generate your own certificate or import certificates from other systems, including other operating systems. RACDCERT also provides the ability to map certificates to users so that instead of using user ID and password to authenticate to RACF, a certificate can be used. While RACDCERT provides a basic set of certificate functions, more advanced functions are provided by PKI Services for z/OS.

PKI Services for z/OS is a z/OS base component which can provide a full life-cycle management on certificates - request, approve, create, renew and revoke. It uses web interface to provide more robust functions.


You can find FAQS for these topics related to Digital Certificates:


RACDCERT, PKI Services, and MD5

Q: Do RACDCERT and PKI Services use MD5 in the signing algorithm?
A: RACDCERT always use SHA1, no option is provided. PKI Services allows you to choose different algorithms through the configuration file, pkiserv.conf. The shipped configuration file has SHA1 as the default.

RACDCERT and Long Issuer's Distinguished Names

Q:I have heard that there is a length restriction on my certificate's issuer's Distinguished Name when I use RACDCERT. Why?
A:RACDCERT creates a profile to represent a certificate in the form of <serial_number>.issuers_distinguished_name. The maximum length of any RACF profile is 246. Therefore, you need to make sure that the Distinguished Name of your issuer is within that limit, otherwise you can't install your certificate.

RACF Remote Sharing Facility (RRSF)

RACF for MVS Version 2 Release 2 introduced the RACF remote sharing facility (RRSF), a powerful RACF facility linking together multiple RACF data bases using MVS/APPC, allowing remote RACF administration and password synchronization.


You can find FAQS for these topics related to RRSF:


Synchronizing passwords

Q: Isn't having the same password on multiple systems a risk?
A: No, because of the way most people handle their passwords. Studies have shown that when people have IDs on multiple systems, when they change one ID they change them all so that they stay common. When forced to select different passwords, people tend to write them down, which is a larger exposure. RRSF allows you to specify at a user ID and node level the user IDs for which you want the passwords synchronized. This makes your environment as safe as your "weakest" system. Therefore, you should make each system equally strong before enabling password synchronization among them.

Q: Should the password rules be the same across all the systems with which we are synchronizing passwords?
A: Yes. RACF validates the password for adherence to the SETR password rules and exits at the source system only.

Q: Can we control who is allowed to perform password synchronization?
A: Yes! The RRSFDATA class contains profiles that administrators can use to control who can do password synchronization through user ID associations. Use of automatic password synchronization can also be controlled.

Q: Can I synchronize passwords with a VM system?
A: No, this support is available on MVS only.

Q: What if something goes wrong on the target side, such as a password is not valid, the user ID is expired, or the system isn't available?
A: For password synchronization, the password validation is done only at the point of origination. The password flows to the target system where the target ID has its password changed to the new value. We recommend that where password synchronization is being used, the same SETROPTS options and password exit processing should be in place. RACF will change the password if the target user ID is revoked. Because the ID remains revoked, changing the password doesn't present a security exposure. RRSF has extensive facilities for queuing requests. If the target node is not available, RRSF retains the request until the node is available.

Q: What happens if I use a program that alters a password in the RACF database using the ICHEINTY macro?
A: ICHEINTY-initiated password changes are propagated if they are not ENCRYPT=NO requests.


Sharing a RACF database between MVS and VM

Q: Can I share my RACF database between MVS and VM?
A: While RACF 2.2 continues to support the sharing of a RACF data base between MVS and VM, you can share the database only if neither the RRSF nor RACF datasharing are in use.


The RRSF node name

Q: Is the RRSF node name the same as the VTAM node name?
A: No. You get to select your own meaningful node name.


Shared RACF database

Q: What if we have a shared RACF data base?
A: If you are sharing the RACF data base among systems, one of the systems sharing the database should be designated the "MAIN" system. This is the system to which data base changes are directed. This technique, named multisystem node support, was introduced with APAR OW13567.

Note: If you have not configured your RACF remote sharing facility system, be sure to apply OW13567 before your begin your RRSF configuration to shorten the time required to configure RRSF.


Directing commands

Q: Can I direct any RACF command?
A: You can direct all of the RACF administrative commands, such as ADDUSER, ADDGROUP, RDEFINE, and PERMIT. Only RACLINK, RVARY, and BLKUPD cannot be directed.


Restricting the execution of a command to one system

Q: Can I restrict the execution of a command to only one system even if I have multiple RRSF nodes defined and connected and have enabled automatic command direction to another system?
A: Yes. All of the commands have a keyword, ONLYAT, that causes the command to be executed "only at" the node that was specified.


Using the ONLYAT keyword

Q: Can an auditor issue commands with the ONLYAT keyword?
A: No. ONLYAT is restricted to users with the SPECIAL attribute.


The workspace data sets

Q: The RRSF workspace data sets contain sensitive data. How are they protected?
A: RACF uses normal OPEN processing to access these VSAM data sets. Normal RACF protection rules apply. The RACF address space must be marked as trusted or be on the access lists of these data sets.

Q: Can I view the data in the RRSF workspace data sets?
A: Yes. We are shipping a dump utility that processes these data sets and creates an easily-readable data set. The user of the utility must have read authority to the data set and authority to use the utility (via a check against the IRRBRW01 profile in the RRSFDATA class). The utility does not dump passwords.


Setting the CDMF key

Q: Can installations set the CDMF key?
A: No, it is fixed by IBM.


The RRSFLIST data set

Q: Is the RRSFLIST data set a DISP=MOD data set?
A: Yes, it is appended to, not deleted. It is the user's responsibility to manage this data set.

Q: What happens when the RRSFLIST data set fills up?
A: RACF transmits the data that it cannot fit into the data set to the user.

Q: What is the naming convention for the RRSFLIST data set?
A: If no TSO prefix is defined or the prefix is the same as the user ID, RACF uses < user_id>.RRSFLIST. Otherwise, RACF uses < tso_prefix>.< user_id>.RRSFLIST.


Terminating RRSF

Q: Do I have to terminate RRSF before VTAM?
A: No.


Terminating RRSF connections

Q: Can I terminate all of the RRSF connections in one command?
A: Yes, using a RACF parameter library member that is invoked through the SET command. The parameter library would contain a TARGET command for each of the nodes with which you wish to terminate communication.


Abnormal termination of a connection

Q: What happens if a target node terminates abnormally as in a power failure? Is there any trouble restarting the RRSF communication?
A: No, there are timeouts on the connections and the data is checkpointed in the RRSF workspace data sets.


Generic qualifiers in the APPC/LU profile

Q: Can I use generic qualifiers anywhere in the APPC/LU profile?
A: No, only in the last qualifier. This is due to the way that VTAM RACLISTs the profiles in its address space.


Protecting the APPC utility that creates the DBTOKENS

Q: IBM recommends protecting the APPC utility that creates the DBTOKENs. How do I do this?
A: RACF's program access to data sets (PADS) facility is used to control access to the APPC utility program. The programs that require PROGRAM profiles are ATBSDFMU, ATBSDEPE, and ATBINMIG. You can find details in RACF Version 2 Release 2 Installation and Implementation Guide, SG24-4580.


Changing RRSF definitions

Q: Do I need to restart the RACF address space when I change RRSF definitions?
A: No, as long as you have the RACF parameter library allocated to DDNAME RACFPARM in the RACF address space started procedure.


A target node is down

Q: What happens when the target node in the remote sharing environment is down?
A: RACF has extensive store and forwarding facilities. In-flight data is kept in RRSF workspace data sets until it can be delivered to the target system.


Audit records

Q: What IDs appear in the audit records that are created for directed commands?
A: Both the source ID (the ID of the person issuing the command) and the target ID (the ID under which the command executes) appear in the audit record.

Q: Does the audit record for a directed command contain the command that is being propagated?
A: Yes.


The number of tasks handling commands in the RACF address space

Q: Is there any way for the installation to control the number of tasks that are handling the commands in the RACF address space?
A: No.

RACF and MVS TCP/IP

You can find FAQS for these topics related to RACF and MVS TCP/IP:


Securely enabling TCP/IP on an MVS or OS/390 system

Q: Can I securely enable TCP/IP on my MVS or OS/390 system?
A: Yes you can. However, remember that when we speak of TCP/IP we are usually talking about not only an architecture, but also a set of applications. In TCP/IP, application code must follow the same protocols for security as any secure application. If the TCP/IP application uses the MVS's System Authorization Facility (SAF) interface to make application determined security requests, security will be similar to that provided by other MVS or OS/390 environments.

IBM's TCP/IP telnet server application requires the use of a user ID and password and issues the appropriate SAF calls for verification of this information before completing the telnet session into MVS. Telnet defines the TCP/IP connection as a VTAM virtual terminal. Similarly, when IBM's TCP/IP FTP server application establishes communications with MVS the FTP application code uses SAF to prompt for user ID and password.

Any other TCP/IP application written to communicate or connect to the MVS environment is subject to the security protocols on MVS. Since MVS does not mandate the use of SAF interfaces to invoke security, any TCP/IP application should be examined for use of these interfaces to provide the necessary security calls required to provide the minimum level of security required by the installation. This caveat applies especially to user-written applications whether TCP/IP-based or not.

If there will be TCP/IP access into MVS by other applications, the installation should create a change management and monitoring process to ensure that applications using TCP/IP adhere to the installation's base security policies for identification and authorization and that they include the type and level of resource checking deemed necessary by the installation.

There are some external security issues which might be of concern. One is the possible exposure of the user ID and password as they cross the network. This exposure exists to a certain extent in SNA environments as well. It can be limited or removed by the use of encryption on the transmission of the sensitive data. Another concern is the possibility of someone masquerading as a valid terminal.

TCP/IP sessions have no dedicated LU name associated with them, limiting the ability to provide security based on terminal resources. However, security control via terminal access can be achieved by grouping TCP/IP LU names within pools dedicated for use by similar resource/access-need users. Assigning a specific LU name to a specific TCP/IP address is also possible; however, the administrative overhead would probably be too burdensome. This is a consideration if the RACF TERMINAL class protection is other than READ.

Overall the security of the MVS system is similar whether one is using TCP/IP or SNA. The major difference is that in a SNA environment there exists a defined set of resources for that environment and applications supplied by IBM within that environment use the SAF interfaces at appropriate control points to ensure security. User-written SNA applications, though, are under the same caveat as TCP/IP applications to require the installation check for the existence of security calls at the appropriate application control points to enforce security policies.

RACF in the year 2000

You can find FAQS for these topics related to RACF in the year 2000:


RACF support for the year 2000

Q: How is RACF handling the problems associated with the year 2000?
A: IBM has announced its support for the Year 2000 in IBM announcement letter 295-464 (31 October 1996) . Additional information can be found on the System/390 Year 2000 page.

In particular, IBM has announced that RACF 2.2 will support the year 2000. This support requires two PTFs, and the second one will provide our documentation on the components of our support. The major change made to RACF for year 2000 comprises a re-interpretation of our existing 3-byte dates ( yydddF) such that a yy value less than or equal to 70 indicates a 20 yy date, and a yy value greater than or equal to 71 indicates a 19 yy date.

Additionally, we plan to have some ISPF panel modifications to support year 2000 dates and a callable service that given one of our 3-byte dates will return an MVS-style 4-byte date with the appropriate century indicator.

Technical Tips

You can find FAQS for these RACF technical tips:


An automated process for revoking dormant users

Q: Is there an automated process by which user IDs that have been dormant for a specified period of time will have their data access revoked and their group connections deleted?
A: Yes there is! Using the RACF remove ID utility (IRRRID00) and the RACF SEARCH command you can find all of the user IDs that have been inactive for a given period of time and generate the commands to remove their access list entries and group connections.

The process is simple:

  //CLEANUP JOB
Jobcard
//*---------------------------------------------------
//SEARCH EXECPGM=IKJEFT01,DYNAMNBR=100
//SYSTSPRT  DD SYSOUT=*
//SYSPRINT  DD SYSOUT=
    
* //SYSTSIN
DD * PROFILE PREFIX(MARKN) SR
CLASS(USER)
AGE(30)
CLIST('','  SYSOPS') /*//*----------------------------
//COMMANDS  EXEC  PGM=IRRRID00
//SYSPRINT    DD  SYSOUT=
*   //SYSOUT  DDSYSOUT=
*    //SORTOUT  DDUNIT=SYSALLDA,SPACE=
(CYL,(05,5))     //SYSUT1  DDUNIT=SYSALLDA,SPACE=
(CYL,(05,5))      //SYSIN  DDDISP=SHR,DSN=MARKN.EXEC.RACF.CLIST
//INDD     DD  DISP=SHR,DSN=SYS1.RACF.IRRDBU00
//OUTDD          DDDISP=(NEW,PASS),DSN=MARKN.IRRRID00.CLIST(CLEANUP),
//          UNIT=SYSALLDA,SPACE=(CYL,(2,1,1)),

//DCB=(LRECL=259,BLKSIZE=0,RECFM= VB) //*-----------------------------------------------------
//DELETE EXECPGM=IKJEFT01,DYNAMNBR=100
//SYSTSPRT  DD SYSOUT=
*   //SYSPROC DDDISP=(OLD,DELETE,DELETE),

DSN=MARKN.IRRRID00.CLIST //SYSTSIN DD * PROFILE PREFIX(MARKN) EX IRRRID00(CLEANUP) L /*

Contact IBM

Browse z/OS