z/OS Security Server RACF
The operating system provides integrity. By using a Security Server, in this case Resource Access Control Facility (RACF), you can protect resources by defining which resources are protected and which groups of users or which individual users have access to the defined resources. The definitions are kept in the RACF database. A RACF administrator defines users, user groups, and resources together with rules for how these resources can be used. RACF is “invisible” for most users if a good security structure is put in place. Most companies have well-documented policies for Information Security. All RACF definitions need to be based on these policies.
RACF helps meet the needs for security by providing the ability to:
•Identify and verify users
•Authorize users to access the protected resources
•Control the means of access to resources
•Log and report attempts to access protected resources
•Administer security to meet an installation's security goals
RACF provides these functions when the installation defines the users and the resources to be protected.
A specific RACF user, called the security administrator, has the responsibility to define users and resources to RACF. The security administrator also specifies the rules that RACF uses to control access to the resources.
The responsibility to implement the guidelines falls to the system programmer, who provides technical support for RACF. The system programmer installs RACF on the system and maintains the RACF database. This person oversees the programming aspects of system protection and provides technical input on the feasibility of the implementation plan. In addition, the technical support person can write and implement RACF installation exit routines to extend the security infrastructure. RACF retains information about the users, resources, and access authorities in profiles in the RACF database and refers to the profiles when deciding which users are permitted access to a protected system resources. The auditor monitors the security controls and examines that the security goals are met.
2.1 What is RACF?
Figure 2-1 What is RACF?
What is RACF
RACF is an add-on software product that provides the basic security to a z/OS system. Other security software products are available, such as from Computer Associates, ACF2, and Top Secret. RACF is included as part of the base z/OS system but requires a separate licence to be activated.
RACF provides the ability to implement the security policies that you choose on your system.
 
Note: Your system will not be secure by simply installing RACF. The quality of the system protection depends on the way that you use the RACF functions.
2.2 RACF functions
Figure 2-2 RACF functions
RACF functions
RACF protects resources by granting access only to authorized users of the protected resources. To accomplish this, RACF gives you the ability to accomplish the tasks described in this section.
Identify and authenticate users
User authentication is validation of the user requesting access. The first step is to identify the person who is trying to gain access to the system, and the second is to authenticate that the user is really that person. The standard approach to RACF user identification is achieved by the use of a user ID and password phrase or password to perform user identification and authentication. Other options are available, such as digital certificate and smart card.
Resource authorization
Having identified and verified the user, RACF then controls interaction to the system resources. RACF must authorize the users who can access resources and also the way users can access them, which depends on the purpose of each user (for example, reading or updating). RACF can also authorize when a user can access resources, by either time or day.
Log and report access to protected resources
RACF provides the ability to log information, such as an attempted access to a resource and to generate reports containing that information which allows identification of users who attempt to access resources. The logging and reporting functions are:
•Logging: RACF writes records to the system management facility (SMF) data set for unauthorized attempts to enter the system and optionally RACF writes records to SMF for authorized attempts. Other events can also be logged.
•Reporting: The SMF records can be analyzed by the RACF Report Writer or be translated and followed up by other reporting packages such as DB2®.
•Sending Messages: RACF sends messages “real time” to the security console and, if implemented, to RACF-defined TSO users as well.
Security administration
RACF can be administered either in a centralized or decentralized manner. In a centralized approach, the RACF administrator (user attribute SPECIAL) controls the access to all users, groups and resources.
In a decentralized approach, RACF administration can be delegated to administrators only at a group level. These administrators have the group-SPECIAL attribute, which enables them to control access only to their group or to be more precise to their scope of the group. The scope of control of a group-level attribute percolates down through a group-ownership structure from group to subgroup to subgroup and so on. Percolation is halted (and, therefore, the scope of control of the group-level attribute is ended) when a subgroup is owned by a user instead of a superior group.
Another way to implement decentralized administration is by use of class authorization. To do this an administrator is authorized only for specific types of profiles, for example for user profiles. In this case, the administrator can administrate user IDs but cannot define which user IDs, how resources are protected, or who should have access to resources.
Control the means of access to resources
RACF retains information about the users, groups, resources, and access authorities in profiles that are stored in the RACF database and refers to the profiles when deciding if users are permitted access to protected system resources. Applications can request RACF services. Most of these services can only be requested by authorized applications.
RACF database
The RACF database holds all RACF access control information. RACF processing uses the information from the database each time a RACF-defined user enters a system and each time a user wants to access a RACF-protected resource. Some of this information can be cached in storage.
You maintain the RACF database through commands, macros, and utilities.
The RACF database is a non-VSAM, single extent data set that is made up of 4 KB blocks and must be cataloged.
RACF allows you to provide a backup database to which you can switch without a re-IPL in case your primary RACF database fail. A backup RACF database reflects the contents of the primary database. After the installation has created the backup database, RACF can maintain it automatically.
2.3 RACF ISPF panel
Figure 2-3 RACF primary ISPF panel
How to use RACF ISPF panels
If your installation has installed the RACF panels, you can use them to perform security tasks.
To access the RACF panels, enter the following command:
ISPF
The Interactive System Productivity Facility (ISPF) primary menu displays. From this menu, choose option R for RACF.
 
Note: Although this method is the usual way to access RACF panels, your installation might have this implemented through a different path.
The RACF panel interface is similar in use to all other ISPF panel options. Therefore, we do not go into detail here on to how to use it.
You can access help information for the RACF panels. Help panels exist for each individual panel. If you have a question about the information that you should provide on the panel, either press PF1 or type HELP on the command line. The help panels give more information about the terms on the panel and the information that you need to enter.
2.4 RACF profiles
Figure 2-4 RACF resource profiles
RACF resource profiles
RACF-protected resources can be divided into two categories:
•Data sets
•General resources
General resources are all of the resources that are defined in the class descriptor table. For example, general resources include DASD and tape volumes, load modules (programs), terminals, and others.
RACF maintains information entries, called profiles, in the RACF database. It uses profiles to protect DASD and tape data sets and general resources, such as tape volumes and terminals:
•Data set profiles contain security information about DASD and tape data sets.
•General resource profiles contain security information about general resources.
Each RACF-defined resource has a profile, though you can optionally use single profile to protect multiple resources.
RACF commands or the RACF ISPF panels can be used to create and modify general resource profiles.
RACF provides discrete, generic, and grouped resource profiles for both data sets and general resources, as follows:
Discrete Discrete profiles have a one-for-one relationship with a resource—one profile for each resource. Discrete profiles provide very specific levels of control. Use them for sensitive resources. They protect only the one identified data set that is on the specified volume or that spans specific volumes. For example, a single data set can be defined with a discrete profile to allow access by one user.
Generic Generic profiles have a one-for-many relationship. One profile controls access to one or more resources whose names contain patterns or character strings that RACF uses to associate them with each other. They contain a list of the authorized users and the access authority of each user. A single generic profile can protect many data sets that have a similar naming structure. For example, all data sets that have a high-level qualifier of SMITH and the characters DATA as a second-level qualifier can be controlled with one generic profile.
Grouped Another type of RACF profile is the grouped profile. There might be no way to associate the resources with a common access list based on patterns in the resource names. In this case, the many resource names can be associated with a single RACF profile through the use of a grouping profile that contains the names of the associated resources.
Some subsystems with high performance requirements, such as IMS™ and CICS®, have the profiles resident in the subsystem address space. These subsystems can save main storage by using grouped profiles.
2.5 RACF commands
Figure 2-5 RACF commands
RACF commands
For each resource type, a set of commands is available to define, modify, list, and delete resources.
There are several ways to enter RACF commands:
•RACF TSO commands
Easy and appropriate for ad hoc displays and update of user profiles and data set profiles, for example:
RDEFINE FACILITY BPX.SUPERUSER UACC(NONE)

PERMIT BPX.SUPERUSER CLASS(FACILITY) ID(JANE) ACCESS(READ)
•RACF TSO commands in batch
Most appropriate for a set of displays that is run, unchanged, at regular intervals.
•RACF ISPF panels
Might be most appropriate for display of some of the more complex RACF general resource profiles. They are also very useful if you do not know the syntax for a particular command.
In general, you must have authority for a RACF entry in order to display it. A normal TSO user can display only the RACF data relevant to himself. A user with SPECIAL authority can display almost anything.
 
Note: We say almost because RACF has another authority named AUDITOR who can uniquely display certain statistical data. A SPECIAL user can create AUDITOR authority, so the SPECIAL user remains the ultimate controller of RACF.
Using RACF commands with TSO/E
You can enter RACF TSO commands from the ready prompt or by selecting Option 6 from the ISPF menu.
You can get online help for RACF commands. To get online help for a command, type:
HELP command-name
For example, to see online help for the PERMIT command, enter:
HELP PERMIT
To limit the information displayed, use the SYNTAX operand on the HELP command:
HELP command-name SYNTAX
For example, to see only the syntax of the PERMIT command, enter:
HELP PERMIT SYNTAX
General use RACF commands include:
PASSWORD Change password/interval
CONNECT Associate user with group
REMOVE Disassociate user from group
PERMIT Modify resource profile access list
SEARCH Locate RACF information
SETROPTS Set/modify RACF system options
RVARY Switch RACF databases
You can use abbreviations for commands and parameters:
•AU for ADDUSER
•LG for LISTGROUP
•CO for CONNECT
•ID for USERID
•AC for ACCESS
•INT for INTERVAL
You can use any TSO commands in a batch job, using the JCL for executing the TSO monitor in batch, as shown in Figure 2-6.
//P390S JOB 1,P390,MSGCLASS=X
//TSOBAT01 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUADS DD DSN=SYS1.UADS,DISP=SHR
//SYSLBC DD DSN=SYS1.BRODCAST,DISP=SHR
//SYSTSIN DD *
LD DA('MARTIN.*') AUTHUSER
LU MARTIN
/*
Figure 2-6 JCL example of executing RACF commands in a batch job
Where the following command lists generic profile MARTIN and its access list:
LD DA('MARTIN.*') AUTHUSER
And, the following command displays the basic RACF data for user ID MARTIN:
LU MARTIN
2.6 User authentication
Figure 2-7 User authentication
RACF identifies and authenticates users accessing the system when the various system resource managers (such as TSO logon) request it. RACF determines the following conditions:
•Whether the user is defined to RACF.
•If the user has supplied a valid password or Pass Ticket or operator identification card (OIDCARD) and belongs to a valid group. RACF has support for a password phrase that can be up to 100 characters long.
•If the user accesses a UNIX System Services resources, then the user also must have a valid UID and GID (if this is not provided by a default user and group ID).
•Whether the user ID is in REVOKE status, which prevents a RACF-defined user from entering the system at all or entering the system with certain groups.
•If the user can use the system on this day and at this time of the day (an installation can impose restrictions).
•If the user is authorized to access the terminal (which can also include day and time restrictions for accessing that terminal).
•If the user is authorized to access the application.
2.7 Resource managers
Figure 2-8 Resource managers
Resource validation overview
After the user has been authenticated, RACF controls access to resources. Before the user can access a protected resource RACF makes sure that the user is authorized to use the resource in the intended way (read, update, day, time, and so forth).
RACF can also authorize when a user can access resources, by either time or day as follows:
•A user is identified and verified to the RACF-protected system.
•A user wants to modify an existing RACF-protected resource.
•The user issues a command to the system to access the resource.
•The system resource manager (such as data management) processes the request.
•The resource manager “asks” RACF whether the user can access the resource.
•RACF checks one profile to verify that the user can access the resource and to determine whether the user has the required authorization to modify the contents.
•RACF returns the results of its check to the resource manager.
•The resource manager, based on what RACF indicates, either grants or denies the request.
2.8 System Authorization Facility (SAF)
Figure 2-9 System Authorization Facility (SAF)
System Authorization Facility (SAF)
System Authorization Facility (SAF) is part of the operating system. SAF establishes default security functions when RACF is not active. To enable this, SAF is initialized early in the NIP process. SAF is also the interface between the resource managers and the security product.
Resource managers are responsible for calling SAF to determine whether a user or group is allowed access to the system or resource.
 
Note: The resource manager is responsible for initiation of the authorization check.
Figure 2-9 illustrates the SAF function. Based on the original user’s request, the resource manager formulates a request to SAF. Depending on the request, SAF can respond directly or pass the request to RACF.
 
Note: In either case, the user receives the response from the resource manager.
Examples of resource managers are shown in 2.7, “Resource managers” on page 20.
Token support
SAF also creates and maintains security tokens. A security token is an 80-(decimal) byte packet of security information that is associated to a unit of work. These tokens provide a means by which all work, including input and output, can be identified as it flows around the system.
Information contained in the token includes:
•Port of entry
•Submitting node
•User ID
•Group ID
2.9 RACF classes
Figure 2-10 RACF classes
RACF database
RACF stores information about users, groups and resources in the RACF database. The information is normally kept in storage to enhance performance. The drawback is that this data has to be refreshed when data is changed.
RACF - Administrator
To protect resources the RACF Administrator needs to know in which classes a resource manager keeps the RACF information. This information is normally documented in the reference manuals.
The RACF administrator defines user profiles in the RACF class USER, group profiles in the class GROUP, resource profiles for data sets in the class DATASET and resource profiles for tapes in the class TAPEVOL.
It is possible to define additional classes. You can do this by modifying the Class Descriptor Table and then activating the updated table. The IBM supplied class descriptor table can be found in Appendix A of z/OS Security Server RACF Systems Programmer’s Guide, SA22-7681.
 
Note: The class descriptor table can be updated dynamically.
2.10 Security administration with RACF
Security administration with RACF
The administrator is a user with the SPECIAL user attribute. As the security administrator, you are the focal point for planning security at your installation. You need to:
•Determine which RACF functions to use and how these functions are to be used
•Identify the level of RACF protection
•Identify what resources RACF is to protect
•Identify administrative structures (centralized or decentralized)
•Decide on naming conventions (for example for groups and user IDs)
A RACF security administrator performs the tasks that we describe in this section.
Define RACF system options
The key factor is to understand what RACF functions to use and to use these functions to achieve your security goals. Questions for the security administrator to consider and then set the system wide options accordingly include:
•Data Set Protection for all data sets?
•Resource Protection for which classes?
•Group Structure?
•RACF Tailoring?
•Transparency?
•Recovery?
•Violation Detection?
•Subsystems?
•Networks?
•Data Sharing?
Define user IDs and assign attributes
Individual accountability should be one of your installation’s prime security objectives. RACF offers you the ability to assign each user a unique identifier. (Of course, whether you establish this degree of accountability in all cases is an installation decision.) A RACF user is identified by an alphanumeric user ID that RACF associates with the user. The maximum length of a user ID from RACF’s point of view is eight characters, but the maximum length for TSO is seven characters. Some users have particular tasks and, therefore, have attributes assigned. Some examples of attributes include:
•SPECIAL for a system wide security administrator
•AUDITOR for a person who has overall responsibility to monitor the security guidelines
•REVOKED for a user ID who should be prevented from entering the system
The information about the user is stored in the user profile.
When defining a user it is mandatory to name the default group of the user. Each RACF defined user belongs at least to his default group, but can be a member of multiple groups. Furthermore it is necessary to have an owner of the user profile. Normally the default group is chosen as owner.
Define groups
A user is connected to one or more groups. The information about the group is stored in the group profile. A RACF group normally contains a number of users who share common access requirements. It is important to consider the basic purpose of a group, for example whether it is an administrative group, a holding group, a data control group, a functional group, or a user group? Beyond this consideration, it is necessary to specify the owner of the group.
 
Important: The owner in RACF relates to the profile. The owner of a profile can update the profile.
Define RACF resource profiles
Appropriate protection of resources is an important goal that the security administrator has to achieve. RACF maintains these information entries in resource profiles in the RACF database. It uses them to protect DASD and tape data sets and general resources, such as transactions, programs, or spool output. RACF uses two kinds of resource profiles:
•Data set profiles contain security information about DASD and tape data sets.
•General resource profiles contain security information about general resources.
 
Note: In most cases, multiple resources are protected with a single profile, referred to as generic profiles.
ISPF Panels and commands
You can define most RACF functions using RACF ISPF panels. This interface is very useful for definitions or updates of a small number of entries. If you need to change a large number of entries, then TSO commands, maybe in combination with REXX™, is often a better alternative.
The RACF operator commands allow you to perform functions in the RACF subsystem. You can enter these commands from an operator console. These commands allow an z/OS operator to perform certain RACF operations in the RACF subsystem. The RACF subsystem prefix in front of the command identifies the RACF subsystem as the processing environment. Many RACF commands can be entered using TSO/E.
2.11 RACF user identification and verification
Figure 2-12 RACF user identification and verification
RACF user
As a general objective, all users should be defined to RACF. Users who are not defined to RACF can use the system virtually without verification, unless, of course, they attempt to access data to which they are unauthorized.
You should consider defining the following users to RACF:
•Interactive users of CICS, IMS, TSO/E, NetView®, or other products that support logging on at a terminal
•Users who submit batch jobs
•MVS or JES system operators
•Started procedures
•Node names in an NJE network
•RJP or RJE remote workstations or nodes
User identification
RACF uses an alphanumeric user ID for its user identification. The user ID identifies the person to the system as a RACF user. From a security point of view, the user ID is unique and must not be shared by different users. This uniqueness provides individual accountability.
In a client-server network environment, entities identify themselves using digital certificates. The combination of a serial number and the name of the certificate authority (or issuer's distinguished name) uniquely identifies a client's digital certificate.
User verification
There are different techniques for user verification:
•Use a password phrase or password, something only the user knows
The system-encrypted password or password phrase is character strings that are known only by the user (not even by the security administrator) and, therefore, verifying against the system that the user is the actual person who owns that user ID. This can either be a password that is a maximum of eight characters long or a password phrase that is between nine and 100 characters long. The password can use uppercase or mixed characters.
•Use something only the user has
This verification can be done with the use of a card with a magnetic stripe encoded with unique characters and used to verify the identity of a user to RACF on a z/OS System.
Valid users
Normally, when you define a user to RACF, you assign a user ID and a temporary password. There are exceptions. Therefore, RACF provides the RESTRICTED parameter, which we explain in 2.13, “RACF user attributes” on page 29.
Furthermore, you can have installations exits that expand user verification.
 
Note: It is the installations responsibility to accomplish and monitor security guidelines (for example, unique user IDs and password rules).
2.12 RACF user profile
Figure 2-13 RACF user profile
User profile
RACF stores information in its database. For each defined user ID, RACF keeps a user profile in the class USER. The profile consists of the RACF base segment and optionally additional segments which hold informations related to the different resource manager.
RACF base segment
The RACF base segment contains the following fields:
user ID The user ID is at the same time the name of the profile.
owner The owner of the profile has the authority to change the profile. Every profile in RACF needs an owner.
password The password entry is one-way encrypted. It is not possible to decrypt the password. If a user forgets the password phase or password, the administrator has to set a new temporary password and the user has to change this at the next logon.
attributes This field contains extraordinary attributes. The attributes SPECIAL, OPERATIONS and AUDITOR should be given only to a few selected user IDs. Further information is provided in 2.13, “RACF user attributes” on page 29.
groups A user ID belongs at least to his default group, but can be a member of more groups. This field contains the groups to which the user ID is connected.
security classification Security classification is a further step of security and is described as mandatory security control compared to the discretionary security control.
 
Important: Ownership in RACF is of high importance. The owner of profiles can manipulate the profiles. For example, the owner can change or delete a profile. Your installation needs guidelines that define who is an owner of a profile.
2.13 RACF user attributes
Figure 2-14 RACF user attributes
User attributes
User attributes are extraordinary capabilities, limitations, or environments that can be assigned to a user either system wide or when the user is connected to a specific group or groups. When an attribute is to apply system wide, it is specified at the system level and is called a user attribute. When an attribute is to apply only to a specified group or groups, it is specified at the group level and is called a group-related user attribute.
User attributes that you specify in an ADDUSER or ALTUSER command are stored in the user’s profile and are in effect regardless of the group to which the user is connected. However, attributes that you specify in a CONNECT command are valid only for this group.
The user attributes are as follows:
SPECIAL A user who has the SPECIAL attribute at the system level can issue all RACF commands and, therefore, is used only for special users, for example administrator. This attribute gives the user full control over all of the RACF profiles in the RACF database.
You can assign the SPECIAL attribute at the group level. When you do, the group-SPECIAL user has full control over all of the profiles within the scope of the group.
 
Note: Users with the SPECIAL attribute do not have access to all resources, but they can use commands to give themselves access to all resources.
AUDITOR The AUDITOR attribute is given to users who are responsible for auditing RACF security controls and functions. To provide a check and balance on RACF security measures, you should give the AUDITOR attribute to security or group administrators other than those who have the SPECIAL attribute.
You can assign the AUDITOR attribute at the group level. When you do, the group-AUDITOR user’s authority is limited to profiles that are within the scope of that group.
OPERATIONS A user who has the system wide OPERATIONS attribute has full access authorization to all RACF-protected resources in the classes DATASET, DASDVOL, GDASDVOL, PSFMPL, TAPEVOL, VMBATCH, VMCMD, VMMDISK, VMNODE, and VMRDR classes.
You can assign the OPERATIONS attribute at the group level. When you do, the group-OPERATIONS user’s authority is limited to resources within the scope of that group.
 
Note: Because the OPERATIONS attribute can permit access to a wide range of resources, use this attribute very carefully. In some cases, you need to audit these users.
REVOKE You can prevent a RACF user from entering the system by assigning the REVOKE attribute. This attribute is useful when you want to prevent a user from entering the system, but you can or will not use the DELUSER command because the user still owns RACF resource profiles.
You can also assign the REVOKE attribute on a group level by using the CONNECT command. If the user has the REVOKE attribute for a group, the user cannot enter the system by connecting to that particular group or access resources as a member of that group.
 
Note: RACF allows you to specify a future date for a REVOKE to occur (at both the system and the group level). You can also specify a future date to remove the REVOKE attribute by using the RESUME operand on the ALTUSER command (for example, when you want to inhibit a user from entering the system during a long absence).
CLAUTH Users receive the CLAUTH attribute on a class-by-class basis. You cannot assign the CLAUTH attribute at the user or group level.
If a user has the CLAUTH attribute in a class, RACF allows the user to define profiles in that class.
RESTRICTED You can prevent RACF users from gaining access to protected resources they are not specifically authorized to access by assigning the RESTRICTED attribute on the ADDUSER or ALTUSER command.
PROTECTED You cannot log on to a protected user. This attribute is used mainly for started tasks to prevent a user ID from being revoked due to multiple unsuccessful logon attempts.
WHEN Specifies days of the week and hours of the day during which the user has access to the system.
2.14 RACF user segments
Figure 2-15 RACF user segments
RACF users segments
When you define a user to RACF, you create a user profile in the RACF database. A user profile consists of a RACF base segment and optionally any of the following segments:
•CICS
•DCE
•DFP
•LANGUAGE
•LNOTES
•NDS
•NETVIEW
•OMVS
•OPERPARM
•OVM
•TSO
•WORKATTR
The base RACF segment is the part of the RACF profile that contains the fundamental information about a user, group, or resource and is common to several applications.
The other segments enable resource managers to keep related information.
The number of resource managers using RACF segments is continuously growing.
The following information is kept in the RACF base segment of the user profile:
USERID User’s identification
NAME User’s name
OWNER Owner of the user’s profile
DFLTGRP User’s default group
AUTHORITY User’s authority in the default group
PASSWORD User’s password (one-way encrypted)
PWD PHRASE Optionally a Password Phrase (one-way encrypted)
REVOKE Date on which RACF prevents the user from having access to the system
RESUME Date on which RACF lets the user have access to the system again
UACC Default universal access authority for resources that the user defines
WHEN Days of the week and hours of the day during which the user has access to the system
ADDCATEGORY User’s installation-defined security category
SECLEVEL User’s installation-defined security level
CLAUTH Classes in which the user can define profiles
SPECIAL Gives the user the system-wide SPECIAL attribute
AUDITOR Gives the user the system-wide AUDITOR attribute
OPERATIONS Gives the user the system-wide OPERATIONS attribute
DATA Installation-defined data
ADSP Indicates that all permanent data sets the user creates are to be RACF-protected with discrete profiles
GRPACC Indicates that other group members can have access to any group data set the user protects with a data set profile
MODEL Name of the data set model profile to be used when creating new data set profiles, either generic or discrete
OIDCARD Indicates that the user must supply an operation ID card when logging on to the system
SECLABEL User’s default security label
CERTNAME The names of the profiles in the DIGTCERT class that are related this RACF user ID
CERTLABL The certificate labels associated with the profiles in the DIGTCERT class that are related to this RACF user ID
2.15 RACF user ID and password
Figure 2-16 RACF user ID and password
RACF user ID passwords
User identification is achieved using the user ID, which is a string of characters that uniquely identifies a user to a system.
In RACF, users select their own password (and optionally a password phrase) and only the user knows these values. If a password or password phrase needs to be reset, the security administrator either resets it to the default or sets a temporary password (and optionally a password phrase). This profile is normally in an expired state, thus forcing the user to enter a new password or password phrase on the first logon.
You can set a variety of rules for forming valid passwords, using the SETROPS command (for system-wide settings) or the PASSWORD command (to affect only one user). You can change such things as the number of days a password is valid, how long to maintain password history to prevent the user from reusing the same password again, and so on.
The syntax rules for password phrases are “hard coded” but can be controlled by use of an exit.
The password and password phrase is one-way encrypted using a DES algorithm. The key being used is the password itself. The encrypted password and password phrase are stored in the user profile.
Alternatives to password verification
Alternative to password verification include:
1. RACF allows workstations and client machines in a client-server environment to use a PassTicket in place of a password. A PassTicket can be generated by an authorized routine in z/OS or on any other platform. The creator of the PassTicket and the verifier of the PassTicket must share a “common secret.” In addition the creator and verifier must have the same user ID, Application Name, and time. The PassTicket is valid for +/- 10 minutes. You can enforce that a PassTicket is only valid for one logon.
2. RACF allows the use of an operator identification card (OIDCARD) in place of, or in addition to, the password during terminal processing. By requiring that a person not only know a password but also furnish an OIDCARD, an installation has increased assurance that the user ID was entered by the proper user.
3. z/OS UNIX users are also identified with numeric user identifiers (UIDs), and z/OS UNIX groups are identified with numeric group identifiers (GIDs). Unlike user names or group names, these numeric IDs can be shared by more than one user. However, this practice is not recommended.
4. In a client/server environment, RACF can identify a RACF user ID by extracting information from the digital certificate. A digital certificate or digital ID, issued by a certifying authority, contains information that uniquely identifies the client.
5. The Lotus® Domino® Go Web server authenticates a client using the client’s certificate and the Secure Sockets Layer (SSL) protocol. Domino Go Web server passes the client’s digital certificate to z/OS UNIX for validation. z/OS UNIX passes the certificate to RACF. Thus, the RACF user ID and password of each client do not need to be supplied when accessing secure Web pages.
2.16 Adding a new user to RACF
Figure 2-17 Adding a new user to the RACF database
How to add a user
When you define a user’s profile (using the ADDUSER command) or change a user’s profile (using the ALTUSER command), you can specify the information contained in each field of each segment of the profile.
The command adds a profile for the new user to the RACF database and creates a connect profile that connects the user to whichever default group you specify. The user profile consists of a RACF segment and, optionally, other segments such as a TSO segment, a DFP segment, or an OMVS segment. You can use this command to define information in any segment of the user’s profile.
Figure 2-17 shows sample output from the following ADDUSER command when the LISTUSER is issued:
ADDUSER JAMES NAME('BROWN JAMES') DFLTGRP(MFG)
OWNER(ADMUSERS) PASSWORD(NEW2DAY)
This command adds a new user ID, JAMES, into default group, MFG.
2.17 Reset a user password
Figure 2-18 Resetting a password
Reset a user password
A system administrator is often asked to reset a user’s password. There are two common reasons for resetting a password:
1. The user forgot the password (or made too many errors when attempting change it).
2. The user ID was REVOKED for some reason.
You can use the RACF ISPF panels to reset passwords but it is easier to use the following commands:
PASSWORD When used to reset another user’s password, the only option is to set the password equal to the user’s default group name. The default group name is often SYS1. So, if the PASSWORD command is used to reset a user’s password, the password is probably SYS1, which has obvious security consequences.
ALTUSER You set the password phrase or the password. You can also specify whether the user must specify the passwords again. This is indicated by EXPIRED or NOEXPIRED.
In both cases, the password is marked automatically as expired, by default. Thus, the user is forced to select a new password when logging on to the system the next time. With the ALU command, you can also set an unexpired password, which is password one that the user can use until changing it for some reason.
Before resetting a password, we suggest that you always use the LISTUSER command to verify that the user definition exists and to determine if the user is REVOKED. For example, we can use this command:
ALU martin RESUME PASS(newpwd) <== if REVOKED
ALU martin PASS(newpwd) <== if not REVOKED
ALU martin PASS(newpwd) NOEXPIRED <== if not REVOKED

PASSWORD NOINTERVAL USER(martin) <== if you want this
You need to tell Martin the new password that you assigned. Martin needs the new password to log on but is forced to change the password immediately to a password of his own selection (unless you used the NOEXPIRED option). The PASSWORD NOINTERVAL command prevents this user’s password from ever expiring. You need SPECIAL authority to issue these commands.
How to reset a password with ISPF panels
You can also use the RACF ISPF panels to change or reset passwords. The end result is the same as using the direct commands discussed previously.
The path to the appropriate RACF ISPF panels is:
ISPF Primary Option Menu
RACF (select RACF from the primary ISPF menu)
RACF - Services Option Menu
User Profiles and Your Own Password
RACF - User Profile Services
CHANGE (and enter target userid in the USER field)
When the panel shown in Figure 2-19 displays, carry on from this point.
Figure 2-19 RACF CHANGE USER menu
Remember that the password that you assign must be changed by the user when that user logs on to the system the next time. You can use this same panel, and other panels that displays after you press Enter, to change the same elements as the ALTUSER command.
2.18 Alter a user ID
Figure 2-20 Altering a user ID
How to alter a user ID segment
Use the ALTUSER command to change the information in a user’s profile, including the user’s system-wide attributes and authorities. The user profile consists of a RACF segment and, optionally, other segments such a TSO segment or a DFP segment. You can use this command to change information in any segment of the user’s profile.
When you change a user’s level of authority in a group (using the AUTHORITY operand), RACF updates the appropriate group profile. When you change a user’s default universal access authority for a group (using the UACC operand), RACF changes the appropriate connect profile. For all other changes, RACF changes the user’s profile.
Figure 2-20 shows sample output from the following ALTUSER command which adds the attribute of AUDITOR to the user ID ROGERS:
ALTUSER ROGERS AUDITOR
2.19 Change a user’s password interval
Figure 2-21 Changing a user’s password interval
How to a change a user’s password interval
The interval indicates the number of days during which a password remains valid. The range is from one through 254 days.
The value that you specify here cannot exceed the value, if any, that your installation has specified using the INTERVAL operand on the SETROPTS command. The initial system default after RACF initialization is 30 days.
If you specify INTERVAL on the PASSWORD command without a change-interval value, RACF uses the installation-specified maximum.
Figure 2-21 shows sample output from the following PASSWORD command, which sets the password expiration date for user ID James to 60 days:
PASSWORD USER(JAMES) INTERVAL(60)
Overriding any system default password expiring setting is set by the SETROPTS command.
2.20 Delete a user ID
Figure 2-22 Deleting a user from the RACF database
How to a delete a user
Use the DELUSER command to delete a user from RACF. This command removes the user’s profile and all user-to-group connections for the user. (The connect profiles define the user’s connections to various RACF groups.)
There are, however, other places in the RACF database where the user’s user ID might appear. The DELUSER command does not delete the user ID from all these places. Specifically, the user could be the owner of a group, the owner of a user’s profile, the owner of a group data set, or in an access list for any resource. Before issuing DELUSER, you must first issue the REMOVE command to assign new owners for any group data sets the user owns in groups other than his default group. You can use the RACF Remove ID utility (IRRRID00) to remove all of the occurrences of a user ID. For information about using the RACF Remove ID utility, see z/OS Security Server RACF Security Administrator's Guide, SA22-7683.
To use the DELUSER command, at least one of the following must be true:
•You must have the SPECIAL attribute.
•The user profile to be deleted must be within the scope of a group in which you have the group-SPECIAL attribute.
•You must be the owner of the user’s profile.
Figure 2-22 shows sample output from the following DELUSER command, which deletes the user ID James.
DELUSER JAMES
2.21 User related RACF commands
Figure 2-23 User-related RACF commands
RACF commands
You define users to RACF by issuing RACF commands that include various user attributes, as well as other control information that RACF uses. Some of the commands that you might use in your user-definition tasks include:
ADDUSER Add a user profile to RACF.
ALTUSER Change a user’s RACF profile.
CONNECT Connect a user to a group.
DELUSER Delete a user profile from RACF and remove connection to a group.
REMOVE Remove a user from a group and assign a new owner for group data sets owned by the removed user.
LISTUSER Display the contents of a user’s profile.
PERMIT Permit a user to access a resource (or deny access to a resource).
PASSWORD Change a user’s password.
In addition to defining individual users, you can define groups of users. Group members can share common access authorities to a protected resource.
2.22 RACF groups
Figure 2-24 RACF groups
RACF groups
With RACF, all defined users belong to at least one group. You can think of the groups forming a hierarchical, or “tree” structure, where each group is owned by a superior group. Groups can also own resources as well as users in another group.
RACF has the following types of groups:
Administrative You can create a group simply as an administrative convenience. For example, you might create a group to represent an organizational entity, such as a region or a division. With RACF delegation, you can create this kind of group for each group administrator. Operating from such groups, the group administrators can then define other groups needed by their local users.
Holding This is a technique that retains user definition centrally, yet allows the effective use of group administrators to establish a holding group. You define all users centrally and initially connect them to a group named HOLD with the minimum of authorities. HOLD does not appear in any access lists and, therefore, has no real significance to the user.
Group administrators, to whom you give CONNECT (but not JOIN) authority, can connect the appropriate users to the groups under their control and change the user’s default group name as appropriate. This technique allows the installation to assign correct account numbers and control other installation considerations while allowing flexibility in the grouping of the user population.
Data Control You can create a group to act as a control point for the protection of data. For example, by using the group SYS1, you can determine which users are permitted to protect the SYS1 data sets. Only users with CREATE authority or higher in this group can protect system data sets. At your location, you might consider defining one such group for every high level qualifier representing data that is to be protected.
Functional A group can represent a functional area of the installation for the purpose of data sharing. For example, a financial analyst might need to access a variety of resources across many groups, such as accounting, payroll, marketing, and others. Of course, the owners of each resource could permit the financial analyst to access their resources by placing the analyst’s user ID on an access list. But if a new financial analyst takes over the job, it is then necessary to add the new user ID to each RACF profile. Likewise, the RACF profiles must be updated when the analyst no longer has a need to access the data. This arrangement involves a great deal of unnecessary activity by the resource owners.
Instead, you can create a group that represents the financial analyst function and permits access to the data defined to the group. Access to the entire range of data can then be managed by controlling the user population in the defined group. For cases involving one-time access, owners of the needed data would simply PERMIT access by the defined group. Where appropriate, the group name could be included in profile access lists to ensure automatic availability of needed data to the financial analyst group. New financial analysts could be connected to the group, as required, to gain access to the entire range of data. Likewise, analysts could be removed from the group whenever necessary. By controlling the user population of such a functional group, resource profile changes on a day-to-day basis becomes unnecessary.
User You can define a group to serve as an anchor point for users who otherwise have no common access requirements. For example, engineers and scientists, as well as other problem-solving users, might have no need to access application-related data in the system. Their only interest might be in their own personal data. You can place this set of users in a single group that has no access to other data.
You can also define groups based on access level. For example, if PAY.DATA is a RACF-defined data set, two groups could be defined, PAYREAD and PAYUPDTE, both of which would appear in the PAY.DATA access list, but with READ and UPDATE access, respectively. Any users requiring access would be connected as appropriate, by the group administrator.
2.23 RACF group structure example
Figure 2-25 RACF group structure example
RACF group structure
The group structure of RACF can be mapped to the organizational structure that exists at your installation. That is, RACF conforms naturally to a tree structure of groups, where each group (except SYS1, which is predefined as the highest group) has a superior, or owning, group. Groups can correspond directly to business entities such as divisions, departments, and projects. Users can be connected to one or more groups.
When you define a group, consider the basic purpose of the group. Is it an administrative group, a holding group, a data control group, a functional group, or a user group? When setting up RACF groups, keep in mind that the maximum number of users that you can connect to any one group is approximately 5900.
You should map your groups to your organization’s structure and arrange them hierarchically, with the IBM-supplied SYS1 group as the highest group, so that each group is a subgroup of another group.
A user can be connected in more than one group (in Figure 2-25, SALLY is connected to MFG and TEST groups).
In Figure 2-25, GROUP, DESIGN, TEST, and MFG are all owned by group POU. Tom is connected to group POU as special, which gives Tom (who is the RACF administrator) control over all POU resources DESIGN, TEST, and MFG.
2.24 RACF group related commands: Add a group
Figure 2-26 Add a group
How to add a group
Use the ADDGROUP command to define a new group to RACF. The command adds a profile for the new group to the RACF database. It also establishes the relationship of the new group to the superior group you specify.
Group profiles consist of a RACF segment and, optionally, other segments such as DFP and OMVS. You can use this command to specify information in any segment of the profile.
To use the ADDGROUP command, you must meet at least one of the following conditions:
•Have the SPECIAL attribute
•Have the group-SPECIAL attribute and the superior group is within your group-SPECIAL scope
•Be the owner of the superior group
•Have JOIN authority in the superior group
Figure 2-26 shows sample output from the ADDGROUP command, adds a new group named EXPED and is a subgroup to group POU:
ADDGROUP EXPED OWNER(ADMGRPS) SUPGROUP(POU)
2.25 RACF group related commands: Alter a group
Figure 2-27 Alter a group
How to alter a group
Use the ALTGROUP command to change:
•The superior group of a group
•The owner of a group
•The terminal indicator for a group
•A model profile name for a group
•The installation-defined data associated with a group
•The default segment information for a group (for example, DFP or OMVS)
To change the superior group of a group, you must meet at least one of the following conditions:
•You must have the SPECIAL attribute
•All the following group profiles must be within the scope of a group in which you have the group-SPECIAL attribute:
 – The group whose superior group you are changing
 – The current superior group
 – The new superior group
•You must be the owner of, or have JOIN authority in, both the current and the new superior groups.
 
Note: You can have JOIN authority in one group and be the owner of, or have the group-SPECIAL attribute in, the other group.
Figure 2-27 shows sample output from the ALTGROUP command, which moves the group named EXPED from being a subgroup of group PGN to a subgroup to group KGN:
ALDGROUP EXPED SUPGROUP(KGN)
2.26 RACF group related commands: Delete a group
Figure 2-28 Delete a group
How to delete a group
Use the DELGROUP command to delete a group and its relationship to its superior group from RACF.
There are, however, other places in the RACF database where the group name might appear, and DELGROUP processing does not delete these other occurrences of the group name. For example, the group name could be in the access list for any resource. You can use the RACF Remove ID utility (IRRRID00) to remove all occurrences of a group name. For information about using the RACF Remove ID utility, see z/OS Security Server (RACF) Security Administrator’s Guide, SA22-7683.
Figure 2-28 shows sample output from the DELGROUP command, which deletes the EXPED group:
DELGROUP EXPED
2.27 Connect a user to a group
Figure 2-29 Connecting a user to a group
How to connect a user to a group
Use the CONNECT command to connect a user to a group, modify a user’s connection to a group, or assign the group-related user attributes. If you are creating a connection, defaults are available as stated for each operand. If you are modifying an existing connection, no defaults apply.
To use the CONNECT command, one of the following conditions must be true:
•The SPECIAL attribute
•The group-SPECIAL attribute in the group
•The ownership of the group
•JOIN or CONNECT authority in the group
Figure 2-29 shows sample output from the CONNECT command, which connects user James to group TEST:
CONNECT JAMES GROUP(TEST)
2.28 Remove a user from a group
Figure 2-30 Removing a user from a group
How to remove a user from a group
You can use the REMOVE command to remove a user from a group, and to assign a new owner to any group data set profiles the user owns on behalf of that group.
To use the REMOVE command, one of the following conditions must be true:
•The SPECIAL attribute
•The group-SPECIAL attribute in the group
•The ownership of the group
•JOIN or CONNECT authority in the group
Figure 2-30 shows sample output from the following REMOVE command:
REMOVE JAMES GROUP(TEST)
2.29 Data sets and general resources
Figure 2-31 Data sets and general resources
Controlling access to resources
To protect a general resource, create a general resource profile using the RDEFINE command. When you create a general resource profile, you must specify a general resource class for the profile. IBM supplies a list of the general resource classes in the class descriptor table (CDT). The classes for z/OS systems are relevant to the system on which you are running the z/OS Security Server (RACF).
RACF-protected resources can be divided into two categories: data sets and general resources. General resources are all of the resources that are defined in the class descriptor table. For example, general resources include DASD and tape volumes, load modules (programs), terminals, and others.
RACF allows the installation to set its own rules for controlling the access to its resources by defining what is controlled at what level. The installation can tailor RACF to interact with its present operating environment and assign security responsibilities either on a system-wide or a group-wide basis.
Your installation can add new class descriptor table (CDT) entries or modify or delete existing entries that you have added in the installation-defined class descriptor table (ICHRRCDE). When you define a new resource class, you can optionally designate that class as either a resource group class or a resource member class. For a resource group class, each user or group of users that is permitted access to that resource group is permitted access to all members of the resource group. Note that for each resource group class you create, you must also create a second class that represents the members of the group.
It is possible to define dynamic class descriptor table (CDT) entries. This is done by defining profiles in the CDT class. Profiles in this class have a CDTINFO segment which contains all the parameters that could be defined in the installation-defined class descriptor table (ICHRRCDE).
2.30 Data sets and general resources
Figure 2-32 Resource profiles
Resource profiles contain:
•The owner of the profile
•The auditing parameters
•The Universal Access authority
•An access list with users and groups
•A “Warning” indicator
•A security classification
•A real-time notification information
•An erase-on-scratch indication for data sets
•A volume and a unit (if data set)
•A security retention period (if tape data set)
•Access statistics
2.31 Data set profiles
Figure 2-33 Locating a resource profile
RACF data sets and general resources
To locate a resource profile:
•RACF looks for a discrete profile, if no discrete profile is found.
•RACF looks for a generic profile and will then use the most qualified generic profile available.
See z/OS Security Server (RACF) Security Administrator's Guide, SA22-7683, for more detail about how this process works.
Some of the generic profile naming for general resources has been enhanced with some of the same concepts as generics for data set profiles as valid generic characters as follows:
* You can have an asterisk (*) within a profile name, representing one qualifier of a resource name, or specify * in the profile name to match more than one character in the same position of the resource name.
** You can also use a double asterisk (**) to represent zero or more qualifiers within a general resource generic profile or at the end of such a profile, or specify ** in the profile name to match more than one character in the same position of the resource name. Use of the double asterisk (**) in general resource generic profiles is not controlled by the SETROPTS EGN option, which applies only to the data set profiles.
% Specify % any single non-blank character (except a period) in the same position of the resource name
Choosing between discrete and generic data set profiles
Decide which type of profile to create as follows:
•Generic
Choose a generic profile for the following reasons:
 – If you want to protect more than one data set with the same security requirements.
 – If you have a single data set that might be deleted, then re-created, and you want the protection to remain the same, you can create a fully qualified generic profile. The name of a fully qualified generic profile matches the name of the data set it protects. Unlike a discrete profile, a fully qualified generic profile is not deleted when the data set itself is deleted.
•Discrete
Choose a discrete profile for the following reasons:
 – To protect one data set that has unique security requirements. The name of a discrete profile matches the name of the data set it protects.
 – To allow changes to a data set profile to take effect immediately, without needing to refresh in-storage copies of the profile.
In Figure 2-33, a resource manager issues a security check for the data set SALES.YEARLY.QUOTA. Three different types of profiles can be defined in the RACF database:
•A discrete profile
•A fully qualified generic profile
•The most specific generic profile
The example shows that RACF looks for a profile in the order shown. If no discrete profile is found, check for a fully qualified profile. If not found, then find the most specific generic profile, which is the second one in the example, SALES.YEARLY.%%%%%.
 
Note: By using generic profiles, your installation can reduce both the number of profiles that are required to protect data sets and the size of the RACF database, thus making RACF protection easier to administer. In addition, generic profiles are loaded into storage when first needed, are not deleted when the data set they protect is deleted, and are not volume-specific (that is, data sets protected by a generic profile can reside on any volume).
You can create a profile with a generic name when the following is true for the class of the profile:
SETROPTS GENERIC(DATASET) option is in effect.
This option allows the creation of generic profiles and also causes RACF to use generic profiles during authorization checking.
2.32 Defining data set profiles
Figure 2-34 Defining data set profiles
Defining data set profiles
Use the ADDSD command to add RACF protection to data sets with either discrete or generic profiles.
The ADDSD command adds a profile for the data set to the RACF database to control access to the data set. It also places the user ID on the access list and gives ALTER authority to the resource unless SETROPTS NOADDCREATOR is in effect.
Data set profiles
By default, RACF expects a data set name (and the data set profile name) to consist of at least two qualifiers. RACF also expects the high-level qualifier of the data set profile name to be either a RACF-defined user or a RACF-defined group name.
Each data set profile defined to RACF requires a RACF-defined user or group as the owner of the profile. The owner (if a user) has full control over the profile, including the access list.
If the owner of the data set profile is a group, users with group-SPECIAL in that group have full control over the profile.
Ownership of data set profiles is assigned when the profiles are defined to RACF. Note that ownership of a data set profile does not mean that the owner can automatically access that data set. To access a data set, the owner must still be authorized in the profile’s access list, unless the high-level qualifier of the profile name is the owner's user ID.
Data set profile examples
The ADDSD command in Figure 2-34 specifies that no users have access to the data set except the creator of the profile, because the universal access, UACC, is none.
To allow users to have access to the data set, the PERMIT command shown specifies that user ID JANE has only READ access to the data set, ACC(READ). User ID JANE exists in the access list for the data set profile using the PERMIT command.
2.33 Data set profile access list
Figure 2-35 Data set profile access list
Data set profile access list
When a user requests access to a RACF-protected resource (such as a data set), the resource manager issues a RACF authorization request. RACF then performs two checks.
Using the PERMIT command maintains a list of users and groups authorized to access a particular resource. RACF provides two types of access lists:
Standard The standard access list includes the user IDs and group names authorized to access the resource and the level of access granted to each.
Conditional The conditional access list includes the user and group names authorized to access the resource and the level of access granted to each when a certain condition is met.
Types of access levels
Types of access levels include:
ALTER ALTER allows users to read, update, delete, rename, move, or scratch the data set.
When specified in a discrete profile, ALTER allows users to read, alter, and delete the profile itself including the access list.
ALTER does not allow users to change the owner of the profile using the ALTDSD command. However, if a user with ALTER access authority to a discrete data set profile renames the data set, changing the high-level qualifier to his or her own user ID, both the data set and the profile are renamed, and the OWNER of the profile is changed to the new user ID.
When specified in a generic profile, ALTER gives users no authority over the profile itself.
NONE The specified user or group is not permitted to access the resource or list the profile.
EXECUTE For a private load library, EXECUTE allows users to load and execute, but not to read or copy programs (load modules) in the library.
READ Allows users to access the data set for reading only. (Note that users who can read the data set can copy or print it.)
UPDATE Allows users to read from, copy from, or write to the data set. UPDATE does not, however, authorize a user to delete, rename, move, or scratch the data set.
CONTROL For VSAM data sets, CONTROL is equivalent to the VSAM CONTROL password; that is, it allows users to perform improved control interval processing. This is control-interval access (access to individual VSAM data blocks), and the ability to retrieve, update, insert, or delete records in the specified data set. For non-VSAM data sets, CONTROL is equivalent to UPDATE.
2.34 Add a data set profile
Figure 2-36 Add a data set profile
How to add a data set profile
When you define data set profiles to RACF, you can use either standard or nonstandard naming conventions. If you use nonstandard naming conventions, the data set naming convention table and the single-level data set names option are ways to help “fit” RACF standard naming conventions.
The descriptions of naming conventions are followed by rules for protecting and allocating user and group data sets.
By default, RACF expects a data set name (and the data set profile name) to consist of at least two qualifiers. RACF also expects the high-level qualifier of the data set profile name to be either a RACF-defined user or a RACF-defined group name.
This command added a generic profile for data sets with a high level qualifier of JAMES.*. The asterisk (*) character is a valid generic character for more than one character in this position.
ADDSD 'JAMES.*'
Figure 2-36 shows sample output from the LISTDSD command.
2.35 Alter a data set profile
Figure 2-37 Alter a data set profile
How to alter a data set profile
Use the ALTDSD command to:
•Modify an existing discrete or generic data set profile.
•Protect a single volume of either a multivolume tape data set or a multivolume, non-VSAM DASD data set. At least one volume must already be RACF-protected.
•Remove RACF-protection from either a single volume of a multivolume tape data set or a single volume of a multivolume, non-VSAM DASD data set. You cannot delete the last volume from the profile.
Figure 2-37 shows the output for the following command to alter the auditing options for the previously data set, JAMES.*:
ALTDSD'JAMES.*' AUDIT(S(U),F(R))
The command also specifies which new access attempts you want to log to the SMP data set.
SUCCESS S(U) Indicates that you want to log authorized accesses to UPDATE
FAILURES F(R) Indicates that you want to log detected unauthorized access attempts to read
Figure 2-37 shows a sample output from the ALTDSD command, which shows the auditing options as:
SUCCESS(UPDATE),FAILURE(READ)
2.36 Search RACF database using a mask
Figure 2-38 Search the RACF database
List a data set profile matching a mask
The SEARCH command obtains a list of RACF profiles, users, and groups from the RACF DATABASE using search criteria specified.
MASK specifies the strings of alphanumeric characters used to search the RACF database. This data defines the range of profile names selected. The two-character strings together must not exceed 44 characters for a tape or DASD data set name, or, for general resource classes, the length specified in the class descriptor table.
The visual shows a SEARCH command with the search criteria, MASK.
SEARCH MASK(JAMES) CLASS(DATASET)
This command allows RACF to list profiles starting with the MASK, in this case JAMES.
A second example allows RACF to list all profiles containing the filter string.
SEARCH FILTER(JAMES) CLASS(DATASET)
2.37 Data set related commands
Figure 2-39 List a data set
List a cataloged data set
Figure 2-39 shows sample output from the following LISTDSD command, which allows RACF to list data sets protected by a profile (in this case, the JAMES.* data set profile):
LISTDSD'JAMES.*'DSNS
DSNS specifies that you want to list the cataloged data sets protected by the profile specified in the DATASET, ID, or PREFIX operand.
2.38 Data set related commands
Figure 2-40 List who has access to a data set
List who has access to a data set profile
Figure 2-40 shows sample output from the following PERMIT command:
PERMIT 'JAMES.*' ID(BILL,DESIGN) ACCESS(UPDATE)DSNS
This command allows Bill and the DESIGN group update access to the files protected by the James.* data set profile. Mark, Laurie, and Walt part of the DESIGN group will have UPDATE access, unless the access list contains their user ID with another level of access.
PERMIT 'JAMES.*' ID(PAT) ACCESS(READ)DSNS
Pat has read access to the files that are protected by the JAMES.* profile.
2.39 General resources related commands
Figure 2-41 Add a general resource profile
How to add a general resource profile
Figure 2-41 shows sample output from the following RDEFINE command, which defines a new resource profile called MYMUSIC that will run in PROGRAM class:
RDEF PROGRAM MYMUSIC ADDMEM('JAMES.PGMLIB'/VOL123/NOPADCHK)
The program MYMUSIC is located in JAMES.PGMLIB member on DASD volume VOL123.
Setting NOPADCHK means that RACF will not check for program-accessed data sets when a user is executing the control programs.
2.40 General resources related commands
Figure 2-42 Change universal access authority
How to change universal access authority
Figure 2-42 shows sample output from the following RALTER command, which sets the Universal Access Authority (UACC) to read:
RALT PROGRAM MYMUSIC UACC(READ)
The UACC is the default access to a resource if the user or group is not specifically permitted access to the resource. The ALTER command has set the default access of MYMUSIC at READ.
2.41 General resources related commands
Figure 2-43 Permit access to a resource
How to permit access to a resource profile
Figure 2-43 shows sample output from the PERMIT command:
PERMIT MYMUSIC CLASS(PROGRAM) ID(MARVIN) ACCESS(NONE)
Despite the UACC(READ) on the resource profile, MARVIN cannot access the resource because NONE is specified in the access list.
2.42 SET RACF system options
SETROPTS command
RACF provides many system-wide options for controlling the way it works on your system. You specify most of these options by issuing the SETROPTS command with the appropriate operands. One example is to set the system-wide valid password interval:
SETROPTS PASSWORD INTERVAL(30)
The INTERVAL suboperand specifies the system default for the number of days that the user’s password is to remain valid. The example specifies that each user’s password remains valid for 30 days.
CLASSACT parameter
When you install a new RACF system, initially only a few RACF classes are active (for example USER, GROUP, and DATASET), other classes (for example TAPEVOL and TSOPROC) are inactive. For example, if you want your tape volumes to be protected by RACF, you have to activate the TAPEVOL class using the following command:
SETROPTS CLASSACT(TAPEVOL)
RACLIST REFRESH parameter
The system options are stored in the RACF database and if your installation has activated SETROPTS RACLIST processing for a particular resource class, the information is stored in in-storage profiles too. Using the SETROPTS command with the REFRESH parameter allows these profiles to be updated dynamically.
The following example updates the profile in the class TSOPROC dynamically:
SETROPTS RACLIST(TSOPROC) REFRESH
Authorization
The SETROPTS command is very powerful and, therefore, most of the options require the SPECIAL attribute.
 
Note: For further information about the required authority, refer toz/OS Security Server RACF Command Language Reference, SA22-7687. The description for each RACF command contains a heading called Authorization Required.
The following pages show some examples (but not all) of system-wide settings. They are grouped to:
•STATISTIC related options
•PASSWORD options
•Data set related options
•CLASS related options
•AUTHORIZATION Checking options
•TAPE related options
•Other initial setup related options
•Security Label related options
•AUDITOR related options
2.43 Statistic related options
An installation can record two types of RACF statistics:
•STATISTICS, which records access to resources in specific classes that are protected by discrete profiles
•INITSTATS, which records user logon information
Activating statistics collection (STATISTICS option)
For some reasons (for example if a specific resource has unique security concerns and, therefore, is protected by a discrete profile) it might be useful to have statistic data about a resource concerning how that resource is being accessed and how many times it is being accessed. The SETROPTS STATISTICS options provides this information. RACF maintains two sets of statistics in a discrete resource profile. One set counts all activity for the resource or profile. The other set counts activity for each entry in the access list. The following command turns STATISTICS on for the resources in the class TSOPROC:
SETROPTS STATISTICS(TSOPROC)
 
Attention: Remember that the initiation of STATISTICS is system-wide for all discrete profiles within a particular resource class across your system. Depending on the number of discrete profiles in the various resource classes, turning on STATISTICS can negatively affect performance.
When a new RACF database is initialized, the default is STATISTICS off (NOSTATISTICS) for all classes.
 
Tip: It is recommended that you keep STATISTICS off until your installation has had an opportunity to evaluate the need for STATISTICS versus the potential impact on performance.
For details seez/OS Security Server RACF Systems Programmer’s Guide, SA22-7681.
Activating statistics for user verification (INITSTATS option)
When a new RACF database is initialized, the default is INITSTATS on. INITSTATS records statistics on all user profiles in the system.
 
Note: Although INITSTATS affects performance because of I/O to the database, it is recommended that INITSTATS stays on, because it allows you to use other options to provide additional security at logon.
INITSTATS is required if your installation wants to take advantage of the following options:
•SETROPTS INACTIVE option
•SETROPTS PASSWORD option with parameter REVOKE, HISTORY, and WARNING
Revoking unused user IDs (INACTIVE option)
The INACTIVE operand of the SETROPTS command causes RACF to revoke the user’s right to use the system if the user ID has remained unused beyond a specified number of days. The following command causes RACF to revoke a user ID if it is unused for over 30 days:
SETROPTS INACTIVE(30)
If you issue the SETROPTS INACTIVE(30) command and if a user has not done any of the following activities in 31 days, that user is considered revoked:
•Logged on
•Submitted a job
•Changed the user’s password by any method
•Attempted an unsuccessful logon
•Received a directed command or output from RACF
The INACTIVE option applies also to new RACF defined user IDs if the new user ID is not used within the number of days specified by SETOPTS INACTIVE.
 
Note: The user is not actually revoked. RACF revokes the user the next time the user attempts to enter the system.
2.44 Password related options
SETROPTS PASSWORD
The examples in this section show some of the SETROPTS PASSWORD parameter, which gives you the possibility to specify system-wide options regarding passwords. An optional password phrase can be used. Most of the information for password also controls password phrases.
Allowing mixed-case passwords
By default, NOMIXEDCASE is in effect and mixed-case passwords are not supported. Mixed-case passwords are more secure and harder to guess than uppercase passwords. You can allow mixed-case passwords with the following command.
SETROPTS PASSWORD(MIXEDCASE)
 
Attention: If you want to allow mixed-case passwords, be sure that mixed-case content is permitted by your password syntax rules.
 
Note: z/OS 1.7 is the first release that supports mixed-case passwords. If you share the RACF database with downlevel systems that do not support mixed-case RACF passwords or if you use a mix of applications that do and do not support mixed-case passwords, do not activate the SETROPTS PASSWORD(MIXEDCASE) option.
Establishing syntax rules
You can establish up to eight password syntax rules to verify that new passwords meet the installation standards. These rules allow you to control:
•The minimum and maximum length of passwords
•The character content of installation-selected positions in the passwords
 
Note: Your changes will take effect for current users only when they change their passwords. For new users, the changes will take effect when the new user logs on for the first time.
Setting the maximum and minimum change interval
The INTERVAL suboperand specifies the system default for the maximum number of days that a user’s password is to remain valid. The MINCHANGE suboperand specifies the system default for the minimum number of days that must pass between a user’s password changes. To specify that each user’s password remains valid for 45 days and that no user can change passwords more often than every sever days, use the following command:
SETROPTS PASSWORD(INTERVAL(45) MINCHANGE(7))
 
Note: z/OS 1.7 is the first release that supports MINCHANGE. The installation default is zero (0) days for minimum change interval. The value MINCHANGE(0) allows users to change passwords more than once each day.
Extending password and user ID processing
The WARNING suboperand specifies when RACF issues a password expiration message each time a user logs on to TSO or submits a batch job with a password within a specified number of days (in the following example, five days) before the password expires:
SETROPTS PASSWORD(WARNING(5))
The HISTORY suboperand specifies the number of previous passwords (in the following example, 10) that RACF saves and compares with an intended new password:
SETROPTS PASSWORD(HISTORY(10))
REVOKE specifies how many consecutive password verification attempts RACF permits before it revokes a user ID on the next attempt:
SETROPTS PASSWORD(REVOKE(3))
 
Note: Option INITSTATS is prerequisite of the options WARNING, HISTORY, and REVOKE.
2.45 Data set related options
Enhanced generic naming for the DATASET class (EGN option)
When you first initialize the RACF data base, enhanced generic naming is not in effect (NOEGN). Using the following command so that RACF allows you to specify the generic character, double asterisks (**), in addition to the generic characters, asterisk (*) and percentage (%).
SETROPTS EGN
 
Note: IBM strongly recommends that you do not deactivate enhanced generic naming after data set profiles have been created while enhanced generic naming was active.
RACF-protecting all data sets (PROTECTALL option)
If PROTECTALL is active, a user can create or access a data set only if the data set is RACF-protected. Use the following command to activate this option:
SETROPTS PROTECTALL
 
Note: Before activating this option, activate generic profile checking also for the DATASET class as shown in the following command:
SETROPTS GENERIC(DATASET)
PROTECTALL also has a warning option that allows the request even though the data set is not protected but sends a warning message to the user and the MVS console. For example:
SETROPTS PROTECTALL(WARNING)
For further considerations on the PROTECTALL option, see z/OS Security Server RACF Security’s Administrator’s Guide, SA22-7683.
Bypassing automatic data set protection (NOADSP option)
With the installation default ADSP operand in effect, RACF creates discrete data set profiles automatically when users who have the ADSP attribute create new data sets.
 
Note: We recommend the NOADSP option because it reduces the number of data set profiles in the RACF database. Using generic data set profiles is generally more efficient.
You can change the installation default using the following command:
SETROPTS NOADSP
Preventing access to uncataloged data sets (CATDSNS option)
You can use the CATDSNS operand of the SETROPTS command to keep users who do not have the SPECIAL attribute from gaining access to data sets that DFP controls. These data sets include system temporary data sets and data sets that are not cataloged. Users cannot read data sets from tape, and they cannot read from or write to DASD data sets.
 
Note: Because of the big impact this option can have on data processing, it might be reasonable to specify CATDSNS(WARNING) before you plan to activate it in failure mode.
Displaying and logging real data set names (REALDSN option)
Putting the REALDSN option into effect ensures that log printouts and operator messages identify data sets by their real names rather than by the data set names that are created by installation exit routines to conform to RACF naming conventions.
Protecting data sets with single-qualifier names (PREFIX option)
If your installation has data sets names consisting of only a single qualifier (that is, single-level names) and if you want RACF to protect this data set, you have to specify the PREFIX option:
SETROPTS PREFIX(myhlq)
RACF internally modifies single-qualifier names by adding the high-level qualifier (in this case myhlq) when it processes requests for the data set. The prefix must be an existing group name and cannot be the name used as the high-level qualifier of any actual data sets or data set profiles.
Erasing scratched or released DASD data (ERASE option)
If erase-on-scratch is active and a DASD data set profile has the erase indicator set, ERASE specifies that data management is to erase the contents of any scratched or released data set extents that are part of a DASD data set protected by that profile.
Protecting DFP-managed temporary data sets
You can protect DFP-managed temporary data sets. Normally, these data sets are considered protected from any accesses except by the job or session that created them and, therefore, do not need to be protected by RACF. However, the following situations can leave a temporary data set unprotected:
•A system failure
•An initiator failure or initiator termination by the FORCE command
•An automatic restart—between the failure and the restart
In these cases, if the TEMPDSN class is active, only users with the OPERATIONS attribute can scratch any residual DFP-managed temporary data sets remaining on a volume.
 
Note: The user with the OPERATIONS attribute can access the data set only to scratch the data set. No other access is allowed (such as would be allowed by READ or UPDATE access authority to the data set).
To activate the TEMPDSN class, enter:
SETROPTS CLASSACT(TEMPDSN)
 
Important: Plan carefully when to activate the TEMPDSN class to avoid a situation where current users or jobs are using temporary data sets. Otherwise, you might cause users or jobs to receive an ABEND.
2.46 Class related options
Activating general resource classes (CLASSACT)
The system-wide security administrator specifies in which general resource classes RACF provides access authorization checking.You can specify this option for selected general resource classes with the CLASSACT operand of the SETROPTS command. The following example shows how to specify RACF access authorization checking for the TERMINAL and CONSOLE resource classes:
SETROPTS CLASSACT(TERMINAL CONSOLE)
 
Important: We do not recommend that you activate all RACF classes. Activate only those classes that are important to your installation, because some classes have a default return code of eight. Activate those classes only after you define the necessary profiles to allow access to resources, using the following command:
SETROPTS NOCLASSACT(TERMINAL)
This NOCLASSACT operand indicates that RACF performs no access authorization checking for the specified general resource classes.
 
Attention: If you activate a class using SETROPTS CLASSACT, RACF activates all classes in the class descriptor table that have the same POSIT value as the class that you specify. The same effect is true for the other class related options. Thus, we do not mention this note in every topic. For details see z/OS Security Server RACF Command Language Reference, SA22-7687
Activating generic profile checking and generic command processing (GENRIC and GENCMD)
You can activate or deactivate generic profile checking and generic command processing on a class-by-class basis. The following example shows how to activate generic profile checking and generic command processing for the DATASET class:
SETROPTS GENERIC(DATASET)
Generic profile command processing is activated automatically for all classes for which generic profile checking is activated.
NOGENERIC and NOGENCMD are in effect when a RACF database is first initialized using IRRMIN00.
 
Tip: We recommend that you use generic profiles, if possible, to protect multiple resources and, thus, to ease the administration. Consider issuing SETROPTS GENERIC(*) so that generic profiles and generic command processing are usable in all classes.
The following command might be helpful in case of maintenance:
SETROPTS NOGENERIC(classname) GENCMD(classname)
For more information, see z/OS Security Server RACF Security’s Administrator’s Guide, SA22-7683.
Activating global access checking (GLOBAL)
RACF provides global access checking to improve performance of RACF authorization checking for selected resources. You can use global access checking for public resources that are accessed frequently. The global access checking table is maintained in storage and is checked early in the RACF authorization checking sequence. If an entry in the global access checking table allows the requested access to a resource, RACF performs no further authorization checking.
 
Attention: Because RACF performs global access checking before many of the other kinds of access authority checks, such as security label checking or access list checking, global access checking might allow access to a resource you are otherwise protecting. To avoid a security exposure to a sensitive resource, do not create an entry in the global access checking table for a resource that is protected by a profile containing a security level, security category, or security label.
 
Important: When global access checking allows a request, RACF performs no logging other than that requested by the SETROPTS LOGOPTIONS command. See also “LOGOPTIONS: Activating auditing for access attempts by class” on page 90.
For further consideration before activation of global access checking, see z/OS Security Server RACF Security’s Administrator’s Guide, SA22-7683.
Activate in-storage profile processing (RACLIST and GENLIST)
In-storage profiles can help the administrator maximize performance of the RACF database. RACF provides processing to activate in-storage profiles. The SETROPTS operands are GENLIST and RACLIST.
 
Note: RACF does not allow you to specify SETROPTS GENLIST and SETROPTS RACLIST for the same general resource class at the same time.
For more information about when to use RACLIST and GENLIST processing, see z/OS Security Server RACF Systems Programmer’s Guide, SA22-7681. Classes for which RACLIST processing is recommended are listed there.
 
Note: A general resource class must be active before you can activate SETROPTS GENLIST or SETROPTS RACLIST processing for that class.
Refreshing in-storage profiles (REFRESH)
If your installation maintains in-storage copies of resource profiles through the SETROPTS RACLIST or SETROPTS GENLIST command, changes to those profiles do not take effect on the system until a SETROPTS RACLIST REFRESH or SETROPTS GENERIC REFRESH command is issued. For details, see z/OS Security Server RACF Security’s Administrator’s Guide, SA22-7683.
To activate refreshing of SETROPTS RACLIST processing for the TSOPROC and TSOAUTH classes, use this command:
SETROPTS RACLIST(TSOPROC TSOAUTH) REFRESH
Restricting the creation of general resource profiles (GENERICOWNER)
RACF provides the possibility to restrict the creation of profiles in general resource classes.You have to issue the SETROPTS GENERICOWNER command and define a double asterisk (**) profile for the class with yourself as owner.
 
Note: The GENERICOWNER operand does not affect the DATASET class. It cannot be activated for individual classes. When active, GENERICOWNER affects all general resource classes except the PROGRAM class and general resource grouping classes.
Automatic omission of creator’s user ID from access list (NOADDCREATOR)
The SETROPTS options ADDCREATOR and NOADDCREATOR allow you to specify whether the user ID of the person who defines a resource profile is placed on the access list for that resource automatically with ALTER authority. The following command causes RACF not to place the profile creator’s user ID on the profile access list:
SETROPTS NOADDCREATOR
 
Note: We recommend that you use the NOADDCREATOR option. If the creating user needs access to the profile being defined, then access to the profile should be done separately, and if possible, by specifying a group and not an individual user ID.
2.47 Authorization checking related options
Activating list-of-groups checking (GRPLIST)
A RACF defined user can be a member of different RACF groups. If list-of-groups checking is activated, a user’s authority to access or define a resource is not based only on the authority of the user’s current logon group. Access is based on the authority of any group to which the user is connected.
 
Note: If list-of-groups checking is activated and if a user is in more than one group and tries to access a resource, RACF uses the highest authority that is allowed by the user’s list of groups and the resource’s access list.
NOGRPLIST is in effect when RACF is using a newly-initialized database. You can change this option using the following command:
SETROPTS GRPLIST
 
Tip: We recommend that you use the GRPLIST option because it eases administration and minimizes the number of times the user might have to log off and log back on to access resources.
Activating program control (WHEN(PROGRAM))
There are some specifics with the general resource class PROGRAM. One of these is the kind how program control is activated using SETROPTS:
SETROPTS WHEN(PROGRAM)
When program control is active, RACF provides access control to load modules, and program access sets and SERVAUTH resources.
Access control to load modules allows only authorized users to load and execute specified load modules (programs). RACF uses profiles in the PROGRAM general resource class to control access to programs.
Program access to data sets allows an authorized user or group of users to access specified data sets in conjunction with the user’s authority to execute a certain program. That is, some users can access specified data sets at a specified access level only while executing a certain program.
Program access to SERVAUTH class resources allows an authorized user or group of users to access certain IP addresses in conjunction with the user’s authority to execute a certain program. That is, some users can access specified IP addresses at a specified access level only while executing a certain program.
NOWHEN(PROGRAM) is in effect when a RACF database is first initialized using IRRMIN00.
 
Note: We recommend that you implement the general resource class PROGRAM from a security point of view. There are a lot of system programmer related programs, for example AMASPZAP or some RACF utilities, which should not be used by unauthorized users.
For details on program control, seez/OS Security Server RACF Security’s Administrator’s Guide, SA22-7683.
Activating terminal control (TERMINAL(READ/NONE))
RACF provides the general resource class TERMINAL to control the use of terminals. The system-wide option TERMINAL(READ) or TERMINAL(NONE) is used to set the universal access authority (UACC) associated with undefined terminals.
The following command sets the TERMINAL class of resource in RACF to an active, system-wide status:
SETROPTS CLASSACT(TERMINAL) TERMINAL(READ)
All subsystems that use RACF to control access to terminals now have terminal checking active when this command is issued. The READ option of the TERMINAL operand indicates how RACF is to view terminals that are not defined to RACF. READ indicates that if RACF cannot find a profile for that terminal, access to the terminal is to be allowed.
To prevent undefined terminals from being used for logging on, use the following command:
SETROPTS TERMINAL(NONE)
 
Attention: Before you specify NONE, be sure that you define some terminals to RACF and give the appropriate users and groups proper authorization to use them. Otherwise, no one can log on to your system.
If your installation uses dynamic IP addresses instead of static VTAM defined terminal names, it is not easy to administrate profiles in the RACF class TERMINAL.
2.48 Tape related options
RACF allows you to establish access requirements for both tape data sets and tape volumes.
Activating tape data set protection (TAPEDSN)
RACF provides means of tape data set protection if you use the TAPEDSN operand of the SETROPTS command. When you activate tape data set protection, RACF refers to profiles in the DATASET class when verifying a user’s access authority to a tape data set. The following example shows how to specify this option:
SETROPTS TAPEDSN
NOTAPEDSN is in effect when a RACF database is first initialized using IRRMIN00. In this case, RACF cannot protect individual tape data sets, although it can protect tape volumes.
Activating tape volume protection (TAPEVOL)
You can activate tape volume protection using the CLASSACT(TAPEVOL) operand of the SETROPTS command. When you activate tape volume protection, RACF refers to profiles in the TAPEVOL class when verifying a user’s access authority to a tape volume.
If both the TAPEVOL class and TAPEDSN are active, RACF maintains profiles in both the TAPEVOL and DATASET classes. Data fields within these two profiles (data set name in the TAPEVOL profile and volume serial in a discrete data set profile) link the two profiles to each other. The following example shows how to activate tape volume protection:
SETROPTS CLASSACT(TAPEVOL)
 
Note: If your installation has a tape management system, you might consider running with TAPEDSN active and TAPEVOL inactive. In this case, your tape management system, not RACF, maintains tape volume security and controls access to tape volumes.
For more information, see “Choosing Which Tape-Related Options to Use” in z/OS Security Server RACF Security’s Administrator’s Guide, SA22-7683.
Establishing a security retention period for tape data sets (RETPD)
The RACF security retention period is the number of days that RACF protection remains in effect for a tape data set. RACF stores the value in the tape data set profile. If you specify RETPD, you must also activate TAPEDSN. The following example shows how to specify a RACF security retention period of 365 days:
SETROPTS RETPD(365)
2.49 RVARYPW and other options for initial setup
RVARY command background information
This section provides some background information about the RVARY command.
Importance of the RVARY command
The RVARY command is a very important command for the system programmer and helpful for maintenance of the RACF data base. With the RVARY command you can:
•Deactivate and reactivate the RACF function.
•Switch from using a specific primary data set to using its corresponding backup data set, perhaps because of a failure that is related to the primary data set.
•Deactivate or reactivate primary or backup RACF data sets. (Deactivating a specific primary data set causes all RACF requests for access to that data set to fail. Deactivating a specific backup data set causes RACF to stop duplicating information about that data set.)
•Deactivate protection for any resources belonging to classes defined in the class descriptor table while RACF is inactive.
•Select the mode of operation when RACF is enabled for sysplex communication.
Authorization required
Unlike the SETROPTS command, the RVARY command needs no special user attribute for the submitting user ID. However, the operator (at the operator console or security console) must approve the RVARY command unless it is a RVARY LIST before RACF allows the command to complete.
If the RVARY command changes RACF or its database status (ACTIVE/INACTIVE), RACF issues an informational message, and the operator is required to enter the password that is defined by RVARYPW STATUS(status-pw) to authorize the change.
If the RVARY command switches the RACF data sets (SWITCH) or changes the RACF operating mode (DATASHARE/NODATASHARE), RACF issues an informational message, and the operator is required to enter the password that is defined by RVARYPW SWITCH(switch-pw).
Setting the RVARY passwords (RVARYPW)
You use the SETROPTS command with the RVARYPW operand to specify the passwords that are necessary for the RVARY command to succeed.
RACF allows you to specify separate passwords for switching the databases and for changing RACF status. The following example specifies HAPPY as the switch password and RABBIT as the status password:
SETROPTS RVARYPW(SWITCH(HAPPY) STATUS(RABBIT))
When RACF is first initialized, the switch password and the status password are both set to YES.
 
Important: We strictly recommend to change the RVARY password, because of the importance of the command. Otherwise, everyone reading RACF publications can inactivate or influence security in your installation.
Activating JES2 or JES3 RACF support (JES)
The parameter JES of the SETROPTS command has several subcommands that control the job entry subsystem (JES) options. The following subcommands are described in detail in z/OS Security Server RACF Security’s Administrator’s Guide, SA22-7683, and z/OS Security Server RACF Command Language Reference, SA22-7687:
BATCHALLRACF Forcing Batch Users to Identify Themselves to RACF
XBMALLRACF Support for Execution Batch Monitor (XBM) (JES2 Only)
EARLYVERIFY JES User ID Early Verification
NJEUSER Understanding Default User IDs
UNDEFINEDUSER Understanding Default User IDs
Establishing national language defaults (LANGUAGE)
With the LANGUAGE option of the SETROPTS command, you can specify the system-wide defaults for national languages (such as American English or Japanese) that your system uses. You can specify a primary language, a secondary language, or both. The languages that you specify depend on which products, when installed on your system, check for primary and secondary languages (using RACROUTE REQUEST=EXTRACT).
To specify the installation default languages, enter:
SETROPTS LANGUAGE(PRIMARY(language1) SECONDARY(language2))
 
Note: The SETROPTS LANGUAGE operand does not affect the language in which the RACF ISPF panels are displayed. The order in which the RACF ISPF panel libraries are allocated determines the language that is used. If your installation ordered a translated feature of RACF, the RACF program directory gives instructions for setting up the ISPF panels.
Controlling data set modeling (Model)
The MODEL operand of the SETROPTS command allows you to supplement the information that is normally placed in new data set profiles automatically by ADSP, PROTECT=YES, or ADDSD.
NOMODEL is in effect when a RACF database is first initialized using IRRMIN00.
 
Note: The FROM(profile-name) operand on the ADDSD command overrides any specifications from the MODEL(USER) or MODEL(GROUP) operands.
2.50 Auditor related options(1)
AUDITOR authorization required
There are several system-wide audit controls using the SETROPTS command. General audit controls direct RACF to log (or not to log) certain security-relevant events. To specify the general audit controls, you must have the AUDITOR attribute.
This section describes the auditor control options which refer to security events in conjunction with RACF commands.
AUDIT: Logging RACF commands and DEFINE requests
RACF provides means to specify individually for which classes RACF logs all detected accesses to the RACF database through RACF commands and DEFINE requests. You can specify the AUDIT operand on the SETROPTS command. Logging becomes effective immediately. The following example specifies that you want RACF to log RACF commands and define requests for users, groups, data sets, and the TERMINAL general-resource classes.
SETROPTS AUDIT(USER GROUP DATASET TERMINAL)
If you specify AUDIT(*), logging occurs for all classes.
You deactivate logging for a class using the NOAUDIT operand. NOAUDIT(*) is in effect when RACF is using a newly-initialized database.
 
Note: If you activate auditing for a class using SETROPTS AUDIT, RACF activates auditing for all classes in the class descriptor table that have the same POSIT value as the class you specify. For details, see z/OS Security Server RACF Command Language Reference, SA22-7687.
CMDVIOL: Logging RACF command violations
A command violation can occur because RACF does not authorize a user to modify a particular profile or to enter a particular operand on a command. If you specify the CMDVIOL operand on the SETROPTS command, RACF logs all command violations (except for LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH, which are never logged). CMDVIOL is in effect at RACF initialization.
 
Tip: We recommend that you keep CMDVIOL active and cause RACF to log all the command violations that it detects. You can then use the RACF report writer to produce a printed audit trail of command violations. You can determine how many command violations are occurring and which users are causing the violations. A significant number of command violations, especially when RACF is first installed, can indicate the need for more user education. The report can also help you to identify any specific users who are trying persistently to alter profiles without the proper authority.
If you decide to bypass logging of all violations that are detected by RACF commands (except RVARY and SETROPTS, which are always logged) during RACF command processing, you can specify the NOCMDVIOL operand on the SETROPTS command as shown in the following example:
SETROPTS NOCMDVIOL
SAUDIT: Logging of activity of users with the SPECIAL attribute
The SETROPTS option SAUDIT specifies that RACF is to log RACF commands (except LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH) issued by users who either had the SPECIAL attribute or who gained authority to issue the command through the group-SPECIAL attribute. SAUDIT is in effect when RACF is using a newly initialized database.
 
Tip: We recommend that you specify SAUDIT, because of the powerful commands a SPECIAL user can submit. You can then use the RACF report writer to produce audit reports.
If you decide to bypass this logging (for example, if you are concerned only with how SPECIAL users change profiles and you have AUDIT(*) in effect), you can use the following command:
SETROPTS NOSAUDIT
2.51 Auditor related options(2)
AUDITOR authorization required
There are further system-wide audit controls using the SETROPTS command for which the AUDITOR attribute is needed. This section describes the auditor control options which refer to security events in conjunction with access to resources.
OPERAUDIT: Logging activities of users with the OPERATIONS attribute
The SETROPTS option OPERAUDIT specifies that RACF is to audit all accesses to resources granted and all uses of the ADDSD, and RDEFINE commands allowed only because the user has the OPERATIONS or group-OPERATIONS attribute. Without the OPERATIONS attribute, the access is denied, because the user is not authorized over the access list. The following example shows how to specify this option:
SETROPTS OPERAUDIT
NOOPERAUDIT is in effect at RACF initialization.
 
Tip: OPERAUDIT might be useful if you decide to remove the OPERATIONS attribute and give those users access through the normal access list. You can then use the RACF report writer or other auditing tools to produce a report on this events.
LOGOPTIONS: Activating auditing for access attempts by class
With the LOGOPTION operand you can cause RACF to audit attempts of accessing resources in specified classes (whether or not successful). There are different options available. You can specify the DATASET class and any active classes in the class descriptor table. The resources need not have profiles created in order for the auditing to occur. The following command specifies that auditing is to be done for all attempts to access the TERMINAL class:
SETROPTS LOGOPTIONS(ALWAYS(TERMINAL))
In this case, auditing is done every time a user logs on at any terminal on the system, regardless of whether that terminal is protected by a profile and regardless of whether that profile specifies auditing. You can specify that auditing be done for the following conditions:
ALWAYS All attempts to access resources protected by the class are audited.
NEVER No attempts to access resources protected by the class are audited. (All auditing is suppressed.)
SUCCESSES All successful attempts to access resources protected by the class are audited.
FAILURES All failed attempts to access resources protected by the class are audited.
DEFAULT Auditing is controlled by the profile protecting the resource, if a profile exists. You can specify DEFAULT for all classes by specifying an asterisk (*) with DEFAULT.
 
Note: The SUCCESSES and FAILURES operands result in auditing in addition to any auditing that is specified in profiles in the class. In contrast, the ALWAYS and NEVER operands override any auditing specified in profiles in the class.
 
Note: When RACF grants access to a resource because of an entry in the global access checking table, RACF does not log the event even if you request logging.
LOGOPTIONS(DEFAULT(*)) is in effect at RACF initialization.
APPLAUDIT: Auditing for APPC/MVS
Specifying the APPLAUDIT parameter on the SETROPTS command, you can request auditing of APPC transactions. NOAPPLAUDIT is in effect at RACF initialization. See z/OS Security Server RACF Auditor’s Guide, SA22-7684, for more information.
SECLABELAUDIT: Activating auditing for security labels
The SECLABELAUDIT option of the SETROPTS command specifies that the SECLABEL profile’s auditing options are to be used in addition to the auditing options specified for the user or resource. NOSECLABELAUDIT is in effect when RACF is using a newly-initialized database. For more information, refer to z/OS Security Server RACF Auditor’s Guide, SA22-7684.
SECLEVELAUDIT: Activating auditing for security levels
The SECLEVELAUDIT (security-level) operand of the SETROPTS command activates auditing of access attempts to all RACF-protected resources based on the specified installation-defined security level. RACF audits all access attempts for the specified security level and higher. You can specify only a security level name defined by your installation as a SECLEVEL profile in the SECDATA class. (For information about defining security levels, see the description of the RDEFINE and RALTER commands in z/OS Security Server RACF Command Language Reference, SA22-7687.)
The NOSECLEVELAUDIT operand deactivates auditing of access attempts to RACF-protected resources based on a security level. NOSECLEVELAUDIT is in effect when RACF is using a newly-initialized database.
2.52 SETROPTS: Display options (LIST)
SETROPTS LIST command
This command specifies that the current RACF options are displayed. If you specify operands in addition to LIST on the SETROPTS command, RACF processes the other operands before it displays the current set of options.
If RACF is enabled for sysplex communication and the system is in read-only mode, users on that system can issue the SETROPTS LIST command. All other operands are ignored.
You must have the RACF SPECIAL, AUDITOR, group-SPECIAL, or group-AUDITOR attribute to enter the LIST operand.
If you have the SPECIAL or group-SPECIAL attribute, and not the AUDITOR or group-AUDITOR, RACF displays all operands except the auditing related operands.
Figure 2-54 shows sample output from the following SETROPTS command:
SETROPTS LIST
2.53 RACF monitoring
Figure 2-55 RACF monitoring
RACF monitoring
For more immediate action, the user can request notification to the master terminal at the time of violation. A non-zero value for the SECCNT keyword of the SECURITY macro causes the master terminal to be notified.
Because the number of violations for a large network can be high due to misspelled passwords, transaction codes, and commands, you can specify a threshold for notification. The master terminal is not notified until the specified number of violations occur without a valid input from a given terminal. You specify one to three invalid entries as the violation limit, eliminating or reducing the number of notifications that are caused merely by operator error, while still providing evidence of real attempts to avoid security safeguards.
2.54 RACF monitoring
Figure 2-56 RACF monitoring example
Example of RACF immediate notification: Example 1
The explanation of the RACF message ICH408I is as follows:
ICH408I USER(userid) GROUP(group-name) NAME(user-name)
This message is issued when RACF detects an unauthorized request (a violation) made by a user or job. The user and group indicated in the first line of the ICH408I message are the execution user ID and group ID under which the job was to run.
2.55 RACF monitoring
Figure 2-57 RACF immediate notification example
Example of RACF immediate notification: Example 2
The RACF message ICH70004I is as follows:
ICH70004I USER(accessor) GROUP(group-name)
NAME(user-name) ATTEMPTED 'access-type' ACCESS
OF ENTITY 'resource-name' IN CLASS 'class-name' AT
hh:mm:ss ON month day, year.
This message alerts a RACF user that an access violation has occurred against the indicated resource. This message is routed to the user specified in the NOTIFY field of the resource profile that denied the access.
2.56 RACF auditing tools
Figure 2-58 RACF auditing tools
RACF auditing tools
RACF auditing is basically verifying that the principals set forth by the installations security policy are not compromised. The issue with auditing is being able to reduce the amount of information to something that can be easily analyzed.
Two types of auditing data exist:
•Security data content from the RACF database, which is a static image or a snapshot of the system parameters at any one time.
•Security events data statistical information, such as the date, time, and the number of times a specific resource was accessed by any one user.
RACF writes security log records when it detects:
•Unauthorized attempts to enter the system
•Authorized or unauthorized attempts to enter RACF commands
•RACF status changes
•Warning mode resource access attempts
•Failsoft operator access decisions
•Optional authorized or unauthorized attempts to access RACF-protected resources
You can list the contents of these records to help you to detect possible security exposures or threats and verify the security of the system.
Each of the following programs can help you accomplish your goals, depending on your specific needs:
•SMF data unload utility
•RACF data unload utility
•RACF report writer
•Data security monitor (DSMON)
2.57 RACF auditing - IRRADU00
Figure 2-59 SMF unload utility
SMF data unload utility (IRRADU00 program)
The system management facility (SMF) data unload utility processes SMF records and permits more complex auditing than the RACF report writer. Output from the SMF data unload utility can be:
•Viewed directly
•Used as input for installation-written programs
•Manipulated by sort or merge utilities
•Uploaded to a database manager, such as DB2
You can process complex inquiries and generate custom-tailored reports from the output of the SMF data unload utility. These reports can be useful in identifying suspicious patterns of access by authorized users that another program might miss. Because data is more often misused by authorized users than stolen by unauthorized users, reports such as this are essential to security.
2.58 RACF auditing
Figure 2-60 SMF unload utility example
How to run the SMF data unload utility (IRRADU00)
A RACF SMF data unload utility sample JCL is as follows:
//KHEWITT1 JOB (ITSO),'SMF FLAT',MSGCLASS=X
//SMFDUMP EXEC PGM=IFASMFDP
//SYSPRINT DD SYSOUT=*
//ADUPRINT DD SYSOUT=*
//OUTDD DD DISP=(NEW,CATLG),DSN=KHEWITT.RACF.IRRADU00,
// UNIT=SYSDA,SPACE=(CYL,(10,5),RLSE),
// LRECL=5096,RECFM=VB
//SMFDATA DD DISP=SHR,DSN=SYS1.SC42.MAN2
//SMFOUT DD DUMMY
//SYSIN DD *
INDD(SMFDATA,OPTIONS(DUMP))
OUTDD(SMFOUT,TYPE(000:255))
ABEND(NORETRY)
USER2(IRRADU00)
USER3(IRRADU86)
//SYSIN DD DUMMY
To display the active SMF data set, use the D SMF command from the system console as follows:
IEE974I 10.12.27 SMF DATA SETS 796
NAME VOLSER SIZE(BLKS) %FULL STATUS
P-SYS1.SC42.MAN1 MVS004 1200 0 ALTERNATE
S-SYS1.SC42.MAN2 MVS004 1200 86 ACTIVE
S-SYS1.SC42.MAN3 MVS004 1200 0 ALTERNATE
MAN2 is the active SMF data set.
The output file in this example is KEWITT.RACF.IRRADU00.
2.59 RACF auditing
Figure 2-61 RACF report writer
RACF report writer
The RACF report writer lists the contents of SMF records in a format that is easy to read. It also uses the same SMF data to generate the following specialized reports:
•Reports that describe attempts to access a particular RACF-protected resource in terms of user identity, number and type of successful accesses, and number and type of attempted security violations.
•Reports that describe user and group activity.
•Reports that summarize system use and resource use.
The RACF report writer is stabilized at the RACF 1.9.2 level, and is not able to report on many of the later RACF functions.
2.60 RACF auditing
Figure 2-62 RACF report writer example
How to run RACF report writer
A RACF Report Writer sample JCL is as follows:
//KHEWITT1 JOB (ITSO),'RACF FLAT',MSGCLASS=X
//HEWITT EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN DD *
RACFRW DSNAME('KHEWITT.RACF.IRRADU00')
LIST
SUMMARY USER
END
/*
The RACF report writer can also be run from the TSO command line.
2.61 RACF auditing - DSMON
Figure 2-63 RACF data security monitor
RACF data security monitor
The RACF data security monitor (DSMON) enables you to verify the basic system integrity and data security controls.
RACF auditors can use the DSMON reports to evaluate the level of security at the installation and to compare the actual level of security at an installation with the planned level of security.
DSMON reports
DSMON produces the following reports:
•System report
•Group tree report
•Program properties table report
•RACF authorized caller table report
•RACF class descriptor table report
•RACF exits report
•RACF global access checking table report
•Selected user attribute report
•Selected user attribute report summary report
•Selected data sets report
The system report
The system report contains information such as the identification and model of the processor complex, and the name, version, and release of the operating system. This report also specifies the RACF version and release number and whether RACF is active. If RACF is inactive, DSMON prints a message that tells you whether RACF was not activated at IPL or was deactivated by the RVARY command.
The group tree report
This report lists, for each requested group, all of its subgroups, all of the subgroups of the subgroups, and so on, as well as the owner of each group that is listed in the report, if the owner is not the superior group. You can use the group tree report to examine the overall RACF group structure for your system. You can also determine the scope of the group for group related user attributes (group SPECIAL, group OPERATIONS, and group AUDITOR).
The program properties table report
This report lists all of the programs in the MVS program properties table (PPT). The report also indicates, for each program, whether the program is authorized to bypass password protection and whether it runs in a system key.
You can use the program properties table report to verify that only those programs that the installation has authorized to bypass password protection are, in fact able to do so. Such programs are normally communication and database control programs and other system control programs.
You can also verify that only those programs that the installation has authorized are able to run in a system key.
The RACF authorized caller table report
This report lists the names of all of the programs in the RACF authorized-caller table. The programs in this table are authorized to issue REQUEST=VERIFY (which performs user verification) or REQUEST=LIST (which loads profiles into main storage).
You can use this report to verify that only those programs that are supposed to be authorized to modify an ACEE (accessor environment element) are able to issue a REQUEST=VERIFY. This verification is a particularly important security requirement because the ACEE contains a description of the current user. This description includes the user ID, the current connect group, the user attributes, and the group authorities. A program that is authorized to issue REQUEST=VERIFY could alter the ACEE to simulate any user.
You can also use this report to verify that only those programs that are supposed to be authorized to access profiles are able to issue REQUEST=LIST. Because profiles contain complete descriptions of the characteristics that are associated with RACF-defined entities, you must carefully control access to them.
The RACF class descriptor table report
This report lists, for each general resource class the class name, the default UACC, whether the class is active, whether auditing is being done, whether statistics are being kept, and whether OPERATIONS attribute users have access.
You can use the class descriptor table report to determine which classes (in addition to DATASET) are defined to RACF and active and, therefore, can contain resources that RACF protects.
The RACF exits report
This report lists the names of all of the installation-defined RACF exit routines and specifies the size of each exit routine module.
You can use the RACF exits report to verify that the only active exit routines are those that your installation has defined. The existence of any other exit routines might indicate a system security exposure, because RACF exit routines can be used to bypass RACF security checking. Similarly, if the length of an exit routine module differs from the length of the module when it was defined by your installation, the module might have unauthorized modifications.
The RACF global access checking table report
This report lists, for each resource class in the global access table, all of the entry names and their associated resource access authorities.
Because global access checking allows anyone to access the resource at the associated access authority, you should verify that each entry has an appropriate level of access authority.
The RACF started procedures table reports RACF generates two reports about the started procedures table.
If the STARTED class is active, the report uses the STARTED class profiles and contains the TRACE attribute. The trace uses module ICHDSM00.
If the STARTED class is not active, the trace uses the installation replaceable load module, ICHRIN03.
The reports list the procedure name, the user ID and group name to be associated with the procedure, and whether the procedure is privileged or trusted.
You can use the report to determine which started procedures are defined to RACF, and which have the privileged attribute. If a started procedure is privileged or trusted, it bypasses all REQUEST=AUTH processing (unless the CSA or PRIVATE operand was specified on REQUEST=AUTH), including checks for security classification of users and data.
Selected user attribute report
The selected user attribute report:
•Lists all RACF users with the SPECIAL, OPERATIONS, AUDITOR, or REVOKE attributes
•Specifies whether they possess these attributes on a system-wide (user) or group level
•Indicates whether they have any user ID associations
You can use this report to verify that only those users who need to be authorized to perform certain functions have been assigned the corresponding attribute.
Selected user attribute summary report
The selected user attribute summary report shows the number of installation-defined users and totals for users with the SPECIAL, OPERATIONS, AUDITOR, and REVOKE attributes, at both the system and group level. You can use this report to verify that the number of users with each of these attributes, on either a system or group level, is the number that your installation wants. In particular, you should make sure that you have assigned the SPECIAL attribute (on a system level) to at least one user and the AUDITOR attribute (on a system level) to at least one user.
Selected data sets report
This report lists the names of selected system data sets and, for each data set, specifies the criterion for selection, the serial number of the volume on which it resides, whether the data set is RACF-indicated or RACF-protected, and the universal access authority (UACC). If a data set meets more than one selection criterion, there is a separate entry in the report for each criterion. The selected data sets include system data sets, the MVS master catalog, user catalogs, the RACF primary and backup data sets, and user-specified data sets.
You can use the selected data sets report to determine which of these data sets are protected by RACF and which are not. You can also check whether the UACC associated with each of the data sets is compatible with your installation's resource access control requirements.
2.62 RACF auditing
Figure 2-64 DSMON report example
How to run the DSMON program
DSMON runs as an authorized program facility (APF) authorized batch program. DSMON can also be run on TSO if SYS1.PARMLIB(IKJTSO00) is configured correctly.
A sample DSMON JCL is as follows:
//P390S JOB 1,P390,MSGCLASS=X
//TSOBAT01 EXEC PGM=ICHDSM00
//SYSPRINT DD SYSOUT=*
//SYSUT2 DD SYSOUT=*
//SYSIN DD *
LINECOUNT 55
FUNCTION all
USEROPT USRDSN sivle.memo.text
/*
2.63 RACF auditing
Figure 2-65 RACF DBU output example
How to run IRRDBU00
A RACF data unload utility sample JCL is as follows:
//KHEWITT1 JOB (ITSO),'RACF FLAT',MSGCLASS=X
//UNLOAD EXEC PGM=IRRDBU00,PARM=NOLOCKINPUT
//SYSPRINT DD SYSOUT=*
//INDD1 DD DISP=SHR,DSN=SYS1.RACFESA
//OUTDD DD DISP=(NEW,CATLG),DSN=KHEWITT.RACFDB.FLATFILE,
// UNIT=SYSDA,SPACE=(CYL,(70,10),RLSE),
// LRECL=4096,RECFM=VB
//SYSIN DD DUMMY
The output file name in this example is KHEWITT.RACFDB.FLATFIL.
2.64 RACF auditing - IRRDBU00
Figure 2-66 RACF Database Unload Utility
RACF Database Unload Utility
The RACF database unload utility (IRRDBU00 program) is used to unload data from the RACF database (except password fields) into a flat file.
The output file from the database unload utility can be:
•Viewed directly
•Used as input to your own programs
•Manipulated with sort/merge utilities
•Used as input to a database management system
Installations can produce reports that are tailored to their requirements.
Using the database unload utility output with DB2, you can use the DB2 Load Utility or its equivalent to process the records that are produced by the database unload utility. The definition and control statements for a DB2 to use this output, are shipped with OS/390 in the SYS1.SAMPLIB.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.126.211