Racf

International Technical Support Organization Planning for CA-ACF2 Migration to OS/390 Security Server (RACF) May 1996
SG24-4663-00
IBML
International Technical Support Organization Planning for CA-ACF2 Migration to OS/390 Security Server (RACF) May 1996
SG24-4663-00
Take Note! Before using this information and the products it supports, be sure to read the general information under Special Notices on page ix.
First Edition (May 1996)

This edition applies to early experiences with various MVS releases and the initial release of PC Server System/390 support programs. Order publications through your IBM representative or the IBM branch office serving your locality. Publications are not stocked at the address given below. An ITSO Technical Bulletin Evaluation Form for readers feedback appears facing Chapter 1. If the form has been removed, comments may be addressed to: IBM Corporation, International Technical Support Organization Dept 541 Mail Station P099 522 South Road Poughkeepsie, New York 12601-5400 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1996. All rights reserved. Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Abstract
The task of migration from CA-ACF2 to RACF requires good planning in a number of areas. This document, written for a CA-ACF2 user planning (or considering) migration to RACF, addresses a number of topics that must be considered. It addresses conceptual differences of the two security products, and discusses ways of handling these differences. It assumes the reader is familiar with MVS and CA-ACF2 at the systems-programming or security administration level, but perhaps not overly familiar with RACF. The more mechanical details of converting a CA-ACF2 database to a RACF database are not discussed. This is a planning and design document, not a cookbook. (118 pages)
Copyright IBM Corp. 1996
iii
iv
Migration to RACF
Contents
Abstract
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii ix xi xi xii 1 2 2 9 11 13 15 15 21 25 27 31 34 35 36 38 41 42 43 47 47 48 50 52 53 55 57 57 58 58 59 59 60 62 62 63 64 65 65 67
Special Notices
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . International Technical Support Organization Publications Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . Chapter 1. Introduction and Overview 1.1 Why RACF . . . . . . . . . . . . . 1.2 RACF Protection Concepts . . . . . . . . . 1.3 MVS System Integrity 1.4 Migration Considerations . . . . . . . . . . 1.5 RACF Documentation Chapter 2. Basic Concepts . . . . . . . . . 2.1 Users and Groups 2.2 Data Set Protection . . . . . . 2.3 General Resource Protection . . . . 2.4 Global RACF Options 2.5 Batch Job Submission . . . . . . . . . . . 2.6 Program Control 2.7 Started Task Control . . . . . 2.8 Tape Protection . . . . . . . . 2.9 CICS Protection . . . . . . . . 2.10 IMS Protection . . . . . . . . 2.11 DB2 Protection . . . . . . . . 2.12 TSO Protection . . . . . . . . Chapter 3. Advanced Controls 3.1 Operator Command Control 3.2 Remote RACF Control . . . 3.3 NJE and RJE . . . . . . . . . 3.4 Other Network Controls . . . . . . . 3.5 RACF PassTickets 3.6 Mandatory Access Control
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 4. MVS Open Edition and RACF . . . . . . . . . . 4.1 IBMs Commitment to Open Systems . . . . . . . . . . 4.1.1 MVS Achieves Open Systems Brand From X/Open . . . . . . . . . . . . . . . . . . . 4.2 UNIX Security Basics . . . . . . . . . . . . . . . 4.2.1 UNIX Security and Files . . . . . . . . . . . . . . . . . . . . 4.3 OS/390 OpenEdition 4.3.1 OS/390 OpenEdition Security Processing . . . . . . . . 4.3.2 OS/390 OpenEdition Kernel Address Space 4.3.3 OS/390 OpenEdition Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Home Directory and Program 4.4.1 OS/390 OpenEdition Shell Environment . . . . . . 4.4.2 Hierarchical File System (HFS) . . . . . . . . . . . 4.4.3 File Security Packet . . . . . . . . . . . . . . . . . . 4.4.4 Default File Permissions . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 OS/390 OpenEdition DCE Support . . . . . . . 4.6 What is a Distributed Computing Environment? . . . . . . . . . . . . . . 4.6.1 OpenEdition DCE 4.6.2 DCE Cell Configuration . . . . . . . . . . . 4.6.3 RACF Interoperability . . . . . . . . . . . . 4.6.4 The RACF Interoperability Utilities . . . . Chapter 5. Administration and Maintenance 5.1 Administrative Interface . . . . . . . . . 5.2 Privilege Levels . . . . . . . . . . . . . . 5.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Security Reports 5.5 Availability Considerations . . . . . . . 5.5.1 RACF Active Backup Option . . . . . . . . . . . . 5.5.2 Recovery Strategies 5.5.3 Reorganizing the RACF Database 5.6 RACF Performance Considerations . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67 68 70 70 72 73 75 75 76 80 81 83 84 85 85 85 89 89 89 89 91 92 92 92 92 92 93 93 97 97 97 97 97 98 99 99 101 101 101 101 101 102 102 102 102 102 103 103 103 103 103
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 6. Technical Details . . . . . . . . . . . . 6.1 System Authorization Facility (SAF) and RACF . . . . 6.1.1 MVS/RACF Security Environment 6.1.2 Control Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.3 RACROUTE Calls . . . . . . . . . . . . . . . . 6.1.4 Return Codes . . . . . . . . . . . . . . 6.1.5 SAF Control Flow 6.1.6 Tables . . . . . . . . . . . . . . . . . . . . . 6.1.7 Exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.8 Old RACF Interfaces . . . . . . . . . . . . . . . . . . . 6.2 RACF Tables 6.3 RACF Exits . . . . . . . . . . . . . . . . . . . . . Chapter 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.6 7.1.7 7. IBM Migration Services . Mainframe System Software . . . . . Migration Services . Conversion vs. Migration Migrations - No Two Alike . Migration Service Offerings . . . . . Product Migrations Getting Started . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Security Policy Considerations . . . . . . . . . . . . A.1 User Identification . . . . . . . . . . . . . . . . . A.1.1 Batch A.1.2 TSO . . . . . . . . . . . . . . . . . . A.1.3 STC . . . . . . . . . . . . . . . . . . A.2 Resource Protection . . . . . . . . . . . A.2.1 Data Sets . . . . . . . . . . . . . . . A.2.2 Transactions and Other Resources . . . . . . . . . . . . . . A.3 Authentication A.3.1 Passwords . . . . . . . . . . . . . . A.3.2 Passtickets . . . . . . . . . . . . . . . . . . . . . . . . A.4 Naming Conventions A.4.1 Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . A.4.2 Other Resources . . . . . . . . . A.4.3 Users and Groups
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
Migration to RACF
A.5 Ownership . . . . . . . . . . . . . . A.6 Security Administration . . . . . . A.6.1 Structure . . . . . . . . . . . . A.6.2 Effectiveness . . . . . . . . . . A.6.3 Efficiency . . . . . . . . . . . . . . . . . . . A.7 Audit Considerations A.7.1 Logging . . . . . . . . . . . . . . . . . . . . A.7.2 Event Monitoring A.7.3 Status Review . . . . . . . . . A.8 Resource Utilization . . . . . . . . A.8.1 Performance Options . . . . . A.8.2 Potential Performance Impact Appendix B. Sample Migration Plan
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
103 103 104 104 104 104 104 105 105 105 105 105 107 109 113
. . . . . . . . . . . . . . . . . . . . . . . .
Appendix C. Frequently Asked Questions Index
. . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
vii
viii
Migration to RACF
Special Notices
This publication is intended to help you to understand and plan for a migration from CA-ACF2 to RACF within an MVS/ESA environment. The information in this publication is not intended as the specification of any programming interfaces that are provided by any of the products discussed. See the PUBLICATIONS Section of the IBM Programming Announcements for the various products discussed for more information about what publications are considered to be product documentation. References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM program product in this document is not intended to state or imply that only IBMs program product may be used. Any functionally equivalent program that does not infringe any of IBMs intellectual property rights may be used instead of the IBM product, program, or service. Information in this book was developed in conjunction with use of the equipment specified, and is limited in application to those specific hardware and software products and levels. IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Commercial relations, IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594, USA. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The information about non-IBM (VENDOR) products in this manual has been supplied by the vendor and IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customers ability to evaluate and integrate them into the customers operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. The following terms are trademarks of the IBM Corporation in the United States and/or other countries:
RACF CICS VTAM OPC/ESA DFSMS/dss NetView MVS/ESA CICS/ESA DB2 DFSMS/rmm DFSMS/dfp
Zeke and Zebb are trademarks of Altai Software CA-1, CA-7, CA-11, CA-Librarian, CA-ACF2, CA-Top Secret, CA-ROSCOE CA-Scheduler, CA-Manager, CA-NETMAN, CA-IDMS and CA-DATACOM are trademarks of Computer Associates International Control-M and Control-R are trademarks of 4th Dimension Software Jobtrac and Runtrac are trademarks of Legent Corp.
ix
Adabas is a trademark of Software AG Inc. Mod204 is a trademark of Computer Corporation of America Total is a trademark of Cincom Systems Other trademarks are trademarks of their respective companies.
Migration to RACF
Preface
CA-ACF2 and RACF are both sophisticated products. In some areas their designs are similar, and in other areas the designs are very different. Planning a migration from CA-ACF2 to RACF, without unduly disrupting an MVS production environment, requires considerable planning and understanding. With proper planning, and perhaps with specially skilled people to assist in certain areas, the migration can usually be accomplished in an orderly way. Understanding the higher-level issues and differences between the two products is an important starting point. This document is intended to assist in this area.
International Technical Support Organization Publications

A complete list of International Technical Support Organization publications, with a brief description of each, may be found in:
International Technical Support Organization Bibliography of Redbooks , GG24-3070

For a technical presentation of new RACF features, we recommend:
RACF Version 2 Release 2 Technical Presentation Guide (GG24-2539).

For the special area of APPC security, we recommend:
APPC Security: MVS/ESA, CICS/ESA, and OS/2 (GG24-3960) APPC Programming Considerations in MVS/ESA and OS/2 (GG24-3818)
To get a catalog of ITSO technical publications (known as redbooks), VNET users may type:
TOOLS SENDTO WTSCPOK TOOLS REDBOOKS GET REDBOOKS CATALOG

How to Order ITSO Redbooks IBM employees in the USA may order ITSO books and CD-ROMs using PUBORDER. Customers in the USA may order by calling 1-800-879-2755 or by faxing 1-800-445-9269. Almost all major credit cards are accepted. Outside the USA, customers should contact their local IBM office. Customers may order hardcopy ITSO books individually or in customized sets, called GBOFs, which relate to specific functions of interest. IBM employees and customers may also order ITSO books in online format on CD-ROM collections, which contain redbooks on a variety of products.
xi
Acknowledgments
This document is the result of a project of the International Technical Support Organization in the Poughkeepsie Center. The following people contributed to this document:

Kurt Meiser - ITSS International, Inc. Kleber Candido de Melo - IBM Brazil George Dawson - ISSC Australia Bill Ogden - ITSS International, Inc. Cees Kingma - IBM International Technical Support Organization Gunnar Myhre - ITSS International, Inc. Walt Farrell - IBM RACF Development Peter Desforge - IBM Software Migration Project Office Rich Miles - IBM Software Migration Project Office
xii
Migration to RACF
Chapter 1. Introduction and Overview

This document is intended for installations considering or planning a migration from CA-ACF2 to RACF. This migration involves much more than converting the CA-ACF2 databases to a RACF database. Planning, planning, and more planning is the key to a good migration. Good planning requires a good understanding of the basic concepts involved on both ends of the migration. The functions of the OS/390 Security Server, an optional component of OS/390, are included in any reference to RACF in this document. Rather than repetitively writing RACF and OS/390 Security Server , we will simply write RACF but understand that the OS/390 Security server is also implied in this name. In the same sense, our use of the name MVS is meant to include OS/390. We assume you are a current user of CA-ACF2 and understand its concepts fairly well. This document explains many of the important RACF concepts, starting from an external requirements point of view. It is intended to provide a bridge from your understanding of CA-ACF2 to an understanding of RACF sufficient for initial planning activities. This initial planning should concentrate on policy goals, taking into account what is reasonable and possible with RACF. The document explains how various security policy elements are addressed by RACF functions. RACF, like CA-ACF2, offers a number of ways to implement security policies. Experience has shown some approaches to work better than other approaches. We provide a number of recommendations for designing and implementing your new RACF protection. Our recommended approaches are not the only way to implement and use RACF, but we suggest you consider our approaches unless you have strong reasons for going in other directions. This document does not address the specific steps involved in converting the CA-ACF2 databases to a RACF database. Experience has shown that a good conversion requires:
A rather unique set of skills, used only once in any given installation. The skills are based on both experience and detailed product knowledge. Unique software tools -- initially simple, but becoming complex very quickly -- that are used only once in a given installation. Considerable flexibility in using the skills and tools, due to the wide range of techniques and functions being migrated from CA-ACF2. Simplistic cookbook approaches are useful only for simplistic installations, and there are few of these.
We believe the detailed conversion should be left to specialists, available through contracts. This is discussed more in Chapter 7, IBM Migration Services on page 97. The time and efforts of installation personnel are much better spent at the policy level, learning RACF, and working with specific application-related issues (programs, procedures) that cannot be automatically converted. As with many specialized fields, computer security has its own vocabulary, and complex individual products extend this vocabulary with their own key words and phrases. You will need to become familiar with the RACF vocabulary. This is important, and must be started early in the migration process. While this whole
document deals with the RACF vocabulary, the second chapter specifically addresses the meanings and context of important RACF definitions and concepts.
1.1 Why RACF

Why migrate to RACF? There are many answers reflecting various points of view. From a higher-level technical perspective, we find the following points are important:
RACF is designed to be extendable. Its database is not hard coded. New classes and fields can be added by IBM in a well-defined manner, using the Class Descriptor Table (CDT) and Templates. We expect the ability to change and grow in an architected manner will become more important as new technology (such as client-server, objects, distributed objects, DCE, and so forth) is added to MVS. RACF takes full advantage of the SAF interface to MVS. This is its only primary interface. RACF, together with MVS, has a strong commitment to DCE support, use, and growth. We expect DCE to be increasingly important for enterprise-level solutions. RACF performance is excellent, especially with CICS. RACF recoverability is excellent, starting with the active backup RACF database. RACF performance with shared RACF databases is excellent, due to the specialized design of the database access program. A variety of sophisticated third-party products are available for RACF. RACF releases are usually synchronized with MVS releases, providing immediate support for new MVS functions. RACF provides sophisticated remote sharing of database changes. RACF controls data set-level erase-on-scratch controls, making this function practical to use. RACF exploits sysplex features for performance and sharing. RACF documentation, on CD-ROM, can be searched and accessed online from mainframes or PC systems. RACF provides a structured, consolidated command language.
1.2
RACF Protection Concepts

RACF is an IBM program product designed to provide Multiple Virtual Storage (MVS) and Virtual Machine (VM) users with an effective tool for managing access control, an increasingly important user responsibility and concern. This section provides a very brief overview of basic RACF concepts. Each of these concepts is discussed at more length in the remainder of this document. RACF performs authentication, authorization and logging. In other words, RACF controls users, protects resources and provides security audit trails. The objective of RACF access control is to protect data sets and other general resources from unauthorized destruction, modification, or disclosure, whether by
Migration to RACF
accident or design. To be effective, security procedures should be easy to use and place no additional burden upon data processing management. RACF meets this requirement. Users are identified by a user ID and authenticated by a password . A RACF user ID may represent a person or a process. For instance, a user ID can be associated with a started task or a batch job. Each defined user belongs to at least one group, known as a default group . A group is a collection of RACF users who share common access requirements to protect resources or who have similar attributes within the system. RACF users can be members of one or more groups. In RACF terminology, when a user is associated with a group we can say that this user is connected to that group. RACF resources can be divided into two categories, data sets and general resources . General resources are defined in various resource classes which include:

DASD volumes Tape volumes Terminals Programs JES and NJE controls and processes CICS/VS resources and transactions IMS/VS resources and transactions Installation-defined resources
RACF contains many predefined general resource classes, many more than are listed here. You can add to the list to create any unique security controls required by your applications. The user, group, data set, and resource definitions are kept in a data base. RACF is initialized automatically during system IPL. Conceptually, there is only one RACF database, which holds profiles . RACF uses the word profile for logical entries in the data base. These entries, as depicted in Figure 1 on page 4, include:

user profiles - representing persons or processes group profiles - used to group users according to job functions for easier administration data set profiles - protection disk and tape data sets general resource profiles - protecting, in a variety of resource classes, all other resources, e.g., CICS or IMS transactions, tape volumes, programs, NJE nodes, etc.
In addition, global options (which are not termed profiles ) are maintained in the RACF database. Figure 1 on page 4 shows a simplified view of a profile, including the following fields:

profile name, e.g., SYS1.LINKLIB or SYS1.** profile owner, i.e., the name of the user or group owning the profile access list, i.e., a list of user IDs or group names and their access authority such as READ, UPDATE or NONE. UACC, the field containing public (universal) access authority.
Figure 1. Simplified RACF Database Structure
For performance purposes, the database can be broken in several physical files spread among system DASD volumes. However, it is still used as a single logical database. This logical database can be shared by other local (channel-connected) MVS systems. RACF contains the necessary logic to maintain data coherence while being updated and used by multiple independent MVS systems. For recovery purposes, this base can be mirrored onto another database. The main database is referred to as the PRIMARY DATABASE. The mirror database is referred to as the BACKUP DATABASE. That backup database is a local data set, on a DASD unit that can be written directly from the MVS system. The use of a backup database is optional, but most, if not all, RACF installations use it. Modifications to the primary database are automatically reflected in the secondary base at the time they occur. RACF database definitions allow some flexibility in the information to be mirrored, and trivial information (such as statistical updates) can be excluded from mirroring. Starting with release 2.2, RACF can also update remote RACF databases located on MVS systems connected through SNA links. This facility is intended for keeping user IDs and protection profiles in synchronization among multiple MVS sites, but it also provides recovery possibilities. See 3.2, Remote RACF Control on page 48 for more information.
RACF Terminology
RACF has specific meanings for the following words and phrases:
RACF User: A user is a single logical entity to RACF. A user:

can be authenticated (password) own and manage resource profiles be granted access (at various levels) to other resource profiles
Migration to RACF
and so forth.
A user is always connected to a default group, and can be connected to many other groups.
RACF Group: A RACF group basically consists of all the users that have similar requirements for access to the systems resources. Each group, with exception of the highest group (SYS1), has a superior group. A RACF group is identified by its name. The name of a group is one to eight alphameric characters, the first being an alphabetic or national character. An entry in the RACF database describing a group is a GROUP PROFILE. A typical use of a group is to own a high level qualifier (HLQ) that is not appropriate for an individual user; for example, the HLQ associated with a production application. The SCOPE 1 of a group is confined to all resources and users within that group and those of all groups that are subordinate to that group. Using normal options, RACF automatically and transparently handles the various groups of a user. Owner: Each entry (or profile) in the RACF database has an OWNER. The owner must be a RACF defined USER or GROUP. The RACF owner of a profile has full administrative authority over the profile. Ownership by a group has several administrative advantages. One aspect is that groups tend to be more static than users and that ownership does not have to be reassigned as users are deleted. In addition, a group profile that is designated as the owner of other profiles provides a group administrator full administrative authority over the other profiles. This hierarchy of ownership is only for administration; it does not affect authorization to a resource. Access Authority: RACF levels of access authorization that can be assigned to users or groups are hierarchical, i.e., a given level includes the privileges of lower levels:

ALTER - full power over profile and resource CONTROL - allows VSAM CI level access UPDATE - read and write a data set READ - read a dataset EXECUTE - execute a program NONE - no access allowed
These levels were designed for data set access; their interpretation for general resources depends on the context. Typically, access of READ or higher is interpreted as a yes answer by the application or subsystem that checked the users access to a general resource.
Access List: Access lists are the parts of RACF profiles that list authorized groups or users together with their level of authority. Standard access lists are commonly used; they contain unconditional access rules to a resource. Conditional access lists are optional and less frequently used. They allow the specification of conditions that must be met before access is granted. One conditional access list deals with conditions such as working on specific terminals, consoles, and so forth. The other implements program access to data, known as PADS to RACF and program pathing to CA-ACF2.
This is an administrative scope, rather than an access scope.
Universal Access: Universal access defines public access to a resource. It applies to all users not represented on the standard access list (either directly or indirectly through groups). If used alone, UACC applies to all users, whether RACF-defined or not. If used in conjunction with ID(*), an optional access list construct representing RACF-defined usrids, UACC represents undefined users only. RACF Protected Resources: RACF resources are all the components of a computing complex required by a job or a task. RACF resources include input/output devices, processing units, data sets, job output, nodes, programs, and other items that must be kept secure for normal business operations. RACF protected resources can be divided into two categories:

Data sets General resources
RACF Profiles Both are described by profiles. A profile can be a DISCRETE PROFILE or a GENERIC PROFILE.: A discrete profile protects a single resource. The profile name reflects the name of the resource; it contains a resource description, an owner field, the authorized users, the access authority of each user, and, in the case of data sets, the volume of the data set. When a discrete profile is used to protect a data set, the RACF indication bit is set in the DSCB for that data set. In general, discrete profiles are no longer used for data set protection, although the function is still supported for backward compatibility.
A generic profile protects one or more resources that have a similar naming structure and identical security requirements. The profile name reflects key elements of the names of the resources it protects. The profile contains, among other elements, a description of the resources, including the authorized users and the access authority of each user (access list).
Data Sets: Data set resources include both DASD and tape data sets, and are defined in the RACF database using DATASET PROFILES. A data set profile contains information about the profile owner, universal access, and other optional information, such as the device volume serial number and data set security classification. Before a data set profile can be created in the RACF database, the data set high-level qualifier must be defined to RACF through a GROUP PROFILE or USER PROFILE. In practice, group profiles are the preferred way because of implied access rights to user data sets.
If a data set is protected by several different profiles then RACF searches for the best fitting profile from the most specific to the least specific profile. Access is then granted or denied according to the security classification associated with the data set and the user requesting access, the access lists contained in the selected resource profile, and user attributes.
PROTECTALL FAIL: A global switch determines whether RACF will enforce default protection for data sets. This is the PROTECTALL option, and most installations use it. It has an optional subset known as WARN mode, in which non-protected data sets can be used, with RACF issuing messages to the user and the administrator about the use of non-protected data sets. : Global Access Checking The RACF Global Access Checking (GAC) is used to improve the performance of RACF authorization checking by performing table-based checking for trivial access to selected resources. This table is
Migration to RACF
Figure 2. Simplified RACF Authorization Checking. cover the normal cases.
This is not a complete flow of access checking, but it does
maintained in storage and is checked early in the RACF authorization checking sequence.
General Resources: A general resource is any resource other than a data set. For example, transactions, TSO logon procedures, and job SYSOUT are general resources. RACF defines the set of general resources in a CLASS DESCRIPTOR TABLE (CDT), which identifies one or more entities with a resource class name. This table includes the resource class name, all syntax rules, and auditing and statistical control. A standard IBM supplied CDT is installed with RACF at initialization time. You can define your unique class names in a user CDT to represent your installations requirements in addition to those defined by RACF.
A conversion to RACF may require you to add installation-defined classes. Protection of a general resource is through use of one or several profiles, either specific or generic. Note that authorization checking is the same as data sets, but there can be different interpretations of what READ, UPDATE, ALTER, and so forth mean when the protected resource is not a data set. General resource classes are usually defined in pairs, consisting of a MEMBER class and a related GROUP class. Depending on the resource manager for these classes, either the member class or the group class or both may be used. Group classes are designed to protect several resources with dissimilar names but identical protection requirements through a single profile. The protected resources are members of the profile and the profile name does not relate to the resource names. See 2.3, General Resource Protection on page 25 for more information.
RACF Options: System-wide RACF options are defined by values set by the SETROPTS RACF command. Mainly, these options deal with:

Auditing, writing SMF records Statistics, kept in some RACF profiles Activation of classes Use of generic profile options In-storage profiles, used for performance JES job verification Default JES user IDs data set protection and access Password rules SECLABELS, used for B-level security Default language settings
Setting appropriate values for general options is an important part of migrating to RACF.
Commands: RACF administration commands are TSO/E commands that may be executed either on-line from a TSO terminal or as a part of a batch job. RACF ISPF panels and REXX procedures are both available in addition to the basic TSO commands. Some RACF commands can also be issued as console commands. Templates: All information stored in the RACF data base is formatted by templates. The RACF manager, the RACF component maintaining the RACF database, uses the templates to address and interpret the various database fields. This technique has enabled IBM to add new fields as needed and to allow simple release upgrades; different RACF releases can share the same database during a migration.
Migration to RACF
Authorization Checking
A simplified flow chart of RACF authorization checking process for data set access is shown in Figure 2 on page 7. Some special mechanisms that may grant or deny access have been omitted for simplicity; they include security bypass based on the PPTNOPASS bit, the RACF PRIVILEGED or TRUSTED attributes and RACF exits. The flowchart was designed to show the order of checking and the resulting priority of the different control mechanisms.
1.3 MVS System Integrity

An MVS security subsystem, whether RACF or CA-ACF2, is pointless if MVS integrity is seriously compromised. Perfect system integrity may be an unrealistic target, especially since there is no way to verify such a goal, but you should do everything you can do to avoid compromising MVS integrity. IBM takes MVS integrity very seriously; a key goal during migration should be to maintain the integrity of the delivered MVS system.
Goal
The goal of MVS integrity is to prevent bypassing or alteration of the MVS components that provide basic system operation and security functions. Some elements of integrity are within the scope of RACF or CA-ACF2 (such as data set protection), and other elements (such as poor SVC design) are outside this scope and are not discussed in this document. The protection of system data sets is the key contribution of RACF or CA-ACF2 to system integrity. Protection of these data sets can be categorized thus: 1. A few data sets may contain confidential information, and general users should not have any access to these. Examples are: spool (in the sense of directly reading the spool data sets), paging data sets, the RACF database, SYS1.PARMLIB (usually), and so forth. 2. Some system load libraries, while not containing company confidential data, should be available only for execution. Denying READ access to these libraries reduces the potential for hacking. 3. Many system data sets should have READ access for general users. 4. A few system data sets, such as SYS1.BRODCAST, have universal write access. While, in principal, system integrity is maintained by merely denying update access to certain system data sets, in practice a mixture of no access, execute-only access, and read-only access is needed.
Functional Issues
Several key issues for integrity are:
Are all the necessary data sets protected at the right level? Can we identify all data sets that function as part of the system? Are there global tables (RACF) or privileges (CA-ACF2) that cause normal protection to be bypassed? Are global options (RACF or CA-ACF2) properly set? Is there an audit trail for changes to these data sets?
There are several MVS controls that, with appropriate programming, permit bypassing the security monitor. These include authorization lists in SYS1.PARMLIB(IKJTSOxx), TESTAUTH commands, and PPT table entries. If these functions are not managed correctly, then RACF or CA-ACF2 controls are not meaningful. Note that the same possibilities exist for any authorized program, and controlling updates of authorized libraries is the cornerstone of system integrity.
Terminology
The trusted computing base (TCB) 2 is the part of the operating system that must work correctly in order to prevent bypassing the security controls. If a user can execute a special SVC, or execute a certain program from a certain library, and then bypass RACF or CA-ACF2 checks, all the data and programs in your system are at risk. Within the MVS community, this issue is usually addressed as system integrity concerns. The global term Trusted Computing Base can include many topics (such as trusted program distribution, program design verification, periodic verification that trusted programs have not been changed, and so forth), but the final goal is system integrity , in the sense used by MVS specialists. Since this document is for MVS specialists, we will use the term system integrity instead of TCB unless we reference a topic outside the normal sense of MVS system integrity. Other than names (and functions) of global controls, there are no fundamental terminology differences between RACF and CA-ACF2 for this area.
Basic TCB Concepts

Bypassing the security system (RACF or CA-ACF2) typically involves several steps. 3 The first step is to bypass system integrity -- this means obtaining program control in an authorized state . In MVS, any program that obtains control in protection key zero to seven, or in supervisor state, or in APF state, is executing as an authorized program . (APF state means that a program was loaded from a program library that was defined as an authorized library, and the program was linkedited with AC=1.) Note that it is the program that may be authorized , not the user. 4 Furthermore, simply being authorized does not automatically permit the program to bypass RACF or ACF2 controls. It does permit the program to manipulate protected MVS control blocks in ways that permit bypassing normal security controls. Knowledgeable MVS assembly-language programmers know how to do this, if they can obtain control in an authorized state. There are a variety of ways to go about it, and we will not discuss these. The underlying goal of MVS system integrity design and function is to prevent an unauthorized program from obtaining control in an authorized state, where authorized state is as defined above. The security system is a key element in
MVS-oriented systems programmers know that TCB means Task Control Block; this is a fixed, long-standing acronym used with MVS. However, for the purposes of a general, somewhat technical security discussion, we might use an alternate meaning of TCB (Trusted Computing Base). This is contrasted to UNIX, where a single step, executing as UID=0 (commonly known as root ), permits a user to automatically bypass almost all security mechanisms. This is contrasted with UNIX, where an equivalent level of authority can be associated with a user, and extend to any program that user executes.
10
Migration to RACF
maintaining MVS system integrity. In particular, the security system must prevent users from writing into system libraries. In this context, any authorized library (APF authorized, or APF-listed) is considered a system library. Used in the normal manner, both CA-ACF2 and RACF have adequate protections for data sets. However, both have extensions, intended to improve performance, that may short-circuit some of the basic data set protections.
Migration Issues
There are few integrity issues that are unique to the migration process. However, the migration project should include a review of key integrity items. These include:
Identifying all authorized libraries. If automatic LNKLST authorization is used, then multiple lists must be referenced. Determine how to handle dynamic APF list additions. Translate relevant CA-ACF2 global options to RACF equivalents. The PPT NOPASS option permits bypassing some SAF calls. In keeping with MVS design architecture, all RACF functions are obtained through SAF. In CA-ACF2, only some functions have been obtained through SAF traditionally, although newer releases use SAF more extensively; other CA-ACF2 protection has been obtained by hooks into the system, and these have not been not bypassed by PPT NOPASS. Because of this, the PPT entries in a CA-ACF2 system may not not reflect the actual level of protection required. These must be reviewed as part of migration.
Summary
With proper controls, MVS offers excellent system integrity. RACF can readily provide the necessary security management controls to maintain this integrity. We recommend that a migration project always include a review of MVS integrity, even though some of the issues are outside the narrow scope of CA-ACF2 to RACF database conversion.
1.4 Migration Considerations

The migration from CA-ACF2 to RACF involves more than a conversion of database records. Some of the key elements are discussed in this section. We must first note that this is an excellent time (just before your migration) to review, rethink, and polish your security policy. A clear vision of what you want to produce will help the migration work, and provide better results.
Management Involvement
You need strong management commitment to undertake a major conversion of any kind. Owners or managers of production applications, in particular, must be involved in testing phases. This is an additional task for these people, and there must be sufficient management commitment to force testing compliance on a reasonable schedule.
11
Test System
It is not practical to run both CA-ACF2 and RACF on the same MVS system. Likewise, it is not practical to undertake a migration to RACF without having a RACF system available for testing. In this case testing means a large range of testing, and this is not practical on any production system. Therefore, you need a RACF MVS system solely for test purposes. In practice the test system is most likely to be a Logical Partition (LPAR) on a larger processor. With some care, the test MVS can share DASD with your production data, making testing much easier. Whether you clone your production MVS (removing CA-ACF2 and installing RACF), or install a new MVS (with RACF already integrated) is your choice. In either case, systems programming time is needed to install, make ready, and maintain the test MVS system.
Education
You can obtain a reasonable overview and understanding of RACF by reading the RACF manuals. This is sufficient for many purposes. However, if you are the migration leader, or intend to be the primary RACF specialist in the organization, you should arrange for formal RACF education.
Application Involvement
A major goal of the migration project is to avoid disruption of production applications, and this can be accomplished only with sufficient testing. Major applications can be complex, with many jobs, files, procedures, and programs involved. Specific job and application knowledge is usually required to test these applications, and this means involvement by the application group(s). They must help you test their applications in the new RACF environment.
Manpower and Timing

For a security subsystem to be effective, it must be very tightly tied into the heart of the operating system. Given this, then it is quite difficult to make a major change in the security subsystem without impacting system production. A large, production MVS installation has many complex jobs. Some of these are rarely used, such as year-end jobs or obscure recovery jobs. The bulk migration of basic CA-ACF2 user records and rule records can be automated. However, testing the results of this conversion, and discovering/migrating all the special cases that exist -- without disrupting production -- is another matter altogether. Nevertheless, this is the requirement for almost all CA-ACF2 to RACF migrations. It is these practical considerations that dictates the time frame and manpower needed for migration. No single plan can apply to all situations. However, a time frame of six to nine months, with one full-time person and several part-time people is typical. See Appendix B, Sample Migration Plan on page 107 for an overview of one migration plan.
Clean Databases
One of the lasting aphorisms of the data processing business is Garbage In Garbage Out, commonly known as GIGO. While it is a complex, one-time activity, migrating a security database from one product to another is a data processing function, especially when an automated tool is used to help perform part of the work. A fairly clean input database at the beginning of the migration will help produce a higher quality result. There is no magic in the migration
12
Migration to RACF
process or tools that will automatically clean up substantial problems in the initial database. Unless meticulously maintained, a security database tends to accumulate a certain amount of unwanted or erroneous entries over time. There are a number of causes: changing security administrators, changing philosophy of security management, former users who still own resources, and so forth. You have several choices for handling these problems:
Make a reasonable effort to clean up your original database, before starting the migration process. Migrate whatever is in your original database, and clean up the resulting RACF database. Ignore the problems, and accept whatever appears in the final RACF database.
The first choice is the best one. You understand your current CA-ACF2 database, and have the skill to review it. While reviewing and correcting a large security database is not an enjoyable task, it will certainly reduce future problems. Some migration tools may help you clean up your current database; see Chapter 7, IBM Migration Services on page 97 for one example. Schedule pressures may push you toward the second choice. The problem with this approach, cleanup after migration, is that the migration process may amplify the problems in the original database. The conversion of a CA-ACF2 database to a RACF database is not a simple, one-to-one process. Small anomalies in the input, easily corrected there if someone would take the time to do it, might create large unwanted structures in the output. A pre-migration review process should consider (and correct) obvious errors in the database. It should also consider design and philosophical changes that will produce a better database after migration. Again, small changes here may make the migration much easier, and produce a better result. Examples of such changes are the elimination of global flags that are not really needed, or removing SCOPE controls that are outdated. In practice, of course, you are likely to use all three choices: some clean up of the original database, some clean up of the RACF database, and then go into production with the resulting database.
1.5 RACF Documentation

A number of documents are available for the RACF product. You should obtain a full set of documentation as part of your migration planning. The documentation includes:

General Users Guide. This provides basic user level information. Security Administrators Guide. This is the primary document for planning and implementing RACF. Command Language Reference). This contains the formal description of all RACF commands. Master Index. This is an extensive index for all the RACF books. Auditors Guide. This document describes the auditing facilities of RACF, the report writer, and the data security monitor.
13
System Programmers Guide. This explains the maintenance processes for RACF and its database. Messages and Codes. This document contains detailed information for all the RACF messages. General Information. This provides an overview of RACF, and the differences between the current and previous release. Planning: Installation and Migration. This contains useful information about moving from a previous release of Callable Services. This explains how to call RACF services directly. External Security Interface (RACROUTE) Macro Reference for MVS. Macros and Interfaces. This explains the format and use of the direct RACF macro functions. RACF to the current release. Data Areas. This contains control block and record descriptions. It is a licensed document. Diagnosis Guide. This contains information that may be needed if you must perform any debugging activities within RACF. Program Directory. This document cannot be ordered by itself; it is provided only with the product tape. It contains detailed installation information not found elsewhere. Command Syntax Booklet. Licensed Program Specifications. This contains a brief, formal description of the functions of the licensed product.
This list is, roughly, in the order of usage. You may need several copies of the first few documents in the list, while one copy will probably be adequate for the others. The complete RACF library is also available on CD-ROM:
The RACF Version 2.2 Licensed Product Library is included with the RACF product. The RACF Security CD-ROM (SK2T-2180) contains RACF documentation from multiple releases (1.9 - 2.2), relevant MVS manuals, and a number of documents from the International Technical Support Organization and the Washington Systems Center. The Online Library Omnibus Edition MVS Collection Kit contains a wide range of MVS documents, including several releases of RACF (through release 2.2).
As part of migration planning, we also recommend these documents:

CICS-RACF Security Guide 4.1 (ZES1-1723) RACF Version 2 Release 2 Technical Presentation Guide (GG24-2539) Securing the Open Client/Server Distributed Enterprise (SC28-8135-01)
14
Migration to RACF
Chapter 2. Basic Concepts

This chapter addresses key areas of security protection and describes the approach RACF uses for each area. It covers the most commonly used RACF functions, while other important features are addressed in the next chapter.
2.1 Users and Groups

RACF, very much like CA-ACF2, controls the access of objects by subjects; the subjects are called users and the objects are called resources. To facilitate easier administration, users are organized in groups. A user must be in at least one group, the default group, but can be connected to many groups. The term object applies to both tangible entities, such as a file, and logical concepts, such as permission to use a certain function in a program. The primary purpose of a group is to represent multiple users with identical job functions and access authority. Adding one group entry to access lists rather than a multitude of user IDs keeps access lists simple and makes maintenance much easier. Both users and groups are maintained in RACF in profiles, i.e., every RACF-defined user has a user profile and every RACF group a group profile. Related user and group profiles point to each other. When RACF is delivered to customers, it has one user, IBMUSER, and one (real) group, SYS1, predefined. You must add your groups and users and we recommend that you start with your groups. For this reason, we discuss groups next.
RACF Groups
Groups are generally used in RACF for two different reasons: 1. The main purpose of RACF groups is, as outlined above, the simplification of security administration through functional groups providing access to member users. 2. In addition, groups are used to define high-level dataset qualifiers to RACF (RACF protects only data sets with HLQs that are defined as a user ID or a group name). When designing your groups, you should attempt not to mix the two concepts and keep these types separate. It may be practical to design other subtypes. A typical installation could have the following types of groups:
Functional Groups Functional groups could be used to describe job functions or roles. Rather than include individual user IDs on access lists you would only include the functional group, for example, PAYADM. You would then connect and remove users from this group as their job roles changed. The group PAYADM may appear on resource access lists like datasets, transactions and SDSF.
Holding Groups Users could be assigned to a holding group as their default group. This holding group, by itself, would have no access privileges. It would keep the
15
administration under a single point of control. As users are required to perform functions they would also be connected to the respective group.
Administrative Groups These groups would be used where the organization wishes to decentralize the administration of RACF. For example based on geographic location or industry divisions. These groups do not necessarily have to own resources on the system. They also do not need to appear on access lists. For example an Enterprise that spans the world could have at the very top of their group tree group names AMERICA, EUROPE, ASIA and AFRICA. These groups are only used to identify the region and not used for access control.
When a group is defined by the security administrator, RACF builds and maintains a group profile containing all information about that group. Some of this information is the group name, the groups position in the hierarchy, any sub-groups the group may have, and all connected users. RACF groups exist in hierarchy with group SYS1 at the top. Each other group has a superior group, and a group may also have subgroups. The group hierarchy has significance for security administration but not for access checking. When administering group profiles, the administrator must be aware of the group hierarchy, when assigning groups to access lists the hierarchy can be ignored. The group structure is used in RACF in conjunction with group ownership to define and limit the scope of group administrators, i.e., users with the group-SPECIAL attribute. Before discussing RACF group administration, we must first understand OWNERship. Each profile in the the RACF database has an owner. The owner must be a RACF defined user or group. For ease of administration, group ownership is the preferred method. The RACF owner of a profile has full administrative authority over the profile. In general, group ownership tends to be more stable than individual ownership, making administration easier and more accurate. In the specific context of decentralized administration, the group administrator can act within the defined scope of group . This is, in principle, defined by the ownership of the group where he has group-SPECIAL and extends to all groups and resources below this group as long as group ownership is maintained. When building a group structure, attention should paid to who owns the groups. Planning ownership will allow for easier decentralized administration later on. By establishing a hierarchical group structure so that subgroups are owned by their superior groups, the authority of group user attributes, for example group-SPECIAL, will flow down the group tree as far as the administrator requires. A users attributes in the subgroups is the same as if the user was connected directly to the subgroups with that group attribute, such as group-SPECIAL. Many installations pattern their group-user structure after their organization charts. It is important to note again that scope of group is used purely for administrative control. It is not used for access. For example, a user connected to a group near the top of a tree will not have access to resources owned by groups lower down the tree. They may have administrative access and can issue a PERMIT command to give themselves access, but they do not have access by default.
16
Migration to RACF
Figure 3. RACF Base GROUP Structure
A RACF group has an alphanumeric name with a maximum length of 8 characters. Names of functional groups often reflect the job function or department they represent. Some installations have established standards to include certain special characters in group names for easier distinction from user IDs.
CA-ACF2 Group Migration Issues

When converting from CA-ACF2, RACF groups are typically created based on information in the UID string.
RACF User
A RACF user is identified by a user ID. The composition and length of a user ID depends on its intended use. TSO user IDs must be alphanumeric (starting with an alpha character) and have a maximum length of 7 characters. Other RACF user IDs, exclusively used for e.g., CICS or VM, may have other characteristics and can be up to 8 characters long. The primary use of user IDs is for real users, i.e., persons accessing an environment protected by RACF. Another legitimate use of user IDs is for processes such as a started procedure or a job. However, sometimes a user ID is actually used for a group of users who share the password. In this case individual accountability is lost and many organizations prohibit this in their policy. When a user is defined by the security administrator, RACF creates a user profile.
User Profile: The user profile describes the user by name (user ID), the user s password, privileges assigned to the user, the groups to which the user belongs, and optional information such as the time of day user can use the computing system. The user is now under RACF control. To access the computing system,
17
the user must adhere to all RACF security requirements. Keep in mind that the user need not control information other than his own password, although he might also control his user ID HLQ, a group HLQ, general resource profiles, and so forth. Users must be a member of at least one group, their default group. Users can be connected to many other groups as well. For users who are members of multiple groups, RACF access checking can occur in two ways, depending on the setting of list-of-group checking, a RACF option. If this option is turned off, the users access is determined by the current connect group, i.e., the one group specified (or defaulted to) at logon. To enable the user to use each group s access rights simultaneously, list-of-group checking must be enabled. This will appear to the users as if they were logged on with all their groups at the same time. List-of-group checking is enabled in most commercial RACF installations.
User attributes: User attributes determine the privileges the user has when using the system. The three most prominent user attributes are:
SPECIAL - the RACF administration privilege enabling the user to issue all RACF commands OPERATIONS - the privilege to access all data sets and some other resources AUDITOR - the privilege to read all RACF definitions and to control the audit settings.
These attributes can be assigned at the system level or group level. When attributes are assigned at a system level, for example SPECIAL, which allows the user full control over all the profiles in the RACF data base, or AUDITOR, which gives the user total responsibility for auditing security controls, the attributes apply across the entire system. When attributes are assigned at the group level, the RACF privileges are restricted to a specific group and its scope.
User Segments: The RACF user profile can also contain several segments which are in addition to the base RACF segment. These segments consist of fields which contain more specific information about the user in the context of a subsystem. For example the CICS segment contains a field called TIMEOUT. This field determines how long a user can be dormant before CICS will automatically terminate the session.
As more products use RACF to validate security the number of segments in the RACF profile will expand. RACF Version 2.2 currently supports the following user segments:

TSO DFP CICS OMVS OPERPARM WORKATTR LANGUAGE NETVIEW
18
Migration to RACF
CA-ACF2 User Migration Issues

Migrating the basic user from CA-ACF2 to RACF is not a complex task. What may become more complicated is the migration of privileged users. Some of these privileges can be carried across into RACF while there are a few that will require careful planning and possibly an exit. We have tried to keep this section focused on some fairly common areas. We have noted where RACF has no corresponding function.
Translation of CA-ACF2 UIDS

Each user is defined to CA-ACF2 by a unique LOGONID and LOGONID record. This LOGONID record is used for user verification and resource access validation. The CA-ACF2 LOGONID record fields are installation-defined by the CA-ACF2 Field Definition Record. These fields define:

The LOGONID (LID) The user name User privileges User system history User TSO attributes (optional) Other product-related (such as IMS) information (optional) Other CA-ACF2 system related information
A user identification (UID) is also used by CA-ACF2. The UID is a character string selected from the previous previously listed fields. Field selection and the order of concatenation are determined by the field definition record. The UID contains more than a RACF user ID:
It has a LOGONID, one to eight characters in length, used for LOGON/SIGNON and general identification. For example in Figure 4 on page 20, we can see how a very basic UID could be expanded into a RACF user ID with equivalent RACF GROUP connections. Other fields, which are typically used as: FUNCTION is the first field - length is three characters DEPARTMENT is the second UID field - length is three characters BRANCH is the third field - length is two characters
All users on the same system, performing the same function, and within the same application have the same values for the FUNCTION field, DEPARTMENT field, and BRANCH field in their UID. The LOGONID value is unique.
UID Translation Exceptions

Embedded blanks can be part of the UID string. Since RACF does not allow embedded blanks, a standard must be developed for such situations prior to the conversion. Another problem that may arise occurs when the length of the UID field, without the LOGONID, is more than eight characters. This is longer than a RACF group name can be. These exceptions may not impact most users but careful consideration must be given when they do.
19
Figure 4. Possible CA-ACF2 Logonid Conversion to GROUP and USERID Structure
Adding Additional Fields in the RACF User Profile

We now consider other fields in the CA-ACF2 LOGONID records that can be converted into the RACF user profile either with an ADDUSER command, or, after the ADDUSER command has been executed, by an ALTUSER command for the same user ID. These additional fields are:
NAME and PHONE The (optional) NAME field of the identification section of the CA-ACF2 LOGONID record contains the name of the user. The PHONE field contains the telephone number of the user. As RACF provides a NAME field of 20 characters in the USER profile this presents no problem in a migration. The CA-ACF2 PHONE field may be entered into the INSTALLATION DATA field (255 bytes) of the RACF USER profile. Care must be taken as other uses for this field may be found and it will be up to the installation to decide on how to administer it and also delimit the entries contained within the field. An alternative would be to use the WORKATTR segment in the RACF USER profile.
CANCEL or SUSPEND The CANCEL or SUSPEND attribute indicates a LOGONID that cannot be used to access the system. The RACF attribute REVOKE (without date) should be the translation used for the CANCEL/SUSPEND attributes.
SHIFT A pointer to a SHIFT record is in the SHIFT field of any section of the CA-ACF2 LOGONID record. The SHIFT record defines the allowable system access periods for this specific CA-ACF2 LOGONID for logon and resources. A translation of this field can be made with the RACF USER profile WHEN field. An ALTUSER command is used to implement this translation. Note that RACF does not support the SHIFT privilege for resources. This will need to be addressed when building the migration process.
PASSWORD
20
Migration to RACF
CA-ACF2 user passwords are encrypted and stored in the CA-ACF2 data base using a one-way DES encryption algorithm, similar to RACF. Unfortunately, you cannot just copy the CA-ACF2 passwords into the RACF database or vice versa. If possible, users should not be forced to change their password when cutover takes place. Each installation must address this issue individually. One potential scenario is for an exit to capture the users password, encrypt it and store it in the users LOGONID record. At conversion time you can then decrypt the password and use it for the new RACF user IDs. This means that users will keep the same password and the conversion process remains transparent to them. A problem is, of course, that you are storing passwords for the duration of the migration in a decryptable form. The algorithm and keys should be entrusted to one person and carefully audited until cut-over.
STATISTICS and HISTORY In the conversion process, you may want to keep track of previous statistics recorded for a user in the CA-ACF2 LOGONID record. The RACF installation data field, whose length is up to 255 characters, can contain a copy of selected fields from CA-ACF2 the LOGONID record or any other requested data can be copied.
2.2 Data Set Protection

Data set protection, along with user authentication, is the most basic function of RACF and CA-ACF2. Data set protection is usually the primary reason for implementing an MVS security product, and most if not all installations protect data sets before using other CA-ACF2 or RACF functions. The quality of protection that is achievable depends on product functions as well as on installation-specific parameters such as naming standards. In our assessment, the data set protection functions of CA-ACF2 and RACF are largely equivalent, and we believe that the installation standards are the key factors determining the resulting protection of data sets. Access rules in CA-ACF2 and access lists in RACF can become long and complex unless well-defined naming conventions for users, groups and datasets are established, and group structures are clearly defined.
Goals
The goal of any implementation or conversion should be default protection, appropriately restricted public access and specific access defined according to the principle of least necessary privilege. In addition, the administration of access authorities should be easy and create little overhead. Access should be given to groups, and not specific users, whenever feasible and practical.
Control Issues
Key control issues for data set protection are:
The security system may not be called to control access to data sets. When using the SAF interface (standard in RACF and optional in CA-ACF2), the PPTNOPASS privilege must be considered. When using intercept points, dependencies may exist with regard to software levels.
21
Unprotected data sets may exist. Only if default protection is implemented (MODE ABORT in CA-ACF2 and PROTECTALL FAIL in RACF), access to unprotected data sets is prevented. Public access may be inadequate. A temptation exists in all security environments to grant high levels of public access to data sets in order to simplify administration. This is done in CA-ACF2 rules through UID(*) entries and in RACF through UACC and ID(*) specifications. Excessive user privileges may bypass many rules. All security systems offer user privileges that bypass normal rule checking. The CA-ACF2 NONCNCL and READALL privileges and the RACF OPERATIONS attribute fall into this category. Specific access may not be in line with policy. Access rules may not exactly reflect policy for two main reasons, policy may require a more granular control than technically possible, or policy may change over time while access rules do not. Data set protection rules may be difficult to understand or audit. This is often the case in CA-ACF2 when the $NOSORT option is used; in RACF an incorrect use of Global Table entries may contribute to such confusion. Application integrity may require program pathing. The nature of an application such as payroll may require a need for eliminating access to files through other than certified application programs, e.g., TSO EDIT access may not be acceptable.
While all these issues exist in both environments, a migration from CA-ACF2 to RACF is probably a good time to revise some of these controls.
Security Interface
CA-ACF2 can set intercept points (modifications) in key MVS routines, or use the SAF interface. The general use of SAF is a fairly recent feature, and many CA-ACF2 installations use the intercept implementation. In this case, when CA-ACF2 is installed, intercept points are inserted in all the DADSM functions, so that CA-ACF2 will be called each time a dataset is accessed. When SAF is used, the ALWAYS CALL function of DFP will cause a RACROUTE call when a dataset is accessed, except for programs the have the PPT NOPASS property. 5 Note that this property bypasses RACF checking because RACF always uses the SAF interface; it bypasses CA-ACF2 checking if CA-ACF2 uses the SAF interface for data sets instead of code modification.
Protection Modes
Both products can be set to enforce default data set protection, i.e., denial of access to data sets not covered by an CA-ACF2 rule or a RACF profile. When no CA-ACF2 rule is found for a data set, the GSO MODE option or the RULE $MODE option will decide what will happen. If MODE is set to ABORT, the dataset must have a matching rule set, otherwise access is denied. If the global RACF option PROTECTALL(FAILURES) is set, RACF will require a matching profile for all accessed datasets. 6 Without a profile match, access will be denied. So CA-ACF2s MODE=ABORT and RACFs PROTECTALL(FAILURES) will both require all datasets to be protected.
5 6
The DFP ALWAYS CALL function is not an option that can be turned on or off. Note that a Global Access Table entry can also allow access.
22
Migration to RACF
CA-ACF2 MODE can have these setting: QUIET, LOG, WARN, RULE and ABORT. RACF PROTECTALL can have these settings: not specified, WARNING and FAILURES.
Not specified can be compared to RULE mode. If a profile exists, grant access accordingly. In RACF, if no profile is found, dataset is UNPROTECTED. WARNING or WARN has approximately the same function in both products. Check access rules, but always grant access and report any violations to SMF. FAILURES is the same as ABORT. CA-ACF2s QUIET is the same as having no profiles defined and all datasets are UNPROTECTED. The CA-ACF2 LOG mode could, theoretically, be replaced by RACF AUDIT(ALL), but this may not be a practical solution.
RACF Profiles: Consider the following CA-ACF2 access rule set:
$key(SYS2) $mode(ABORT) PARM***.PARMS UID(ITSO-) read(a) PARMLIB.- UID(km1234) read(a) write(l) alloc(a) IMS.RESLIB UID(*) exec(a) - UID(*)
For RACF this could be converted as follows:
SYS2 would most possibly be a group-id. It is also a high level qualifier for datasets. SYS2 should also be the OWNER of all SYS2.something datasets. The CA-ACF2 generic data set name PARM***.PARMS would convert to a RACF generic profile of SYS2.PARM*.PARMS. In CA-ACF2, UID(ITSO-) read(a) permits all users whose UID begins with the characters ITSO to have read access to the indicated datasets. In RACF, we would create a group that is given read access to the profile for these datasets, and then connect all appropriate users to this group.
PARMLIB.- would be SYS2.PARMLIB.** with ID(KM1234) ACCESS(ALTER) UACC(NONE) AUDIT(SUCCESS(UPDATE)) OWNER(SYS2) GENERIC IMS.RESLIB would be SYS2.IMS.RESLIB UACC(EXECUTE) OWNER(SYS2) GENERIC. A fully qualified generic profile. It could have been a discrete profile if generic was not specified. Discrete means it covers only this specific dataset on this specific volume/unit combination and the DSCB protect flag is set. When such a dataset is opened, RACF will search for a discrete profile. If no such profile is found, it will look for a generic profile that could cover the request.
- UID(*) would allow no further access to data sets under SYS2.
RACF will first evaluate the RACF Global Table if present, then, if no matching entry is found in the table, always look for the most specific profile to use for access checking. CA-ACF2 also applies the most specific rule unless the $NOSORT option is used.
Protection by Volume Through the GSO option SECVOLS, users in CA-ACF2 can be granted access to datasets at the volume level. The access specified for the volume applies to all data sets it contains. : There is no equivalent facility in
23
RACF, so such CA-ACF2 rules must be converted to regular RACF data set profiles. 7 A common misunderstanding exists with regard to the RACF DASDVOL class. Although the name may suggest it, this class does not provide general volume level access nor allocation control. The RACF DASDVOL class is only used by programs that perform DASD management like DF/DSS or FDR.
Program Pathing Both products can control access to datasets through program pathing (CA-ACF2) or Program Access to Data Sets - PADS (RACF). : CA-ACF2 does it through the dataset rule by using the LIB and PGM control options. For ease of use, the GSO LINKLST option can be used to reduce the rule set to refer to SYS1.LINKLIB only.
RACF uses the PROGRAM class to define the controlled programs and libraries. On the dataset profile the additional statement WHEN(PROGRAM(xxx)) results in a Conditional Access List which is used to restrict access only through this program. The following must be observed:
In the PROGRAM class, both library name, program name and the volume for the library is specified. Any aliases of the program being defined must also be included in the PROGRAM class profile. In addition, the PROGRAM class profile can specify PADCHK or NOPADCHK (PADCHK is the default). PADCHK adds the following additional requirements: all programs represented by the opening tasks PRBs, and all programs that link to, load or call the program that opens the data set
must be controlled in class PROGRAM.
PADCHK may be difficult to establish and maintain and is therefore rarely used.
Erase-On-Scratch (EOS) should be used for confidential data to ensure that residual data cannot be accessed after deletion. Residual data is a potential security exposure for confidential data. : In CA-ACF2 it is done on a volume level based on the GSO AUTOERAS option. In RACF it can be done on a dataset level and as such can be very selective, and used without causing performance problems.
RACF Approach
Start with PROTECTALL(WARNING) mode to enable corrections in the setup and adjustments in the access lists, but always target PROTECTALL(FAILURES). It only affects dataset protection on DASD (and TAPE dataset if TAPEDSN class is active). Other resource classes are not impacted. Use group-ids as dataset highlevel qualifiers as much as possible, except for typical TSO user datasets. Establish UACC(NONE) as a basic rule for all profiles, but allow for exceptions when and where necessary.
By using exit programming, RACF can provide access control at the volume level.
24
Migration to RACF
Use group IDs as the owners of user ID profiles whenever possible. To help administration, use generic profiles whenever reasonable. When one generic profile can cover many data sets, this will also improve system performance. However, using too many fully-qualified generic profiles can hurt both performance and administration. Try to stay with group-ids for access administration, to keep access lists shorter and easier to handle. Userids on the access list should be an exception.
Summary
Each CA-ACF2 rule set must be analyzed for features used. Most of them can be directly translated to RACF profiles and ACLs, but some will have to be either converted, removed, or even converted into exit code, which should be the last option applied. The rule options that cannot be converted to RACF without some planning are:

$MODE used to change the GSO MODE for this rule set %CHANGE/%RCHANGE used to specify additional users with authority to change this rule set beside OWNER and SECURITY UNTIL/FOR used to put date/time limit on the access DDN used to limit this rule set to be used only when referred to by the DDNAME mentioned SOURCE used to control input sources. RACFs TERMINAL and JESINPUT conditional access lists can be used for part of this function.
2.3 General Resource Protection

General Resources are physical or logical objects , other than data sets, that can be protected through RACF.
Definitions
RACF-protected resources can be divided into two categories: data sets and general resources. General resource classes and their properties are defined in the RACF class descriptor table (CDT). Note that the SAF router table (which is part of RACF) must contain corresponding entries. The RACF CDT initially contains general resource classes defined by IBM; it is designed to accommodate additional installation-defined classes. Such classes are often used to provide protection for critical add-on products such as performance monitors, job schedulers, tape management systems and alike. The installation procedures for some products may require that you create a new class in RACF. Sometimes the FACILITY class is used for a limited number of profiles as an alternative to creating a new class. General RACF classes can also be used to implement application security by placing RACROUTE calls in applications and maintaining rules in RACF.
25
General Resource Considerations

Except for class FACILITY which is designed to control various resource types (through a limited number of profiles), general classes are typically used for one specific resource type. The length and syntax of resource names depend on the type of the protected resource and are defined in the CDT. As an example, the resource name in class TERMINAL is the 8 character terminal name, while the name field in class JESSPOOL is composed as follows:
localnodeid.user ID.jobname.jobid.dsnumber.name
It follows that, for existing general resource classes, you must use the exact syntax as defined in the CDT and described in the RACF documentation. For installation-defined resource classes, the resource name can be chosen as required by the resource type. General resource classes can be defined in pairs of member and group classes, or can occur as single classes. In still another case, single nongrouping, non-member classes can be used. In some cases both parts are used, e.g., for CICS transactions where the standard member class is called GCICSTRN and the group class is GCICSTRN. In other cases only the grouping class is used, e.g., class PROGRAM. The basic concept is that the name of a profile is the resource name. Generic profile names can be used to protect several resources with similar names and identical protection requirements through a single profile. When the resource has both grouping and member classes, the generic entries would normally be created in the member class. To protect multiple resources with identical protection requirements but unlike names through one profile, group profiles (in resource group classes) can be used. Resource group profiles contain the names of protected resources 8 in their member lists; their profile names are arbitrary and the RACLIST function must be used before group profiles can be used for access checking. It is important to understand the use of access authorities in general resource classes. The RACF access authorities of READ, UPDATE, CONTROL and ALTER were developed for data set access where they are truly meaningful. They are also used for general resources, and the the original meaning may not apply, depending on the resource. In many resource classes the meaning is reduced to a simple yes/no logic; NONE is interpreted as no and any access of READ or more as yes. Several exceptions exist to this general rule, e.g., in the NODES class the different access authorities do have very specific meanings. The resource manager making the RACROUTE calls and interpreting the return codes can actually define the meaning of an access level, and the security administrator must understand its use in the resource manager. Default protection depends primarily on the resource managers interpretation of a profile not found condition (RC=4). Different resource managers handle this condition differently, e.g., IMS will grant access to transactions for which a RACF profile is not found, while CICS will deny access. You have two ways to enforce default protection: 1. by modifying the CDT entry (for installation-defined classes) to change R C = 4 to RC=8, or 2. by defining catch-all profiles (* with UACC=NONE) where appropriate.
Or they may contain generic names, but we recommend placing these in member classes.
26
Migration to RACF
We recommend the second solution.
Migrations Issues
CA-ACF2 has some options to define general resource rules; a description of important differences follows:
the UNTIL option on a CA-ACF2 rule set is not supported by RACF. An alternative is creating a group that is permitted access to the resource and connecting users with revoke dates. The same solution can be applied to the FOR() option. the SERVICE() option does not have a direct translation to RACF. You need to review the RACF class that you are planning to use and then select the authority you need. For each RACF class you can have a specific meaning of security levels: READ, UPDATE, CONTROL and ALTER. For the USERDATA option you have a INSTALLATION DATA field in RACF profile that can be used. This may require changes to the programs using this information.
Most general resources supported under CA-ACF2 can be converted to RACF, typically by creating a class in the CDT and the router table. An evaluation of the programs making calls to RACF may be necessary.
2.4 Global RACF Options

This section describes the system-wide security options for both CA-ACF2 and RACF. These options determine how the security product is protecting your system. The best conversion solution is presented for the system options of CA-ACF2 and how to implement these with RACF security. A table is included to show the most direct mapping of the CA-ACF2 system options (GSO RECIDs) to RACF.
Common System-wide Security Options

Table 1 contains the system-wide options common to both CA-ACF2 and RACF. These options may be fully mapped or best-fitting in RACF.
Table 1 (Page 1 of 2). System-wide Options C o m m o n to RACF and CA-ACF2
ACF2 GSO RECID AUTHEXIT AUTOERAS
Description provides for extended user authentication. Indicate the physical erasure of the DASD data set when deleted. Specifies programs authorized to use tape Bypass Label Processing. Specifies names of installation written exits.
Equivalent RACF Implementation RACINIT pre-processing exit SETROPTS ERASE and data set ERASE flag ICHBLP profile in FACILITY Class
BLPPGM
EXITS
Exits found during RACF start are activated.
27
Table 1 (Page 2 of 2). System-wide Options C o m m o n to RACF and CA-ACF2
ACF2 GSO RECID LOGPGM
Description Specifies programs for which all data set accesses are logged. Specifies the default ID for jobs coming into a system. A job sent to a node inherits the submitting LOGONID. Specify default user ID is assigned to batch jobs that enter the system and do not have a execution user ID assigned. Specify default STC ID. Specify what actions to take when a violation occurs. Tape data set protection. Specifies if UADS is being used. Specifies if JES Execution Batch Monitor support is active. Defines password controls and options. Defines global TSO usage and system options for TSO logon
Equivalent RACF Implementation AUDIT() operand of ADDSD; and LOGOPTIONS SETROPTS JES (UNDEFINEDUSER()) or NODES class profiles JESINPUT, JESJOBS, and NODES classes NODES class profile ADDMEM(user ID)
NJE DFTLID()
NJE INHERIT/ VALIN()/ VALOUT OPTS DFTLID()
OPTS DFTSTC() OPTS MODE()
Started classes or ICHRIN03 SETROPTS PROTECTALL() and LOGOPTIONS() SETROPTS TAPEDSN and TAPEVOL class The RACF TSO SEGMENT is checked first, then UADS SETROPTS JES XBMALLRACF
OPTS TAPEDSN OPTS UADS
OPTS XBM
PSWD TSO
SETROPTS PASSWORD() RACF TSO SEGMENT of user ID and TSO/E resource protection
CA-ACF2 Global System Options

GSO RECIDs not listed in Table 1 on page 27 that also have to be analyzed are listed below. Suggestions on how to convert these are offered where possible.
BACKUP - Defines the automatic backup procedures for the CA-ACF2 databases. RACF automatically maintains backup copies of profiles in a live secondary (backup) database as defined in the RACF Data Set Name Table (ICHRDSNT). Starting in RACF 2.2 you can direct RACF to maintain the backup at a different site; you can define the target node using the command TARGET.
28
Migration to RACF
For this reason, RACF does not have to perform automatic physical database backups.
LNKLST - Defines libraries that are considered part of the system linklist. This is used with the CA-ACF2 program protection facility. Analyze and document the use of the libraries identified in this record. If the use of these libraries is still valid consider using PROGRAM control in RACF. See 2.6, Program Control on page 34 for more information.
OPTS SAF - Activates the CA-ACF2/SAF interface. You dont have similar setting in RACF, because RACF uses SAF by default. (This is valid in 5.0+. 6.0+ uses CA-ACF2s own version of SAF.) OPTS STC - Validates data set accesses by Started Task Control (STC). The STC user IDs, groups, and privileges are defined in the STARTED class or in Started Procedures Table (ICHRIN03). You can assign either a PRIVILEGED or TRUSTED attribute to these entries. The PRIVILEGED attribute indicates that RACF will bypass validation on most access requests from this STC, without logging. TRUSTED means that RACF will bypass most validation checking, but that logging accesses by the STC can be turned on.
PPGM - Defines which users can execute specified programs. To restrict access to programs do the following: activate the PROGRAM class in RACF define a data set profile to protect the library define a profile in the PROGRAM class to protect the program:
See 2.6, Program Control on page 34 for more information.
If the RESDIR code is R , then this operand is the equivalent of the RACLIST function in RACF. Many applications load the equivalent RACF resource profiles into storage when the application is initialized. The security administrator can also RACLIST classes using the SETROPTS command. Note that most group classes require RACLIST usage. You must determine which R-type entries in RESDIR do not automatically get built in common storage by RACF. These equivalent classes must then be loaded by specifying the following SETROPTS command once.
SETROPTS RACLIST(classname,...)
If the RESDIR code is T then this operand is the equivalent of the NORACLIST operand of the SETROPTS command. NORACFLIST is the default. If you do not want the equivalent RACF profile class to be loaded into common storage then issue the following command once.
SETROPTS NORACLIST(classname,...)
There are no RACF options similar to CA-ACF2 option D . The only information that is loaded in users address space is informations from USER PROFILE, plus, in more specialized cases, generic profiles and RACLIST data.
29
RACF Options
This section describes some additional RACF options you should use when defining system-wide protection for your installation. The following example specifies that all the current RACF options be displayed. You must have the SPECIAL or AUDITOR attribute to issue the SETROPTS command. The attribute needed depends on the SETROPTS function. If you have the AUDITOR user attribute you can set and list audit-related functions and if you have SPECIAL you can issue all RACF commands except the AUDITOR s commands.
SETROPTS LIST
Additional RACF SETROPTS parameters can include:
NOADSP - Disallows the automatic creation of RACF discrete profiles. This parameter is strongly recommended and the use of generic profiles is encouraged. PASSWORD() - Specifies the monitoring and checking of passwords by indicating the following suboperands. The use of the operands may replace current CA-ACF2 logon and password exits: HISTORY() - Specifies that 1 to 32 previous passwords are saved and compared to a new password if specified. INTERVAL() - Indicates the number of days that the current password is valid (1 to 254). This value is used as a default for new users added with the ADDUSER command and is also used as the upper limit for the INTERVAL operand of the PASSWORD command. REVOKE() - Indicates the number of invalid passwords that can be entered before RACF revokes the user ID. RULEn() - Specifies 1 to 8 individual password syntax rules. The rule contains a length attribute and content keywords describing valid passwords. For example:
RULE1(LENGTH(8) ALPHA(1:3) CONSONANT(4,8) NUMERIC(5:7))

You can use the ICHPWX01 exit to perform additional checks for password rules, e.g , the password cannot be equal to the user ID.
PREFIX() - Enables protection of data sets with a single-qualifier data-set name and specifies an HLQ to be prefixed to these data-set names during RACF authorization processing. The prefix should be a defined group name and not an existing HLQ. PROTECTALL() - Enables protect-all processing. All data sets that do not have a RACF profile cannot be accessed, including data sets on DASD, GDG, and catalogs. Tape data sets are also included if TAPEDSN is active. The two operands used with PROTECTALL are: FAILURES - Causes RACF to deny access to all data sets that are not protected with a RACF profile. WARNING - Causes RACF to allow access to data sets that are not protected by a RACF profile and issue a warning to the user and security administrator.
The PROTECTALL parameter pertains only to data set protection. General resources are covered only by their existing resource profiles with specified access levels and an optional WARNING parameter.
30
Migration to RACF
Note that default protection of general resources can be controlled by catch-all profiles, e.g., profile name * with UACC=NONE.
2.5 Batch Job Submission

In commercial mainframe environments, batch jobs are an important part of day to day production. They are used in support of online systems as well as pure batch applications, and operating systems without batch job capabilities have limitations in satisfying commercial application needs.
Goals
Good batch job management has operational goals as well as control aspects. Operational goals include the timely and successful execution of jobs in a predetermined order; these goals are usually met through the use of job scheduling software such as CA-7 or OPC/ESA. The control aspects include:

secure submission of user-owned jobs, mostly test jobs control over the submission of production batch jobs control over access to job output the ID under which a job executes and its dataset access authority potentially control over production job names
Control Issues
Key control issues with batch job submission are
passwords may be exposed in the submission process (whether they are stored in files or added unencrypted during at submission time, all techniques violate the principle that no clear passwords should be stored) jobs with unknown user IDs may be executed, but their access to resources is limited to UACC-level access production jobs may have excessive privileges (the power to access any dataset across all applications, a violation of the least necessary privilege and granularity of controls principles).
Terminology and Differences

Jobs submitted from user address spaces (via TSO or batch INTRDR) are treated similarly in CA-ACF2 and RACF; the authority of the submitting environment is passed on to spawned jobs without user intervention. This concept is called inheritance in CA-ACF2 and propagation in RACF. The approaches to controlling production batch jobs in CA-ACF2 and RACF differ more:
the CA-ACF2 restrict attribute allows the definition of production logonids without passwords. RACF does not provide user IDs without passwords and there is no equivalent function in RACF. the CA-ACF2 jobfrom attribute allows the use of /*JOBFROM JCL statements for MUSASS; there is no equivalent function in RACF. the CA-ACF2 command ACFSUB (for TSO) and utility JOBCOPY (for batch or STC) enable authorized users to submit a job with a different jobname. In RACF more specific controls are available through surrogate user support without special commands or utilities. Surrogate user support uses the SURROGAT resource class to define batch user IDs which can be submitted by surrogate users and, for each id, which users or groups are authorized to submit (or cancel) jobs.
31
the .CA-ACF2 JCL statements /*LOGONID and /*PASSWORD are ignored in a RACF environment and the account field is not used to derive a valid RACF user ID. RACF user IDs must be provided on the job statement or via propagation.
The RACF Approach

Many different approaches to job submission have been developed over time; some involve TSO submit exits, router exits, scheduler exits, JES exits etc. The following, recommended approach is an effective and easy way to manage jobs in a RACF environment without exits:
Controlled Job Submission

Except for jobs submitted via RJE and NJE, passwords should not be specified on job statements (see also the discussion of RJE and NJE): 1. to submit a job under the same user ID (to have the authority of the current address space propagated), neither user ID nor password should be specified on the job statement. This is the recommended technique for user-owned jobs and does not require additional setup. 2. to submit jobs to be executed under a different (production) user ID, that user ID (and no password) should be coded on the job statement. This technique invokes surrogate user support and requires that the submitting user ID is properly authorized to the submitted user ID in class SURROGAT. This is the recommended technique for enabling job scheduler software to submit production jobs. The diagram below depicts the logic in JES and RACF:
32
Migration to RACF
Figure 5. Security Processing for Submitted Job
Required Controls The surrogate user support in RACF is only a technique to control job submission ; to achieve adequate controls, it must be used appropriately by:
specifying the SETROPTS option BATCHALLRACF to enforce that all batch jobs have a valid user ID, defining and assigning appropriate user IDs for batch production, i.e., individual IDs by application or processing type, and defining specific access authorities to these IDs according to the principle of least necessary privilege. authorizing only the job scheduler to submit production jobs, plus a few individuals in charge of production to restart failed jobs or perform maintenance activities. establishing change control over production JCL and protecting job libraries adequately.
Other Controls If production job names have operational or control significance, their use can be controlled by profiles in the RACF JESJOBS class. Profiles in this class control which users or groups of users can submit jobs with production job names. : If it is important to establish control over the job origin (CA-ACF2 source, RACF port of entry), profiles in the RACF classes TERMINAL and JESINPUT can be used to authorize users accordingly.
33
Control over spooled job input and output files can be achieved in RACF through profiles in the JESSPOOL class. Please see JES Controls and SDSF.
Summary
Batch controls in RACF are effective and easy to implement through user ID propagation for user-owned jobs and through surrogate user support for production jobs. No major problems are expected in migrating batch jobs from CA-ACF2 to RACF.
2.6 Program Control

Both products can control the execution of programs. This involves two steps, the protection of load libraries and the protection of specific programs in those libraries:
Load libraries in MVS are regular data sets and protected like other data sets through CA-ACF2 rules or RACF profiles. To allow the execution of programs in a library but prevent users from copying them, EXECUTE access can be used in both environments. Programs and TSO commands (considered programs in this context) are protected in slightly different ways. In CA-ACF2 there are several options. The PROGRAM resource class is available and can be used to control programs. Typically, an exit (VALDPGM1 is the sample) is installed as part of this control. For the specific programs defined in the PPGM and LOGPGM GSO options, profiles are defined in the PROGRAM class. In RACF programs are protected through profiles in class PROGRAM; program definitions are very specific and consist of three parts, the program name, the library name, and the volser of the DASD volume containing the library.
When protecting programs, it is important to note that
for programs with alias names, all aliases must be protected. For example, to effectively protect the superzap program, both commonly used names, AMASPZAP and IMASPZAP, as well as a number of less commonly-known names, must be defined in class PROGRAM. DASD maintenance and other changes of the environment may affect the established controls. Protection may be lost if a program library is moved to a different volume and the program profiles is not adjusted accordingly. Likewise, when moving programs to different libraries, program profiles may have to be revised.
Program protection is not a prerequisite for CA-ACF2 Program Pathing controls. Program protection is a prerequisite for RACF PADS, a technique to restrict data access through a specific program. This approach can improve application integrity by enforcing access through certified application programs and elimination other access (such as editors and other tools). See Program Pathing on page 24 for a discussion of Program Pathing and conditional access lists.
34
Migration to RACF
2.7 Started Task Control

Newer RACF releases have introduced the STARTED class which allows you to define SPT entries dynamically, using the RDEFINE and RALTER commands. When you use the STARTED class, you do not need to modify code or re-IPL in order to add or modify RACF identities for started procedures. Note: You must have a started procedure table (module ICHRIN03), even if your installations uses the STARTED class. RACF does not initialize if ICHRIN03 is not present. However, the table can be empty, as it is when delivered with RACF. The security issue regarding started procedures has traditionally been that security software expected to receive a job statement containing USER, GROUP and PASSWORD information for started procedures, until recently, could not contain job statements. It was therefore necessary to associate a started procedure with a user ID (and optionally a group name). CA-ACF2 and RACF use rather different techniques for this process. CA-ACF2 provides the capability to define logonids equal to the procedure name with an indicator that these IDs can only be used for STCs. RACF uses a Started Procedures Table to assign user IDs, group names and certain privileges to started procedures. The techniques to define and maintain the RACF SPT have changed over time, and different approaches are available. The way to define this relationship in early RACF releases was the Started Procedure Table that resides in module ICHRIN03 in the LPA library. The entries have the following information:
procedure name JES2 SCHEDLR
assigned user ID JES2 SCHEDLR
group name STCGRP STCGRP
optional privilege TRUSTED
To create or modify a started procedure table, you needed to:

Edit the Table Assemble and link-edit the update table Re-IPL the system with CLPA
This technique did not lend itself to frequent updates, and more dynamic approaches were developed. To eliminate the need for this cumbersome update process, a commonly used technique involved a generic (last) catch-all entry. Following static entries for standard procedures, the following generic entry was used:
procedure name *
assigned user ID =
group name STCGRP
optional privilege 00
This entry has the effect that all procedures not defined in preceding table entries use a user ID equal to their procedure name associated. The security administrator defines a user ID for each new procedure and connects it to the designated group. stcgrp in the examples above is the name of a group for STCs. It is important to define a group for the exclusive use by STCs group and to list this group in all SPT entries. With this information, normal access checking is performed for all started procedures using the associated RACF user ID and group name. You can indicate that selected started procedures are to be considered as PRIVILEGED or
35
TRUSTED, which means that most RACF authorization checks are accepted unconditionally. TRUSTED is the recommended choice because it provides the ability to turn on logging. It is recommended that you assign the TRUSTED attribute to system procedures as recommended in the appropriate documentation to avoid problems in starting up your system, but that you do not assign the PRIVILEGED or TRUSTED attribute to other procedures, and certainly not to the generic catch-all entry in your SPT.
Migrations Issues
The CA-ACF2 user related with STC can be used only by STC, and is not allowed to log on with this user ID. In RACF no STC flag is available in the user profile, and the IDs assigned to started procedures can be used otherwise. It is recommended that you do not assign TSO privileges to these IDs and do not assign user attributes such as SPECIAL and OPERATIONS.
2.8 Tape Protection

Although tape is typically not the primary storage media for production data, tape silos and traditional storage facilities are found in most mainframe shops. The primary uses of tape are data backup and archiving and data exchange.
Goals
Information on tape should be protected as securely and effectively as data on DASD, preferably by the same rules. Due to the differences in the architecture of disk and tape controllers, and the nature of tape media, some limitations exist.
Issues
When securing data on tape, it must be noted that:
multiple datasets on tapes cannot be secured separately. Protection must therefore be limited to the volume level, or a user must implement procedures not to store information with different protection requirements on the same tape. tape labels contain only the last 17 characters of the 44 character dataset name. The full dataset name for security checking must therefore be obtained from other sources such as a tape management system. there is often a need to process foreign tapes, i.e., tapes received from other organizations containing unknown dataset names. They are typically used in bypass label processing (BLP) mode. tapes are likely to be shipped or stored outside the physically secured computing facility and CA-ACF2 or RACF protection is not effective. Data encryption is often used to protect such information.
Terminology
CA-ACF2 and RACF use slightly different approaches to protecting tape and to granting privileges to bypassing tape protection:
The TAPE-BLP attribute in the CA-ACF2 login record grants full BLP processing. The RACF equivalence is a users access authority on the access list of the ICHBLP profile in class FACILITY. READ access provides the ability to read a tape in BLP mode, UPDATE access permits writing to it.
36
Migration to RACF
TAPE-LBL is a similar attribute that grants limited BLP privileges; there is no exact RACF equivalent. TAPEDSN is the name of similar options in CA-ACF2 and RACF. It activates access checking for tape at the dataset level. SECVOLS in CA-ACF2 defines a limited list of volumes (disk and tape) for which access control is performed at the volume rather than the dataset level. The RACF equivalence for tape volumes are profiles in the TAPEVOL resource class; there is no similar DASD control in RACF. RESVOLS in CA-ACF2 defines DASD volumes for which CA-ACF2 is to provide protection at the dataset level. The CA-ACF2 default to protect all DASD volumes at the dataset level is also the default in RACF.
RACF Tape Protection Concepts

This section describes the recommended approach to protecting tape data under RACF.
Tape Dataset Protection The RACF option SETROPTS TAPEDSN activates tape protection at the dataset level through profiles in the DATASET class. This is the recommended standard for all local tape data.
Tape Volume Protection

The activation of RACF class TAPEVOL and the definition of profiles enables access control at the volume level. Tape volume checking is done first and therefore overrides dataset level checking. This effect is helpful when dealing with tapes for which dataset names are not defined or not known. Many organizations apply tape volume controls to foreign tapes.
Maintaining Full Dataset Names As mentioned earlier, the dataset name field in standard tape labels contains only the rightmost, least significant 17 characters of an MVS dataset name which can be up to 44 characters long. There are two potential solutions available:
maintaining the full name in a tape management system which makes MVS Router calls to RACF, or in the absence of tape management software, maintaining the full name in a TVOTC, an extension of a TAPEVOL profile.
If a tape management system was used with CA-ACF2, its interface issuing MVS Router calls should also work with RACF.
Bypass Label Processing An ICHBLP profile in the RACF FACILITY class controls the BLP privilege. Groups of users or, if necessary, individual users are put on the access list with their assigned access authority, READ to allow BPL for input or UPDATE for input and output. Archiving on Tape The use of HSM, for automated archiving on tape, is a specialized area of tape usage. Provided you establish clear goals for protection of data sets automatically retrieved from tape storage, RACF setup can be fairly simple. The issue here is often the handling of retrieved data sets for which the owner is no longer present in the current RACF data base.
37
Migration Issues
In summary, the conversion of tape protection should be simple and straight forward. The protection at the dataset level should be addressed by the standard rule conversion for DASD, volume level protection should translate easily, and existing tape management systems should interface in a compatible way with RACF.
2.9 CICS Protection

Prior to CICS 3.2.1 security could be accomplished by CICS internal security, an External Security Manager (ESM), or a combination of both. Starting with CICS 3.2.1 all CICS security must be implemented through an ESM. RACF has long supported CICS security through RACF classes and USERID verification and authentication. CICS uses SAF to communicate with RACF for all security calls. To enhance the performance of CICS, RACF now keeps a listing of the CICS RACF profiles in a different address space. One of the performance advantages of this is that when the administrator needs to refresh profiles, the performance of the CICS region is not impacted. The following section will discuss, at a high level, CA-ACF2 and RACF functions.
CICS Users
ACF2 allows or denies access to an application through entries in the PRIVILEGES section of LOGONID records. Your installation may have several CICS regions executing at the same time and users allowed to logon to more then one region. With RACF and CICS, authorization checking can be made against a resource class called APPL. For each CICS region requiring logon control, you must have a corresponding profile in the RACF APPL class. CICS users can then be connected to an access group which in turn is given access to the APPL profile. This way the APPL profile remains static and users are connected and removed from the access group as required.
Default Users: The ACF2PARM may include default values for non-signed-on users at a terminal. Lets assume that this user ID is named CICDUSR.
For a non-signed-on (or unattended) terminal, ACF2 signs on the terminal using the CICDUSR LOGONID. ACF2 then checks the authorization of CICDUSR to access a resource. The CICDUSR must be defined as a user by means of a LOGONID record. This default value may vary across CICS regions in the system or you can use the system-wide default value, DFTCICS, provided by ACF2. With RACF, the ability to associate an unattended terminal with a user ID is provided by CICS Version 3.2.1. Prior to this release, modifications and exits had to be developed to provide this capability.
CICS Signon Table - DFHSNT: In CICS 3.2.1, support for CICS internal security was dropped and customers could only use an ESM to provide CICS security. In ACF2 this support is provided in the LOGONID record. With RACF the support is included in the CICS segment of the RACF user profile.
38
Migration to RACF
CICS Resources
The TYPEs of all rules that apply to protected resources in a CICS environment are specified by parameter values in ACF2PARM. Default values for ACF2 and corresponding RACF default class names are given in Table 2.
Table 2. CICS Default Resources
ACF2 Default TYPE CKC CTD CFC CPC PSB CTS
RACF Default CLASS
Resource Description
TCICSTRN/GCICSTRN DCICSDCT/ECICSDCT FCICSFCT/HCICSFCT MCICSPPT/NCICSPPT PCICSPSB/QCICSPSB SCICSPSB/UCICSPSB CCICSCMD/VCICSCMD ACICSPCT/BCICSPCT
Transactions Transient Data Files Programs PSBs Temporary Storage CICS Commands CICS Started Transactions User defined DBD for DL/I MRO in/outbound
MTP CDB CMR
User defined No direct equivalent
Default values for CICS resource TYPEs are used. As can be seen from Table 2, there are some ACF2 types that do not have RACF equivalents. CDB will need to be assessed and if required either use an exit or a user defined RACF class. Although MRO has no direct match resource checking can still be carried out on the target region. RACF does offer the capability to protect started transactions, CICSPCT, and also CICS commands like CEMT PE SHUT with the class CICSCMD. If an installation has defined its own set of resource TYPEs then you will need to create a set of RACF equivalents.
ACF2 User Resources: In a multiple CICS address space environment, an ACF2 installation may define other rule TYPEs besides those provided by default. This allows unique resource authorizations to be defined for each CICS region. The TYPEs that apply to a specific CICS region are given by the keyword CICSKEY in ACF2PARM.
CICSKEY CICSKEY CICSKEY CICSKEY CICSKEY CICSKEY
...,TYPE=KC1,RESOURCE=TRANS,... ...,TYPE=FC1,RESOURCE=FILE ,... ...,TYPE=PC1,RESOURCE=PROGRAM,... ...,TYPE=TS1,RESOURCE=TEMPSTRG,... ...,TYPE=TD1,RESOURCE=TRANDATA,.. ...,TYPE=PS1,RESOURCE=PSB,...
Figure 6. ACF2 CICSKEY Example
39
The rule TYPEs that we have defined for our CICS region are CFC1, CKC1, CPC1, CTS1, CTD1, and PSB1. For a transaction, ACF2 checks CKC1 type rules for user authorization.
RACF User Resources: As displayed in Table 2 on page 39, a set of default RACF resource classes is provided by RACF at installation time. In a multiple CICS region environment, it may be preferable to define the same resources with different access lists, for example test and production. The CEMT transaction, for instance, may be allowed to a substantial number of people in a CICS test region, and reserved to very few people in a CICS production region.
There are two RACF methods available to differentiate authorizations by CICS region. They are:

Prefixing of resource names User defined resource class names
Prefixes: If this option is chosen then CICS will use only those profiles that are prefixed with the USERID associated with this CICS region. This USERID comes from either the job statement, Started Task identifier or USERID propagated by JES if CICS is started by a submitted job without a USER on the job statement. You need to plan whether to use prefixing or not. There are administrative and run-time considerations that vary with the release of CICS being used. User Resource Classes: In RACF 2.2 the possible number of user defined classes was increased to 768. This increase will allow most installations to define unique classes for all their CICS regions. The class names specified in the CICS DFHSIT are the class names that will be checked by RACF for authorization to the various resources.
Table 3 may be used to translate the ACF2 rule TYPEs to RACF classes from our example in Figure 6 on page 39.
Table 3. Example of ACF2 TYPE Translation in RACF CLASS
RESOURCE TRANSACTION FILE PROGRAM TEMPORARY STORAGE TRANSIENT DATA PSB
ACF2 TYPE KC1 FC1 PC1 TS1 TD1 PS1
DFHSIT $CKC1 $CFC1 $CPC1 $CTS1 $CTD1 $CPB1
RACF CLASS T$CKC1/G$CKC1 F$CFC1/H$CFC1 M$CPC1/N$CPC1 S$CTS1/U$CTS1 D$CTD1/E$CTD1 F$CPB1/H$CPB1
It is recommended that you include a national or numeric character in your user class name. In the examples, we used the $ character. IBM has stated that any new IBM-defined RACF resource class will never include a national or numeric character.
40
Migration to RACF
CICS Application Security

There maybe some CICS applications that make security calls to ACF2 from within the application. If this is the case then, provided that they are written in CICS Command Level language, you can use an equivalent function with RACF. The CICS QUERY SECURITY command can be issued from your program against a user defined RACF resource CLASS. RACF then returns to your program the access level for you to make a decision.
Migration Issues
The migration of security from CICS-ACF2 to CICS-RACF is not a trivial task. If an installation is running several non-connected CICS regions and only protecting CICS transactions then a migration will be reasonably straight forward. Applications that make security calls directly to ACF2 will present the greatest challenge, especially on versions prior to CICS 3.1. In this case exits will definitely have to be written. Some installations will administer ACF2 from within CICS. While RACF itself does not offer this function there are two alternatives. One would be the purchase of a vendor product that allows this, and there are several to choose from. The second option would involve programming using APPC. You would need to code APPC Allocate, Send, Receive and Free calls in your CICS transaction and initiate an APPC/MVS transaction that runs TSO, with RACF TSO commands to perform the desired function. The CICS IDENTIFY SECURITY function can be used to pass the issuers user ID. The APPC transaction can run on any MVS system as well as the local one. APPC/MVS transactions can be written in REXX so it is possible to avoid assembler entirely.
2.10 IMS Protection

CA-ACF2 and RACF can basically control the same resources for IMS. One exception is that CA-ACF2 has special code that can be installed for DL/1 batch processing for the protection of database segments.
Terminology/Differences
CA-ACF2 IMS security is provided by a separate CA-ACF2 IMS subsystem which has its own GSO records defining the options used. For example: CA-ACF2 for MVS can be in ABORT mode, while CA-ACF2 for IMS is in LOG mode. This is based on specifications in the different CA-ACF2 IMS records. The /ACF SHOW STATE command in IMS will display all the IMS records and their settings. CA-ACF2IMS calls CA-ACF2MVS to perform the actual user identification and access checking. CA-ACF2IMS provides an IMS transaction (ACF) that can be used to maintain LOGONID records for IMS users directly from IMS. There are no subsystems to activate IMS controls in RACF. Activate the IMS resource classes APPL, TIMS and GIMS and specify in the IMS CNTRL and SECURITY macros used to control/generate IMS that RACF is to be used for logon and transaction control. If the class is active, IMS will perform an
41
authorization check. If the resource is defined in the class, IMS will verify access according to rules (UACC and/or access list). If the transaction is not defined or the class is not active, the transaction will be regarded as unprotected and access will be granted. This is opposite to CA-ACF2IMS, which by default regards all resources protected. A generic * profile with UACC(NONE) is an easy way to implement default protection for IMS transactions under RACF.
RACF Approach
Specify your security requirements in the IMSCTRL and SECURITY IMS definition macros. Use SECURITY TYPE=(TRANAUTH,SIGNAUTH) and SECLVL=(FORCSIGN) to implement transaction security, RACF user authentication and dont allow the MTO operator to override any of the security settings at IMS start/restart. If you are to control dependent regions access to resources through the AGN (Application Group Name) function, specify these names and run SMU (Security Maintenance Utility) to define these resource names to IMS. Define all IMS subsystems in the RACF APPL class with UACC(NONE) and permit users and groups read access. Define transactions in the TIMS or GIMS classes with UACC(NONE) and give users and groups read access. If AGN is used, define them in the AIMS class with UACC(NONE) and give the IDs for the dependent regions read access to the AGN group they need. To implement default protection, add * profiles with UACC(NONE). Do not forget to protect all libraries, datasets and databases.
Goals
The basic goal for both products is to achieve:

Authenticate users Control user access to IMS systems Control user access to transactions Record attempted violations
Summary
RACF-IMS is a structured and well defined interface. No IMS code changes or exit codes are needed. There are few differences in the way resources are protected, and migrating from CA-ACF2 to RACF should be fairly straight forward.
2.11 DB2 Protection

Protection of DB2 resources is different in CA-ACF2 and RACF. Some of the functions in CA-ACF2 cannot be directly translated to RACF. This makes it critical to understand which DB2 functions are used before a conversion takes place.
42
Migration to RACF
Terminology/Differences
A user has access to Tables and Plans in DB2. DB2 has it own access control mechanism to control these entities, maintained through DB2 administration. These controls can be implemented in CA-ACF2.through CAs Event Notification Feature. RACF currently has no similar function to replace internal DB2 security and resources in DB2 must be defined and controlled through native DB2 security feature. RACF can authorize a user for access to the DB2 subsystem itself, by granting access to either the user ID or a group-id. The DB2 subsystems must be defined as resources in the general RACF resource class DSNR. The RACF user ID (from batch, TSO, CICS or IMS, depending on where the attach comes from) will by default become the primary SQL-id in DB2. The DSNR class must be activated and each DB2 subsystem must be defined with its subsystem name as a resource in this class. Undefined subsystems will be considered unprotected.
RACF Approach
The following are the major steps in the process:

Document which CA-ACF2 functions are used to control users in DB2. Define all DB2 subsystems to RACF, in the DSNR class, with UACC=NONE Protect DB2 datasets and libraries and only grant access to the DB2 started tasks Install the IBM-supplied standard DB2 exits for CICS and IMS signon processing; these will cause RACF group-ids to be used as Secondary SQL-ids. Ensure that RACF LIST-OF-GROUP checking is active to support the above exit code Put the different RACF groups on the access list for the DB2 systems defined in the DSNR class with access(read). Use DB2s internal security to grant these groups access to tables and plans.
Summary
To control internal tables and plans in DB2, DB2s own security features must be utilized. RACF will only control user or group access to the different DB2 subsystems that are running. Insist on using RACF groups for access rights administration within DB2, to reduce administration overhead and to reduce the number of access rules that must be maintained.
2.12 TSO Protection

The privilege for a user to start a TSO session is maintained together with certain session parameters, limitations and functional privileges either in the TSO User Attributes Data Set SYS1.UADS or within the security software. Both products, CA-ACF2 and RACF, provide the option to maintain this information in SYS1.UADS or in their respective databases. RACF stores TSO information in an optional TSO segment of the user profile and uses general resource classes to control user access to account numbers, logon procedures, and TSO privileges.
43
TSO Segment
A TSO segment in the RACF user profile supplies default information to TSO during logon processing. You can specify the following fields in the TSO segment of a users profile:
ACCTNUM - specifies the users default TSO account number when logging on through the TSO/E logon panel. JOBCLASS - specifies the users default job class. MSGCLASS - specifies the users default message class. HOLDCLASS - specifies the users default hold class. SYSOUTCLASS - specifies the users default sysout class. DEST - specifies the default destination to which the system will route dynamically-allocated sysout dataset. PROC - specifies the name of the users default logon procedure when logging on through the TSO/E panel MAXSIZE - specifies the maximum region size the user can request at logon. SIZE - specifies the minimum region size if the user does not request a region size at logon. SECLABEL - specifies the users security label if one was entered on the TSO LOGON panel. UNIT - specifies the default name of a device or group of devices that a procedure uses for allocations. USERDATA - specifies optional installation data defined for the user.
If a user logs on to TSO and you havent defined a TSO segment for that user, TSO checks the SYS1.UADS data set for information it needs to build a session. If TSO does not find an entry for the user in SYS1.UADS, the logon attempt is terminated. When a user logs on, if using the TSO segment in RACF, TSO checks the authority to use certain TSO resources such as account numbers (class ACCTNUM) and logon procedures (class TSOPROC). If the user is authorized to use a resource such as an account number, TSO continues building a session for the user. Otherwise TSO prompts the user for a valid account number or logon procedure. You can move TSO user attribute information from SYS1.UADS to the RACF database. When you do this, RACF stores this information in the TSO segment of the users profile. You must maintain an entry in SYS1.UADS for certain users, such as IBMUSER and/or one or more system programmers. They are used if you need deactivate RACF for an emergency repair. Other information that you need to supply is profiles in TSOAUTH class. This class controls TSO authorities, like MOUNT, JCL, CONSOLE, TESTAUTH, etc.
44
Migration to RACF
Migrations Issues
If you are using SYS1.UADS in your current CA-ACF2 environment, you can continue to do so when migrating to RACF We recommend, however, using TSO segments and suggest the RACONVERT command for a conversion from UADS to RACF segments. It is common practice to maintain a few selected user IDs in SYS1.UADS to be able to logon to TSO in case RACF is not available. It is important that all such user IDs also be RACF-defined to prevent logons by undefined TSO users. (As a separate issue, you might elect to permit TSO users who are undefined to RACF to use your system. We do not recommend this, but it is possible. If a user is defined in SYS1.UADS but not in RACF, the user can log onto the system and access resources at the UACC level.)
45
46
Migration to RACF
Chapter 3. Advanced Controls

/* .im ac3 This chapter describes several of the more advanced functions of a security manager for MVS, and the RACF approach to these functions.
3.1 Operator Command Control

In traditional MVS console security, physical security seems to be the most common approach. An installation may place all consoles in an isolated area to prevent unauthorized accesses. This is a low cost approach that meets minimum security control requirements. However, when operators are grouped into different function groups with different operation requirements, consoles are still exposed. Physical security cannot provide sufficient guarantees to meet control and auditing requirements. RACF 1.9 and MVS 3.1.3 introduced MVS and JES command control. The level of protection covered commands entered at MCS consoles, extended consoles, inline within batch JCL or via SVC 34. RACF can authorize individual commands and command groups, and restrict their use to specific MCS consoles if required. Authorization can also be extended to check commands that come from other ports of entry, such as NJE nodes and RJE workstations. Implementation of CONSOLE may control access to consoles from which certain operators may issue commands, and also provide an audit trail. Moreover, the control concept can be easily accepted and implemented within current control procedures. OPERCMDS also provides extended control over which commands can be used by certain operators. This control replaces functions previously provided by MVS command authorization and SDSF. Implementing OPERCMDS requires additional effort and careful planning. Much will depend on how well operators or users have been grouped, how the control policy was set, and how strict a control level is required. If RACF is not active or the classes are not enabled, then existing JES or MCS controls are used.
Summary
Installations that need to protect and audit sensitive commands that control the system can do so with RACF and MVS. The following list summarizes the levels of protection the user can implement for command and console protection:
Force Operator signon can only allow authorized users access to MCS consoles. The RACF resource CONSOLE is used to control the use of consoles. Operators can be permitted or restricted to certain commands or group of commands based on their user ID. The OPERCMDS resource class is for this purpose. The command subjects can be defined as MVS JES2 JES3
47
Certain operator commands can be authorized based on their input source. Input sources may be: MCS consoles Extended MCS consoles System commands within JCL (JES2) JES2 and JES3 commands with JES JCL (JECL) RJE and RJP workstation operators Commands from other NJE nodes JES2 initialization statements Commands issued internally via SVC 34. Commands from SDSF Commands propagated from another node
Auditing of some or all commands entered can be recorded in SMF type 80 records. These records contain: Time and date Issuer user ID Command image Origin of command Command success/failure indicator
3.2 Remote RACF Control

In todays complex MVS environment data processing can be extended across many systems, including remote sites. For example systems in Sydney and Sao Paulo might be linked in an extended environment. In addition to the challenge of maintaining adequate levels of security in one location, there is the new challenge to maintain this level of security synchronized across multiple, remote systems. A few installations have used exits and/or additional products to achieve this. However, each time MVS or a security component was enhanced, the installation usually had to modify their exits or products to continue to provide security across multiple systems. RACF 2.2 Remote Sharing Facility, RRSF, provides the necessary capability without the need to manage exits or make changes to MVS. The key areas addressed by RRSF are:

Password synchronization Command direction Automatic command direction Automatic password direction
RRSF uses APPC to communicate with other RACF/MVS systems. This provides a secure way for you to administer and maintain remote RACF databases without having to logon to the remote systems. It also enables end users, even with multiple user IDs, to synchronize passwords among these user IDs. RRSF allows one or more systems, using a common RACF database, to act as a node in a network of RACF/MVS systems. Across nodes, the communication is through APPC/MVS. The RACF address space, introduced in RACF 1.9.2, provides the base for the RRSF function. RRSF can automatically propagate database updates that were entered using RACF commands. Other database updates (for example, updates that happen
48
Migration to RACF
due to RACROUTE and ICHEINTY macros) are not all propagated. Currently, only certain updates (such as passwords changes and passdate changes) made through RACROUTE and ICHEINTY are propagated. IBM intends to make enhancements to RACF for MVS administration capabilities by providing support for the automatic propagation of RACF database updates done by applications using the RACROUTE or ICHEINTY macro interfaces. When these enhancements are introduced, all updates to your RACF databases (by RACF commands or by application code) can be propagated throughout your enterprise. Using the same mechanisms, a security administrator can administer several local RACF databases on different systems, for example a production and a test system, without logging on and off several times from one system to another. (Test and production systems normally share the same RACF database if the two systems have shared DASD units; however there may be special cases where separate data bases are desired.) RRSF optionally permits systems to keep user passwords synchronized. For example, a user who owns more than one user ID on the same system, or different user IDs on different systems, can keep passwords synchronized among all his user IDs. This might be useful for RACF users who need to work on several systems, or who use more than one user ID on the same system to carry out different jobs. For example, a user with a USERID of TJONES on one system and TOMJ on another could have the passwords for both user IDs updated automatically whenever either is changed. Command distribution and password synchronization for users with multiple user IDs is controlled by new entries in the USER profile. These target user ID entries may be administered by the individual users or the RACF administrators. The entries for a user contain information to indicate what other user IDs the user has, and on what nodes they occur. Additional Systems Management RRSF enhancements are:
System performance:: Customers can create multiple copies of a RACF database and use RRSF to keep the copies synchronized. This can reduce the number of systems that access each copy of the database. System management:: If workload must shift to a different location, and that location is a RRSF node, then all the security definitions are in place and end-user passwords are synchronized when the work moves. System availability: The customer can create multiple copies of the RACF database so that fewer systems are affected by failures. RRSF can be used to keep the copies synchronized. (RACF failure is rare, and is usually handled by using the rvary command to switch to the backup data base. Using a separate, remote data base may be useful in unusual circumstances.)
49
3.3 NJE and RJE

NJE Security Overview
The NJE security enhancements provide the installation with control over data entering and leaving a node. The requirements are to preserve the security of the system so it is not compromised by NJE functions or jobs, and to enhance the overall security of the network. NJE security, with JES and RACF, does the following:
Controls who can send jobs and data to another node on the basis of destination node and sending user ID. Controls owner and level of jobs and data entering a node on the basis of origin node, user ID and group. Propagates user validation across the network, so passwords do not have to be sent with the job. (When passwords are required, provides a means of encrypting them.) Permits different USERIDs or GROUPs on different nodes and provides a means for translating them to locally-defined values under installation control. Permits surrogate job submission across NJE nodes. Can define a default USERID under certain conditions.
These controls are exercised primarily on the origin and destination nodes, not on store-and-forward nodes. It is assumed that all the nodes and links in the network are trusted to the extent that they will not make unauthorized changes to security fields in the NJE headers. Centralized SAF/RACF management allows mixed levels of nodes in a network, including previous levels of JES2 and RACF as well as JES3, VM, and POWER. If the NJE network is not defined to RACF through the NODES profiles, then existing JES security controls are used. RACF does not require any modifications to the NJE headers.
NJE Levels of Trust

The level of RACF verification is determined by the level of trust , as defined in the RACF NODES class profiles. Each access level corresponds to one of the levels of trust.
Levels of Trust: Jobs coming from other nodes are validated during input service processing in the receiving node. The NODES class is used to verify whether the transmitting Node and its Userid or Group, is trusted, semi-trusted, or untrusted. Userids may be translated only from trusted nodes, but groupids may be translated from trusted or semi-trusted nodes.
Trusted The node and user ID(s) are accepted as validated without a password. The trusted attribute is defined by UACC(UPDATE) in the NODES profile definition. The node is trusted enough to ensure that NJE headers are valid, but the user must supply a password (which can be encrypted). The semi-trusted attribute is defined by UACC(READ) in the NODES profile definition.
Semi-Trusted
50
Migration to RACF
Untrusted
The node is not trusted, and any jobs received from this node will be purged, with a message sent to the submitting user. This is defined to RACF as UACC(NONE). Nodes (including the one we are on) that are defined as part of &RACLNDE profile to RACF. It is assumed that all users and groups are defined identically on all local nodes, and share a compatible RACF data base. Unknown users tagged and used for NJE work on store and forward nodes and for SYSOUT files when the owner is not known.
Local
Unknown
Trust should usually be assigned at the node level. In other words, you either trust all users on a given node to have verified headers, or you trust no users of that node. Most nodes from which you expect to receive jobs should probably be treated as Trusted, unless you feel that forcing them to supply passwords on the JOB card is required for additional security.
RACF NODES Class

RACF profiles in the NODES class contain the names of all networking nodes that are controlled on this system. There are four levels of access available for this class: NONE READ UPDATE Allows no work from the specified node to be entered into this system. Allows work from the specified node to be entered into this system if a user ID and password are given. Allows work from the specified node to be entered into this system because the node is trusted and no additional verification is required; however the user ID and group that was assigned must exist in the receiving system. Allows work from default or down-level nodes to have the trusted attribute, which allows the user to be validated.
CONTROL
The Universal Access field (UACC) controls jobs on a node-by-node basis. Individual users can also be permitted to the NODES class profile with the required authority. Any user that requires verification on the current node must be defined to RACF on this node. You can also use a generic access profile to cover all work from any nodes entering this system. An installation can choose to protect either inbound work, outbound work, or both. For inbound jobs and SYSOUT, you can decide whether to protect jobs, SYSOUT, or both. You can also determine which users or group of users are allowed to enter NJE jobs or SYSOUT.
51
RJE Signon (JES2)

RJE passwords for signon/logon are checked by JES2. These passwords are specified in JES2 initialization parameters. With RACF and JES, signon processing can be verified by RACF provided that

RACF is active. FACILITY resource class is active. RJE.rmt-name profile is defined in FACILITY class. RJE remote name defined as a user to RACF through ADDUSER command.
The USERID that represents the remote name, password, and new password are passed to SAF/RACF. After this check, the remote name is recognized as a user ID by RACF. Security checking for commands coming from remote terminals are also checked by RACF. Instead of the remote terminal password, you can use the line password for signon/logon commands. The line passwords are still checked by JES2. JES2 checks the password if no decision is made by RACF, indicating that the FACILITY class profile was not found. When dedicated BSC lines are started, RJE user IDs are checked, but no passwords are used. When sessions are started by $SRMTn command or autologon, RJE user IDs are checked at JES2 initiated logon time, but no passwords are used. Exit17 (BSC signon/off), and Exit18 (SNA logon/off) can be used to perform additional security checks or selectively bypass security checks.
RJP Signon (JES3)

The protection of RJP workstations is based on JES3 verification of the workstation passwords. JES3 initialization parameters or operator commands are used to update the passwords. The protection of RJP workstations can be controlled by RACF. To activate the RACF protection, you must define the RJP workstation to the FACILITY class and also define a RACF user ID with the workstation name. Additionally controls can be placed on remote printers or punches. Also, operator commands that are allowed from the workstation can also be controlled by RACF. If the workstation is not defined to RACF, then existing JES3 verification is used.
3.4 Other Network Controls

RACF can control network resources at a variety of different levels. Few installations use all the possible controls, and frequently use none of them directly. A migration plan must determine which of these functions, using CA-ACF2, are currently in use and need to be migrated to RACF. This is a good time to determine if changes are needed in this area, since perceptions and accepted methods for network controls have changed considerably during the last few years.
52
Migration to RACF
VTAM ACBs are controlled through the RACF VTAMAPPL class for non-APF authorized programs. VTAM does a RACHECK against the class to verify that the user is allowed to open the specified ACB(APPLID) name. CA-ACF2 provides a similar check, and migration should be easy in this case. APPC usage can be complex, because application programming is involved. Both RACF and CA-ACF2 have resource classes used to protect the basic elements of the APPC environment. APPC applications may be multi-user applications, possibly running in an authorized state. This implies that the applications may be responsible for fine-grain security, and this requires application code. The application designer has many options for handling his security requirements, under either CA-ACF2 or RACF. Migration may involve inspecting each APPC application. If most of the applications are written to a common pattern, as often happens, this inspection and migration may be easy. TERMINAL usage can be restricted in both products. In RACF it is rarely used for standard VTAM-connected terminals. 9 Most installations rely on user, application, and data set protection for basic security. Security controls that attempt to manage which users can use which terminals tend to have unusually high manpower requirements for administration. Also, terminal passthrough connections (through SNA, from another host, or through connections such as telnet) can make TERMINAL-related security management very difficult to administer and sometimes pointless. Migration of terminal controls to RACF may not be difficult, but we suggest you review the need for these controls first. Netview uses standard SAF functions for user authentication. Both RACF and CA-ACF2 support this interface, and there should be few migration issues. Netview Access Services (NVAS) uses predefined resource classes in RACF. NVAS installations using CA-ACF2 would probably have defined several resources and rules for use with NVAS. Migration of these functions to RACF will require a manual review. General VTAM Applications that do user authentication typically use RACROUTE VERIFY processing. This implies that CA-ACF2 is set up for RACROUTE VERIFY, and migration to RACF should be easy.
3.5 RACF PassTickets

Network monitoring is a major security concern for all modern systems, where user IDs and passwords often flow in clear text. A related concern is the use of automatic logon functions, often found in MVS-to-MVS links, single-signon products, and so forth. In both cases, passwords are sent, in clear text, over a network. Single-signon functions may use files containing user ID/password pairs, forming a concentrated potential exposure. A means to avoid password exposures on networks has become an important part of overall security design. One-time passwords, where the exposure of the password does not matter, are the generally accepted solution. Use of such technology is increasing rapidly, and the MVS security subsystem should contain suitable functions for using this technology.
MCS consoles may be an exception.
53
Terminology
A RACF passticket is a password, with eight alphanumeric characters. In its present form, it uses uppercase characters in order to be compatible with systems that are case-insensitive (MVS) and systems that are case-sensitive (UNIX, for example). A key for a passticket is a DES key, known in both ends of the passticket interaction. The key is never directly used on the network connecting the sender and receiver.
Concept
RACF PassTickets provide one-time passwords. Exposure of these passwords (on a network, for example) is not a security threat because they cannot be reused. RACF PassTickets can be generated and used internally, between MVS systems and applications (often as part of a single logon function), or generated externally at user workstations (as part of a user logon), typically by using a security server or smart card. A passticket is generated by a DES encryption function, using a secret key (known to RACF and the generating workstation) and using variables that include the user ID, time, and date. The general formula for generating a RACF passticket has been published in RACF literature, but the process for verifying a received passticket is available only as licensed IBM technology. RACF can both generate and validate PassTickets. This is useful in MVS-to-MVS connections. RACF can validate (that is, accept a valid passticket in place of a password) PassTickets properly generated on other products, such as IBM s NetSP product. The RACF passticket design is very flexible. A passticket can be related to an application, a group, or a user. The passticket can be generated by smart card functions, network-resident single-signon monitors, or other means.
Migration Issues
The RACF passticket validation function does not exist in CA-ACF2, so direct migration is not an issue. There are other one-time password products for both CA-ACF2 and RACF. If you are using one of these products, you will need to obtain the corresponding version for RACF early in the migration process. This is often an easy one-to-one replacement. If a locally-written one-time password process in being used, it must be converted to RACF. Such processes normally use well-defined exits, and conversion may be relatively simple.
Summary
PassTickets are an important technology in RACF One-time passwords, in general, are expected to be widely implemented over the next few years, in response to the increasing exposures of network monitoring. While specific passticket operation might not be part of your current migration, you should consider it in your overall policy planning.
54
Migration to RACF
3.6 Mandatory Access Control

Mandatory Access Control (MAC) is usually known as a component of B-level security (B1, B2, B3, as defined by the U.S. Department of Defense). RACF offers B1 features, although they are rarely used -- practically never in commercial installations. Both CA-ACF2 and RACF offer MAC and other B-level functions. MVS B-level security involves much more than RACF or CA-ACF2 functions, and places many restrictions on other parts of MVS. We do not regard B-level security as a normal CA-ACF2 to RACF migration topic. If your ultimate target is an MVS RACF B1 system, we suggest the following:
Separate the CA-ACF2 to RACF migration from the further migration to B1. In our opinion, attempting to do both at one time is not practical. Concentrate on obtaining a well-defined, reasonable number of RACF GROUP definitions during your CA-ACF2 to RACF migration. Create a RACF PROTECTALL environment. Understand what B1 is, and is not. It is not, for example, simply improved security over the normal C2 level provided by RACF.
Having provided these warnings about B1-level security, we must note that RACF can provide elements of B1, without requiring a complete B1-level MVS implementation. In unusual cases, you may want to use some of these elements. However, as we noted earlier, we do not consider this a normal topic of CA-ACF2 to RACF migration, and it is not further discussed here.
55
56
Migration to RACF
Chapter 4. MVS Open Edition and RACF

Note We have included introductory material in this section because MVS OpenEdition concepts may be new to some readers. Some, but not all, of these concepts will already be familiar to UNIX users.
4.1 IBMs Commitment to Open Systems

POSIX standards have been embraced by nearly all major computer manufacturers, hundreds of software vendors, and information system users. Many government bids specify POSIX conformance as a requirement. The International Organization for Standardization (ISO) has adopted the work done by the IEEE on several occasions. The POSIX 1003.1 standard was adopted as the ISO/IEC 9945-1 standard in 1988 and 1990. In September 1991, IBM affirmed its intent to provide POSIX services and OSF DCE across a wide range of platforms. In June 1992, as part of the MVS/ESA SP 4.3 announcement, IBM expressed the intent to significantly expand MVS/ESAs role in a open system environment by providing interfaces to enable interoperability of applications within a heterogeneous network, and increase portability of applications, data, and skills with other environments conforming to the same open system standards. In August 1992, X/Open and OSF announced a joint initiative to integrate the OSF DCE specification into X/Opens Common Application Environment (CAE). X/Opens goal is to make DCE interface components part of the formal XPG specifications with the XPG brand being applied to implementations that are registered as compliant. In February 1995, as part of the MVS/ESA SP 5.2 and the MVS/ESA SP 5.2.2 announcement, IBM expressed the intent to upgrade the MVS/ESA OS/390 OpenEdition Distributed Computing Environment (DCE) to OSF DCE Version 1.1. OSF DCE Version 1.1 support provides a foundation for RACF-DCE interoperation and for support of single sign-on between MVS/ESA and DCE environments. MVS/ESA OpenEdition DCE will provide support for DCE RPC over SNA networks in addition to the TCP/IP networks. New MVS/ESA OpenEdition DCE servers includes DCE Security Server and Distributed File Service Program Products. X/Open Company, Ltd. and the Open Software Foundation (OSF), the two leading consortia for the advancement of open systems, announced on February 14, 1996 the consolidation into a new, more powerful worldwide organization known as The Open Group. The new entity has been formed to strengthen and streamline the entire open systems process, including adoption of open systems specifications, development of specification-compliant technologies, and promotion of their use in the global enterprise computing marketplace.
57
4.1.1 MVS Achieves Open Systems Brand From X/Open

In an effort to help customers realize the benefits of cross-platform, client/server computing, IBM announced on December 8, 1995 that it has achieved open systems branding for its System/390 MVS/ESA operating system. The XPG4 Base brand certification was awarded by X/Open Company, Ltd. and ensures that IBMs large server operating system is compliant with current open industry standards. Once thought of as a proprietary system, MVS is one of the first non-native UNIX platforms to achieve this brand from X/Open. MVS is an integral part of IBMs overall network-centric computing strategy and the XPG4 Base certification will increase customers flexibility to launch open network-enabled applications on the server operating system. MVS customers will also benefit from validation of a common set of popular programming interfaces, as well as easier application portability and migration. This announcement exemplifies the recent transformation of IBMs System/390 into a large, scalable server designed to provide open, client/server computing, and application portability to a wide range of commercial customers. System/390 provides new open systems functionality, while retaining the classic large system strengths that customers continue to demand in today s network-centric computing environment.
4.2 UNIX Security Basics

On UNIX systems each user needs an account that is made up of a user name, and a password. UNIX uses the /etc/passwd file to keep track of user names and other information. Internally, the UNIX operating system uses a numeric ID to refer to a user, so in addition to user names, the /etc/passwd file also contains a numeric ID called the user identifier or UID. 10 UNIX operating systems differ, but generally these UIDs are unsigned 16 bit numbers, ranging from 0 to 65535. The UID is the actual number that the operating system uses to identify the user. User names are provided as a convenience, as an easy way for us to remember our sign on to the UNIX system. If two users are assigned the same UID, UNIX views them as the same user, even if they have different user names and passwords. Two users with the same UID can freely read and write over each others files and can kill each others processes. Assigning the same UID to multiple users is generally not recommended. UNIX systems also have the concept of groups where you group together many users who need to access a set of common files, directories, or devices. Like user names and UIDs, groups have both group names and group identification numbers (GIDs). Each user belongs to a primary group that is stored in the /etc/passwd file on UNIX systems. Along with user name, UID, and GID, the /etc/passwd file also contains the users full name, the users home directory (the directory where a user would generally store their files) and the file name of the shell program that is
10
Please do not confuse the UNIX UID with the CA-ACF2 UID. The names are the same, but the functions are quite different.
58
Migration to RACF
executed when the user initially logs in. Older UNIX systems also included the encrypted password in /etc/passwd (hence the name of the file), but this is seldom done in modern systems.
4.2.1 UNIX Security and Files

In UNIX systems, general information about each file is stored with the files in the file system. Included with this general information (such as, the file size and last modification date) is the security information for each file:

The files owner (as represented by a UID) The files group (as represented by a GID) The files mode bits or file permissions bits
All UNIX files have three types of permissions; read, write and execute (displayed as r, w and x respectively). These permissions are stored with each file as file permission bits that are split into three groups:

Owner permissions Group permissions Permissions for others
The permission bits are set in the same way for each level of access using a simple binary 9-bit code.
tuuugggooo | | | | | | | |______ | | |_________ | |____________ |______________
OTHER permissions GROUP permissions OWNER permissions Type of file
The types of files include:

- regular file c character special file d directory l symbolic link p FIFO special file
The first group of three characters describes the owner permission, the second describes group permission, and the third describes other (or sometimes called world) permissions.
4.3 OS/390 OpenEdition

The OS/390 OpenEdition features fit together between application programs and the existing services of MVS/ESA. POSIX-compliant application programs include C language POSIX 1003.1 functions that, after being recompiled with the C/370 (or equivalent) compiler, result during program execution in calls to the function routines. Some of the functions are performed by these routines alone. For other functions, the library routine in turn calls OS/390 OpenEdition services or basic MVS services.
59
The prepackaged POSIX 1003.1 function routines are included in a runtime library such as the one provided by LE/370. A dbx feature can be used to help debug an OS/390 OpenEdition application. The dbx is not part of the POSIX standards. In addition, applications can invoke shell scripts, which in turn invoke shell utility programs. Some of these utility programs make operating system requests and thus are seen from the operating system as applications. The MVS support for OS/390 OpenEdition services feature provides the new control program services for POSIX 1003.1 process management, file system management, and communication. Process management is controlled by the kernel address space. The kernel address space is started as part of OS/390 OpenEdition initialization. The file system is the set of routines necessary to support the new file system type introduced with the OS/390 OpenEdition feature. These new files are byte stream files, and they are part of a new file system called the hierarchical file system (HFS). Communication services refer to the functions that are related to end-user terminal attachment, and to other IBM telecommunication and networking products used by, or in conjunction with, OS/390 OpenEdition. VTAM and TCP/IP are examples of such products.
4.3.1 OS/390 OpenEdition Security Processing

There are differences in security processing between a standard MVS environment and the OS/390 OpenEdition implementation. In both cases, RACF can protect resources by granting access only to authorized users of the protected resources. To accomplish this, RACF gives the ability to:

Identify and verify users Authorize users to access the protected resources Log and report various attempts of unauthorized access to protected resources Control the means of access to resources Allow applications to use a RACF interface
The following issues describes some of the differences between the security processes in the two environments.
Table 4 (Page 1 of 2). Security Processing
MVS processing RACF retains information about the users in profiles on the RACF database and refers to the profiles for user identification and verification. RACF uses a user ID to identify the person who is trying to gain access to the system and a password (or PassTicket) to verify the authentication of that identity. RACF uses the concept of only one person knowing a particular user ID - password combination to verify user identities and to ensure personal accountability. OS/390 OpenEdition Processing RACF can store information in user profiles for use by OS/390 OpenEdition. OS/390 OpenEdition users are identified with numeric user identifiers (UIDs), and OS/390 OpenEdition groups are identified with numeric group identifiers (GIDs). Unlike user names or group names, these IDs can be shared by more than one user or group, although sharing is not recommended.
60
Migration to RACF
Table 4 (Page 2 of 2). Security Processing

MVS processing The RACROUTE macro is the (external security) interface to RACF (or another external security manager) for MVS resource managers. The RACROUTE macro invokes the system authorization facility (SAF) router. If RACF is present, the SAF router directs control to the RACF router. If RACF is active, the RACF router then invokes RACF. The system authorization facility (SAF) is part of the MVS operating system. RACF retains information about the users, resources, and access authorities in profiles on the RACF database and refers to the profiles when deciding which users should be permitted to protected system resources. OS/390 OpenEdition Processing The RACF security functions provided for use by OS/390 OpenEdition and other products integrated with it are called as callable services. Normal customer applications using the services or functions of OS/390 OpenEdition cannot call the RACF callable services directly. They must use the OS/390 OpenEdition callable services instead. (These interfaces to the callable services are part of SAF.) The security rules (permission bits) for the files and directories in a HFS are stored within the file system itself in file security packets (FSPs). The interprocess communication (IPC) security packets (ISPs) contain data needed to make security decisions. One is built when a new ID for an IPC key is created and is saved in memory by the kernel. An ISP is used in place of a profile in the RACF database to contain information about the IPC keys owner and access rights. Administration of user profiles can be performed by using RACF TSO commands. Administration for OS/390 OpenEdition and OpenEdition DCE resources, such as the HFS, must be performed by using OS/390 OpenEdition functions, which, in turn, invoke RACF services.
RACF TSO commands can be used to maintain the profiles in the RACF database. RACF allows for different levels of security administrators.
Traditional UNIX security differs from the RACF philosophy in that the implementation of protection is built into the design of the process or the server rather than being external to the application. RACF can control whether a user is allowed to execute a program or gain access to a data set and at what level (read, write, alter), from the RACF profiles external to the application. RACF can also enable an application to define resources that can represent processes within the application through RACF general resources. An HFS file system (to OS/390 OpenEdition) is a single PDSE data set (to base MVS) and can be protected as a single data set by RACF. Protection of elements within the HFS (that is, UNIX-type files and directories) is done using permission bits stored in the file security packets that are stored within the HFS. Under the covers, RACF functions are used to check permission bits, even though the RACF data base (and its profiles) are not involved.
61
4.3.2 OS/390 OpenEdition Kernel Address Space

The kernel is that part of an operating system that contains programs for such tasks as I/O, management, and control of hardware and the scheduling of user tasks. The kernel is an interface with the hardware and provides services for other system layers, such as system calls, file system support, and device drivers. It performs basic functions, such as allocating hardware resources. The installation should establish the security environment for the kernel by assigning a RACF user ID (and RACF group ID) to the kernel. The cataloged procedure that runs the OS/390 OpenEdition kernel must be added to the started procedure table. The kernel attributes are not propagated to programs that are created by the kernel, such as the INIT process, or to programs forked by/etc/init, such as daemons.
4.3.3 OS/390 OpenEdition Users

Resource Access Control Facility (RACF) can be used to manage system and data security in a OS/390 OpenEdition environment by:

Identifying and authenticating a user Verifying that a user can access: OS/390 OpenEdition processes (programs that uses OS/390 OpenEdition services) OS/390 OpenEdition files Other OS/390 OpenEdition resources such as shared memory segments
A user is identified by an OMVS userid (UID) , which is kept in the RACF user profile, and one or more OMVS group IDs (GIDs) , which are kept in RACF group profiles. The system verifies the user IDs and passwords of the users when they log on to a TSO/E session or when a job starts. When a user in a TSO/E session invokes the shell, RACF verifies that the interactive user is defined to the OS/390 OpenEdition before the system initializes the shell. When a program requests a service from OS/390 OpenEdition for the first time, RACF verifies that the user running the program is defined to OS/390 OpenEdition MVS before the system provides the service. OS/390 OpenEdition information about a user is stored in an OMVS segment in the user profile. OS/390 OpenEdition information about a RACF group is stored in the OMVS segment in the RACF group profile. To authorize a RACF user to access OS/390 OpenEdition resources, you must add a UID to the RACF user profile for an existing or new TSO/E user and connect each user to a RACF group that has a GID. You also have to add a GID to a RACF group profile for an existing or new RACF group. The UID and GID number value can be between 0 and 214783647. Similar to the way some users with special RACF attributes have unrestricted ability to access resources and processes within MVS, there must be a so-called superuser defined for the OS/390 OpenEdition environment. Each user who has a UID = 0 is a superuser. A superuser can, in one way or another, bypass standard UNIX permission checks. When a user is logged on to OS/390 OpenEdition, the UID from the users RACF user profile becomes the effective UID of his process. This effective UID is used to check the users authorization to access OS/390 OpenEdition resources.
62
Migration to RACF
When a TSO/E user becomes an OS/390 OpenEdition user, the GID from his current connect group becomes the effective GID of the users process. The user can access OS/390 OpenEdition resources available to members of the users effective GID. When RACF list-of-group checking is active, a user can access an OS/390 OpenEdition resource if it is available to members of any group the user is connected to that has a GID in its RACF profile. The additional groups are called supplemental groups .
4.4 Home Directory and Program

The security administrator specifies the pathname of the home directory for each user or process in the HOME field of the OMVS segment in the RACF user profile. When a user initializes the shell, the users working directory is the home directory. This home directory is the default for a OS/390 OpenEdition cd command. The user can use the cd command to use another directory as the working directory. On an open system, a working directory is normally defined in lowercase letters and usually has the users TSO/E user ID as its name, for example, /u/peter. When the HOME directory is changed in a user profile, for example with the ALTUSER command, and this directory is not already defined, you will get the following message when the user tries to access open ae OS/390 OpenEdition shell:
FSUM2078I No session was started. The home directory for this TSO/E user ID does not exist or can not be accessed. + FSUM2079I Function = sigprocmask, return value= FFFFFFFF, return code= 0000009C reason code=0507014D
There are two different ways to define this home directory. It can be defined by either using a TSO/E command:
MKDIR directory_name MODE(directory_permission_bits)

or through a OS/390 OpenEdition shell command:
mkdir -m(permissions_for_directory) directory_name

The mode parameter (MODE in the TSO/E command and -m) are used to specify the requested access authority for users in the OS/390 OpenEdition MVS environment. The permission bits are changed with the OS/390 OpenEdition shell command chmod. The PROGRAM variable specifies the OS/390 OpenEdition program that is invoked when the user enters the OS/390 OpenEdition environment, for example, by entering the TSO/E OMVS command. If the shell is to be installed, the HOME and PROGRAM parameters must be specified. If the shell is not to be installed, specify only the HOME parameter.
63
4.4.1 OS/390 OpenEdition Shell Environment

The OS/390 OpenEdition shell is a command interpreter that accepts the POSIX commands that come with the OS/390 OpenEdition Shell and Utilities feature. For some command requests, the shell calls other programs, known as utilities . The user can start the shell by, for example, entering the OMVS command. The user then works within the shell environment until exiting or temporarily switching over to the TSO/E interface. You can select options on the OMVS command to customize aspects of the shell interface, such as the function keys. A shell user can invoke the shell automatically at the end of logon processing, for example, by updating his TSO/E logon procedure IKJEFT01, as follows:
// //
EXEC PGM=IKJEFT01,..... PARM=OMVS
If an installation wants to customize the OMVS command for all users, they can create a REXX EXEC with the customized options. Then they need to specify the name of the REXX EXEC in the PARM parameter, instead of the OMVS command. After a TSO/E user enters the OMVS command, the system initializes the shell for that user. During the initialization, the system does, among other things, the following:
Determines that the user is authorized to use the shell by checking for a UID value in the users RACF user profile and checking that the users RACF group has a GID assigned to it. Sets the following environment variables from data in the RACF user profile: Connects the user to the initial working directory identified in the HOME field in the RACF user profile. If the RACF user profile does not identify a working directory, the system uses the root as the users working directory and issues a message. Invokes the shell named in the PROGRAM field in the RACF user profile.
When the OS/390 OpenEdition kernel is started, either by an operator command or from a parmlib member, a shell customization job is started. This job invokes a shell to execute an initialization shell script that customizes the environment for shell users. The input file for this customization job can be tailored by the installation. The user can also request a shell environment for a MVS batch job or through TCP/IP, using the rlogin command. The differences between a utility program, a shell command, and a shell script are sometimes important: OS/390 OpenEdition utility A OS/390 OpenEdition utility is a program that can be called by a name from a shell to perform a common services, or a related set of services. This program can either be an executable file, such as might be produced by a compiler-linker from source code, or a file of shell source code, directly interpreted by the shell. The program may have been produced by the user, provided by the installation, or acquired from an independent distributor.
64
Migration to RACF
Shell scripts A shell user can write a named list of shell commands that is called a shell script . The name of the command list then effectively becomes a new, powerful command that a user can enter so that the entire list of commands is run sequentially. (A shell script is similar to an MVS command list or to a REXX EXEC.) The shell script can also be invoked within an OS/390 OpenEdition application if the Shell and Utilities feature is installed. Shell commands A shell command is a function that is directly executed by the shell program itself. No other program, utility, or script is called. Shell commands often manipulate shell variables.
4.4.2 Hierarchical File System (HFS)

OS/390 OpenEdition includes a UNIX-style file system. This HFS conforms with the POSIX 1003.1 standard. This file system is in addition to traditional MVS data sets. It is built using an extended PDSE data set. An HFS file is found by searching HFS directories (which are themselves HFS files). A file is named by specifying the name of each directory in the path of the file plus the file name itself. A fully-qualified filename is made up of the directory names in the path plus the filename, such as /dira/dirb/dirc/mydata . Note that the forward slash is used as the delimiter between directory and filenames. HFS files are byte-oriented. There is no concept of a record to the file system. An application can define any structure it wishes for the byte stream. For convenience, a user generally specifies a current (working) directory so that the entire pathname does not have to be specified. Like in a normal UNIX environment, OS/390 OpenEdition filenames are case-sensitive. For example, a file named MYDATA is not the same as mydata which is not the same file as MyData .
4.4.3 File Security Packet

HFS files and directories are protected by permission bit information, which is kept within file security packets (FSPs). These file access permission bits that accompany each file (or directory) provide discretionary access control. An FSP is stored in the file system as a part of the attributes of every file. OS/390 OpenEdition commands, not RACF commands, are used to make changes to the file security packet. However, under the covers, the OS/390 OpenEdition commands invoke RACF callable services. File access permission bits determine the type of access a user has to a file or directory. The bits are set for three classes of users:
Owner class: Any process with an effective UID that matches the UID of the file. Group class: Any process with an effective GID or supplemental GID that matches the GID of the file. Other class: Any process that is not in the owner or group class.
65
Figure 7. File Security Packet
The permission bits are split into three groups of three characters. The first group of three characters describes the owner permissions; the second describes group permissions; the third describes other permissions. Characters that can be used on fixed positions in each of the groups of three characters, are:
Table 5. File Access Types and Permission Bits
Pos. 1 2 Char. r w Access Type Read Write Permission for File Permission to read or print the contents. Permission to change, add to, or delete from the contents. Permission to run the file. This permission is used for executable files. Permission for Directory Permission to read, but not search, the contents. Permission to change, add, or delete directory entries. Permission to search the directory.
Execute or Search no access
any
This table notes a difference between reading and searching a directory. If the user knows the exact name of a file, he needs to only read the directories in the path in order to access the file. If the user wants to list all the contents of a directory, he needs to search it. Permission bits are usually presented in a 3-digit octal number, where the first digit describes owner permissions, the second digit describes group permissions, and the third digit describes permissions for all others. For each type of access, owner, group, and other, there is a corresponding octal number: 0 1 2 No access (---) Execute-only access (--x) Write-only access (-w-)
66
Migration to RACF
3 4 5 6 7
Write and execute (-wx) Read-only access (r--) Read and execute access (r-x) Read and write access (rw-) Read, write, and execute access (rwx)
Some typical 3-digit permissions are specified in octal in this way: 666 700 755 777 Owner (rw-) group(rw-) other(rw-) Owner (rwx) group(---) other(---) Owner (rwx) group(r-x) other(r-x) Owner (rwx) group(rwx) other(rwx)
4.4.4 Default File Permissions

The system assigns default access permissions for files and directories at creation time. The setting depends on the type of command or facility that is used and on the type of file or directory that is created. The following table shows some default permissions set by the system:
Table 6. Default Permissions Set by the System
Task Create directory Create directory Create file Create file Create file Using shell cmd mkdir TSO/E MKDIR OEDIT command Default Permissions In octal form: 777 In octal form: 755 In octal form: 700 In octal form: 666 Set the output file permission to the input file permissions.
ed editor cp command
For more information on the default permissions settings, refer to: MVS/ESA OpenEdition MVS User s Guide . When a file is created, it is assigned initial access permissions by the system. If a user wants to control the permissions that a program can set when it creates a file or directory, he can set a file mode creation mask , using the umask shell command.
4.5 OS/390 OpenEdition DCE Support

Beginning with OS/390 OpenEdition Distributed Computing Environment, interoperability between Resource Access Control Facility on MVS/ESA and DCE is possible. This security interoperability allows a DCE client to access a DCE-enabled server on an OS/390 system and allows the DCE-enabled server to acquire corresponding local security credentials for the DCE client for access to OS/390 resources. The interoperability function provides:
Information necessary for DCE-enabled servers running on OS/390 to use OS/390 userids on behalf of their DCE clients. Appropriately authorized DCE
67
servers can also log the DCE user on to OS/390 (acquire OS/390-RACF credentials) if needed.
Information necessary to transparently log an OS/390 user in to DCE when necessary, without prompting for a DCE userid or password. This ability is called single sign-on . Single sign-on requires that the DCE principals name and password be available to the OS/390 system when it needs to log a user in to DCE. This is done with information from a RACF DCE segment associated with an OS/390 userid. The segment information allows the OS/390 user to authenticate to OS/390 and run a DCE program without re-authenticating to DCE.
Administration commands provided by RACF and utilities provided by OS/390 OpenEdition DCE to populate the RACF database with cross-linking information. There are also SAF, OS/390 OpenEdition, and C language application programming interfaces (AIPs) to access this information. Getting the cross-linking information into (and out of) the RACF database is what allows interoperability and single sign-on to work. Any MVS external security manager that has equivalent support can be used to establish interoperation between the DCE security facilities and that security manager. However, OS/390 OpenEdition DCE provides utilities for cross-linking information only between DCE and RACF.
4.6 What is a Distributed Computing Environment?

Distributed Computing Environment (DCE) provides the services that allow a distributed application to interact with a collection of heterogeneous computers, operating systems, and networks as if they were a single system. It has achieved wide acceptance in the industry. Because DCE is a technology developed by the Open Software Foundation, many of the worlds leading software manufacturers are busily working on implementing DCE on their respective platforms. IBM has been a leader in providing DCE services. DCEs set of services is organized into two categories: distributed programming facility and distributed services . The distributed programming facility includes:

Remote procedure call Directory service Time service Thread service Security service
Distributed services include:

Distributed file service Diskless support
Let me briefly go through the elements and explain what they are. Threads Threads are a familiar concept to the MVS programmer. The name may be new though. The MVS programmer might call it multiprocessing using multiple task control blocks (TCBs). It is a way to multiprogram in a single address space. DCE threads is a user level interface that conforms to POSIX 1003.4a (draft 4). It consists of an API that gives C programmers the ability to create and manipulate threads.
68
Migration to RACF
Distributed security To prevent unauthorized access to the resources in a distributed environment, distributed services and applications must be able to securely identify users, guarantee the integrity and privacy of communications, and control access to resources in an orderly way. The distributed security mechanisms provided in DCE not only perform these functions, but also allow for the distributed administration of the security network. Distributed time service Many distributed applications have to identify the order of events, compute the interval between two events, and schedule events independent of where they occurred. The DCE time service synchronizes the clocks in the systems that comprise the distributed system. Distributed directory In a distributed environment, every resource that will be accessed must have a distinct, unambiguous name, and the location of the resource must be accurate. The distributed directory services in DCE provide both unambiguous naming and accurate location information for all resources described in it. The distributed directory services provide the naming mechanism and the functionality to allow users to create, store, retrieve, and manage the information in the directory entries. Remote procedure call (RPC) RPC is a facility for calling a procedure on a remote machine as though it were a local procedure call. The RPC uses all of the other facilities (threads, security, time, and directory) to accomplish transparent access to servers throughout the network. OpenEdition DCE is an implementation of de facto industry-standard technologies for distributed client/server systems. To a large extent these technologies have their roots in UNIX. The objective of the MVS support is to preserve the general look and feel of the base OSF DCE rather than provide an MVS look and feel. The source of the technology integrated into the OSF DCE offering is as follows: RPC Network Computing System (NCS) 2.0 jointly submitted by DEC and Hewlett Packard. Directory Distributed Naming Service (DECdns) from DEC and DIR-X X.500 service from Siemens. Time Service Distributed Time Synchronization Service (DECdts) from DEC. Threads service Concert Multithread Architecture from DEC. Security Service Kerberos Version 5 from Athena at MIT and Access Control Lists from Hewlett-Packard. Distributed File Service (DFS) Andrew File System (AFS) 4.0 from Transarc; AFS is officially called the Distributed File Service in DCE literature.
69
Diskless Support Diskless workstation support (based on AFS) from Hewlett-Packard. (Not applicable to OpenEdition DCE)
4.6.1 OpenEdition DCE

As discussed in the previous topic, OS/390 OpenEdition DCE was built from technology gathered from the UNIX world. POSIX 1003.1 provides the base operating system services, such as process, file system, and communications. POSIX 1003.2 defines over 180 commands and utilities, POSIX 1003.2a is an extension of 1003.2. POSIX 1003.2 and 2a commands and utilities are very important to the DCE environment. They are primarily used by administrators and application developers. POSIX 1003.4a is the standard on which DCE threads is based. There is no need to implement the threads support shipped with OSF/DCE on MVS since threads support has already been integrated into OS/390 OpenEdition. OS/390 OpenEdition provides a platform that implements international standard interfaces; thus applications and products can be ported to MVS easily. DCE is one of the first products to take advantage of this capability. DCE is currently based on the usage of the C programming language. Therefore, an appropriate C compiler is required. IBM SAA AD/Cycle C/370 implements the ANSI C standard and ISO C standard and is compatible with the DCE requirements. Other commercially available C compilers are expected to function in the OS/390 OpenEdition DCE environment as well. IBM SAA AD/Cycle Language Environment/370 has been extended to include the POSIX functions. OS/390 OpenEdition for MVS/ESA SP 5.1 included IBM SAA AD/Cycle Language Environment/370 and DCE as non-priced features. With MVS/ESA SP 5.2.2, Language Environment for MVS (and VM) and the MVS C/C++ Language support feature in MVS are available.
4.6.2 DCE Cell Configuration

A group of DCE machines that work together and are administered as a unit is called a cell. A cell is the fundamental unit for configuration and administration in DCE. A cell consists of a network connecting three kinds of nodes:

DCE user machines DCE administrator machines DCE server machines
DCE user machines are DCE general-purpose machines. They contain software that enables them to act as clients to all other DCE services. Software running on a DCE user machine is basic for the other kinds of machines also. These services are CDS clerk, DTS clerk, security clerk, and DCE runtime library. DCE administrator machines contain software that enables a DCE administrator to manage DCE services. A DCE administrator has a job function similar to that of an MVS system programmer. The administrator is responsible for configuring and maintaining the distributed computing environment. DCE server machines are equipped with special software enabling them to provide one or more of the DCE services as CDS, DTS, or security services.
70
Migration to RACF
Figure 8. DCE Cell Configuration
Every cell must have at least the following servers in order to function:

One (or more) cell directory service (CDS) servers One (or more) security servers Three (or more) distributed time service (DTS) servers
Note that there can be more than one DCE server running on a DCE server machine, and that the servers necessary to run a DCE cell can be distributed over several machines within the cell. Other DCE servers may be present in a given DCE cell to provide additional functionality. DCE assumes that all nodes (hosts) participating in the DCE environment are physically connected by a highly available network (LAN, WAN, or a combination of both). The DCE architecture supports different types of network protocol families. A DCE environment consists of one or more DCE cells that can communicate with each other. A cell becomes part of a DCE environment when it obtains access to one or more global directory services in which the other cells in the environment are registered. Important elements and terms used with DCE include: administrator machine A machine enabling an administrator to manage DCE services. CDS The DCE Cell Directory Service (CDS) stores names and attributes of resources located in a DCE cell. It is optimized for local access because most directory service queries are for information about resources within the same cell as the originator of the query. clerk A clerk is a client process whose purpose is to fetch information from a server and pass it to another user or application.
71
client host A DCE machine running an application client or an application server but not running a DCE server (that is CDS server, or DTS server, or security server). DTS The DCE Distributed Time Service (DTS) provides synchronized time for the distributed environment. host A machine in a DCE acting as a client or a server IP Internet Protocol (IP) is part of TCP/IP suite of network protocols. runtime library A library containing RPC routines, DCE thread routines, and other DCE routines basic for DCE operations. server host A DCE machine running one or more DCE servers. user machine A DCE general purpose machine.
4.6.3 RACF Interoperability

In order to have interoperability, the RACF database must contain information that associates an OS/390-RACF user ID with a DCE principal and the DCE principals UUID with the corresponding OS/390-RACF user ID. The interoperability information is contained in a RACF DCE segment and in the RACF general resource class, DCEUUIDS. The RACF profile for a given OS/390 user ID contains an optional DCE segment. After this RACF DCE segment is created for an OS/390 user ID by a RACF administrator and fully populated, it contains DCE information for that user, including:

User principal name Principal UUID DCE cell name DCE cell UUID DCE principals password, used for single sign-on Automatic login flag
The information in the DCE segment is used both for single sign-on and for determining a DCE identity when a corresponding RACF identity is known. An optional profile in the RACF general resource class, DCEUUIDS, provides the principals UUID. This profile contains the RACF user ID (on the OS/390 system) that is associated with the DCE principals UUID. The information placed in both the RACF DCE segment and the RACF general resource class, DCEUUIDS, is called cross-linking information . This cross-linking information must be set up before interoperability functions can be used. RACF provides administrator commands for creating, modifying, and deleting the user profile DCE segment and RACF general resource class, DCEUUIDS. OS/390 OpenEdition DCE provides the utilities that support RACF interoperability. These utilities are discussed next.
72
Migration to RACF
4.6.4 The RACF Interoperability Utilities

Two OS/390 OpenEdition DCE utilities, mvsimpt and mvsexpt , are provided to automate much of the administrators work in creating the cross-linking information. The mvsexpt utility creates the cross-linking information in the RACF database from information in the DCE registry. It also allows the migration of the OpenEdition DCE Application Support for MVS/ESA sidefile. The mvsimpt utility creates DCE principals from information obtained from the RACF database. The mvsexpt utility populates individual RACF users DCE segments with the corresponding DCE principal name, principal UUID, cell name, cell UUID, and AUTOLOGIN setting. It also populates the RACF general resource class, DCEUUIDS, with an entry mapping the individual DCE principals UUID and OS/390 user ID. Figure 9 on page 74 depicts the flow of the cross-linking utilities. The input to the utilities comes from either the RACF database or the DCE registry. To be completed, input to MVSIMPT-P1 requires RACF database unload utility. While the RACF DCE segment contains the DCE principals password, the utilities dont fill in the password field of the DCE entry. This must be done by each individual user after the DCE segment is created and populated, and any time the user changes his or her DCE password. The use of the DCE segment information is primarily for single sign-on, but can also be used whenever information in a users DCE segment is needed. The utilities handle these categories of users:

The user is an existing RACF user, but is a new DCE user The user is an existing DCE user, but is a new RACF user The user exists in both DCE and RACF, but the information needs to be cross linked
The utilities are supported only on an OS/390 system and must be run on the OS/390 host system whose RACF database is to be cross linked. If the RACF users are principals in different cells, then the utilities must also be run against the DCE registry for each unique cell. For security reasons, these utilities can only be run by RACF and DCE administrators. The utilities do not support RACF Remote Sharing. The initial cross-linking can be done from either the RACF database or the DCE registry, but mvsimpt and mvsexpt must be run from the OS/390 system where the RACF database resides. Before the utilities can be run, the data entry for cross linking must be done by the RACF administrator (creating RACF DCE segments for OS/390 users) or the DCE cell administrator (creating DCE principals). The process of defining or updating users to the DCE registry that have been previously defined to RACF is the user importing process. The process of defining or updating users to RACF that have been previously defined to the DCE registry is the user exporting process. (The concepts of import and export are seen from the perspective of the DCE registry.) The import-export process can be seen as a circle which can be entered from one of two points depending on whether existing DCE users are to be cross
73
Figure 9. Cross-Linking Utilities.
linked with OS/390 RACF IDs, or new DCE principals are to be cross linked with existing OS/390 RACF IDs.
74
Migration to RACF
Chapter 5. Administration and Maintenance

The administration of the security subsystem is an important factor when selecting the subsystem, or when migrating to another one. In general, normal MVS users see only the effects of the security system, and very seldom issue commands directly to it. Security administrators, however, frequently issue commands to the security subsystem, and the structure (and convenience) of this process is important to them.
5.1 Administrative Interface

RACF administration consists of several different categories of tasks: 1. Routine, day-to-day functions, such as adding users, resetting passwords, adding data set protection profiles, and so forth. 2. Higher-level administration, such as adding new SPECIAL, GROUP SPECIAL, or OPERATIONS users, setting AUDIT controls, and so forth. 3. Setting global RACF controls. 4. Maintaining the database, in the sense of purging unwanted entries, detecting unwanted situations, monitoring the correctness of the security policy reflected by the database, and so forth. 5. Monitoring the audit records written by RACF 6. Maintaining the database, in the sense of backups and reorganization, monitoring performance, and so forth. RACF commands are normally used for the first three tasks in this list. There are a number of ways to enter RACF commands, and these are discussed below. There are many ways to address the fourth task, database quality maintenance. The RACF SEARCH command is a starting point, and may be all that is required. In more demanding cases, a number of third-party products address this area. The fifth task, monitoring audit records, involves listing selected SMF records. The RACF report writer (no longer actively maintained by IBM) is an easy starting point. There are many SMF reporting programs, including the SMF Unload utility that is part of RACF. The sixth task, physical care of the database, involves several utilities supplied with RACF, and also involves normal MVS tuning activities. RACF commands may be entered in a number of ways:

RACF commands from the TSO command line ISPF panels (provided with RACF) Batch jobs (which issue the same commands as under TSO) Application programs (or third-party products) that issue RACF commands RACF commands from MVS operator consoles.
Most commonly, TSO line commands and the ISPF panels are used for day-to-day administration. Batch jobs are useful for bulk updates. RACF commands issued from an MVS operators console (a new feature of RACF) are very useful in critical situations, but are not intended for routine
75
administration. The operator must have performed a logon function (password authentication) before entering RACF commands. (An exception exists for the operator command that switches to the backup RACF database; an operator logon is not needed in order to issue this command.)
RACF Utilities
Several utilities are provided with RACF. These are normally used in batch jobs, and address some of the tasks listed above. These utilities are:
IRRUT200. This program will simply copy the RACF database, checking major structural items as it copies. However, it observes all RACF interlocks for update activities that occur while the copy is in progress. This ensures a logically consistent copy. IEBGENER can be used to copy a RACF database, but it does not observe such interlocks and, if there are RACF updates during the copy, may not produce a correct copy. IRRUT400. This program also copies the RACF database, but it reorganizes it at the same time. It can split the database into multiple data sets (for performance) or merge multiple datasets back into one. IRRUT400 can rebuild internal index records, and generally correct small structural errors. IRRUT100. This program reads the RACF database, and can search for specified entries. While reading, it checks the correctness of internal index records and other pointers. IRRDBU00. This program unloads the RACF database into sequential records, with fields specified in EBCDIC characters. It is readable by a person, and can be used as input to external programs. For example, some installations load this data into DB2 and perform what if searches there. IRRRID00. This program searches an unloaded RACF database for user IDs and groups that are about to be removed from the installation. You can specify the user ID or group that will replace these departing user IDs and groups.
5.2 Privilege Levels

A security system can provide different levels of authority. This is required to administer the security functions, and to handle special needs of certain operations and applications. Management of these special privileges is critical to the integrity of the security system. A good security policy should only grant full security privileges to as few users as possible, and where possible limit the extent of these special privileges. The use and distribution of special privileges must be a basic part of any security policy design or review. It must certainly be an early part of CA-ACF2 to RACF migration planning. This section briefly describes the privilege concepts of the two products.
RACF Privileges
RACF privileges can be divided into two groups, user privileges and class authorities. Users can be assigned any combination of privileges either on a system wide basis or group basis (scope of group). The RACF user privileges are:
76
Migration to RACF
SPECIAL: Permits the user full control over all resource profiles and RACF options in the RACF database. It does not allow the user to access all resources, but will allow the user to authorize themselves so they can have access. It is strongly recommended that all users with this option be fully audited. AUDIT: Permits the user to control audit (logging) activities for all RACF profiles. It does not give the user any additional authority to access resources, such as data sets, or to alter other details of RACF profiles. OPERATIONS: Permits a user full access to all resources where allowed in the Class Descriptor Table, CDT. The dataset CLASS will honor the OPERATIONS attribute. If a user is specifically identified either via USERID or a connected GROUP, then that level of access is taken in precedence of OPERATIONS. OPERATIONS does not allow the user to modify or delete the RACF profile covering the resource. It is strongly recommended that all users with this option be fully audited. CLAUTH: Allows the user to define profiles within a specific class. Note that when this privilege is associated with the JOIN authority then this user can define new RACF USERIDS for the group that they have JOIN access to. Users can have more than one CLASS authority, for example FACILITY and GCICSTRN. CLAUTH cannot be assigned at the group level. Class Authorities can be delegated to any RACF USERID.
Each user in a group requires one level of group authority for that group. If a user is connected to several groups then they will have several group authorities. The default authority is normally USE.
USE: USE allows the user to enter the system under the control of that GROUP and can access resources to which the group is authorized. CREATE: CREATE authority will allow a user to allocate new GROUP data sets, protect GROUP data sets and control access to the profiles the user has created. CREATE authority includes the authority of USE. CONNECT: CONNECT will allow the user to connect existing RACF users to that particular group and also assign the USE, CREATE or CONNECT authorities to that USERID. CONNECT authority includes USE and CREATE. JOIN: JOIN is the highest group authority and will allow the user to define new users and sub-groups to RACF. Note to define new users to RACF then the user must also have the CLAUTH authority for the USER class.
ACF2 User Privileges

In a sense, ACF2 has two sets of privilege groups, those that operate on records within the ACF2 database and are subject to SCOPE records, and those that grant operational accesses not related to changing database records and are not subject to SCOPE records. RACF privileges are easy to identify, understand, and administer, but they are not as granular as ACF2 privileges. Conversely, the ACF2 privileges allow more granular control of authority, but have more complex interactions and may require more administrative effort.
77
Scoped ACF2 Privileges

There are many ACF2 user privileges that can be assigned to users and where possible we have tried to simplify them and break them down into a RACF function. This section discusses the privileges we consider most important for user conversion. In ACF2 you can restrict user privileges by using SCOPE records. This is similar to RACF group-related user attributes. In RACF, users who have the group-SPECIAL, group-AUDITOR, or group-OPERATIONS attributes are restricted to only profiles that are within the scope of their groups. Table 7 lists the RACF translations of ACF2 privileges that can be scoped. (This table does not imply that the listed CA-ACF2 and RACF privileges are one-to-one translations to each other. They are not.)
Table 7. ACF2 User Privileges
ACF2 SECURITY (needs TSO ACCOUNT) ACCOUNT RACF SPECIAL RACF Description Full control over ALL RACF profiles
CLAUTH(USER)
Together with JOIN in a specific group, allows a user to list, alter and define other user profiles in that group. There is no direct RACF translation. This needs careful planning in how the RACF groups will be setup. A RACF user may display his user profile. He is not allowed to modify or delete it unless he is the owner. Allows display of all RACF profiles and monitoring of all RACF related activities.
LEADER (display or alter certain fields) CONSULT
Profile ownership
AUDITOR at a group level AUDITOR
AUDIT
Table 8 is a summary for the scoped LOGONID privileges which are to be mapped into RACF user attributes and group attributes.
Table 8. Default SCOPE Records Mapping Table
PRIVILEGE SCOPE FIELD SECURITY LID and UID DSN group-special group-SPECIAL group-OPERATIONS ACCOUNT AUTH(JOIN) CLAUTH(USER) group-SPECIAL CLAUTH(user) AUDIT group-auditor group-AUDITOR
The SECURITY or ACCOUNT privileged LOGONIDs will receive more authority after the SCOPE record migration is completed according to the default table. An ACCOUNT-privileged LOGONID receives extended authority for data set management, even though it previously had authority only to create matching LOGONIDs in the ACF2 environment. The same is true for a user with the SECURITY privilege with LID() or UID() specified. This will allow the user to manage any data sets owned by the group(s) that the user is connected to.
78
Migration to RACF
Note there are no corresponding authorities in RACF for the ACF2 LEADER and CONSULT privileges, therefore these privileges must be examined and carefully planned for in the migration process.
Non-scoped ACF2 Privileges

The following privileges are not covered by SCOPE but can be compared to RACF functions.
RESTRICT Privilege: An ACF2 LOGONID with the RESTRICT privilege may be specified on a JCL JOB statement as a value for the keyword USER without specifying a PASSWORD. The ACF2 LOGONID with the RESTRICT privilege cannot be used for LOGON or SIGNON purpose.
The ACF2 LOGONID with the RESTRICT privilege is accepted by JES as a RACF SURROGATE class user value for the job being submitted. An ACF2 LOGONID with the RESTRICT privilege can be specified in JCL as an extended JCL statement (beginning columns are //* or /*). ACF2 provides JES exits to handle this JCL statement. To convert the ACF2 LOGONID RESTRICT privilege to the RACF equivalent, you might:

Disallow terminal access for the user ID, or limit logon in other ways Allow SURROGATE job submission for the user ID
Access to resources for RESTRICT users is given at the user level rather than the group level. An inventory of all standard users authorized to use RESTRICT LOGONIDs should be made, and these users must be authorized to the proper RESTRICT LOGONIDs in the SURROGATE class. Use of the LOG option of ACF2 is recommended for this inventory.
NON-CNCL Privilege: ACF2 LOGONIDs with the NON-CNCL privilege have full access to all data sets and resources, but are logged if they are not on the access list. No access restrictions can be assigned to this user.
In RACF this would translate to a RACF USERID with the OPERATIONS attribute. Access to data sets allowed with the OPERATIONS attribute should be logged.
DEFAULT Users: ACF2 allocates the DEFAULT LOGONID for different environments. These values are pointed to by GSO records.
Default LOGONIDs are used when no other LOGONID is available for resource access control. For example:

At job submission, when no LOGONID is propagated. For jobs received from NJE nodes, when no LOGONID is in the NJE header. For IMS transaction access control, when the IMS user is not signed on.
USERID translation or JES user exits can be used to provide default USERIDs for submitted jobs. For JES2, exit 36 or exit 37 (or both) can be used. For JES3, exit UX58 or exit UX59 (or both) can be used. In all others situation, RACF exits can be used as required to provide authorization checking for the default USERID when no USERID is propagated.
79
5.3 Commands
CA-ACF2 and RACF both have their own command sets. In each case, ISPF panels are available to ease the use of the commands, but the underlying line commands are central to understanding the use of the product. Both products have extensive documentation, and there is no point in listing all their commands here. We will, briefly, discuss a few commands that are the basis of daily, routine work. These include adding a user, protecting a dataset, and granting access to datasets. RACF has one book to describe all RACF commands and syntax, RACF Command Language Reference . This availability of a single, definitive reference is important.
Discussion
Both products have many commands, and many of these are used only by the security administrator or systems programmers. Only a small part of the full command sets are used daily by other administrators, help desk personnel, and end users. RACF has four general types of database entities ( profiles ); these are: User, Group, Dataset, and General Resources. Each of these types has associated commands to add, modify, delete, and list profiles. The following table lists the basic commands for these operations. The table shows, for example, that the ALTGROUP command would be used to alter a group profile.
Table 9. RACF commands to add, modify, delete and list resources
User Add Modify Delete List ADDUSER ALTUSER DELUSER LISTUSER
Group ADDGROUP ALTGROUP DELGROUP LISTGRP
Dataset ADDSD ALTDSD DELDSD LISTDSD
General Resources RDEFINE RALTER RDELETE RLIST
This table is quite simplistic and is not intended to convey any of the ramifications of the indicated functions.
Who Issues Commands?

5.2, Privilege Levels on page 76 discusses the various privilege levels of RACF commands in some detail. A very brief summary, related to the use of RACF commands, may be helpful here:
Someone with the SPECIAL privilege can issue any RACF command, except those restricted to auditors. (A SPECIAL user can grant himself the AUDITOR privilege, and then issue those commands.) This level is usually restricted to a few security administrators. The SPECIAL user typically issues global RACF commands, constructs important generic data set profiles, defines groups, and delegates Group-SPECIAL authority. Someone with a Group-SPECIAL privilege can issue RACF commands that affect only a designated group, or its subgroups. A group may own many subgroups, providing many ways to structure and delegate authority. Distributed security administrators typically have Group-SPECIAL authority for their areas. Help desk personnel may have Group-SPECIAL authority.
80
Migration to RACF
The owner of a profile can issue several RACF commands that affect only that profile. In practice, this means that the owner of a data set profile can control which users (and at what level) can access data sets protected by that profile. The primary command involved is PERMIT.
In the PROTECTALL environment, a RACF profile will already exist for a user s HLQ (created when the user ID was added to RACF). A user can grant permission to other users to access his files. The PERMIT command is used for this, and this may be the only RACF command that typical users issue. In a well-designed environment, with appropriate use of generic data set profiles, many users will never need to issue PERMIT commands. RACF commands can be issued from MVS operator consoles. This should not be regarded as a routine interface for RACF administration, but it can be very useful in an emergency situation. A profile class, OPERCMDS, is used to control which operators can issue which RACF commands. Operators are required to log onto the MVS operator console before they can issue RACF commands.
Migration Issues
Once the basic command structure is understood, using RACF commands instead of CA-ACF2 commands should not present problems. The more important migration issues are the organizational processes that occur before any commands are issued. Is the organizations structure reflected in the RACF group definitions? Is the organizations security policy well defined? Clear? Have the routine tasks for help desk personnel and security administrators been defined and explained? Has the organizations auditing requirements been defined and implemented? If the administrators who issue RACF commands clearly understand the answers to these questions, then the use of various RACF commands should be straightforward.
Summary
In practice, CA-ACF2 and RACF commands are usually issued from the TSO command line (more experienced administrators) or from ISPF panels. In both cases, a good understanding of the security policy in use, and the use of consistent naming conventions and group conventions, is key to understanding and using the security administrative commands. In both cases, commands can be batched by using the PGM=IKJEFT01 method of running TSO functions in batch jobs. The consolidation of all RACF commands in one book, RACF Command Language Reference , with formal command syntax descriptions, makes the use of new command options easier.
5.4 Security Reports

Reports are important for security administration.
Goals and Issues

To enable tracking and monitoring of events and status of the security environment established, and to uncover changes that could lower or change the expected security level. The problem is to collect and get the correct data to meet the objectives. Too many collect too much data without having any plan or strategy for what they are going to use it for.
81
Terminology
There are two levels of reporting for MVS security subsystems. One level reflects the contents of the security database, and describes what is protected and how it is protected. This is status monitoring . The other level reflects the security events that occurred during a particular period. For example, which users logged onto the system, or what attempted security violations were detected. This is event monitoring .
Concepts & Designs

For both CA-ACF2 and RACF, event monitoring is centered around SMF records. There are many programs and products available for listing SMF records. RACF includes the RACF Report Writer (which is not actively maintained by IBM, but is still useful because it is so simple to use). The usefulness of event monitoring depends on what is monitored; that is, what causes an SMF record to be written? CA-ACF2 and RACF have options to control which events cause an SMF record to be written. RACF has an orderly structure of auditing controls for this purpose. Controls exist at both individual profile levels and at the global level. Since a profile can be used to protect a single data set, or to protect a large number of data sets (with similar higher-level qualifiers), auditing controls can be selective. RACF controls can be set to write SMF records on either access failures (where data set access was prevented by RACF), or on access successes (where data set access was permitted by RACF). In general, reporting of successful accesses is not wanted -- partly because the volume of SMF records would be too large. However, successful access reporting may be appropriate for a carefully selected set of application data sets. Access failure events are typically used to create an SMF record, and a basic part of the security administrators duties is to review these records. 11 RACF can also log (to SMF) changes to the RACF database itself, and records indicating changes to user profiles with any of the high-level authorities, such as SPECIAL, should always be reviewed. Some of the key global controls of RACF, related to auditing, are:
SAUDIT is used to log all commands that need a SPECIAL user privilege. This is used to review activities by these privileged users. It can also be used to recreate profiles and commands from SMF data in an emergency. OPERAUDIT is used to log all data accesses a user with the OPERATIONS privilege is granted, due to this privilege. Access through normal access rights are not logged. Use both SAUDIT and OPERAUDIT to enable auditing of privileged users and their activities.
CMDVIOL is used to switch on/off RACF command reporting; CMDVIO will record all attempts to use RACF commands outside a users authority. LOGOPTIONS are used to specify logging options for different resource classes, from no logging to full logging. These can be used to globally force
11
There are many different approaches to this. Some installations want to review every access failure, while others check only for substantial patterns of access failures. An access failure is not a security failure; it is simply an indication that the security subsystem was doing its job. In practice, reviewing every access failure tends to be impractical.
82
Migration to RACF
logging of resources in one class to avoid having to specify the AUDIT option on each profile.
Global AUDIT can be specified by someone with the AUDITOR privilege. This generates audit data without requiring that specific profiles be selected for auditing.
In addition to these global and class options, each resource profile can have its own audit requirements defined through the AUDIT option: from no logging to full logging. This setting will not lower the logging requirement set by the LOGOPTIONS value for that class. All profiles have a default AUDIT setting; for datasets, it is AUDIT(FAILURES). In addition to the various logging options mentioned here, all invalid password attempts are logged by default. UAUDIT can be set on a user profile to cause all RACF activity for that particular user to be logged. It is an effective way to trace all activities of a user, but must be used with some restraint to avoid writing too many SMF records. Status monitor involves listing control settings in the security data base, and monitoring changes to these controls. SMF records, written by RACF, are useful for detecting changes, while static information must be extracted from the database itself. Several tools are provided by RACF:
DSMON (Data Security Monitor) is a program for reporting on several security settings, user privileges and protection status of important system datasets. It should be run regularly to monitor any changes to any of these security areas. The RACF ISPF panels offer a number of options to display various control settings. The IRRDBU00 utility, which unloads the complete RACF database into a flat, human-readable file. This file can be used in a number of ways: through locally-written programs, by loading it into DB2 and executing searches there, and so forth.
Summary
Log and audit functions are an important part of an organizations security policy. The security policy should clearly define what is expected for logging and audit, and how it will be used. This requires some skill and experience, since a balance is needed between what is practical, the effects on performance, the problems of generating too much data, and so forth.
5.5 Availability Considerations

CA-ACF2 and RACF, when fully implemented and used, are both functions critical to an MVS production environment. Their availability and recoverability must therefore be carefully designed, planned and tested. Due to different technical features and capabilities of the two products, recovery techniques and strategies differ. Approaches to RACF recovery are discussed below.
83
Figure 10. RACF Primary and Backup Data Sets
5.5.1 RACF Active Backup Option

A unique recovery feature in RACF is the active backup dataset option, the commonly used option to maintain a software mirror image of the primary RACF database. While RACF performs all authentication and authorization checking against its primary database, all updates are automatically duplicated onto the active backup database. In case the primary database is lost, a switch to the backup database can be performed without the need for an IPL or other recovery procedures.
RACF Database Backup

The initial setup of the RACF recovery environment requires defining the name of the backup dataset in the RACF Dataset Name Table ICHRDSNT and making a copy of the primary database (while no updates are taking place). Good recovery strategies also have provisions to periodically take additional backup copies (independent of the active backup). We believe that the best tool to create such copies is the RACF verify utility program IRRUT200; this program enqueues on the input database for the duration of the copy process and has the additional advantage that it provides an analysis of the database structure. The IRRUT200 list output can be used to determine the degree to which the database is filled and to identify potential structural problems that need to be addressed.
RACF Database Recovery

When a problem with the primary RACF database is discovered, an RVARY SWITCH command is issued on the system console or in a TSO session to initiate a switch to the active backup database. This one now becomes the primary database and the original primary is deactivated. The system continues to run with just a primary database, and the creation and activation of a new backup database is scheduled for a period of low activity.
84
Migration to RACF
To avoid false alarms, this switching capability can be secured by a password under the control of the central security administration; this feature can be used to enforce procedures that require the involvement of security management in any RACF status change.
5.5.2 Recovery Strategies

The primary strategy to recover from RACF dataset problems is obviously the above described online switching scenario. Two different strategies to recover from other potential RACF malfunctions have evolved over time:

fix the security system first and then resume production, or continue running production at all cost, even if RACF has to be temporarily deactivated.
Fixing RACF First

This is by far the most commonly used approach and the simplest as well. To implement this approach it is most practical to define a small number of emergency TSO IDs in SYS1.UADS so that the technical support persons in charge of the repair work can logon to TSO when RACF is inactive (To avoid potential exposures, these IDs must also be RACF-defined). Typical solutions usually start with restoring a reasonably up-to-date copy of a RACF database that was independently saved.
Production without RACF Active

This is the traditional approach to recovery, designed when the trust in RACF and its recoverability was not as high as is today. This approach usually involves the design of exit code to automate the process to run production with RACF inactive that otherwise would require operator decisions for every security issue. We do not recommend this approach; it can pose many problems. For example, some TSO users may not have SYS1.UADS entries, and others will have forgotten their SYS1.UADS passwords (which are not updated when RACF passwords are changed). Some applications may depend on RACF for more than simple user authentication and data set protection, and these applications may simply not work without RACF
5.5.3 Reorganizing the RACF Database

Some organizations include periodic reorganizations of their RACF databases in their backup and recovery plans. This has performance as well as recovery aspects. In a quiesced environment, use the RACF split/merge utility IRRUT400 to create a logical copy of your RACF database (specify one input and one output file). This process eliminates CI--like splits in the database structure and profiles that have been logically deleted (no pointers in the index structure) but may physically still be present.
5.6 RACF Performance Considerations
85
Goals and Issues

There can be a conflict between your ideal security policy and the performance practicalities of the security subsystem. Controlling CICS transaction accesses is an example of a function that can be torn between security needs and performance needs. Extracting the best performance from the security subsystem involves these areas:

Use of global options that short-circuit the rest of the security monitor. Using some type of cache in main storage. Use of special coding options, in applications, that result in an unusually fast response by the security subsystem. A good design for sharing the database file among multiple systems, since the need for a shared security database is common. Normal DASD tuning techniques to improve I/O response.
Both CA-ACF2 and RACF provide options in all these categories. Some of these are not simply performance options; they affect the policy design of the security database and should be considered part of your high-level design.
Terminology
Some of the key RACF terminology in this area includes:
GAC (Global Authorization Check). RACF uses this in-storage table to make quick decisions about whether further RACF checking is needed. RACLIST refers to the process of moving a complete RACF CLASS of profiles into storage, for faster access. in-storage buffers refer to the allocation, in main storage, of a given number of buffers that are managed by RACF with a type of least recently used (LRU) purging technique.
Concepts
If not deflected by a Trusted or Privileged property, RACF checks the GAC when beginning to process an access request. The GAC is an in-storage table owned by RACF. It is copied into storage when RACF is started, and is static during operation, unless updated by a security administrator. It is usually a very small table. The most typical use is to grant permission to access (in any manner) a dataset with the same HLQ as the caller. That is, a user can work with his own datasets (as identified by a matching HLQ) without any further checking by RACF. The GAC can contain lists of exceptions to the general rules it sets, causing the normal profiles to be checked for these exceptions. This process can provide excellent performance. The exposure is that no other RACF controls are checked. If, for example, the GAC gives all users READ access to all SYS1 datasets, then no SYS1 datasets can have a general access level of NONE because the profiles that try to establish this condition are not checked. The use of a GAC entry bypassed them. The use of the GAC table is important for performance, but the usage must flow from the overall security policy being defined. The installation can specify a certain amount of buffer space to be dedicated to a RACF cache, known as in-storage buffers. This space is in protected common storage. It is pagable, but, for practical purposes can be regarded as fixed because it is referenced frequently. The use of this cache is transparent to policy design, and is a pure tuning function. (The cache is limited to RACF
86
Migration to RACF
elements that are normally read-only, or write-through cache data. The RACF database, on disk, must always reflect current data to other MVS systems sharing the same database.) RACF can manage a BACKUP database, in addition to its primary database. Practically every installation elects to have a backup RACF database. We do not consider deleting this to be a reasonable action. In addition to profile updates, RACF writes statistical data in its database; for example, the date and time of a users most recent TSO logon. There is an option to bypass updating the backup database with statistical data. Many installations select this option. In the rare event of a database failure, requiring use of the backup RACF database, some statistical data will be missing. This is usually considered a reasonable tradeoff. Customers can make use of MVSs virtual lookaside facility (VLF) to cache ACEEs and information for OpenEdition. If RACF finds information in VLF, it will avoid I/O to the database. RACF can use split databases, meaning the database can be divided into multiple files, on multiple volumes. (The backup database can also be split.) RACF still uses it as a single logical database. By placing parts of the database on different volumes, different control units, and/or different channels, normal DASD dataset tuning techniques can be applied. As an extreme example, a few very large installations have split their database into 26 parts -- one for each letter of the alphabet. If user names, HLQ names, group names, and so forth, were evenly distributed across the alphabet, this split might provide a substantial performance gain. 12 Splitting the RACF database is transparent to security policy decisions. It is another pure tuning function, although it has availability issues associated with it. RACF offers a special high-performance interface, RACROUTE REQUEST=FASTAUTH. Programs must be specially coded to use it; it is not used by automatic system calls that go through SAF. CICS is the major example that can use RACROUTE REQUEST=FASTAUTH. The RACROUTE REQUEST=FASTAUTH function references only in-storage tables (placed in storage by the RACROUTE REQUEST=LIST function), providing major performance benefits over any method that involved disk database checks. The IRRUT400 utility, supplied with RACF, can be used to reorganize the database. Database performance may degrade slightly over time, as updates and changes occur. The effect is usually fairly minor, unless very large databases are involved, or many profiles have been added and deleted. A typical installation might use this utility to reorganize the database every six months.
Performance of Shared Databases

Sharing a database, CA-ACF2 or RACF, among multiple MVS images has become common. This has a number of interesting effects on performance design, including:
12
This particular split was partly for increased reliability. The thought was that if a particular disk failed, only a small number of users/profiles would be lost. We have doubts about this strategy, but there is reasonable debate among RACF specialists about the use of split databases for various purposes.
87
The use of cache functions becomes more restricted, since the corresponding disk record could be updated by another system, making the cached data invalid. Extensive use of RESERVE and RELEASE functions (disk locking commands) can badly impact the performance of a shared disk. The use of a disk API ( access method ) that is not optimized for shared system usage can badly impact performance.
RACF uses a low-level, proprietary API for disk access. It does not use VSAM. The RACF design is optimized for shared-system use and should automatically provide a major performance boost compared with shared-VSAM usage. The RACF use of cache (in-storage buffers) is based on a design that avoids cache coherency problems in the presence of shared-system operation. The element of RACF operation that affect shared-system performance are all automatic. There is no user tuning involved. The tuning items discussed above are effective in both single-system and multi-system environments. MVS Sysplex is a special case of a shared-system environment. RACF can take advantage of the high-speed coupling unit in this case.
Migration Issues
The complete PPT should be reviewed manually, as part of any migration effort. Other performance elements, especially the GAC, should be created manually -although mechanical conversion tools may provide data for use in the GAC. Performance elements that do not interact with policy design, such as in-storage buffers and database splitting, can be managed independently from the migration process itself. If the basic migration process, normally through the use of specialized software tools, provides acceptable performance, then it may be advisable to postpone tuning these elements until the end of the migration project. A CICS installation would certainly want to enable RACROUTE REQUEST=FASTAUTH checking as part of migration. This should provide a substantial performance improvement, as well as integrate CICS usage into normal RACF operation.
Summary
Tuning can make a major difference in security subsystem performance. RACF offers a number of major tuning options. Some of these interact with the security policy goals of the system, and this aspect must be considered in the overall design of the RACF implementation. With reasonable designs, RACF can offer significant performance improvements, especially for key areas such as CICS.
88
Migration to RACF
Chapter 6. Technical Details

The internal details of RACF may not be important at the introductory level, or even at the migration level in some cases. Nevertheless, a sense of the internal structure can help provide a better understanding of RACF. This chapter briefly introduces a few of the more important internal functions and elements.
6.1 System Authorization Facility (SAF) and RACF

System Authorization Facility (SAF) is the name of the central MVS security interface. According to this concept, resource managers issue RACROUTE calls to request security services and then make access decisions based on return codes. RACROUTE calls are received by SAF and most of them are routed to the designated security manager, e.g., RACF, which then evaluates the request based on its rules stored in profiles in its database. A few calls are directly handled by SAF which provides default security services and manages security tokens. SAF has been the standard interface to RACF for 15 years, while CA-ACF2 has only recently added full SAF support (which obsoletes the need for CA-ACF2 modifications to MVS code). The following detail is designed to provide readers not so familiar with SAF with an overview that may be helpful in planning their RACF system.
6.1.1 MVS/RACF Security Environment

For the major resource managers in an MVS system, RACROUTE security calls are used to communicate with RACF via SAF. The most common security calls are for user authentication (RACROUTE REQUEST=VERIFY) and for resource authorization checking (RACROUTE REQUEST=AUTH). While JES and TSO make authentication calls only and DFP authorization calls, subsystems such as IMS and CICS typically issue both types for external security. Note that, for DFP, ALWAYS CALL has been the standard mode of operation for almost 15 years; DFP makes security calls independent of RACF indicators.
6.1.2 Control Blocks

Two types of control blocks are used to secure jobs in a RACF environment, a security token and an Accessor Environment Element (ACEE). Security tokens are attached to a job for the duration of its lifetime, from first card in to last line out. Key elements contained in a security token are:

principal user ID, groupname under which job is executed submitting user ID, groupname, node name security label port of entry execution node etc.
89
Figure 11. Router Flow. This figure illustrates the general flow from the time a system (or application) program call RACF, using SAF. RACROUTE is the SAF macro used.
Figure 12. Subfunctions of SAF RACROUTE.. A n u m b e r of functions can be requested through the RACROUTE interface, such as verify, authenticate, define, and so forth. These functions are transmitted through SAF and sent to corresponding modules in RACF. External callers can directly access the RACF database by using the ICHEINTY macro.
90
Migration to RACF
Figure 13. SAF Interface. SAF is the security interface for user address spaces and for most system address spaces. These call SAF for security services, and SAF routes these calls to the security subsystem.
The ACEE governs the execution of a job; it is built during user authentication and contains information obtained from the security token and the user profile in the RACF database. Key elements in the ACEE are:

principal user ID group name or list of group names used for authorization checking user privileges such as SPECIAL, OPERATIONS, etc. pointers to profiles in users address space etc.
6.1.3 RACROUTE Calls

Resource managers can use RACROUTE to issue various different requests for security services. Figure 12 on page 90 maps the different RACROUTE requests against RACF functions and also shows services handled by SAF plus ICHEINTY, a low level interface to the RACF manager. RACROUTE macros provide a logical secruity interface; a brief overview of some request types follows:
VERIFY and VERIFYX requests invoke the function which authenticates users and builds the ACEE at job start time, AUTH requests call the function which performs authorization checking, DEFINE requests invoke services to define RACF resource profiles dynamically (although profile creation is normally done by using TSO commands, and not through macro interfaces), LIST and FASTAUTH call the services used to build in-storage profiles and perform fast authorization checking for online services such as IMS or CICS, and EXTRACT provides services to extract information from RACF profiles.
TOKEN services are, as shown, provided by SAF without link to RACF.
91
ICHEINTY macros provide physical access to the RACF database; it is not a recommended interface because all validity checking is the responsibility of the caller.
6.1.4 Return Codes

SAF and RACF answer security requests through a system of return and reason codes: SAF/Router return codes, RACF return codes and RACF reason codes. Of the many codes, three RACF return codes for AUTH requests are important to note:

RC=0 - allow access, user is positively authorized RC=8 - deny access, user is not authorized RC=4 - no profile found, no RACF decision
If a return code of 4 is presented, a decision is made by the resource manager. Some resource managers, for example DFP, will allow access in this case, while other resource managers, for example CICS, will deny it.
6.1.5 SAF Control Flow

Figure 11 on page 90 shows the control flow of a RACROUTE call and some related tables. The call is first handled by the MVS Router (ICHSFR00) which invokes router exit ICHRTX00 if present. Unless determined otherwise by the exit, control then transfers to the RACF Router (ICHRFR00) which examines its router tables ICHRFRxx. If these tables point to RACF for the requested function, the appropriate RACF module gains control and uses the RACF class descriptor tables ICHRRCDx to locate the proper resource class description and properties. On return, the above sequence is followed in reverse order.
6.1.6 Tables
The RACF router tables list resource classes and request types and the appropriate action. The class descriptor tables contain resource class definitions with all properties assigned to each class. For each type there are two tables defined, one reserved for IBM use (ICHRFR0X and ICHRRCDX) and one for installation use. In a pure RACF environment, the router table ICHRFR0X is set up to call RACF and all IBM resource classes are predefined in ICHRRCDX. To add locally defined resource classes, tables ICHRFR01 and ICHRRCDE can be updated in a synchronized fashion.
6.1.7 Exits
Router exit ICHRTX00 can be used to implement installation-defined controls. While this exit has been used historically, there is no need to consider using it on RACF release 1.9 or higher releases.
6.1.8 Old RACF Interfaces

Some documentation may contain reference to macros such as RACINIT, RACHECK, etc. These macros represent an old interface to RACF used prior to RACROUTE and should not be used. IBM has not added new function to these macros since RACF release 1.8.
92
Migration to RACF
6.2 RACF Tables

Started Task Table
Prior to RACF 2.1 all started tasks had to be defined in the RACF table, ICHRIN03. This table required MVS to be re-IPLed each time a modification was made to it. In RACF 2.1 the ability to define started tasks dynamically was introduced. Started tasks are now defined in the STARTED class. This class completely replaces the old entries in the ICHRIN03 table, but the ICHRIN03 table must still exist (even if it is empty). It might be appropriate to keep critical entries, for JES, VTAM, and TSO, for example, in the table.
Dataset Names Table

The database names table, ICHRDSNT, as well as identifying to RACF the name of the RACF database, also describes

Number of in-storage buffers (a performance option) Sysplex communication option Default data sharing mode.
RACF will allow you to define up to 90 primary and 90 backup databases. If instead of specifying a name in ICHRDSNT you specify an *, then RACF will prompt the operator for a name at IPL time. If ICHRDSNT is not found at IPL time then the operator is still prompted for a name but only 10 in-storage buffers and no backup database will be allocated. This will cause performance problems and should be avoided. If you are going to use more than one primary RACF database then you need to define a RACF Range table, ICHRRNG. This table determines on which RACF database to place each profile. For example all profiles starting with SYS1 could be placed in one database and remaining profiles in another database. (This is an example, not a recommendation!)
Class Descriptor Table

A RACF class is a collection of entities with similar characteristics. There are two class descriptor tables. The first one is ICHRRCDX and is reserved for use by IBM. The second one is for customer use and is called ICHRRCDE. Customer-defined classes cannot duplicate the IBM supplied ones in ICHRRCDX. Customers can have up to 768 entries in ICHRRCDE. Customer-defined classes must have a corresponding entry in the RACF router table, ICHRFR01. There is also an IBM supplied router table for IBM entries, ICHRFR0X.
6.3 RACF Exits

RACF provides exit points that can be used for additional levels of protection. In Figure 14 on page 94 a table shows all the exits that RACF currently supports. Not every installation will need to code these exits. Where possible, standard RACF functions should be used. The following section gives a brief description of some of the more common exits and their possible uses. You can verify which exits are active by reviewing the RACF DSMON report. Some exits can do both pre and post processing. Normal RACF usage does not require the use of any exits. . The exits provide interfaces for changing normal RACF processing.
93
Figure 14. RACF Exits. The flow shown is conceptual, and is intended to illustrate the pre-processing and post-processing nature of the exits. In practice, RACF obtains control and calls the exits at appropriate times.
Command Exits - ICHCNX00/ICHCCX00

These exit routines allow the installation to associate additional security checking, or processing, with certain RACF commands, or to bypass checking all together.
Authorization Exits - ICHRCX01/ICHRCX02.

The RACROUTE REQUEST=AUTH exits can alter the decision-making process that determines if a user should have access to a resource.
Define Exits - ICHRDX01/ICHRDX02.

The RACROUTE REQUEST=DEFINE exits can alter the creation (or deletion) of profiles. These might be used to enforce local standards.
Verify Exits - ICHRIX01/ICHRIX02.

The RACROUTE REQUEST=VERIFY(X) exits can alter the authentication processing for a user.
Password Encryption - ICHDEX01

This exit can be used to alter the form in which passwords are stored.
Password Checking Exit - ICHPWX01.

This exit can be used to check for trivial passwords and enforce local password rules in addition to normal RACF password rules.
94
Migration to RACF
Data Set Naming Convention Table - ICHNCV00

This table allows the installation to set up and enforce data set naming conventions that are different from standard RACF naming conventions. For example, you may need to perform RACF checking on the second level qualifier of a data set and not the first, which is the way RACF normally works.
95
96
Migration to RACF
Chapter 7. IBM Migration Services

IBM offers a number of migration services, including CA-ACF2 to RACF migration. The following is a brief overview of the migration services.
7.1.1 Mainframe System Software

In the evolving world of client/server computing, many customers are redefining the role of their mainframes, and re-evaluating their mainframe system software. They are choosing products that not only perform well today, but that are capable of participating in the evolving world of open systems and enterprise-wide computing. They are choosing vendors who offer quality products, quality support and who offer flexible terms and conditions that allow the software to change as the customers requirements change. Increasingly, customers are choosing IBM software as a base for their enterprise computing needs.
7.1.2 Migration Services

Choosing the right product is one thing, changing mission critical software can be quite another. To accomplish the migration with the least disruption to their business, many customers look for expert assistance. IBMs migration services are designed to minimize the time, risk and total cost of changing critical system software. By assisting many customers with such migrations, IBM has developed skills, tools and experience which can be used to assure a successful migration. Our approach is to leverage IBMs experience and tools, along the customers knowledge of their systems to create a cost effective team. This team approach also allows a great deal of skills transfer to take place naturally throughout the migration, so that when the migration is complete, the customers staff is able to manage the new environment productively.
7.1.3 Conversion vs. Migration

One important consideration when choosing migration services is the difference between a conversion and a migration . A conversion refers to the translation of the operational data from one format to another. A migration project is a much broader effort, beginning with project assessment and planning, continuing with installation and testing, including conversion activities and tools and ending with final cutover. Though the conversion phase is very important, it is only one piece of a full migration project.
7.1.4 Migrations - No Two Alike

Most customers have had their mainframe system software installed for some time. Over that time, the software has evolved, and each customer has uniquely customized their software to better fit their needs. While this customization makes the product more valuable, it also makes the migration more complex. Complexity, along with the amount of skill, resource and focus that each customer is willing to dedicate to a migration effort, make each migration unique. As such, each customer will require a different amount of assistance, take a different amount of time and have a different total cost for completing the same product migration.
97
7.1.5 Migration Service Offerings

IBMs migration service offerings have a flexible, modular structure to allow each customer to choose the type and amount of service that is needed to meet that customers needs. While the details regarding specific product migrations differ slightly, the general structure of IBMs migration service offerings is as follows:
Migration Assessment Service

Performed by a migration specialist, this service assists the customer to assess the time, effort, skill requirements and feasibility of migrating from their current environment. By analyzing reports and extracted data and by interviewing technical staff and management, the migration specialist can create a documented assessment report and review it with the client.
Database Conversion Service

IBM can bring customized conversion tools to bear on many of the product migrations. Fixed priced offerings include the customization, usage and support of the conversion tools.
Migration Consulting Services

Migration specialists, experienced from other similar migrations are available to provide guidance with a wide variety of migration activities. Typical uses of migration consulting are:
Migration Planning - lead a customer/IBM team to create a documented migration plan, including detailed task list, target dates and people assignments. Technical Analysis - analyze the current implementation of the installed product and offer alternative ways of implementing that function using the new product.
Consulting services are typically billed on an hourly basis.
Migration Perform Services

IBM services are available to perform many of the tasks required to complete the migration. Some of the services available are:

Product installation and customization Implementation of new function Exit design and/or coding Testing, test planning and validation Operations skills transfer Project Management
Perform services are typically billed on an hourly basis.
Education Services
Through IBM Education and Training, a variety of education alternatives are offered. Product classes, as well as migration classes are available. Classes are available through a per seat, or onsite private class arrangement.
98
Migration to RACF
7.1.6 Product Migrations

IBM can assist in a wide variety of product migrations. IBMs Software Migration Project Office specializes in MVS system software migrations including:

CA-ACF2 to RACF CA-Top Secret to RACF CA-7 and CA-11 to OPC/ESA Control-M and Control-R to OPC/ESA Jobtrac and Runtrac to OPC/ESA Zeke and Zebb to OPC/ESA CA-Scheduler to OPC/ESA CA-Manager to OPC/ESA CA-1 to DFSMSrmm or DFRMM CA-TLMS to DFSMSrmm or DFRMM CA-IDMS to DB2 Family Adabas to DB2 Family CA-DATACOM to DB2 Family TOTAL to DB2 Family Mod204 to DB2 Family VSAM to DB2 Family CA-LIBRARIAN to ISPF/PDF SCLM Panvalet to ISPF/PDF SCLM CA-JARS to dpAM CA-NETMAN to INFO/MGMT
7.1.7 Getting Started

For additional information, or to discuss how IBMs migration service offerings can be tailored to fit your needs, contact your IBM Client Representative.
Chapter 7. IBM Migration Services
99
100
Migration to RACF
Appendix A. Security Policy Considerations

Various aspects of security policies have been addressed throughout this document in the context of specific technical discussions. This section is intended to consistently summarize policy implementation and enforcement in RACF. We will address general policies such as complete RACF control over users and resources, naming conventions and resource ownership; we will also include discussions of effective and efficient security administration policies and RACF resource utilization. We will not address mandatory access control policies in this document because we have not observed implementations of these policies in commercial environments with either RACF or CA-ACF2.
A.1 User Identification

The recommended policy requires that, except for an initial migration, all users must be identified and verified by RACF, in other words, that undefined users are not permitted. RACF principally allows for undefined users for two reasons:

to support an initial migration to a secured environment, and to ensure uninterrupted system availability.
Techniques to prohibit undefined user IDs vary with the processing environments as outlined below.
A.1.1 Batch
SETROPTS BATCHALLRACF is a global RACF option that enforces the requirements for all batch jobs to have a valid RACF user ID, either through coding USER=user ID on the job statement or through propagation (inheritance).
A.1.2 TSO
To prohibit undefined TSO users, all user IDs defined in SYS1.UADS must also be defined to RACF. The recommended implementation is to use RACF TSO segments for all TSO users and to keep only a few emergency user IDs in SYS1.UADS. In any case, procedures must be implemented to ensure that the RACF database and whatever entries remain in SYS1.UADS are synchronized, and that user IDs deleted from RACF are also removed from the SYS1.UADS data set.
A.1.3 STC
Started procedures are considered part of the computing environment that is essential to the availability and functionality of the MVS system. IBM has therefore implemented RACF STC support with focus on availability, i.e., with the goal to allow rather than disrupt the start of procedures. Procedures will start with an undefined user ID under the following conditions:
the SPT user ID (either assigned specifically or through the generic */= entry) is not a RACF-defined user ID, or the user ID is not connected to the group specified in the table.
101
Undefined user IDs for started procedures can be prohibited by coding a generic entry containing a default ID such as */STCDEF/STCGRP and by ensuring that all entries in the table are error-free. Policy enforcement for all environments can be complemented by monitoring SMF audit trails and, if required, by coding a RACINIT exit terminating all requests for establishing a RACF environment for the default user ID.
A.2 Resource Protection

The recommended policy requires default protection; that is, the prohibition of access to unprotected (undefined) resources. The techniques used in RACF to implement such policy varies with the type of resource as described below.
A.2.1 Data Sets

Default protection for data sets can be activated through SETROPTS PROTECTALL(FAIL). When turned on, unprotected data sets can only be accessed by system-level SPECIAL users. WARN mode is available to ease migration.
A.2.2 Transactions and Other Resources

Default protection over general resources can be achieved through a variety of controls:

program logic in resource managers calling RACF. settings in the RACF CDT catch-all profiles with UACC=NONE and restrictive specific access
We recommend catch-all profiles because the logic applied by resource managers may not always be known and changing CDT entries for existing resource classes may not be desirable.
A.3 Authentication
Policy to establish personal accountability must address user behavior as well as strong technical authentication mechanisms. RACF standard user authentication is based on user-selected passwords; another technique supported is RACF passtickets.
A.3.1 Passwords
Two separate issues must be addressed for RACF passwords, the technique through which passwords are secured when stored in the RACF database and password quality controls. The recommended standard for password protection is DES encryption. Starting with RACF release 2.1 this is the default. For earlier releases the RACF exit ICHDEX01 must either be deleted or modified to select DES encryption instead of password hashing. Password quality controls are SETROPTS PASSWORD options, as listed below (together with generally recommended settings):

rule1(length(6,8) alphanum(1,8) - minimum length 6, alphanumeric interval(30) - expiration after 30 days
102
Migration to RACF
history(32) - remember 32 previous passwords revoke(3) - revoke ID after 3 invalid password attempts
A related SETROPTS option is
inactive(30) - revoke user ID after 30 days of inactivity
A.3.2 Passtickets
RACF offers advanced authentication through passtickets, which are generated by specific products supporting this form of user authentication.
A.4 Naming Conventions

Recommended policy is to establish and enforce adequate naming conventions for all subjects and objects. The RACF support of such policy is discussed below.
A.4.1 Data Sets

Native RACF strictly enforces data set high-level-qualifier (HLQ) naming conventions; in a PROTECTALL(FAIL) environment only HLQs that match user IDs or group names can be created or accessed. Naming convention tables and exits can be used to transform other naming conventions to the RACF standard. The enforcement of standards beyond the HLQ is possible but may not always be practical because it limits the use of high-level generic dataset profiles (such as HLQ.**).
A.4.2 Other Resources

The use of catch-all profiles helps enforce naming conventions for general resources; generic profiles, if used, must be designed accordingly.
A.4.3 Users and Groups

Userids and group names are not controlled by RACF in a way that allows enforcement of local naming standards.
A.5 Ownership
Recommended policy is to assign resource ownership to business managers responsible for an application or business area. RACF practice suggests group ownership of profiles and offers an approximation to policy provided the group structure reflects applications and business areas adequately and custodians are properly assigned as group administrators.
A.6 Security Administration

Recommended policy addresses many aspects of the security administration; some can be supported by RACF as discussed below:
103
A.6.1 Structure
Security administration tasks are typically performed within the following structures:

central security administration group administration or functional delegation helpdesk
Mandatory central security administration uses the RACF system-level SPECIAL attribute to define or alter all but a few profiles and options in RACF. To set or change some specific audit-related settings requires the system-level AUDITOR attribute. Optional group administration in RACF is based on group-SPECIAL which provides authority within the scope of a group, a privilege called class authorization (CLAUTH), or both. Most policy requirements for group administration can be met by assigning group-SPECIAL and possibly CLAUTH, and by defining the scope of authority (based on group ownership). Typical helpdesk functions such as user ID RESUME and password RESET can be implemented through group-SPECIAL; however, many organizations have chosen other (limited) solutions through special programs that run authorized and use authorization schemes other than group-SPECIAL.
A.6.2 Effectiveness
Recommended policy requires security administration to be effective, i.e., to minimize potential risks through errors and omissions, particularly in the area of temporary access and authorization. Typical precautions are automatic expiration dates on user IDs and permissions. RACF provides the direct ability to expire user IDs automatically through coding REVOKE(date) in user definitions; for permissions, expiration dates can be established indirectly through group connections.
A.6.3 Efficiency
Recommended policy also requires security administration to be efficient, to ensure that administration workload problems do not contribute to risks. Efficient RACF administration uses two main elements, generic profiles and group authorization on access lists. The use of generic profiles reduces, in comparison with discrete ones, the number of profiles to be defined and maintained. Using groups instead of user IDs on access lists dramatically simplifies the management of a changing user population.
A.7 Audit Considerations

Recommended policy requires a reasonably complete audit trail and firm procedures to monitor and review security events and status information.
A.7.1 Logging
RACF provides an audit trail of security-related events through SMF; the nature and amount of information recorded is controlled by RACF options and profile definitions as discussed below:
SETROPTS SAUDIT, OPERAUDIT CMDVIOL and INITSTATS are the recommended standard settings which include privileged user activities.
104
Migration to RACF
AUDIT(SUCCESS(UPDATE) FAILURE(READ)) is the recommended standard profile option, unless specific reasons exist for different settings. the RACF Global Table should not cover any resources for which an audit trail is needed. UAUDIT should be used rather carefully because, if used generously, it may create a significant amount of noise records.
A.7.2 Event Monitoring

Recommended policy requires regular event monitoring. We recommend as much emphasis on success as on detected violations. Since the RACF Report Writer has been stabilized, compliance with policy may require a different solution, for example, a Roll-Your-Own program or a third-party product.
A.7.3 Status Review

Recommended policy requires periodic security status monitoring and full security audits. The RACF DSMON utility provides basic event monitoring capabilities. For more detailed monitoring or a full analysis third party tools should be considered.
A.8 Resource Utilization

Recommended policy and common sense require that the security monitor s performance impact be minimal.
A.8.1 Performance Options

RACF offers key performance options that should be used in order to comply with policy:

resident blocks in the RACF data set name table - recommended value 255 global table entries for trivial access in class DATASET - recommended entry &RACUID/ALTER
A.8.2 Potential Performance Impact

Performance impacts may be caused by the following RACF practices:

extensive use of discrete profiles in class DATASET poor use of generic profiles, such as a huge number of profiles under one HLQ no global table in large TSO environments.
105
106
Migration to RACF
Appendix B. Sample Migration Plan

A migration plan should include the following items. The durations listed are representative, but may vary widely depending on circumstances. 1. Project Team Education. This depends on availability of classes, of course. Once classes are available, about three weeks are needed for attendance. There is little point in attempting to make a detailed project plan (the next step) until key team members have obtained the necessary education. 2. Detailed Project Planning. This may take up to two weeks. One of the results should be specific team assignments and schedule targets. This activity requires knowledge of the existing security manager, RACF, the routine operational activities of the installation (including help desk functions, auditing, routine user administration, and so forth), and major production jobs. 3. Planning RACF Groups. This can easily take several weeks. It is a combination of analyzing the existing CA-ACF2 UID definitions and masks, and designing the desired RACF structure. This activity is the key to obtaining a RACF structure that is manageable, well designed, and meets your needs. This area is where experience (from other RACF migrations) is most important. 4. Create Test Environment. This activity can parallel some of the other planning activity, and can take several weeks. In general, it means cloning an existing MVS, including all the subsystems, and providing access (for testing) to appropriate production files. 5. Database Conversion. This can take up to a month. It typically involves using a tool to convert CA-ACF2 database entries to appropriate RACF entries. In practice, the conversion may be done many times -- changing the CA-ACF2 input or changing the tools parameters -- until the resulting RACF structure meets your design. This activity is likely to to intermixed with unit testing and integration testing. After testing a number of your production applications, you may decide a slightly different RACF design would be better; you might then change the conversion tools parameters and convert your CA-ACF2 again. 6. Unit Testing. Some effort is needed to (a) test your important applications, and (b) contain the testing effort in a reasonable schedule. Two to four weeks might be a reasonable target. This phase may require considerable assistance from applications owners and production controllers. 7. Function Testing. This is typically two weeks. It involves moving several selected applications/users to the test system for production work, and closely monitoring potential problems. 8. Production Cut-Over. This involves the final conversion of the CA-ACF2 database to RACF. 13 This phase should contain at least three weeks of monitoring and support, to address specific situations that may arise. After this, the migration team could be released.
13
The production CA-ACF2 database has been changing, through normal production activity, during the test phases. You must capture the current, live CA-ACF2 database at this point.
107
108
Migration to RACF
Appendix C. Frequently Asked Questions

Q. When protecting a HLQ for a production application (when there is no user with a corresponding user ID), when should I use a group name for the HLQ and when should I simply create an artificial user ID? Why? A. Defining a group is the normal approach and this is a normal use for group definitions. We recommend using user IDs only for real users. (Some exceptions exist; artificial user IDs might be used for started task control, for example.) There is no strong technical reason for this recommendation; it is simply that using groupids provides a more orderly way to manage access to application data sets.
Q. Can I prevent users from PERMITing access to files they own? How? A. Yes. The most global way to do this is to remove access to the PERMIT command. However, we recommend that you do not do this unless there is a particular, pressing need. Experience has shown little need to hide the PERMIT command.
Q. How can I control the number of PERMITs created by a user? Should I worry about this? A. Again, experience has shown that this is not normally a problem to worry about.
Q. Do I need to reorganize the RACF database? Also the backup database? How often? A. The IRRUT400 utility can be used to reorganize the RACF database. Experience has shown that this does not need to be done frequently. Some installations never reorganize their database. Others do it every month or so. Reorganizing every six months seems to be a medial position. The backup database is subject to the same reorganization process.
Q. Can I make simple backups of the RACF database? (Without the complication of using IDCAMS?) A. IDCAMS is never needed with RACF. You can use the IRRUT200 utility provided with RACF You could use something as simple as IEBGENER, although IEBGENER (or other similar utilities) will not interlock with RACF to provide a self-consistent copy. IRRUT200 provides the proper interlocks (without effectively stopping RACF) so that partly updated profiles will not be copied.
Q. Can I administer RACF from CICS? A. This ability is not part of the basic RACF product. There are third-party tools that provide this ability. Some installations have written their own tools, often based on submitting a jobs from CICS (via an internal reader) that executes the
109
appropriate RACF commands. We do not recommend this approach unless you have the skills to assure the security of design. Note that APPC interfaces can also be used to schedule RACF administrative commands.
Q. What authority does a Help Desk need? A. A help desk, especially one that is related to a specific set of departments, is often given GROUP SPECIAL authority for those departments. This permits the help desk personnel to make almost any RACF adjustments to users who are members of the groups associated with these departments. There is considerable debate over what authority is appropriate for help desk operations. The trend is to give them less absolute authority, and more tools to perform specific functions. This debate is more related to appropriate security policy than to specific RACF functions.
Q. How do I add a segment to an existing user ID? For example, add CICS to a TSO user? A. The ALU command provides this function.
Q. What do I need to do to share my RACF database between multiple MVS systems? A. Nothing; this function is automatic. You need the appropriate shared-DASD hardware, of course. If sysplex functions are available, a higher-performance mode of sharing can be used.
Q. Someone gave me some interesting programs that use the RACF ICHEINTY set of macros. Should I consider using these? A. The ICHEINTY macro is the low-level interface to the RACF database. At this level, RACF does not check updates for consistency. A poorly designed program issuing these macros could destroy your database, or, worse, introduce subtle errors that grow over time. We recommend not using this level of interface unless you really trust the design of the program issuing the commands, or have a very unusual requirement. There are helpful and trustworthy programs that use ICHEINTY, but there is no easy way to determine if your programs are in this trustworthy and useful group.
Q. I want to see my RACF database contents. The TSO commands and ISPF panels only deal with a small number of elements at one time, and I cannot get an overall picture of what is in the database. How can I do this? A. You can use the RACF database unload utility. With it, you can see every profile in the database, in a printable format. For anything larger than a trivial database, this may not be useful for direct human viewing. It can be used as input to other (locally written) programs, or be used to load DB2 or something similar. The RACF SEARCH command can be used to find and display profiles. A number of third-party products are available for displaying the database in many different ways.
110
Migration to RACF
Q. Can I have both CA-ACF2 and RACF systems sharing the same JES2 spool data sets? In the same MAS cluster? A. In general, no; especially if NJE jobs are present. The security tokens they associate with jobs, and store in defined control blocks, appear to be incompatible.
Q. Do I need to train all my users for RACF? A. Probably not, especially if you have a well-designed group structure and well-designed generic profiles. A relatively short note (a few pages) might be used to inform users about any changes in logon processing, and about the PERMIT command. Your help-desk people, and your group administrators may require more education.
Q. I want a cookbook for converting my CA-ACF2 database to RACF. You previously published such a book. Where is it now? A. More experience has shown us that a simple cookbook does not do the job. This is why we are emphasizing the term migration instead of conversion . It is possible to do a cookbook conversion, but this is unlikely to produce a desirable end product. Considerable experience is needed to do a good migration, and it is difficult to develop this experience without going through the migration process many times.
Q. Can I list the passwords of my users? I have SPECIAL authority. A. RACF can store passwords in two forms: encrypted and hashed. The encrypted form is the default. The hashed form can be recovered; IBM does not provide details about how to do this, but there are many informal programs that do it. We strongly recommend using the encrypted form. There is no way to list the original passwords, once they have been encrypted.
Q. After I install RACF, can I run my MVS without it? What if I make a change that locks out users? A. Once installed, you can run without RACF. This is a very special mode, awkward to use, and suitable for only a single user on the system. In effect, MVS issues a console message for every data set allocation, and the MVS operator must reply to each message in order for the user to log on and repair the problem. In addition, the user ID used in this situation must be defined in SYS1.UADS. This is so rarely used that many installations and systems programmers have never experienced the situation.
Appendix C. Frequently Asked Questions
111
112
Migration to RACF
Index Special Characters

/etc/passwd 58 CICS, performance 2 CICSKEY rules 39 Class Descriptor Table 2 CLAUTH privilege 77 Commands 80 Commands, TSO RACF 8 commitment to open systems 57 Conditional access list 24 CONNECT privilege 77 CONSOLE controls 47 CONSULT privilege (display or alter certain fields conversion, detailed 1 CREATE privilege 77
A
access authority 5 access lists 5 access rules 21 ACCOUNT privilege 78 ACEE control block 89 administration, interfaces 75 administrator machine 70 ALWAYS CALL function 22 APPC controls 53 APPC, with RRSF 48 AUDIT privilege 78 audit records, monitoring 75 AUDITOR authority 18 authenticating DCE users 67 authentication 2, 4 AUTHEXIT 27 authority levels 5 authorization checking 9 authorized programs 10 AUTOERAS 27 availability, RACF 83
78
D
data set naming convention table 95 data set profiles 6 data set protection 6, 21 database name table (RACF) 93 database reorganization 85 DB2 protection 42 DCE 68 DCE segment 67 DCE support 2 de-centralized 57 departmental workgroups 57 DES encryption, PassTickets 54 DFSMS functions 34 directory 68 discrete profiles 6 Distributed Computing Environment 67 distributed time service 70 DME 68 documentation, RACF 13 domain 70 DSMON utility 83 DSNR class 43 DTS 70
B
B1 security 55 backup data set 83 backup database 28 base segment 18 batch job submission 31 BLP 36, 37 BLPPGM 27 bypass label processing 36, 37
C
CDS 70 CDT 2, 25, 92, 93 cell 70 cell configuration 70 cell directory service 70 centralized environment 57 CICS 26 CICS application security 41 CICS default user ID 38 CICS resources 39 CICS security 38 CICS signon table DFHSNT 38 CICS users 38
E
effective GID 62 effective UID 62 encryption, NJE passwords 50 enterprise computing 57 erase-on-scratch (EOS) 24
F
FACILITY class 25 field definition record 19 functional groups 15
113
G
GAC (table), use 86 GCICSTRN class 26 GDS 70 general resources 3, 7, 25 generic profiles 6 GID 58 GID (group ID) 62 GID value 62 global directory service 70 global options 3, 27 group-SPECIAL 16 groups 3, 5, 15 groups, functional 15 groups, superior 16 growing importance of UNIX GSO mode 22 GSO options 27 GSO PPGM/LOGOGM 34
IRRUT100 utility 76 IRRUT200 utility 76, 84 IRRUT400 utility 76, 85 ISPF panels, RACF 75
J
JES command control JESINPUT class 33 JESSPOOL class 26 JOBCOPY utility 31 JOIN privilege 77 47
K
Kerberos 57 68
L
LEADER privilege 78 list of groups checking 63 list-of-group checking 18, 43 LOGONID record 19 LOGOPTIONS, usage 82 LOGPGM 28 LPAR 12
H
HLQ 5 home directory 63 HSM archives 37
I
IBM migration services 97 IBMUSER 15 ICHBLP profile 36, 37 ICHCCX00 RACF exit 94 ICHCNX00 RACF exit 94 ICHDEX01 RACF exit 94 ICHEINTY macros 92 ICHEINTY macros, remote 48 ICHNCV00 RACF exit 95 ICHPWX01 RACF exit 94 ICHRCX01 RACF exit 94 ICHRCX02 RACF exit 94 ICHRDSNT (table) 28, 93 ICHRDX01 RACF exit 94 ICHRDX02 RACF exit 94 ICHRIN03 35 ICHRIN03 (table) 29, 93 ICHRIX01 RACF exit 94 ICHRIX02 RACF exit 94 ICHRRCDE (table) 93 ICHRRCDX (table) 93 ICHSFR00 router 92 IMS protection 41 in-storage buffers, RACF 86 integrity, MVS 9 interoperability 67 INTRDR jobs 31 IRRDBU00 utility 76, 83 IRRRID00 utility 76
M
MAC (Mandatory Access Control) migration services 97 MVS console security 47 MVS integrity 9 MVS router (ICHSFR00) 92 55
N
Netview security 53 Network File System support NJE DFTLID 28 NJE INHERIT 28 NJE levels of trust 50 NJE security 50 NOCNCL privilege 22 NODES class 51 NVAS security 53 57
O
open systems brand 58 OpenEdition DCE 67, 70 OPERATIONS attribute 22 OPERATIONS authority 18 OPERATIONS privilege 77 operator command control 47 Operator logon 47 OPERCMDS class 81 OPERCMDS controls 47 OPTS DFTLID 28
114
Migration to RACF
OPTS DFTSTC 28 OPTS MODE 28 OPTS TAPEDSN 28 OPTS UADS 28 OPTS XBM 28 owners 5 ownership 16
P
PADS 24, 34 PassTickets 53 PASSWORD HISTORY 30 PASSWORD INTERVAL 30 PASSWORD REVOKE 30 PASSWORD RULE 30 passwords 3, 20 performance, RACF 86 PPT table entries 10 PPTNOPASS privilege 21 privilege levels 76 PRIVILEGED attribute 35 p r o g r a m 63 PROGRAM class 24, 34 program pathing 24, 34 PROTECTALL 6 PROTECTALL environment 81 PROTECTALL FAIL 21 PROTECTALL FAILURES/WARNING PROTECTALL mode 24 PROTECTALL option 22 protection concepts 2 PSWD 28
reorganization, database 85 RESDIR code 29 RESTRICT privilege 79 RESVOLS 36 REVOKE attribute 20 RJE security 50 RJP protection 52 RPC 68 RRSF (remote sharing) 48 RULE mode 22 RVARY SWITCH command 84
S
SAF description 89 SAF, use 22 scope of group 16 SCOPE record 78 SCOPE records 78 SEARCH command 75 SECLABELS 8 security interoperability 67 SECURITY privilege 78 security server 70 security services 68 security with UNIX files 59 SECVOLS 36 SECVOLS option 23 segments, database 18 server machine 70 SETROPTS 8, 27 SETROPTS BATCHALLRACF 33 SETROPTS CMDVIO 82 SETROPTS JES XBMALLREAF 28 SETROPTS LOGOPTIONS 82 SETROPTS NOADSP 30 SETROPTS PASSWORD 28, 30 SETROPTS PREFIX 30 SETROPTS PROTECTALL 30 SETROPTS RACLIST 29 SETROPTS SAUDIT 82 SETROPTS TAPEDSN 28, 37 shared databases 87 SHIFT record/field 20 single sign-on 67 Single UNIX 57 SMF records 75, 82 SMF type 80 records 48 SPECIAL authority 18 SPECIAL privilege 76 split databases 87 stand-alone and departmental workgroups started procedures table 35 started task control 35 started task table 93 started tasks 3 superior groups 16 superuser 62
30
R
RACF database 3 RACF DCE segment 67 RACF documentation 2 RACF exits 93 RACF list of groups checking 63 RACF report writer 82 RACF-DCE interoperability 67 RACLIST 26 RACLIST, use 86 RACONVERT command 45 RACROUTE AUTH 91 RACROUTE DEFINE 91 RACROUTE EXTRACT 91 RACROUTE interface 89 RACROUTE LIST 91 RACROUTE REQUEST=FASTAUTH option RACROUTE VERIFY 91 READALL privilege 22 recovery, database 4 remote RACF 4 remote RACF control 48 remote sharing facility 48
87
57
Index
115
SUPERZAP p r o g r a m 34 SUPGROUP 16 supplemental groups 63 support for XPG4 base branding surrogate function 33 surrogate, NJE 50 SYS1 group 16 SYS1.UADS 43
X
57 X/Open Company, Ltd. 58 XPG4 Base certification 58
T
tape protection 36 TAPEVOL class 28, 37 templates 8 TERMINAL class 33 TERMINAL security 53 test system 12 threads 68 time services 68 TRUST, NJE levels 50 TRUSTED attribute 35 trusted computing base (TCB) TSO protection 43 TSO segment 44 TSOAUTH 10 TSOTEST 10
10
U
UACC 3, 6 UID 58 UID (user ID) 62 UID value 62 UIDs 19 universal access 6 UNIX base branding 57 UNIX security basics 58 U N I X , U I D = 0 10 USE privilege 77 user ID 4 user IDs 3, 17 user profiles 17 USERDATA field 27 users 15
V
VLF 87 Volume protection 23 VTAM ACB controls 53 VTAMAPPL class 53
W
WARN mode 23
116
Migration to RACF
IBML
Printed in U.S.A.
SG24-4663-00

Racf

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Racf

Hochgeladen von

Copyright:

Verfügbare Formate

International Technical Support Organization Planning for CA-ACF2 Migration to OS/390 Security Server (RACF) May 1996

First Edition (May 1996)

Copyright IBM Corp. 1996

Copyright IBM Corp. 1996

Appendix C. Frequently Asked Questions Index

International Technical Support Organization Publications

International Technical Support Organization Bibliography of Redbooks , GG24-3070

RACF Version 2 Release 2 Technical Presentation Guide (GG24-2539).

TOOLS SENDTO WTSCPOK TOOLS REDBOOKS GET REDBOOKS CATALOG

Copyright IBM Corp. 1996

Chapter 1. Introduction and Overview

1.1 Why RACF

RACF Protection Concepts

Chapter 1. Introduction and Overview

Figure 1. Simplified RACF Database Structure

RACF User: A user is a single logical entity to RACF. A user:

This is an administrative scope, rather than an access scope.

Chapter 1. Introduction and Overview

Data sets General resources

Figure 2. Simplified RACF Authorization Checking. cover the normal cases.

This is not a complete flow of access checking, but it does

Chapter 1. Introduction and Overview

1.3 MVS System Integrity

Chapter 1. Introduction and Overview

Basic TCB Concepts

1.4 Migration Considerations

Chapter 1. Introduction and Overview

Manpower and Timing

1.5 RACF Documentation

As part of migration planning, we also recommend these documents:

Chapter 2. Basic Concepts

2.1 Users and Groups

Copyright IBM Corp. 1996

Figure 3. RACF Base GROUP Structure

CA-ACF2 Group Migration Issues

Chapter 2. Basic Concepts

TSO DFP CICS OMVS OPERPARM WORKATTR LANGUAGE NETVIEW

CA-ACF2 User Migration Issues

Translation of CA-ACF2 UIDS

UID Translation Exceptions

Chapter 2. Basic Concepts

Figure 4. Possible CA-ACF2 Logonid Conversion to GROUP and USERID Structure

Adding Additional Fields in the RACF User Profile

2.2 Data Set Protection

Chapter 2. Basic Concepts

RACF Profiles: Consider the following CA-ACF2 access rule set:

- UID(*) would allow no further access to data sets under SYS2.

Chapter 2. Basic Concepts

must be controlled in class PROGRAM.

2.3 General Resource Protection

Chapter 2. Basic Concepts

General Resource Considerations

We recommend the second solution.

2.4 Global RACF Options

Common System-wide Security Options

ACF2 GSO RECID AUTHEXIT AUTOERAS

Exits found during RACF start are activated.

Chapter 2. Basic Concepts

Table 1 (Page 2 of 2). System-wide Options C o m m o n to RACF and CA-ACF2

ACF2 GSO RECID LOGPGM

NJE INHERIT/ VALIN()/ VALOUT OPTS DFTLID()

OPTS DFTSTC() OPTS MODE()

OPTS TAPEDSN OPTS UADS