SG 245677

BFront
Broadcom Top Secret and

z/OS Security Server
Lydia Parziale
Ted Anderson
Bill Samsoe
Redbooks
IBM Redbooks
CA TopSecret to z/OS Security Server Migration Guide
August 2024
SG24-5677-01
Note: Before using this information and the product it supports, read the information in , “Notices” on
page vii.
Second Edition (August 2024)
This edition applies to SecureWay Security Server Version 2, Release Number 10, Program Number
5645-001 for use with the z/OS Operating System
© Copyright International Business Machines Corporation 2024. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team who wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Stay Connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Chapter 1. The Value of the IBM z/OS Security Server RACF . . . . . . . . . . . . . . . . . . . . . 1

1.1 Overview of the z/OS Security Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Business Benefits of the z/OS Security Server RACF . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Financial benefits of the z/OS Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 RACF added features and functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 RACF administrative enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 RACF/Db2 security administration overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 RACF market penetration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 2. z/OS Security Server RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Resource Access Control Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 The DCE Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 z/OS Firewall Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 The LDAP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Network authentication and privacy service (Kerberos) . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 z/OS Open Cryptographic Services Facility (OCSF). . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Chapter 3. IBM z/OS Security Server RACF overview . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 RACF and its main components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Information and authorization flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Information flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 Authorization Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 RACF terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 RACF user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2 RACF group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3 Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4 RACF protected resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.5 RACF system-wide options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.6 The RACF database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.7 RACF commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.1 Product Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2 The SAF interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.3 RACF exits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Chapter 4. Broadcom Top Secret overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 The Broadcom Top Secret philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 The Broadcom Top Secret environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 The ALL Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
© Copyright IBM Corp. 2024. iii

4.2.3 Resource rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.4 Broadcom Top Secret database files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Broadcom Top Secret subsystem interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chapter 5. RACF project overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1 Preparing for the project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.1 Review the current Broadcom Top Secret environment . . . . . . . . . . . . . . . . . . . . 44
5.1.2 Personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1.3 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Building the project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.1 Example of a project task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.2 Significant project tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Resource scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Chapter 6. Database migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.1 Conversion methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.1.1 Migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 Converting ACIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.1 Broadcom Top Secret user/group migration issues . . . . . . . . . . . . . . . . . . . . . . . 57
6.2.2 Listing the Broadcom Top Secret ACIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.3 Reviewing and defining ACIDs to RACF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.2.4 Converting profile ACIDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2.5 Converting user ACIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.6 Converting security administrator ACIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2.7 Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.8 Other Broadcom Top Secret user ACID parameters . . . . . . . . . . . . . . . . . . . . . . 65
6.3 Converting data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.1 User-based versus resource-based protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3.2 Data set conversion overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.3.3 Defining data set protection in RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.3.4 Data control groups and the RACF high-level qualifier . . . . . . . . . . . . . . . . . . . . . 69
6.3.5 Data set access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.3.6 Undercutting considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3.7 Other Broadcom Top Secret to RACF data set migration Issues . . . . . . . . . . . . . 72
6.3.8 More data set considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.4 Converting resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4.1 FACILITIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4.2 Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.3 The Online Transaction (OTRAN). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.4 Limited Command Facility (LCF) AUTH/EXMP. . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4.5 Db2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4.6 Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4.7 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.4.8 XA ACID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.4.9 User-defined resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.5 Other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.5.1 z/OS UNIX considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.5.2 Started tasks (STC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.6 Converting system-wide options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.6.1 Common system-wide security options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.6.2 The Command Propagation Facility (CPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.6.3 Protection modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
iv CA TopSecret to z/OS Security Server Migration Guide

6.6.4 RACF options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Chapter 7. Administration and maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.1 The administrative interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.2 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.3 RACF utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.4 Security reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.5 Availability considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.5.1 RACF active backup option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.5.2 Reorganizing the RACF database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.6 RACF performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.6.1 Performance Of shared databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.6.2 Migration issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.6.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Appendix A. A Sample migration plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Appendix B. Security policy considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

B.1 User identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.1.1 Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.1.2 TSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.1.3 Started procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
B.2 Resource protection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.3 Data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.3.1 Transactions and other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.4.1 Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.4.2 Passtickets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.5 Naming conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.5.1 Data sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.5.2 Other resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.5.3 Users and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.6 Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.7 Security administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B.7.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B.7.2 Effectiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B.7.3 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B.8 Audit considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
B.8.1 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.8.2 Event monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.8.3 Status review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.9 Resource usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.9.1 Performance options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
B.9.2 Potential performance impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Appendix C. Frequently asked questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Contents v
vi CA TopSecret to z/OS Security Server Migration Guide
Notices
This information was developed for products and services offered in the US. This material might be available
from IBM in other languages. However, you may be required to own a copy of the product or product version in
that language in order to access it.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user’s responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, MD-NC119, Armonk, NY 10504-1785, US
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION “AS IS”

WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer of express or implied warranties in
certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you provide in any way it believes appropriate without
incurring any obligation to you.
The performance data and client examples cited are presented for illustrative purposes only. Actual
performance results may vary depending on specific configurations and operating conditions.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
Statements regarding IBM’s future direction or intent are subject to change or withdrawal without notice, and
represent goals and objectives only.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to actual people or business enterprises is entirely
coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are
provided “AS IS”, without warranty of any kind. IBM shall not be liable for any damages arising out of your use
of the sample programs.
© Copyright IBM Corp. 2024. vii

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation, registered in many jurisdictions worldwide. Other product and service names might be
trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at “Copyright
and trademark information” at https://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks or registered trademarks of International Business Machines Corporation,
and might also be trademarks or registered trademarks in other countries.
CICS® OS/390® VTAM®
Db2® RACF® z/OS®
IBM® Redbooks® z16™
IBM Security® Redbooks (logo) ®
IBM z16™ Tivoli®
The following terms are trademarks of other companies:
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, or service names may be trademarks or service marks of others.
viii CA TopSecret to z/OS Security Server Migration Guide

Preface
Broadcom Top Secret and the IBM® z/OS® Security Server (RACF®) are both Mainframe
Security products. In some areas, their designs are similar, and in other areas the designs are
very different. Planning a migration from Broadcom Top Secret to z/OS Security Server RACF,
without unduly disrupting an z/OS production environment, requires considerable planning
and understanding. With proper planning, and, if needed, specially skilled people to assist in
certain areas, the migration can usually be accomplished in an orderly way.
This IBM Redbooks® publication describes the higher-level issues and differences between
the two products as an important starting point.
The team who wrote this book

This Redbooks publication was produced by a team of specialists from around the world
working at the IBM Redbooks Poughkeepsie Center.
Lydia Parziale is a Project Leader for the IBM Redbooks team in Poughkeepsie, New York,
with domestic and international experience in technology management, including software
development, project leadership, and strategic planning. Her areas of expertise include
business development and database management technologies. Lydia is a PMI-certified PMP
and an IBM Certified IT Specialist with an MBA in Technology Management. She has been
employed by IBM for over 30 years in various technology areas.
Ted Anderson is a Mainframe Specialist in the United States. He has 40 years of experience
in the IT field, 26 years of which are with IBM.
Bill Samsoe is a Mainframe Security Specialist in the United States. He has 40 years of
experience in the IT field.
Thanks to the authors of the previous editions of this book.

򐂰 Authors of the first edition, CA-TopSecret to OS/390® Security Server Migration Guide:
Ted Anderson, Julie Bergh, Paul de Graaff, Peter Desforge, Lynn Kearney, Lori Halberts
Kikuchi, Tony Nix, Mark Shell
Now you can become a published author, too!

Here’s an opportunity to spotlight your skills, grow your career, and become a published
author—all at the same time! Join an IBM Redbooks residency project and help write a book
in your area of expertise, while honing your experience using leading-edge technologies. Your
efforts will help to increase product acceptance and customer satisfaction, as you expand
your network of technical contacts and relationships. Residencies run from two to six weeks
in length, and you can participate either in person or as a remote resident working from your
home base.
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
© Copyright IBM Corp. 2024. ix

Comments Welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about this book or
other IBM Redbooks publications in one of the following ways:
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, IBM Redbooks
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Stay Connected to IBM Redbooks

򐂰 Find us on LinkedIn:
https://www.linkedin.com/groups/2130806
򐂰 Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
weekly newsletter:
https://www.redbooks.ibm.com/subscribe
򐂰 Stay current on recent Redbooks publications with RSS Feeds:
https://www.redbooks.ibm.com/rss.html
x CA TopSecret to z/OS Security Server Migration Guide

1
Chapter 1. The Value of the IBM z/OS

Security Server RACF
This chapter describes the advantages of using the z/OS Security Server RACF versus
competitive security software from Broadcom Top Secret. The value is presented both from a
functional point of view, component by component, to the monetary savings of the z/OS
Security Server.
© Copyright IBM Corp. 2024. 1

1.1 Overview of the z/OS Security Server
In 2001 the IBM corporation offered a newly packaged operating system for mainframes,
named z/OS. IBM z/OS integrates numerous products, which are pretested, integrated, and
packaged together. This integration, performed by IBM, is beneficial to the users of z/OS
because only one product needs to be ordered. There is no need to test numerous separate
products each time an operating system upgrade is performed. Most of the products
packaged in z/OS, such as JES2 and IBM VTAM®, became standard features of z/OS. Other
products, like z/OS Security Server for RACF and DFSMS, became optional features of z/OS.
Both standard and optional features are packaged, tested, and delivered with every license of
z/OS, but to use the optional features you must order the feature codes from IBM and enable
the features on your system.
The design and development of the z/OS Security Server RACF follows a published
architecture that adheres to standards. Resource Access Control Facility (RACF) does not
modify or front-end any modules nor does it dynamically place hooks into product code.
RACF uses the z/OS provided SAF interface. By following standards and by using the SAF
interface, RACF provides reliability and allows for ease of release to release migration. Also,
RACF also provides day-1 support for new system technology and new product releases.
RACF also exploits these new technologies. When IBM moved from MVS to z/OS, there was
a perception in the marketplace that the name of RACF changed to z/OS Security Server
RACF. IBM created a “security umbrella” as a delivery vehicle for IBM z/OS security-oriented
software. RACF is but one of the products in the Security Server. In z/OS Security Server
RACF, there are six products:
1. DCE Security Server
2. Lightweight Directory Access Protocol (LDAP) Server
3. z/OS Firewall Technologies
4. Network Authentication Service for z/OS
5. Enterprise Identity Mapping (EIM)
6. PKI Services
IBM has positioned the z/OS Security Server RACF as the security product that delivers the
support and exploitation of new technology inside the glass house and in the e-business
arena.
1.1.1 Business Benefits of the z/OS Security Server RACF

The job of a security product is to protect your information and allow your business to move
ahead with new ventures and technologies. RACF could be considered the leader in this
area. RACF integrates upon availability of new versions and releases of IBM subsystems
such as CICS® and Db2® and technologies such as Sysplex Coupling Facility. This allows
your business to move ahead with its objectives and applications as quickly as you choose.
With the LDAP Protocol Server, IBM continues this tradition outside of the glass house. The
z/OS Security Server RACF delivered the LDAP Server as one of its products before many
companies even knew about the new Lightweight Directory Access Protocol. Now those
same companies are ready to provide applications and directories that use the LDAP Server
on z/OS. The companies can provide the applicatins with the confidence of knowing that the
server was delivered as part of the z/OS Security Server RACF.
2 CA TopSecret to z/OS Security Server Migration Guide

Now, any authorized LDAP client throughout the enterprise can search, extract, add, and
delete information from any z/OS LDAP server. For more information, see z/OS Security
Server RACF Security Administrator’s Guide. For more LDAP Information, see 2.4, “The
LDAP server” on page 15.
The Firewall Technology product of the z/OS Security Server delivers a set of features that
can be used alone or with the Firewall Technologies that are provided in the z/OS
Communications Server, a standard part of the z/OS Operating System. When used together,
you have a full function z/OS Firewall ready to use. The Virtual Private Network (IPsec)
support of the z/OS Firewall is one of the areas where it excels.
The RACF product of z/OS Security Server 1.4 first introduced support for Digital Certificates
and Public Key Infrastructure (PKI), z/OS Security Server RACF 1.8 greatly enhanced that
support. Again, RACF has technology available to you for you to move into the world of
e-business. The following is a high-level list of the supported technology features:
򐂰 Digital Certificate Authentication providing integration between PKI Technology and
traditional RACF Authentication.
򐂰 Certificate mapped to RACF user ID to provide seamless access to z/OS resources.
򐂰 User self-registration of digital certificates.
򐂰 Processing of certificate revocation lists by the IBM HTTP Server for z/OS.
򐂰 RACF can generate digital certificates.
1.1.2 Financial benefits of the z/OS Security Server

There are many scenarios where the value of the z/OS Security Server RACF is evident, not
the least of which is the scenario of upgrading CPUs. IBM's pricing policies are flexible yet
predictable. There are no surprises regarding software upgrade charges.
Identifying productivity savings

The z/OS Security Server RACF is an optional feature of the z/OS operating system. The
benefit of being a feature of z/OS is that the Security Server is integrated and pretested with
the z/OS operating system. This can reduce the amount of testing that is devoted to your
security package. Less testing can help create a substantial time savings each time a new
release of the operating system or non-RACF mainframe security product is installed. The
savings to your systems programming organization might be realized multiple times per year.
1.2 RACF added features and functions

This section highlights added features and functions to z/OS Security Server RACF and some
of the recent administration enhancements that are made to RACF.
The following list describes some of the new RACF features:

򐂰 RACF Database Encryption
Continuing the pervasive encryption readmit, RACF now supports RACF database
encryption. This function allows an installation to encrypt a VSAM data set that is used as
a part of a RACF data base and share that data set among z/OS systems in certain
configurations to help further strengthen the overall security posture of the z/OS platform.
򐂰 Compliance support for z/OS
Chapter 1. The Value of the IBM z/OS Security Server RACF 3

z/OS is enhanced to modernize compliance data reporting, which enables the collection of
compliance data from numerous IBM z16™ and z/OS products and components. z/OS
has also simplified auditing by contributing IBM z/OS V2R5 with RACF Benchmark v1.0.0,
which provides security best practices and guidance to clients and auditors.
򐂰 RACF for z/OS
Achieved Common Criteria certification at Evaluation Assurance Level 4 (EAL4+) under
the Common Criteria Evaluation and Certification Scheme. This certification along with
RACF, TCP/IP, UNIX System Services, and Db2 provides customers with a Multilevel
security (MLS) solution.
򐂰 Support for RACF password phrases by TSO/E logon, z/OS UNIX functions, OpenSSH,
and the IBM Tivoli® Directory Server.
򐂰 The RACF CFIELD class
This can be used to create customer-defined fields for user, group, dataset and general
resource profiles, and the labels you want to use for them.
RACF supports the use of passwords longer than eight characters, often called pass phrases.
A pass phrase is a character string that can comprise mixed-case letters, numbers, and
special characters including blanks, from 14 to 100 characters in length. Pass phrases allow
for an exponentially greater number of possible combinations of characters and numbers than
do passwords.
1.2.1 RACF administrative enhancements

Historically, RACF has brought out day-one support and exploitation of new software and
hardware technologies. This is beneficial to corporations that like to be on the leading edge
with new technology. For example, many customers with RACF use the Coupling Facility.
The Remote Sharing Facility (RRSF) of RACF is an integrated feature of the RACF product,
so you can administer and synchronize multiple RACF databases. RRSF is granular so that
you can make the choices that fit your business. For example, some or all commands and
passwords can be synchronized automatically, or they can be targeted to one or more of the
databases being managed. IBM provides this integrated feature with the utmost of integrity by
encrypting the transmission of data and by providing automatic recovery if the transmission is
interrupted.

Node A Session Node B
Password
Password RACROUTE changes
changes
RACDEF ADDGROUP
ADDGROUP
RACXTRT ADDSD
ADDSD
RACF ICHEINTY
RACF ADDUSER
ADDUSER
add
ALTDSD database alter
delete
database ALTDSD
etc. rename etc.
Figure 1-1 RRSF overview
RACF has a number or logging and reporting options that allow a Resource Owner to identify
users who attempt to access the resource. In addition, you and your Auditor can use these
functions to log all detected successful and unsuccessful attempts to access the RACF DB
and any RACF protected resources. Logging all access attempts to detect possible security
exposures or threats.
RACF includes the following logging and reporting options:

򐂰 Logging. RACF writes records to the System Management Facility (SMF) for detected
unauthorized attempts to enter the system.
򐂰 Access RACF Protected Resources Introduction.
򐂰 Issue RACF commands.
򐂰 Modify profiles on the RACF Database. RACF writes these records to an SMF Data Set.
To list SMF records, you can use either the RACF SMF Data Unload Utility (IRRADU00) or
the RACF Report Writer.
򐂰 With the SMF data unload utility, you can convert the RACF SMF records into a format that
you can browse or upload to a database, query, or reporting package, such as Db2 z/OS.
򐂰 With the Report Writer, you can select RACF SMF records to produce the reports.
Because the RACF report writer was stabilized at the RACF 1.9.2 level, it cannot produce
reports for all records beyond that release. The RACF Report Writer provides a wide range
of reports so that you can monitor and verify the use of the system and resources.
򐂰 The RACFICE reporting tool allows an installation to create tailored RACF reports without
requiring a relational database management product, and provides an alternative to the
RACF report writer. It uses the DFSORT ICETOOL reporting facility. RACF makes several
ICETOOL-based reports available in SYS1.SAMPLIB. The RACFJCL member of
SYS1.SAMPLIB provides sample JCL to allocate a report data set and add the RACFICE
reports in IEBUPDTE format.
򐂰 The Data Security Monitor produces reports on the status of the security environment at
your installation and in particular, on the status of resources that RACF controls. You can
use the reports to audit the status of your installation's system security environment by

comparing the actual system characteristics and resource-protection levels with the
intended characteristics and levels.
Both the Report Writer and DSMON are still supported and shipped with z/OS Security
Server RACF. IBM met customer requirements by adding the following two additional
reporting options:
1. The RACF Database Unload feature
2. The SMF Unload feature
By using these features, you can unload the RACF database and the violation records from
SMF into flat files. IBM includes a comprehensive set of Db2-based reporting queries to meet
your needs. Also, you can use any SQL-based language or product to create reports from the
flat files. This method of reporting allows you to combine data stores to create more
informative trend analysis reports on a user, system, or across platforms.
The RACF product that is delivered with version 2.8 of z/OS Security Server includes an
administrative enhancement for reporting, called RACFICE, which was formerly only available
through the web. This feature includes numerous sample reports, and it uses the DFDSS
ICETOOL report generator. This can be beneficial to organizations that do not have Db2.
They can use the database and SMF Unload utilities without the need to write their own
queries. Additional reporting options can be found in the IBM product Performance Reporter
for z/OS. Performance Reporter includes several predefined reports for RACF in its extensive
list of performance-related reports.
The RACF Remove ID utility can help increase the productivity of security administrators. The
administrator can use the utility to search for an occurrence of a user ID or group. The results
of the returned search are a set of RACF commands to delete the user ID or group and its
related access permissions. The administrator can mark the ones to delete, as it might not be
appropriate to delete all occurrences. The administrator can submit the results to delete the
user IDs or groups.
1.2.2 RACF/Db2 security administration overview

z/OS Security Server RACF 2.4 introduced the RACF/Db2 Administration Feature with Db2
Version 5. This feature allows security administrators to manage Db2 security administration
by using RACF. The RACF/Db2 external security module is included with the z/OS Security
Server.
The base support of both RACF and Broadcom Top Secret includes Identification,
Authentication, and the use of Secondary Authorization IDs. This is not the issue. The
comparison is between the RACF/Db2 external security module and the Broadcom Top
Secret Db2 add-on product. By using either the Broadcom add-on products or the RACF/Db2
feature, you can realize the benefits of moving your Db2 security administration function out
of Db2 and into your z/OS security product. Db2 is an outstanding database product. By
including the Db2 add-on for Broadcom Top Secret, you can configure a robust level of
security administration that most organizations prefer. Figure 1-2 on page 7 shows an
overview of Db2 external (RACF) Security.

DSNX@XAC
DB2 Security RACF In-Storage
Profiles in
dataspaces
DSNDXAPL
FASTAUTH
DB2 Catalogs RACF Database
19 New Classes
SYSIBM.SYSTABLES e.g. DSNADM, MDSNTB, etc
SYSIBM.SYSDATABASE etc. e.g. DSNADM1, MDSNTB1, etc
Figure 1-2 Db2 external security (RACF) overview
Benefits of using RACF to administer your Db2 security

The following benefits are gained when you use RACF for Db2 security:
򐂰 Separation of duties
򐂰 Single point of control for Administration and Auditing
򐂰 Ability to define security rules before a Db2 object is created
򐂰 Ability to allow security rules to persist when a Db2 object is dropped
򐂰 Ability to protect multiple Db2 objects with one security rule
򐂰 Eliminate the need to create multiple, and sometimes duplicate, security rules
򐂰 Ability to use RACF Generic Profiles and Member/Grouping Profiles
򐂰 Eliminate Db2 cascading revoke
򐂰 Flexibility for multiple Db2 subsystems:
– One set of RACF Classes for multiple Db2 Subsystems, or
– One set of RACF Classes for each Db2 Subsystem
Migration issues: Protection of Db2 resources via RACF

For organizations currently using the Broadcom Top Secret/Db2 product, the IBM SMPO
Security Team’s migration tools have built-in functions. The built-in functions can convert your
Db2 add-on product data into the appropriate RACF commands to provide you with
equivalent function through the RACF/Db2 external security model.
For organizations currently using internal Db2 security administration, you can use RACF to
phase in the RACF/Db2 function while you move from internal to external Db2 security
administration. After you begin protecting Db2 Resources by using the RACF external
security module, the RACF/Db2 external security module examines the RACF profiles first. If
there is not a RACF Profile to protect the Db2 Object, then the RACF/Db2 external security

module passes control to Db2’s internal security authorization catalogs. This allows you to
move to external security in a manner best suited for your organization.
Product benefits
Because the administrative function is included in RACF, no additional maintenance is
reqiured. The Broadcom Top Secret solution is delivered in a separate product, so there is an
additional product to maintain, upgrade, and test.
The external security module is included in the SAMPLIB member IRR@XACS. It is coded
and fully supported by the IBM RACF development team. This means that you can call the
IBM support center for assistance if you have any problems with this code, and they can
accept APARs if it is determined that a problem does exist.
The external security module is installed in Db2 at the Access Control Authorization Exit
point. This allows RACF and Db2 to use the standard SAF interface, which eliminates the
need to install or modify any Db2 product code. IBM’s implementation of the external security
module provides any vendor the ability to perform Db2 security administration within its
product by using the industry standard SAF interface without the requirement of modifying or
overlaying Db2 code.
The IBM RACF development team works in concert with the Db2 development team to make
sure that this module works and that it continues to work as each product comes out with new
releases and versions. As a user of this function, you can feel confident that you have day-one
support of new releases and versions.
Financial benefits
The RACF/Db2 external security module code is included with RACF for use with Db2 V5 and
higher at no additional cost. The competitive product, Broadcom Top Secret Option for Db2, is
sold as a separate product.
Identifying financial savings based on product price

If you have purchased this add-on product from Broadcom, then you might see an annual
savings equal to your current maintenance charges.
If you are trying to cost justify the migration to RACF and currently have funds for the
Broadcom Db2 add-on product allocated in your budget, then you can release all OTC funds
and the annual maintenance fee. Usually, the amount of money that is saved can be used to
cover the migration charges for the SMPO’s Security Migration Team to advise and assist you
with your migration.
Broadcom products can be subject to upgrade charges when your CPU is upgraded or a new
CPU is purchased.
Broadcom purchased Platinum, the company that released the RC Secure product. If you use
RC Secure, then you might also be able to discontinue that product when you implement the
RACF/Db2 function. When your contract has ended for RC Secure, you can also realize those
savings.
Identifying productivity savings

The maintenance effort for RACF is easy to identify and quantify. It should take your systems
programmer less than an hour to initially install the RACF/Db2 external security module.
If you use Broadcom Top Secret for Db2 add-on product, then you can quantify the benefits of
migrating to RACF by determining the number of hours the systems programming staff
expends installing and maintaining this product annually. Subtract one hour per year from that

number to determine the annual savings in hours that your organization should realize after
migrating to RACF.
1.3 RACF market penetration

RACF has been securing data in the z/OS environment for 45 years. Many companies chose
their security products in the early 1980’s. The main choices then, as now, are RACF from
IBM and Broadcom’s ACF2 and Top Secret. At that time, Computer Associates owned these
products until it was acquired by Broadcom. Most organizations chose Broadcom’s ACF2 or
Top Secret over RACF because RACF was not a robust product then.
Since the early to mid nineties, organizations began taking a second look at RACF. Often the
initial reason to consider migrating was, and still is, a dissatisfaction with their current vendor.
When these organizations researched the implications of migrating to RACF, they also
realized that RACF had become a robust product. It became clear that IBM committed itself to
making RACF the best security product on the z/OS operating system.
In 1986 RACF had roughly a 28% market share in the United States. This is based on the
number of RACF licenses that are billed in z/OS environments. RACF was the number three
product behind Broadcom ACF2 and Broadcom Top Secret.
In 1993 the penetration grew to approximately 38%, and by 1998 the penetration was 70%.
The rise in market share in the United States had finally caught up with the rest of the world,
and as of 2023 the penetration rates are based on the worldwide penetration of RACF on
z/OS systems.
At the end of 1999, the RACF penetration rate had exceeded 100%. Some machines have
more than one security product running in separate LPARs. Therefore, the marketplace
actually exceeds 100%. We estimate that there is possibly a 110% penetrated market,
meaning that RACF is licensed on over 70% of z/OS licenses. The remaining approximately
40% of the market is shared between Broadcom Top Secret and Broadcom ACF2.
There might be some confusion from clients when they hear that RACF is the best security
product for z/OS. The reason for this confusion lies with understanding the basis for the
penetration rates that are quoted by various vendors. Be sure to ask other vendors how many
operating systems and how many products are included in their penetration number. The
penetration rate that is used by IBM includes only actual revenue-producing licenses running
only on the z/OS operating systems.

2
Chapter 2. z/OS Security Server RACF

IBM z/OS Security Server RACF software is an optional feature of z/OS. You can use z/OS
Security Server RACF to control access to protected resources and provide integrated
directory, connectivity, and security between users and applications for e-business in a
networked environment. Every e-commerce application requires the ability to locate
resources, such as people, information, and applications in the network; connect customers,
partners, and employees to those resources across multiple systems; and address the
concern about how to secure communications, data, and transactions. z/OS Security Server
integrates these infrastructure requirements to provide the Secure Network Platform needed
for e-business. IBM Security® Server software is supported on multiple platforms, including
z/OS.
This chapter provides a high-level overview of the z/OS Security Server RACF and the
security enhancements of the IBM Communication Server for z/OS.

2.1 Resource Access Control Facility
Advances in the use of, and general familiarity with, small computers and data processing
increase the need for data security. IBM incorporates the z/OS Security Server RACF, which
provides a platform that gives you solid security for your entire enterprise, including support
for the latest technologies. As a feature of z/OS, the z/OS Security Server comes with the
major components that are described in the following sections.
The primary component of the z/OS Security Server is the Resource Access Control Facility
(RACF). RACF works closely with z/OS to protect its vital resources. The z/OS Security
Server is built from a strong security base that is provided by the RACF component. The z/OS
Security Server RACF can incorporate other components that aid in securing your system as
you make your business data and applications accessible from your intranet, extranets, or the
internet.
By using an entity known as the RACF user ID, RACF can identify users requesting access to
the system. The RACF user password or valid substitute, such as RACF PassTickets or
Digital certificate, authenticates the RACF user ID. RACF supports the use of PassTickets as
other products use this to present a single sign-on environment to users at their workstations.
After a user is authenticated, RACF and the resource managers control the interaction
between that user and the objects they try to access. Figure 2-1 shows an overview of RACF
and its functions.
U ser identification,
and authentication
RA C F R esource authorization
checking and system
RAC F access control
Security adm inistration

(local or rem ote)
R AC F database Security console

Prim ary and backup Violation reporting
Audit reports
Local and rem ote sharing
integrity reports
Figure 2-1 RACF overview
Digital certificates can be mapped to the RACF user ID to provide seamless access to z/OS
resources, as shown in Figure 2-2 on page 13.

Web z/OS
Security
l
IBM
wal
Browser
HTTP Server Server
Fire
e
at
for z/OS
fic
z/OS
rti
Ce
Web Pages Business data

Figure 2-2 Seamless access to z/OS resources using digital certificates
You can enable users to self-register their digital certificates (Figure 2-3) to ease the
administration of digital certificates.
SSL V3 z/OS WEBSERVER
Webpage calls
RACF the initACEE
USERID/PASSWORD callable service to
register certificate
RACF
Database
Figure 2-3 Overview of the self-registration process
Certificate name filtering support was added to associate many certificates to a single,
shared RACF user ID without installing each certificate into the RACF database. Certificate
filters substantially decrease the amount of database storage and the system administration
requirements that are associated with processing numerous certificates.
Chapter 2. z/OS Security Server RACF 13

With network authentication and privacy services support, certificate filters allow privacy
services principal and realm information to be stored and administered in a RACF database
for a Kerberos environment.
RACF program control enhancements were created to provide better security and integrity of
z/OS UNIX server and daemon programs. This is accomplished by providing more control
over the execution environment and preventing uncontrolled programs from entering a
controlled environment. Environment control is accomplished through a service, IRRENS00,
which marks an environment as either controlled (clean) or uncontrolled (dirty).
Application identity mapping provides an improved method for associating identities that are
defined by z/OS UNIX for z/OS.
2.2 The DCE Security Server

The DCE Security Server provides user and server authentication for applications by using
the client/server communications technology that is contained in the distributed computing
environment for z/OS. The DCE Security Server can also interoperate with users and servers
that use the Kerberos technology developed at the Massachusetts Institute of Technology and
can provide authentication based on Kerberos tickets.
Through integration with RACF and with z/OS DCE support, RACF-authenticated z/OS users
can access DCE-based resources and application servers without having to further
authenticate themselves to DCE. Also, DCE application servers can, if needed, convert a
DCE-authenticated user identity into a RACF identity and then access z/OS resources on
behalf of that user with full RACF access control. Figure 2-4 shows an overview of the DCE
and RACF interoperation.
DCE security server

z/OS environment
Registry server
Kerberos AS
Kerberos TGS Registry user ID RACF RACF
Database cross-linking Database
DCE PS
RPC
MVS
subsystems
Logon Appl
RPC RPC DCE
end user
End user using
Ticket Cache CICS, IMS, TSO....
Figure 2-4 DCE-RACF interoperation

2.3 z/OS Firewall Technologies
Implemented partly in the z/OS Security Server and partly in the IBM z/OS Communications
Server, z/OS Firewall Technologies, the network security firewall program for z/OS, provides
basic firewall capabilities on the z/OS platform to reduce or eliminate the need for non-z/OS
platform firewalls in many customer installations.
The z/OS Communications Server provides the firewall functions of Internet Protocol (IP)
Packet Filtering, IP Security with Virtual Private Networks (VPNs) or tunnels, and Network
Address Translation (NAT).
The z/OS Security Server provides the firewall functions of FTP proxy support, socks daemon
support, logging, configuration, and administration.
z/OS Firewall Technologies supports on-demand dynamic VPNs. On-demand VPNs allow an
automatic configuration of an outbound Security Association (SA) when the designated
network traffic requires that it be transmitted securely through a VPN. Figure 2-5 shows the
potential usage of VPN technology.
R e m o te
A ccess
B u s in e ss
P a rtn e r/
S u p p lie r
In tra n e t
In te rn e t
B ran ch
O ffic e
C o rp o ra te In tra n e t
In tra n e t
Figure 2-5 Usage of VPN technology
2.4 The LDAP server

The Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry
standard application protocol for accessing and maintaining distributed directory information
services over an IP network. It is used to provide a central place to store usernames and
passwords, allowing applications and services to connect to the LDAP server to validate
users.

Figure 2-6 LDAP process explained
RACF data presents a large set of user, group, and profile information that is useful to
applications in other environments or on other systems. By using a z/OS LDAP server, this
item makes RACF information that is accessible through System Authorization Facility (SAF)
interfaces available to programs on and off the z/OS platform. Figure 2-7 shows an overview
of the z/OS LDAP server and the back-end systems that it supports.
RACF interfaces with the z/OS LDAP server by defining proxy information about the z/OS
LDAP server so that other products can communicate with an LDAP directory. It uses a proxy
segment within the profile for the LDAPBIND class for communication. You can also set up an
LDAP Event Notification for changes to RACF users, groups, and general resources.
Alternatively, user ID and password authentication of LDAP Client Access to the z/OS LDAP
Directory Server can be handled by z/OS Security Server RACF rather than by accessing
user IDs and passwords that are stored within the LDAP server directory.
z/O S Im age
slapd.conf schem a
LD AP P ro tocol H and ler

(S erver)
U nix C allab le
S ervice
D B 2 D atabase R A C F D atabase
Figure 2-7 Overview of the z/OS LDAP server and supported back-end systems

2.5 Network authentication and privacy service (Kerberos)
Kerberos is a computer-network authentication protocol that works on the basis of tickets so
that nodes communicating over a non-secure network can prove their identity to one another
in a secure manner. It is designed primarily as a client/server model, and it provides mutual
authentication. Both the user and the server verify each other's identity. Kerberos protocol
messages are protected against eavesdropping and replay attacks.
Kerberos was developed at the Massachusetts Institute of Technology in 1988 to protect

network services. The Kerberos Security Technology does not require passwords to flow in
readable text because it uses encrypted tickets that contain authentication information for the
users. It has been part of RACF for over 30 years and was used on the IBM OS/390.
Encrypted passtickets are issued by a Kerberos authentication server. Users and servers
must have keys registered with the server, and the passtickets flow to and from the servers
covered by a session key. Kerberos application servers can use SAF callable services to
parse Kerberos tickets to map the passtickets to RACF users. RACF can authenticate the
user to determine whether they can access the system.
The Network Authentication Server provides the basis of consistent user identification and
authentication in a heterogeneous networked environment when combined with
Kerberos-aware applications that can span z/OS and other platforms that support the
Kerberos reference implementation.
The security client locates the z/OS Security Server through one of three methods:
1. By using LDAP, when the LDAP server is specified in the Kerberos configuration files
2. By using the Domain Name Service (DNS), when DNS lookup is specified in the Kerberos
configuration files
3. By using static information technology that is contained in the Kerberos configuration files,
when the LDAP or the DNS server is not available or the target realm is not defined in the
directory.
Figure 2-8 on page 18 shows a Kerberos implementation on z/OS.
Figure 2-8 on page 18 shows an overview of the various Kerberos pieces:

1. Kerberos registry integrated into the RACF registry.
2. Kerberos Key Distribution Center (KDC) runs within the z/OS address space.
3. z/OS KDC behaves like any other Kerberos realm.
4. Kerberos realm-to-reaIm function supported.

K erb eros on z/O S
(in tergrated w ith R A C F via S A F )
S tandards
R F C 1 510 => K e rbe ros V 5
R F C 19 64 => G S S -A P I
K ey RACF
D istribution K erb eros
C enter R eg istry
(A S )
A dd ress S p ace A uthenticates U sers
G ra nts TG T s
A uthentication
S erve r
(T G S )
G enerates S essio n K eys
G ran ts service tickets based
on T G T
T icke t G ra ntin g
S e rve r
IB M z/16 w ith z/O S
Figure 2-8 Kerberos implementation on z/OS
2.6 z/OS Open Cryptographic Services Facility (OCSF)

Cryptography comprehensively helps meet multiple security needs, such as confidentiality,
authentication, and non-repudiation. Open Cryptographic Service Facility (OCSF) for z/OS
addresses these requirements in the emerging internet, intranet, and extranet application
domains. The primary application interface to this function is provided by Open Cryptographic
Enhanced Plug-ins (OCEP), a component of z/OS Security Server.
OCEP functions are used by applications that comply with Common Data Security
Architecture (CDSA) standard interfaces. This makes it easier for application developers and
independent software vendors (ISVs) to develop and port applications to the z/OS platform. It
also helps customers apply consistent security rules to applications that use digital
certificates. Figure 2-9 on page 19 shows an overview of the OCSF and OCEP.

A p p lic a tio n D o m a in s A p p lic a tio n s
S e c u rity M id d le w a re SSL F ire w a ll
O C S F S e c u rity A P I
O C S F F ra m e w o rk CSP TP CL DL
M anager M anager M anager M anager
SPI TPI CLI D LI
CSP TP CL DL
S e rv ic e P ro v id e rs
P ro vid e rs P ro vid e rs P ro vid e rs P ro vid e rs
O C E P Tru s t O COEP C EDPa ta

P o lic y RACF LDibara
taryL ib ra ry
Figure 2-9 OCSF-OCEP infrastructure overview
The optional PCI Cryptographic Coprocessor (PCICC) brings additional cryptographic

processing capacity and function to z/OS Parallel Enterprise Servers. The PCICC feature is
integrated into z/OS and does not require an external box.
PCICC works with the CMOS cryptographic coprocessor that is standard on those servers.
PCICC is not a substitute for CMOS cryptographic coprocessors and in fact requires that the
CMOS cryptographic coprocessors be enabled. Without affecting applications, IBM z/OS
routes requests to the appropriate crypto engines for processing.
The z/OS Security Server provides all the requirements for security on z/OS. With its
integration of RACF and DCE Security, its contribution to the z/OS Firewall Technologies, the
LDAP server, and RACF support for client authentication by using digital certificates, the z/OS
Security Server RACF provides complete security both for traditional host-based data
processing and for safely expanding your enterprise onto the internet.

3
Chapter 3. IBM z/OS Security Server RACF

overview
The z/OS Security Server RACF, also known as Resource Access Control Facility (RACF), is
an IBM program product that is designed to provide z/OS and VM users with an effective tool
for managing access control, an increasingly important user responsibility and concern.
The objective of RACF access control is to protect data sets and other data processing
resources from unauthorized destruction, modification, or disclosure, whether by accident or
design. To be effective, security procedures should be easy to use and place no additional
burden upon data processing management. RACF controls users and protects resources.
Users are identified by a user ID and authenticated by a password. A RACF user is identified
by an alphanumeric user ID. However, a RACF user does not have to be an individual. For
instance, a user ID can be associated with a started task address space or a batch job.
Resources can be divided into two categories, data sets and general resources.
The general resources category includes the following resources:

򐂰 CICS resources
򐂰 DASD
򐂰 Db2
򐂰 IMS resources
򐂰 JES resources
򐂰 NODES
򐂰 Programs
򐂰 Tape
򐂰 Terminals
򐂰 VM
There are many other resources that can be protected. For a full list of Resource Types or
Resource Classes, see Security Server RACF System Programmer's Guide, SA23-2287.

3.1 RACF and its main components
RACF is started during a system initial program load (IPL). There is no specific command to
start or stop RACF.
At IPL, RACF requires the RACF primary data set names (DSN) that contain the user and
resource definitions.
One way to satisfy this requirement is to place these names in PARMLIB. To activate the
RACF subsystem, update the IEFSSNxx member of SYS1.PARMLIB, assign a RACF user ID
to the RACF subsystem, and review the RACF PROC in SYS1.PROCLIB. The RACF
subsystem must have a valid user ID. The RACF subsystem cannot be initialized if a valid
user ID is not assigned to it. The PROC name for the RACF subsystem must be the same as
the name in IEFSSNxx. When you use PARMLIB to supply the data set names and other
options, IEASYSxx needs a line with RACF=xx. Then the member IRRPRMxx supplies the
information.
Another way is to update a DD statement (SYSRACF) in the member MSTRJCL.
If MSTRJCL does not contain a proper DD statement, the final way to satisfy the
requirement is that the operator is prompted for the name of the RACF database.
Consider the following points when selecting one of the three methods:
1. RACF at startup
Requires the names of the DSN containing user and resource definitions, these names
can be located in PARMLIB
2. MSTRJCL
You can define only one RACF database (the primary database). No secondary RACF
database definition is allowed.
3. Operator reply
Suitable for early tests, a conversion is an iterative process. Replying with the RACF
database name at IPL time might provide flexibility to back out to a previous iteration
stage if errors are encountered and the current IPL is in error.

3.2 Information and authorization flows
This section includes a description of information and automation flows.
3.2.1 Information flow

For all resources, security is processed through the system as shown in Figure 3-1. In this
process, the components that are involved are listed in the left part of the figure:
򐂰 Application or Subsystem (such as JES) or an application
򐂰 z/OS, which includes System Authorization Facility (SAF)
򐂰 RACF
򐂰 Files, which includes the RACF database
The role of each component in the security process is discussed in other topics. The
information that is passed is discussed in the following sections.
Figure 3-1 Information flow for RACF
The application directs a request to RACF. Depending on the type of request, information is
passed along with the request, as shown in Example 3-1 and Example 3-2.
Example 3-1 Request to verify user identity

Request to RACF : Verify user identity
Information passed : USERID and PASSWORD
Example 3-2 Determine user access

Request to RACF : Check user access to a resource
Information passed : USERID, Resource name, resurce type, and user intent
The security interface formats the information that is gathered by the application to be used
by the security monitor RACF and passes it to the System Authorization Facility (SAF).
SAF determines what actions are required to process the request and can forward the
request to RACF if needed. If requested, RACF then performs the check by verification
against data that is retrieved from the RACF Database. Although Figure 3-1 might indicate
Chapter 3. IBM z/OS Security Server RACF overview 23

that an input operation is performed, RACF data is often retrieved from areas in storage and
no input operation takes place.
RACF always returns a return code as a response to a request. A reason code might also be
returned. For list-type requests, RACF also returns the requested data.
A return code of 0 indicates a valid request. A non-zero return code of 4 might be acceptable,
depending on the resource manager giving the message. A return code of 8 indicates an
error. These return codes are passed to the resource manager that issued the request. It is
up to the resource manager to take appropriate action.
Each component has a logical function:

򐂰 Interface Role
– Receive and format information from the application
– Route information to the SAF facility
– Receive a return code from RACF and return it to the caller
򐂰 SAF Role
– Route the request to the security monitor
– Route the response to the proper requester
򐂰 RACF Role
– Send back a return code and reason code as a response to a security request
– Add, modify, or delete profiles in the database as required by RACF commands that
are run by an authorized user
– Set global option values as directed by authorized users
– Return requested information from the database in response to a list-type command
3.2.2 Authorization Flow

For all resources, security authorization is processed through the system as summarized in
Figure 3-2 on page 25. For more information on authorization flow, see z/OS Security Server
(RACF) Security Administrator’s Guide, SA23-2289.

Figure 3-2 Authorization flow for RACF
3.3 RACF terms

This section defines terms that are used in RACF.
3.3.1 RACF user

A RACF user is always defined as a member of a RACF group. This group is called its default
group. An entry in the RACF database that describes a user is called a user profile.

A user profile describes the user by user ID, password, default group, the times that user can
use the computing system, and statistics on a prior logon by the user. It also describes other
groups that the user might belong to. A user must be a member of at least one group, the
default group, and potentially a member of other groups, which are called connect groups.
User profiles might also contain user attributes. These attributes describe the privileges and
restrictions that the user has. Attributes are classified as either user-level or group-level
attributes. When attributes are assigned at the user level, the scope of the attributes is at the
system level, and privileges that are granted are across the entire system. When attributes
are assigned at the group level, the corresponding privileges are restricted to a group or the
scope of the group in which attributes are assigned. Related product data might also be
recorded in user profiles. The set of data for a specific product is called a segment. At the
user level, the following segments might be included:
򐂰 DFP
򐂰 LANGUAGE
򐂰 NDS
򐂰 NETVIEW
򐂰 OMVS
򐂰 OPERPARMS (for MCS extended console sessions)
򐂰 OVM
򐂰 TSO
򐂰 WORKATTR (for APPC/z/OS processing)
For more information on each Segment's content, see the corresponding topic in this book, or
in z/OS Security Server (RACF) Command Language Reference, SA23-2292.
The ability to define attributes at the System or Group Level is used to build the correct
administrative structure for RACF. The SPECIAL and AUDITOR attributes, which are
defined at the appropriate level, are used to achieve centralized or decentralized security
administration.
For conversion purposes, users are often classified as TSO users, started task users (STC)
or others
In the RACF database, there is no special definition for a TSO user, an STC user, or other
users. All are RACF users. The Default Group, Attributes, and other values in the Profiles
make the difference.
Note: A RACF user ID can range from one to eight characters in length, but a RACF user
ID that is used for TSO LOGON must not be longer than seven characters.
3.3.2 RACF group

A RACF group consists of all the users that have similar requirements for access to the
system's resources. Each group, except for 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 alphanumeric
characters. The first character must be alphabetic or a special character.
An entry in the RACF database describing a group is called a group profile. A group profile
contains the group name, the superior group, the owner name (if not the superior group), a list
of all RACF groups that have the described group as its superior group, and a list of user IDs
that are members of the group.
The scope of a group is confined to all resources and users within that group and those of all
groups that are subordinate to that group.

Related product data can also be recorded in group profiles. The set of data for a specific
product is called a segment. At the group level, the following segments might be included:
򐂰 DFP
򐂰 OMVS
򐂰 OVM
򐂰 TME.
3.3.3 Owner
Each entry (or profile) in the RACF database has an owner. The owner must be a
RACF-defined USER or GROUP. For ease of administration, group ownership is
preferred. The RACF owner of a profile has full administrative authority over the profile. If
the profile is a user or a group profile that is in turn designated as the owner of other
profiles, the RACF owner of the top profile has full administrative authority over the other
profiles.
3.3.4 RACF protected resources

RACF resources are all the components of a computing complex that are 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:

1. Data sets profiles
2. General resources profiles
Both are considered resource profiles. RACF subdivides resource profiles into two types:
discrete profiles and generic profiles.
A discrete profile protects a single resource that has unique requirements. This profile can
contain the following features:
򐂰 A description of the resource, which includes the authorized users
򐂰 The access authority of each user
򐂰 In the case of data sets, the volume of the data set.
A generic profile protects several resources that have a similar naming structure and security
requirements. This profile contains a description of the resources, including the authorized
users and the access authority of each user. For more information on discrete and generic
profiles, see z/OS Security Server (RACF) Security Administrator's Guide SA23-2289.
Data sets
Data set resources include both DASD and TAPE data sets, and are described in the RACF
database as data set profiles. A data set profile contains information about the data set 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, a group profile or user profile
having the data set high-level qualifier (HLQ) as the group or username must be defined. This
group or user is used in the RACF database as an anchor point for all profiles that have the
same HLQ.

Therefore, protection for a data set always includes at least two entries (but optionally more)
in the RACF database:
1. A group profile or user profile (with same name as the data set HLQ)
2. One or more data set profiles (either discrete or generic)
When a data set can be protected by several different profiles, RACF searches for the
best-fitting profile. The search is made from the most specific profile to the least specific.
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.
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 a RACF class of entities by the
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 append
your unique class names to the standard CDT to represent your installation's requirements
outside of those identified by RACF. For more information on the Class Descriptor Table and
on how to add new resource classes, see Chapter 10. Administering the dynamic class
descriptor table (CDT) in the z/OS Security Server RACF Security Administrator's Guide.
A conversion to RACF might require you to add installation-defined classes to the standard
CDT.
Protection of a general resource can be achieved through use of one or several profiles,
either specific or generic. Note that:
򐂰 No anchor point is needed for general resource profiles (unlike data set profiles).
򐂰 Authorization is the same as for data sets.
For most of the general resource classes, a relationship exists between a class called a
member class and another class called a grouping class.
The class TCICSTRN, for example, is a standard RACF resource class in which one can
create profiles to protect one or several similarly named CICS transactions.
For example:
򐂰 A transaction named TRN1 can have a profile in the TCICTRN class with a resource name
of TRN1.
򐂰 All transactions whose names begin with TRN can have a profile in the TCICSTRN class
with a resource name of TRN*.
But you might want to define transactions TRN5, TRTA, and XYZ as having the same
protection and authorization requirements.
You can then use the CICS grouping resource class name of GCICSTRN. Our grouping
transaction profile can then be defined in the GCICSTRN class with a name of
MYOWNAME and members TRN5, TRTA, and XYZ. This profile then controls access to
all the member transactions. MYOWNAME is an arbitrary unique name within the
GCICSTRN class. This name is assigned by the installation to be a meaningful
mnemonic. Consider grouping classes when converting protection rules from another
security system.

3.3.5 RACF system-wide options
RACF system-wide options are used to customize RACF for installation-specific security.
Mainly, these options deal with the following aspects of security:
򐂰 Auditing
򐂰 Statistics
򐂰 Activation of classes
򐂰 Use of generics
򐂰 In-storage profiles
򐂰 JES job verification
򐂰 Default JES user IDs
򐂰 Data set protection and access
򐂰 Password rules
򐂰 SECLABELS
򐂰 Default language
The conversion project includes setting appropriate values for all general options to provide
equivalent RACF functions when converting from another security product. When needed,
changes to these values are mentioned in the appropriate chapters. For a complete
description of RACF options, see z/OS Security Server (RACF) Command Language
Reference SA23-2292 and z/OS Security Server (RACF) Security Administrator's Guide
SA23-2289.
3.3.6 The RACF database

There is only one RACF database, which includes the following characteristics:
򐂰 System options
򐂰 User profiles
򐂰 Group profiles
򐂰 Data set profiles
򐂰 General resource profiles
For performance purposes, this one database can be broken into several files spread across
system DASD volumes.
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 secondary
database.
Modifications to the primary database are reflected in the secondary database at the time that
they occur. RACF database definitions allow flexibility in the information to be mirrored,
providing the secondary database is online and active.

Figure 3-3 Database structure for RACF
3.3.7 RACF commands

RACF commands are TSO/E commands that might be run either online from a TSO console
or as a part of a batch TMP job. RACF panels and REXX procedures are both available in
addition to the online commands.
One of the main tasks in a conversion process is the generation of many RACF commands.
These are typically used as input to several batch TMP jobs to load the RACF database with
security information. The creation, review, edit, and running of such files is an iterative
process during the conversion. The following list is a brief review of the main commands:
򐂰 Commands directed to USER Profiles:
ADDUSER (AU) Add User Profile
ALTUSER (ALU) Alter User Profile
DELUSER (DU) Delete User Profile
DELUSER (DU) Delete User Profile
LISTUSER (LU) List User Profile
PASSWORD (PW) )Specify User Password
CONNECT (CO) Connect User to Group
REMOVE (RE) Remove User from Group
SEARCH (SR) Search for User Profiles
򐂰 Commands directed to Group Profiles:
ADDGROUP (AG) Add Group Profile
ALTGROUP (ALG) Alter Group Profile
DELGROUP (DG) Delete Group Profile

LISTGRP (LG) List Group Profile
SEARCH (SR) Search for Group Profiles
򐂰 Commands directed to Data-Set Profiles:
ADDSD (AD) Add Data Set Profile
ALTDSD (ALD) Alter Data Set Profile
DELDSD (DD) Delete Data Set Profile
LISTDSD (LD) List Data Set Profile
PERMIT (PE) Maintain Data Set Access List
SEARCH (SR) Search for Data Set Profiles
򐂰 Commands directed to General-Resource Profiles:
RDEFINE (RDEF) Define General Resource Profile
RALTER (RALT) Alter General Resource Profile
RDELETE (RDEL) Delete General Resource Profile
RLIST (RL) List General Resource Profile
PERMIT (PE) Maintain General Resource Access List
SEARCH (SR) Search for General Resource Profiles
򐂰 Others (RRSF, System, etc.):
DISPLAY Display Sign-On-From List
HELP (H) Obtain RACF Help
RACDCERT RACF Digital Certificate
RACLINK Administer User ID Associations
RESTART Restart RRSF Functions
RVARY Change status of RACF database
SET Set RRSF Operational Characteristics
SETROPTS (SETR) Set RACF Options
SIGNOFF Sign Off Session
STOP Shutdown RRSF
TARGET Define RRSF Nodes
Figure 3-4 on page 32 shows an overview of all RACF commands. For complete details
about each command, see z/OS RACF Command Language Reference, SA23-2292.

Figure 3-4 Commands for RACF
3.4 Interfaces
This section describes the interfaces to RACF.
3.4.1 Product Interfaces

Products might have security interfaces to RACF. RACF product or application interfaces fall
into three categories:
1. Implicit
A product interface to RACF is implicit when no parameter value settings are needed in
the product to enable it to use RACF for security controls. For example, products such as
JES2 or TSO/E have implicit interfaces.
2. Explicit
A product interface to RACF is explicit when parameter value settings are needed in the
product to enable it to use RACF for security controls. For example, products such as
CICS and IMS have Explicit Interfaces.
3. Exit Driven
If neither an implicit nor an explicit interface to RACF exists for a product, the installation
can create the interface by using standard API. The security requests are called from
standard product exits. This approach can also be used to create interfaces to RACF from
within applications.
One of the major problems in converting from another security system to a RACF security
system is the inventory of all interfaces used by the non-RACF security product. You might
discover that an exit interface has been used by the non-RACF security product to bypass a

standard implicit interface to RACF. Or you might discover that parameter values to activate
RACF from an explicit interface have not been set. Re-establishing use of standard interfaces
is one part of the conversion task.
3.4.2 The SAF interface

The System Authorization Facility (SAF) is a part of z/OS and is always active. Any security
product can use the SAF Interface. The main purpose of SAF is to route requests from
applications or subsystems to the proper security component for processing. This routing
uses the SAF Router Table. Depending on the type of request SAF might , or might not,
invoke RACF Services. For a description of SAF and how to add entries in the SAF Router
Table, see z/OS Security Server RACF System Programmer’s Guide, SA23-2287.
3.4.3 RACF exits

RACF provides exit points that can be used for additional levels of protection. Figure 3-5 on
page 34 shows all the exits that RACF currently supports. Most installations do not need to
code these exits. Where possible, standard RACF functions should be used.
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 and include
some of the more common exits:
򐂰 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 altogether.
򐂰 Authorization exits - ICHRCX01/ICHRCX02
The RACROUTE REQUEST=AUTH exits can alter the decision-making process that determines
whether 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.
򐂰 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 might 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.

Figure 3-5 RACF exits

4
Chapter 4. Broadcom Top Secret

overview
This chapter describes the Broadcom Top Secret security product.

4.1 The Broadcom Top Secret philosophy
The way Broadcom Top Secret protects data sets and all other resources is sometimes
referred to as protection based on the user. This means that, when deciding whether a user
can access a certain data set, Broadcom Top Secret starts with the users Accessor ID (ACID)
and then checks for the appropriate XA DATASET rules that are assigned specifically to that
user.
By default, all resources (any component of the operating system required by a task) are not
protected on a system with Broadcom Top Secret installed and active. You must set
system-wide or resource-specific options to enable access to resources. Broadcom’s Top
Secret operates in four modes:
1. DORMANT. Broadcom Top Secret is installed and is not actively validating resources.
2. WARN. Broadcom Top Secret is active, and validating resources, but instead of failing
requests, it generates warning messages.
3. IMPL. Broadcom Top Secret is active, validating resources, and failing unauthorized
access requests. Undefined users can operate normally, but are restricted from defined
resources.
4. FAIL. Broadcom Top Secret is in full control of resources.
For example, for data sets, RACF has the PROTECTALL option with values of FAILURES and
WARNING. These values help map the Broadcom Top Secret MODE Parameter values (FAIL
and WARN).
In Broadcom Top Secret, the data sets a user can access are determined by checking the XA
DATASET rules related to that user. These rules are found in both the individual user ACID
and any profile ACIDs to which the user belongs.
There are three checking sequences, depending on which Broadcom Top Secret startup
option is used. If the more common one AUTH(OVERRIDE,ALLOVER is used, then the
following checking sequence is used:
1. Rules in the user ACID are checked. If a rule meets the criteria, no further checking is
performed.
2. Rules in any profiles assigned to the user are checked, and each profile is checked in the
order that it is listed in the user ACID. If a rule meets the criteria, no further checking is
performed. If multiple accesses for a resource are located, access is granted or denied
based on the access rule containing the most specific match.
3. Rules in the ALL record are checked.
Another checking sequence used by Broadcom Top Secret is AUTH(OVERRIDE,MERGE). It

merges all of the rules in the user profile and all profiles that are connected to the user, and
then chooses the most appropriate one. An access decision is not made until the entire
merged record is searched. If no match is found, the ALL record is searched. If a rule meets
the criteria, no further checking is performed. If multiple accesses for a resource are located,
access is granted or denied based on the access rule containing the most specific match.
Figure 4-1 on page 37 shows these sequences.

Figure 4-1 Broadcom Top Secret access checking sequences
The following example shows a user's access to a resource in each of the AUTH options:
򐂰 User ACID = USER01
򐂰 Profiles = PROF01 and PROF02, and they are assigned to USER01 in that order
– USER01 contains the following resource definitions:
• XA DATASET - TECH.TEST.APPS01 - ACCESS = READ
• XA DATASET - TECH.*.APPS01.LOADLIB - ACCESS = UPDATE
– PROF01 contains the following resource definition:
• XA DATASET - TECH.TEST - ACCESS = UPDATE
– PROF02 contains the following resource definition:
• XA DATASET - TECH.*.APPS01.LOADLIB - ACCESS = NONE
򐂰 The ALL Record contains the following resource definition:
– XA DATASET - TECH.TEST.APPS01.LOADLIB - ACCESS = EXECUTE
USER01 access level to data set TECH.TEST.APPS01.LOADLIB in each of the three

different AUTH options would be determined from the following XA data set rules:
򐂰 Override/Allover:
– XA DATASET- TECH.*.APPS01.LOADLIB - ACCESS = UPDATE
– Reason - it was in the user's profile and had the most number of characters.
򐂰 Merge/Allover:
– XA DATASET - TECH.*.APPS01.LOADLIB - ACCESS = NONE
– Reason - it was one of the two rules that had the most number of characters and it had
an access level of NONE.
򐂰 Merge/Allmerge:
– XA DATASET - TECH.TEST.APPS01.LOADLIB - ACCESS = EXECUTE
– Reason - the ALL record is included in the merge and it had the most number of
characters.
Chapter 4. Broadcom Top Secret overview 37

The RACF security philosophy
The way RACF protects data sets and all other resources is sometimes referred to as
protection based on the resource. This means that, when deciding whether a user can access
a certain data set, RACF starts with the data set profile, and then checks the access list of
that profile for an appropriate USER or GROUP.
ACIDs fall into one of two categories:

1. Functional ACIDs used to perform specific tasks:
– User. This is the lowest level of ACID security in Broadcom Top Secret and is used to
define a person who can log onto a system. User ACIDs are converted to RACF users.
– Profile. This is an ACID containing a collection of access characteristics. This ACID
cannot sign on. Profile ACIDs are converted to a RACF group that is owned by the
equivalent of a Broadcom Top Secret division or department.
– Group. This ACID contains a collection of users who can share access authorities for
protected resources.
– Control. This ACID is used to define security administrators.
2. Organizational ACIDs used to construct the security database hierarchy:
– Department. This is an ACID definition in Broadcom Top Secret describing where a
user usually works. Each user ACID needs to be associated with a department.
Department ACIDs are converted to a RACF group that is owned by the equivalent of a
Broadcom Top Secret division.
– Division. This is an ACID used to define corporate hierarchy in a company’s corporate
security structure. Division ACIDs are converted to a RACF group.
– Zone. This is an ACID used to group two or more divisions.
Broadcom Top Secret profiles can also be referred to as RACF functional groups. Both
products use this concept in the same way. Typically, all resources needed to perform a
particular function are permitted to the same Broadcom Top Secret profile or RACF functional
group, rather than to each individual user performing that function. Each product has a way of
associating the right users with the right Broadcom Top Secret profiles or RACF functional
groups. For more information about functional groups, see z/OS Security Server (RACF)
Security Administrator’s Guide, SA23-2289.
In RACF, no users have functional groups as their default group. Users are instead connected
to these groups to access the resources that these functional groups are permitted to use.
The term profile has a different meaning in RACF than the Broadcom Top Secret definition.
For a definition of profile as used by RACF, see z/OS Security Server (RACF) Security
Administrator’s Guide, SA23-2289.
Broadcom Top Secret is started as a task by the START command, and runs in its own
address space. Broadcom Top Secret is stopped by entering a STOP (P) command with the
proper procedure name on a z/OS operator console.
All Broadcom Top Secret data is stored in the Broadcom Top Secret security file in an
encrypted format.
4.2 The Broadcom Top Secret environment

The following sections describe the Broadcom Top Secret environment and staffing.

4.2.1 The ALL Record
Sometimes in Broadcom Top Secret a user tries to access a data set, but there is no
appropriate XA DATASET rule in either the user ACID or any of the profile ACIDs. For those
situations, the ALL Record is used by Broadcom Top Secret when the OVERRIDE,ALLOVER
option in Broadcom Top Secret is in effect.
The ALL Record is a list of resource rules (data set and others) similar to a profile, except it is
always the last place Broadcom Top Secret looks for a resource rule to check against. If an
appropriate rule cannot be found in the ALL Record, then access to the resource depends on
the overall security mode that Broadcom Top Secret is in, such as WARN and IMPLEMENT.
The functions of the ALL Record in Broadcom Top Secret are handled by the Universal Access
Authority (UACC) in RACF. The UACCs are not stored in one central RACF list, but are defined
separately for each RACF profile.
4.2.2 Personnel
Broadcom Top Secret administrators are needed to obtain information on how Broadcom Top
Secret is implemented in the installation. The following section describes the personnel
involved in the security administration in Broadcom Top Secret.
The Broadcom Top Secret administrative hierarchy has the following levels:
򐂰 Master Security Control ACID (MSCA) is converted to RACF System-Special.
򐂰 Central Security Control ACID (SCA) is converted to RACF System-Special.
򐂰 Limit Central Security Control ACID (LSCA) is converted to RACF Group-Special.
򐂰 Zone Control ACID (ZCA) is converted to RACF Group-Special.
򐂰 Divisional Control ACID (VCA) is converted to RACF Group-Special.
򐂰 Departmental Control ACID (DCA)- is converted to RACF Group-Special.
Broadcom Top Secret officer

The security officer with the MSCA or SCA attribute can provide most of the information you
need to convert the Broadcom Top Secret database into RACF commands.
Broadcom Top Secret auditor

The security auditor has the same duties in both the Broadcom Top Secret and RACF
environments. The Broadcom Top Secret auditor can provide information on Broadcom Top
Secret database contents, and on the reporting and auditing level needed.
z/OS systems programmers

These programmers are responsible for all z/OS/JES/TSO Exits and user modifications. They
are needed for maintaining libraries, modules, procedures, and parameters.
Product systems programmers

These programmers are responsible for converting and updating all product interfaces to
RACF.
Broadcom Top Secret has control options to define the security environment. These options
are defined in the Broadcom Top Secret parameter file. Some examples include Password
Definition, Mode, Tape Dataset Security, Facility, and Violation Logging.

4.2.3 Resource rules
Securing resources in Broadcom Top Secret is a two-step process.
1. After the resource has been defined, it must be owned by an Individual user ACID or a
department ACID.
2. When the resource is owned, the owner can permit other users to access the resource, if
needed.
In Broadcom Top Secret, a resource protection definition is called a resource rule. Some
examples of resource rules are:
򐂰 XA Dataset for Dataset Protection
򐂰 XA Facility for Application Protection
򐂰 XA Terminal for Terminal Protection
򐂰 XA Otran for Transaction Protection
Broadcom Top Secret access authority is defined as follows:

򐂰 ALL converts to the RACF equivalent of ALTER.
򐂰 SCRATCH converts to the RACF equivalent of ALTER.
򐂰 CREATE converts to the RACF equivalent of ALTER.
򐂰 CONTROL converts to the RACF equivalent of CONTROL.
򐂰 WRITE converts to the RACF equivalent of UPDATE.
򐂰 UPDATE converts to the RACF equivalent of UPDATE.
򐂰 READ converts to the RACF equivalent of READ.
򐂰 FETCH converts to the RACF equivalent of EXECUTE.
Some XA DATASET rules also have a FACILITY subparameter. A FACILITY is a way of

grouping options and associating them with a particular service to which users sign on. Some
facilities supported are CICS, TSO, BATCH, and STC. In Broadcom Top Secret, you can
restrict access to a data set to certain applications by using the FACILITY subparameter.
Mapping which applications are defined to each FACILITY is a user-controlled option.
4.2.4 Broadcom Top Secret database files

The following files are used by Broadcom Top Secret to secure an environment:
򐂰 Security file. An encrypted file that contains the security records of all user and resource
permissions and restrictions
򐂰 Parameter file. A file that contains and defines Broadcom Top Secret Control Options
used at initialization and sets up the operating environment
򐂰 Audit/Tracking file. A file that contains security-related events such as violations, job and
session initiation, and resources accesses
򐂰 Backup file. A file that contains the Automatic Daily Backup of the Security File
򐂰 Recovery file. A file that contains recent administrative commands and can be used in
conjunction with the backup file to restore a damaged security file.

4.3 Broadcom Top Secret subsystem interfaces
The interfaces that are discussed in this section provide Broadcom Top Secret access to
z/OS subsystems.
The that Broadcom Top Secret uses to access z/OS subsystems includes the following:
򐂰 TSO
Broadcom Top Secret provides the ability to control access to TSO, commands, and
ISPF/PDF panels.
򐂰 CICS
Broadcom Top Secret provides the ability to control access to CICS. Security access can
be implemented at a transaction level or resource level.
Broadcom Top Secret implements a sign-on interface for CICS to further control the
environment of the CICS user. The interface might include a new sign-on transaction
name and a different sign-on panel.
򐂰 IMS
Broadcom Top Secret provides the ability to control access to IMS. Security access can be
implemented at a transaction level or resource level.
򐂰 Db2
Broadcom Top Secret provides the ability to control access to Db2. When Broadcom Top
Secret Option for Db2 1.3 is installed, native Db2 security is disabled. Db2 also provides a
separate subsystem in the product for security. For more information, see Top Secret
Option for Db2 1.3.

5
Chapter 5. RACF project overview

This chapter is intended as a project management guide for a Broadcom Top Secret to RACF
conversion. It is written to provide a starting point for creating a security project plan that is
appropriate for your environment.
The information presented here was gathered from several Broadcom Top Secret to RACF
conversions. The project examples represent a typical, generic project that converts only one
Broadcom Top Secret database to RACF, with expected completion within three to six
months. The actual time that it takes you to complete your migration can differ, depending on
the nature and complexity of your project.
There is no guarantee that, for any particular conversion, the information that is contained in
this manual is either complete, accurate, or even appropriate. Any individual security usually
has tasks associated with it that are unique and specific to that particular migration. However,
there are also many tasks that are common to all security migrations. The purpose of this
document is to describe those tasks, so you can decide whether the task is appropriate for
your particular migration.
Some of the tasks in a security project involve determining how other products, such as CICS,
IMS and Db2, interface with RACF or Broadcom Top Secret. Whenever those tasks are
discussed in this book, you are usually referred to the documentation of the other product. It
would be difficult, if not impossible, to accurately maintain that kind of information in a manual
of this type. Instead, this book concentrates on providing information not readily found in other
sources, such as creating a security plan and providing some practical guidelines for
converting your Broadcom Top Secret database to an equivalent RACF database.
This chapter describes how to prepare for the project, build the project plan, and schedule the
necessary resources. The need for assessing the current environment and suggested
personnel skills are also discussed.

5.1 Preparing for the project plan
To build a good plan, review your Broadcom Top Secret database and supporting system
environment for any security-related impacts. What you find will determine the number and
types of people you need for the team. In addition, consider what type of education is needed,
who would need it, and when it should be completed.
Your overall goal is to build as complete a plan as possible, using information from this book
or other sources. The plan should identify all required tasks, who will do them, and when the
tasks should be completed.
5.1.1 Review the current Broadcom Top Secret environment

The first step is to look at what security functions are implemented using the Broadcom Top
Secret database. You also need to decide how to convert the Broadcom Top Secret database,
determine any impacts on the supporting system environment, and identify applications with
security interfaces.
Assess the current Broadcom Top Secret database

Some features in Broadcom Top Secret do not convert easily or on a one-to-one
correspondence to RACF. This is because Broadcom Top Secret and RACF are two separate
products.
Typically, this means that you must examine each vendor product (for example, OEM)
implemented in your environment and determine what must be done, if anything, for each
product to work with RACF. Usually, each vendor’s product documentation provides RACF
installation instructions. Identify all vendor product features that you are using that RACF
does not have an equivalent function for then determine alternative ways of providing the
same protection using RACF functions. Also, check your z/OS base product code for any
security-related Usermods, Accounting Exits, JES2 exits, and others.
As you assess the Broadcom Top Secret database and uncover potential issues, ask whether
a current business need still exists which caused the original implementation of the security
feature. If a need still exists, determine a solution to convert the feature to the RACF
environment. Many solutions can be found using either procedural controls or automated
solutions.
Decide on how to convert the security database

Create a RACF database that matches, as much as possible, your Broadcom Top Secret
database. As part of this task, you must write or obtain automated programs that can assist in
converting the rules and parameters contained in the Broadcom Top Secret database to the
appropriate RACF commands.
You have several choices:

򐂰 Buy an existing product to assist with the migration.
򐂰 Write your own conversion routines.
򐂰 Instead of converting your current Broadcom Top Secret database, build a new RACF
database with new definitions.
If you choose to convert your Broadcom Top Secret database, usually you must write or
obtain automated programs that can assist in database conversion. Typically, these programs
or tools use the information in the Broadcom Top Secret database to create RACF

commands. When these RACF commands run, they load the appropriate security information
into an empty RACF database.
Because of the differences between the way Broadcom Top Secret and RACF protect
resources, any database conversion requires that you ensure the RACF commands
implement the same or better access control integrity than the Broadcom Top Secret
environment.
If you choose to write your own conversion programs, the programs might take several
months to write, and they must be ready before the start of unit testing. In addition, you
should do several RACF database loads during the development phase to ensure an
adequate amount of testing.
If you choose to obtain the conversion programs from other sources, ensure that you can
customize these programs to fit your individual needs.
Note: It is very important that you understand the amount of work that is required to
convert your Broadcom Top Secret database. Several chapters of this book are devoted to
this topic. Review them thoroughly before making your decision.
Analyze the current system environment

Complete a comprehensive, detailed review of any products, programs, or interfaces that
perform security functions. Depending on what is being done, you might have to modify
program code or write program code or exits, which perform the function on behalf of a user’s
request.
To analyze your current system environment, start by listing all installed hardware and
software products. Identify which ones have security interfaces, or might otherwise be
affected by this conversion. (This research is similar to what you might do in preparation for a
systems software upgrade, such as a ServerPac Installation.)
For each product that has a security interface, determine how RACF can provide the same
protection. Also determine the amount of work required to have the product work with RACF,
instead of Broadcom Top Secret.
Preparing the RACF test system

A test system similar in size and nature to one that might be used for a z/OS software
upgrade must be available for the project.
Ensure that the RACF test system is dedicated to the project for about two to three months to
complete this project in a timely and efficient manner. A dedicated test system is one that is
available during the normal working day so that the project team can work on the environment
during their normal day-to-day work schedule.
Typical Test System requirements include:

򐂰 A SYSRES volume to install RACF
򐂰 DASD space for the RACF database
򐂰 DASD space for the applications to be tested under RACF
Because of system constraints, a smaller system might limit the amount of RACF testing. At
some point, the RACF tests must be run on a second more comprehensive test system. The
second system might not be available as a dedicated system. .
Install RACF on a test system that is separate from the Broadcom Top Secret production
system. Although upgrading or installing any product is not required for the sole purpose of
Chapter 5. RACF project overview 45

using RACF, some of the advanced functions of RACF might work with only the later release
levels of some products.
5.1.2 Personnel
A typical security project involves people with the job descriptions that are listed in Figure 5-1.
Personnel who work on the migrations often perform multiple duties throughout the project.
As you determine which tasks need to be done, also determine how many people are needed
to perform the tasks to ensure a successful migration.
Sample project organization describes the organization that should be implemented

before the beginning of a migration.
Figure 5-1 Sample project organization
The security administrator

The security administrator is usually the most important and busiest person in a security
migration. The security administrator is the focal point for all questions that are related to what
protection is currently in effect and why it was originally implemented. The security
administrator also determines the methodology and customization of the conversion
programs that convert the Broadcom Top Secret database to RACF.
Frequently, the security administrator is also responsible for coordinating all testing, updating
all security procedures, and educating end users in RACF. Because the responsibilities of the
security administrator for technical issues, they are usually too busy to be the project
manager.
A key factor to the success of any project is having a security administrator on the team who
knows why past decisions were made. The security administrator can also provide guidance
on whether current business needs exist for transferring functions into the RACF
environment.
The project manager

The project manager is primarily responsible for creating the plan, with the assistance of the
team, and for monitoring the progress of the project. Because the team usually consists of

people from several departments, the project manager ensures that everyone is committed to
performing and completing the tasks for which they are responsible throughout the project.
This person is responsible for acquiring any additional personnel or systems support
necessary to keep the project on schedule. The project manager might also assist the
security administrator in their tasks.
The conversion programmer

The conversion programmer is responsible for configuring the options of the conversion
programs. The conversion programmer coordinates resolution of database conversion issues
and configures the conversion programs to properly represent the wanted RACF result.
The z/OS systems programmer

The main responsibilities of the z/OS systems programmer are to install and customize RACF,
to create and maintain the test system to be used throughout the conversion, and to help test
RACF.
In some cases, the z/OS systems programmer also installs and customizes any vendor
(OEM) program products that use security interfaces. Vendor product documentation usually
contains specific instructions to set up their product to use RACF.
The online systems programmers

Online systems programmers are responsible for performing whatever work is necessary so
that their subsystems work properly when RACF is installed. This typically means analyzing
their current subsystem for interfaces to Broadcom Top Secret, preparing the appropriate
code and JCL to accomplish the same protection under RACF, and assisting in the RACF
testing. Some examples of subsystems are TSO, IMS, CICS, Db2, or VTAM.
The application project leaders

Application project leaders are responsible for verifying that they are the true owners of any
resources, usually data sets, as identified through the Broadcom Top Secret database.
Application project leaders ensure adequate testing of their applications is done. During the
testing phase, they are responsible for determining that the security protection for their
resources under RACF is acceptable and that their applications function as well or better than
they did with Broadcom Top Secret.
5.1.3 Education
Determine who must receive RACF education before the project starts, when the education
should be completed, and which classes should be attended. This education might include
formal IBM-taught classes, self-study courses, or classes that are developed in-house for
help desk or end-user training. Schedule and attend RACF education for performing
day-to-day administration before starting the project.
5.2 Building the project plan

Building the project plan means documenting all the tasks that have been identified, who is to
do them, and when they are to be done. After you decide you want to convert to RACF,
determine what methodologies to use in converting to RACF. Develop a detailed plan that
identifies the tasks to be performed, who are the most qualified to complete the task, and a
projected time frame. Remember to include items that are not pure tasks, such as educational
needs and test system availability.

To create accurate estimates for the work involved in some of the tasks, analyze what is
required to complete the task. There can be multiple items to perform to finish the project
tasks. Ask the same questions for any other significant software installed on the Broadcom
Top Secret system.
5.2.1 Example of a project task

As project manager, you review the list of software that is installed on your system and see
that CICS is one of the products installed. You ask the CICS systems programmer the
following questions:
1. Are there any non-standard uses of security that would interfere with a migration to
RACF?
2. How much work would be involved in converting the security for the CICS regions to
RACF?
If the answer to the first question is yes, then that is identified as a potential migration issue.
Also, the amount of overall work that is involved in converting CICS security to RACF, and
who does that work, is identified in the plan. You do not begin that work until you have
determined that the issue identified in the first question does not cause a delay in the overall
project.
In all cases, determine whether a current business need exists for the project task. If
something was done in Broadcom Top Secret that does not need to be carried forward into
the RACF environment, then this item does not need to be addressed.
Figure 5-2 shows a typical project plan by phase lasting over 14 weeks. There are seven
major phases to the migration project: assessment, education, project planning,
development, unit testing, integration testing and production cutover.
Figure 5-2 Project planning phase items
5.2.2 Significant project tasks

Several project tasks are involved.

Analyze the current security environment
Examine the security database and system environment to identify which technical issues
must be addressed. This includes database features that do not have a direct RACF
functional equivalent and includes any system exits or product interfaces that perform security
functions. Review all issues to determine whether a current business need exists.
Project management
Throughout the project, monitor and adjust the plan that you created at the beginning of the
project.
Planning
In this phase, a detailed project plan is developed for the remainder of the project. It lists who
to involve, what other resources are needed, all the security interfaces currently in effect, and
any issues to resolve before proceeding to the next phase. Typical significant checkpoints are
the initial load of the RACF database, testing, and cutover.
Identify project team

Identify the people to complete the tasks identified in the project plan.
Identify concerns or system changes

Review all conditions or situations that are identified as potential issues. Determine whether
any of them are serious enough to delay the project until the condition or situation in question
is resolved. Also, coordinate with other projects in the company, such as software upgrades or
hardware installations that might interfere with the schedule for this project.
Identify anything that might be interpreted as a significant technical project issue. Identify any
issues that might adversely affect the project time frame. For example, if the test system is not
available for several months, there is no need to have the online systems programmers
preparing their products for RACF.
Often, the support and approval of the end-user community is needed before beginning this
project. Often, the information from this phase is used to help obtain that support and
approval.
Install and customize RACF

Install RACF on a test system that is separate from the production system that contains
Broadcom Top Secret if possible. Also review the customizing options available and
determine what is appropriate for your environment.
Prepare the RACF test environment

In this phase, prepare a RACF test environment that emulates the Broadcom Top Secret
environment. All the security interfaces that exist in the current system are identified. Any
code to accomplish the same protection under RACF is prepared in this step.
Install conversion programs

In this phase, install the conversion programs to convert Broadcom Top Secret to RACF.
Customize these programs based on your specific requirements.
Review naming conventions

Naming conventions are important because high-level qualifiers of data sets play a more
important role in RACF than they do in Broadcom Top Secret. RACF assigns ownership of
data sets according to a high-level qualifier. Only one RACF group can own a high-level

qualifier at any one time. For example, Broadcom Top Secret allows the use of generic
characters for masking of high-level qualifiers but RACF does not.
Review security procedures

Identify all procedures that change because of the conversion to RACF. Typical procedures of
this type include how help desk personnel are to change passwords or how operators and
software automation products interact with RACF and z/OS operations.
RACF group structure planning

This is a very important part of the database conversion. Build a RACF group structure that is
manageable, well-designed, and meets your specific needs. For example, there are certain
Broadcom Top Secret logonid fields, which provide security administrative functions. The
migration team determines how to provide similar functionality to the RACF community
through centralized or distributed security administration procedures.
Convert the security database

In this phase, run your conversion programs to convert the Broadcom Top Secret database to
RACF commands. Through repetitive executions of the tool against the Broadcom Top Secret
database, build a functionally equivalent RACF database. Final testing verifies the integrity of
the user ID and resource profile definitions.
Testing
The following list describes a typical RACF testing sequence or cycle:
򐂰 Create a RACF database to match the Broadcom Top Secret database.
򐂰 IPL the test system with RACF.
򐂰 Implement the test plans.
򐂰 Review the results.
򐂰 Make any corrections to the conversion programs.
򐂰 Retest the system.
Several testing cycles are usually needed before your RACF environment is ready for testing
against the full production system. This usually takes several weeks of effort.
Unit testing
Unit testing tasks focus on verifying the initial RACF database, system Environment, and
selected important applications. You identify any differences between the old and new
security environments, make any necessary corrections, and retest until you’re satisfied.
Integration testing
In this phase, test your RACF environment against the full production system. Ensure that
major applications within the company are not adversely impacted. This is usually done on
weekend shifts. If there are no major problems during this phase, you can convert to RACF.
Develop a backout plan

It is prudent to develop a backout plan if you need to back out RACF and return to the
Broadcom Top Secret environment. The backout plan typically identifies all exits and
interfaces that were replaced, how to reinstall them if necessary, and how to relink to the
Broadcom Top Secret databases. Each project team member responsible for implementing
changes for the RACF provides input into the overall backout plan.
Another option is to publish a set of items, or expectations, which would potentially trigger a
backout. Some examples include inadequate testing of security functions and applications not

converted to use RACF. These expectations should be communicated to all affected users
before the cutover date.
Preserve the Broadcom Top Secret databases

Before the cutover date, make copies of the Broadcom Top Secret security databases.
Problem resolution is critical during the days immediately following the cutover, and access to
the previous security environment might help resolve user and system issues.
After the migration to RACF is complete, determine whether any user access problems exist
against what the access was in Broadcom Top Secret. Because you might not be able to log
on to Broadcom Top Secret, ensure that you have the LIST(ACID) reports for all ACIDs
available or any other report used to diagnose and solve user access problems. These files
and reports can be written to DASD files as part of the cutover process for easy accessibility.
You can also migrate Broadcom Top Secret to your test environment concurrent with the
RACF production environment cutover and then log on to Broadcom Top Secret to resolve
problems.
Production cutover
Before migrating RACF to production, test RACF with the full production system, similar to the
way a test is run on a z/OS software upgrade before putting it into production.
Successful migrations freeze all changes to Broadcom Top Secret shortly before the cutover
weekend. The conversion tool is run one last time and a final RACF database is built. All
modified exits and interfaces are installed and passwords are synchronized.
5.3 Resource scheduling

Decide how and when to allocate your project team skills across the entire project. Table 5-1
on page 52 is a representative sample of the typical resources that are needed by project
phase and the level of effort required. Each of the six project skills has responsibilities in each
project phase.
In this table, the full-time or part-time designation represents the allocation of time on the
project in relation to their overall job responsibilities. For example, if the teammate can work
20 hours per week on the project, then a full designation would mean 20 hours of
level-of-effort.

Table 5-1 Scheduling graph
Resource type
Production Cut-over
Integration Testing
Development
Assessment
Unit Testing
Education
Planning
Project manager Full Full Full Part Part Full Full
Security administrator Full Full Full Part Part Full Full
z/OS systems programmer Full Full Part Full Part Full Full
Conversion programmer Full Full Part Full Part Part Part
Online systems programmer Full Part Part Full Part Full Full
Application project leaders Full Part Part Part Part Full Full
5.4 Summary
In summary, the success of the project depends on the quality of the project plan and the
deployment of the right project team members with the right skill level at the right time. Other
considerations might include management involvement, choice of test systems, education,
application involvement and timing considerations.
Management involvement
You need strong management commitment to undertake a major migration 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.
Test system
It is not practical to run both Broadcom Top Secret and RACF on the same z/OS 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, which is not practical
on any production system. Therefore, you need a RACF z/OS system to use solely for test
purposes.
In practice the test system is usually a Logical Partition (LPAR) on a larger processor. With
some care, the test z/OS can share DASD with your production data, which can make testing
easier. You can clone your production z/OS and then remove Broadcom Top Secret and
install RACF. Alternatively, you can install a new z/OS with RACF already integrated. In either
case, systems programming time is needed to install, make ready, and maintain the test z/OS
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 project manager, or
intend to be the primary RACF specialist in the organization, arrange for formal RACF
education.

Application involvement
A major goal of the 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 groups.
They must help you test their applications in the new RACF Environment.
Personnel availability and timing considerations

For a security subsystem to be effective, it must be tightly tied to the operating system. Given
this, it can be difficult to make a major change in the security subsystem without impacting
system production. A large, production z/OS installation has many complex jobs. Some of
these are rarely used, such as year-end jobs or obscure recovery jobs.
The bulk of basic Broadcom Top Secret user records and resource rule records can be
automated. However, testing the results of this conversion and discovering and migrating all
the special cases that exist, without disrupting production can be difficult. Nevertheless, this is
the requirement for almost all Broadcom Top Secret to RACF migrations. It is these practical
considerations that dictate the resources and personnel needed for migration.
No single plan can apply to all situations. However, a project plan of three to six months with
one full-time person and several part-time people working on the project is typical.

6
Chapter 6. Database migration

This chapter describes the process of the actual database migration of Broadcom Top Secret
to IBM’s RACF. It provides guidance on how to convert a certain Broadcom Top Secret
function to the equivalent function in IBM’s RACF.

6.1 Conversion methodology
This section discusses some of the issues and approaches that you can use when you
convert your Broadcom Top Secret database to RACF. Similar to Broadcom Top Secret,
RACF offers a number of ways of implementing security policies and procedures. Experience
shows that some approaches work better than others. This section provides a number of
recommendations for designing and implementing a conversion methodology from Broadcom
Top Secret to RACF.
6.1.1 Migration considerations

The migration from Broadcom Top Secret to RACF involves more than a conversion of
database records. This is an opportune time before your migration to review, rethink, and
polish your security policy. A clear vision of what you want to produce helps the migration
work and provides better results. Some of the key elements to a migration are discussed in
Chapter 5, “RACF project overview” on page 43. Before you begin the conversion, have a
plan that includes:
򐂰 Management involvement, signoff, support
򐂰 Test system
򐂰 Education
򐂰 Application involvement
򐂰 Personnel and timing
One of the lasting aphorisms of the data processing business is Garbage In - Garbage Out,
commonly known as GIGO. Although 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 clean input database at the
beginning of the migration helps produce a higher-quality result. The migration process or
tools cannot 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 such as changing
security administrators, changing philosophy of security management, and former users who
still own resources. 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 usually the best one. You understand your current Broadcom Top Secret
database and have the skill to review it. Reviewing and correcting a large security database
can reduce future problems. Some migration tools might help you clean up your current
database.
Schedule pressures might push you toward the second choice of migrating the existing
database without correcting before migration. The problem with this approach is the cleanup
after migration. The migration process might amplify the problems in the original database.
The conversion of a Broadcom Top Secret database to a RACF database is not a simple,
one-to-one process. Small anomalies in the input that might be easily corrected before the
migration, can create large unwanted structures in the output.
Determine a pre-conversion review process to detect and correct obvious errors in the
database. The review process can also consider design and philosophical changes that

produce a better database after migration. Again, small changes might make the migration
much easier and produce a better result. Examples of such changes are the elimination of
FACILITIES that are not needed or that are outdated.
In practice, you might use all three choices: some clean up of the original database, some
clean up of the RACF database, and by using the resulting database in production.
6.2 Converting ACIDs

ACIDs in Broadcom Top Secret become the user IDs and groups that make up the RACF
security environment. Table 6-1 shows examples of ACIDs in Broadcom Top Secret and their
RACF equivalents.
Table 6-1 ACIDs conversion table

Broadcom Top Secret RACF Equivalent
Terms
Zones GROUPs
Divisions GROUPs owned by Zone
Departments GROUPs owned by Division
Profiles GROUPs owned by a Division or Department
Users USERs
SCAs USERs with SPECIAL privilege
LSCAs USERs with some special privileges
VCAs USERs with group special privileges
DCAs USERs with group special privileges
ZCAs USERs with group special privileges
The ALL record UACC (universal access authority) or ID(*) rules
6.2.1 Broadcom Top Secret user/group migration issues

Migrating the basic user from Broadcom Top Secret to RACF is not necessarily a complex
task. However, the migration of some user privilege attributes might become more
complicated. Some of these privileges can be carried across into RACF, but there are some
that might require careful planning and possibly an exit. This section focuses on some
typically common areas.
The conversion process is shown in Figure 6-1 on page 58.
Chapter 6. Database migration 57

Figure 6-1 Security database conversion process
An essential piece of the conversion process is the selection of a RACF administrative group
structure. The structure is usually based on the Broadcom Top Secret structure. Ensure that
the RACF structure allows for user administration and user access authorization.
The following steps describe an example flow of ACID conversion:

1. Design and define a set of new naming standards for the RACF database.
2. Design and define the RACF group structure (see Chapter 5, “RACF project overview” on
page 43).
3. Run LIST commands against the Broadcom Top Secret database, which lists all ACIDs
into a data set.
4. Use the output from the report as an input to the conversion process.
5. Output from the conversion process is a set of RACF commands that are written to a data
set. These commands define group profiles and user profiles, and user-to-group
connections.
6. Use the commands to load the new RACF database.
6.2.2 Listing the Broadcom Top Secret ACIDs

The following Broadcom Top Secret commands can be used to generate reports that list all
ACIDs and the resources each ACID can access:
Profiles:
Zones - TSS LIST(ACIDS) DATA(ALL) TYPE(ZONE)
Divisions - TSS LIST(ACIDS) DATA(ALL) TYPE(DIV)
Departments - TSS LIST(ACIDS) DATA(ALL) TYPE(DEPT)
Profiles - TSS LIST(ACIDS) DATA(ALL) TYPE(PROF)
Users - TSS LIST(ACIDS) DATA(ALL) TYPE(USER)
Security Administrators:
System - TSS LIST(ACIDS) DATA(ALL) TYPE(SCA)
Limited Scope - TSS LIST(ACIDS) DATA(ALL) TYPE(LSCA)

Division - TSS LIST(ACIDS) DATA(ALL) TYPE(VCA)
Department - TSS LIST(ACIDS) DATA(ALL) TYPE(DCA
Zone - TSS LIST(ACIDS) DATA(ALL) TYPE(ZCA)
The All Record - TSS LIST(ALL)
Typically, you write these reports to files on DASD, then process the information in them by
using a conversion tool that provides automated processing through application programs or
REXX execs.
6.2.3 Reviewing and defining ACIDs to RACF

For each Broadcom Top Secret ACID, determine the equivalent RACF definition and the
appropriate RACF command to use when converting.
The commands that are shown in Table 6-2 are used to define the ACIDs to RACF.
Table 6-2 ACID to RACF definitions

Broadcom Top Secret Term RACF Equivalent
Zones ADDGROUP
Divisions ADDGROUP
Departments ADDGROUP
Profiles ADDGROUP
Users ADDUSER
SCAs ADDUSER
VCAs ADDUSER
DCAs ADDUSER
ZCAs ADDUSER
Converting zone, division and department ACIDs

In Broadcom Top Secret, users are usually defined to a department. In RACF, the Broadcom
Top Secret departments become what RACF refers to as administrative groups. These
groups become the default groups when users are defined to RACF. Zone and division ACIDs
become the group tree structure, which allows administrative controls.
Listing zone, division and department ACIDs

Example 6-1 shows how to list the zone, division and department ACIDs, along with the
output generated by each list command:
Example 6-1 Listing zone, division and department ACIDs with output
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(ZONE)
Output:
ACCESSORID = ZONE1 NAME = ZONE ONE
TYPE = ZONE FACILITY = *NONE*
CREATED = 04/20/98 LAST MOD = 04/20/21
ACIDS = DIV1(V)
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(DIV)

Output:
ACCESSORID = DIV1 NAME = DIVISION ONE
TYPE = DIVISION FACILITY = *NONE*
CREATED = 04/20/92 LAST MOD = 04/20/21
ACIDS = DEPT1(D)
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(DEPT)
Output:
ACCESSORID = DEPT1 NAME = DEPARTMENT ONE
TYPE = DEPT FACILITY = *NONE*
DIV ACID = DIV1 DIVISION = DIVISION ONE
CREATED = 04/20/92 LAST MOD = 04/20/21
ACIDS = PROF1(P)
Defining zones, divisions and departments to RACF

To convert these ACIDs, define them to RACF as GROUPs, by using the ADDGROUP
command. ZONE1 becomes a group that is owned by SYS1 if ZONEs exist. If not, this level is
skipped. DIV1 becomes a group that is owned by SYS1 if no ZONEs exist, or by ZONE1 if
there are zones. DEPT1 becomes a group that is owned by DIV1 by using one of the
following sets of commands:
򐂰 Set 1:
ADDGROUP (ZONE1) SUPGROUP(SYS1) OWNER(SYS1)
ADDGROUP (DIV1) SUPGROUP(SYS1) OWNER(SYS1)
򐂰 Set 2:
ADDGROUP (DIV1) SUPGROUP(ZONE1) OWNER(ZONE1)
ADDGROUP (DEPT1) SUPGROUP(DIV1) OWNER(DIV1)
Note: ACIDs can start with numerics in Broadcom Top Secret, such as DIV=123DIV. In
RACF, a group must start with an alphabetic character. If you have ACIDs that start with a
numeric, change the ACID names.
6.2.4 Converting profile ACIDs

This section describes converting a Broadcom Top Secret profile to a RACF group and
ensuring the users who had the profile are connected to the functional group.
Conversion of Broadcom Top Secret profiles is more complex because of the differences in
philosophy of the two products.
Broadcom Top Secret profiles become what RACF refers to as functional groups. Both
products use this concept in the same way. Typically, all resources that are needed to perform
a particular function are permitted to the same Broadcom Top Secret profile (or RACF
functional group), rather than to each individual user performing that function. Each product
has a way of associating the right users with the right Broadcom Top Secret profiles or RACF
functional groups.
In Broadcom Top Secret, the profile consists of the resources common to a group of users
and is permitted to each user needing the resources. In RACF, the functional group is a list of
users who access the same set of resources.

In RACF, functional groups usually do not own any users. That is, no users have these groups
as their default group. Users are instead connected to these groups, so they can access the
resources that these functional groups are permitted to use.
The term profile has a different meaning in RACF than the Broadcom Top Secret definition.
The profile in RACF is a record in the database. You can have group profiles, user profiles,
data set profiles, and so on. For more information about RACF profiles, see z/OS Security
Server (RACF) Security Administrator’s Guide, SA23-2289.
Listing profile ACIDs

Example 6-2 shows how to list the Broadcom Top Secret profile ACIDs, along with an
example of the output.
Example 6-2 List profile ACIDs with output

Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(PROF)
Output:
ACCESSORID = PROF1 NAME = PROFILE ONE
TYPE = PROFILE FACILITY = *NONE*
DEPT ACID = DEPT1 DEPARTMENT = DEPARTMENT ONE
CREATED = 04/20/98 LAST MOD = 04/20/21
XA DATASET = SYS1. OWNER(SYS1)
ACCESS = UPDATE
ACIDS = USER1 SCA1 (S) VCA1 (V) DCA1 (D)
ACCESSORID = PROF2 NAME = PROFILE TWO
TYPE = PROFILE FACILITY = *NONE*
DIV ACID = DIV2 DIVISION = DIVISION TWO
CREATED = 05/21/98 LAST MOD = 04/20/21
ACCESS = READ
ACIDS = USER3
Defining profile ACIDs to RACF

To convert the profile ACIDs, define them to RACF as groups by using the following
ADDGROUP commands. Using the ACIDs from the previous examples, PROF1 becomes a
group that is owned by DEPT1 and PROF2 becomes a group that is owned by DIV2:
ADDGROUP (PROF1) SUPGROUP(DEPT1) OWNER(DEPT1)
ADDGROUP (PROF2) SUPGROUP(DIV2 ) OWNER(DIV2 )
Also, all resources that these Broadcom Top Secret profiles can access are defined to RACF,
and the function group, for example, PROF1, is permitted to the resource definition. All users
who were associated with these Broadcom Top Secret profiles are connected to the
corresponding RACF functional groups with the CONNECT command.
CONNECT USER1 GROUP(PROF1) OWNER(PROF1)
CONNECT SCA1 GROUP(PROF1) OWNER(PROF1)
CONNECT VCA1 GROUP(PROF1) OWNER(PROF1)
CONNECT DCA1 GROUP(PROF1) OWNER(PROF1)
CONNECT $USER3 GROUP(PROF3) OWNER(PROF3)

6.2.5 Converting user ACIDs
You normally convert each Broadcom Top Secret user ACID to a RACF user ID.
Listing user ACIDs

Example 6-3 shows how to list user ACIDs, along with an example of the output:
Example 6-3 List user ACIDs with output

Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(USER)
Output:
ACCESSORID = $USER3 NAME = AARON AARDVARK
TYPE = USER SIZE = 768 BYTES
ZONE ACID = ZONE1 ZONE = ZONE ONE
CREATED = 11/11/99 LAST MOD = 24/03/21 12:34
PROFILES = PROF1 PROF7
GROUPS = OMVSGRP
LAST USED = 25/03/00 13:26 CPU(CPU1) FAC(TSO ) COUNT(00645)
DFLTGRP = OMVSGRP
MYDEFINE = MYDATA
---------- SEGMENT CICS
OPIDENT = ABC
---------- SEGMENT OMVS
HOME = /
OMVSPGM = /bin/sh
UID = 0000009303
---------- SEGMENT TSO
TSOCOMMAND = LOGOFF
TSOLACCT = ACCT123
TSOLPROC = PROCSP
TSOLSIZE = 0000000
TSOOPT = NOMAIL,NONOTICES,NOOIDCARD
ACCESS = UPDATE
INSTDATA = THIS IS AN EXAMPLE OF INSTALLATION DATA
Defining users to RACF

The user ACIDs are defined to RACF as USERs by using the ADDUSER Command. The
default group is the division or department to which the user belonged in Broadcom Top
Secret. Also, as described in converting profile ACIDs, if there were any Broadcom Top
Secret profiles listed in the ACID, the user is connected to the equivalent functional group in
RACF by using the CONNECT command. The TSO, CICS, and OMVS segments are added
to the user ID as they are in Broadcom Top Secret. Therefore, to define the user that is listed
in Example 6-3 to RACF, enter the following commands:
ADDUSER $USER3 DFLTGRP(DEPT1) OWNER(DEPT1) NAME(‘AARON AARDVARK’) -
DATA(‘THIS IS AN EXAMPLE OF INSTALLATION DATA’) -
TSO(PROC(PROCSP) ACCTNUM(‘ACCT123’)COMMAND(LOGOFF)) -
CICS(OPIDENT(ABC)) -
OMVS(HOME(/) PROGRAM(‘/bin/sh’) UID(0000009303))
CONNECT $USER3 GROUP(PROF1)

Note: There are special considerations for OMVS segments that are covered in 6.5.1,
“z/OS UNIX considerations” on page 81.
Table 6-3 lists some of the Broadcom Top Secret ACID and resource rules that are
subparameters of the RACF ADDUSER command. The RACF default group can be either the
DEPT or DIV ACID:
Table 6-3 USER ACID parameter conversion

Broadcom Top Secret parameter ADDUSER subparameter
ACCESSORID = USER1 ADDUSER USER1
NAME = ARRON NAME(‘ARRON’)
INSTDATA = xxx DATA(xxx)
ATTRIBUTES = SUSPEND REVOKE
DEPT ACID = YYY DFLTGRP(YYY)
DFLTGRP = OMVSGRP DFLTGRP(OMVSGRP)
Segment OMVS OMVS(parameters)
Segment CICS CICS(parameters)
Segment TSO TSO(parameters)
6.2.6 Converting security administrator ACIDs

RACF privileges are not as granular as Broadcom Top Secret privileges. Conversely, the
Broadcom Top Secret privileges allow more granular control of authority, but have more
complex interactions and might require more administrative effort. This section discusses
the privileges that are typically important for user conversion.
Security administrators are defined as users in RACF. In addition, they are given the
SPECIAL attribute, which denotes them as having the special privileges and authority that is
typically associated with security administrators. The functions that the administrator is
required to perform determines any additional required parameters. For example, the
CLAUTH parameter is used if the user has authority over selected user IDs.
Listing security administrator ACIDs

Example 6-4 shows how to list system, zone, division, and department security
administrators, with examples of the output:
Example 6-4 List system, zone, division, and department security administrators with output
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(SCA)
Output:
ACCESSORID = SCA1 NAME = MASTER SECURITY
TYPE = CENTRAL FACILITY = BATCH,STC,TSO
CREATED = 04/20/92 LAST MOD = 04/20/21
PROFILES = PROF1
ATTRIBUTES = CONSOLE
BYPASSING = NODSNCHK,NOVOLCHK

ACCESS = UPDATE
---------- ADMINISTRATIVE AUTHORITIES
RESOURCE = INFO
LIST DATA = *ALL*,PROFILES
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(VCA)
Output:
ACCESSORID = VCA1 NAME = DIV SEC ADMIN
TYPE = DIV C/A FACILITY = BATCH,STC,TSO
CREATED = 04/20/92 LAST MOD = 04/20/21
PROFILES = PROF1
ATTRIBUTES = CONSOLE
ACCESS = ALL
FACILITIES = *ALL*
MISC1 = SUSPEND
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(DCA)
Output:
ACCESSORID = DCA1 NAME = DEPT SEC ADMIN
TYPE = CENTRAL FACILITY = BATCH
DEPT ACID = DEPT1 DIVISION = DEPARTMENT ONE
CREATED = 04/20/92 LAST MOD = 04/20/21 PROFILES = PROF1
ACCESS = ALL
ACID = *ALL*
ACCESS = NONE
Defining security administrators to RACF

The ACIDs shown in Example 6-4 on page 63 are defined to RACF as USERs. The SPECIAL
attribute is used in RACF to distinguish users who perform security administrator functions.
The SCA converts to system SPECIAL, which allows FULL administration of the RACF
database. ZCA, LSCA, VCA, and DCA users are assigned restricted privilege and are given a
GROUP-SPECIAL attribute in RACF. Users who have the GROUP-SPECIAL attribute are
restricted to only the RACF profiles that are within the scope of their groups.
There is a slight distinction between the way you add a user with the system SPECIAL
attribute and the way you add a user with the GROUP-SPECIAL attribute. In Example 6-5,
SCA1 is a user with system SPECIAL authority, and VCA1 and DCA1 are users with
GROUP-SPECIAL authority.
Example 6-5 Adding a user with the system SPECIAL attribute

ADDUSER SCA1 DFLTGRP(SYS1) SPECIAL
ADDUSER VCA1 DFLTGRP(DIV1) CLAUTH(USER)
CONNECT VCA1 GROUP(DIV1) SPECIAL
ADDUSER DCA1 DFLTGRP(DEPT1)
CONNECT DCA1 GROUP(DEPT1) SPECIAL

Security administrators perform the same basic functions in both products. However, the way
each product defines those functions, in terms of resource rules and privileges, is different.
Do not attempt to map the attributes that are associated with the Broadcom Top Secret
security administrators on a one-to-one basis to RACF. Instead, understand what privileges
you can assign to RACF security administrators and what RACF commands are available to
do that. For more information, see z/OS Security Server (RACF) Security Administrator’s
Guide, SA23-2289. Section 6.2.7, “Password” on page 65 lists some of the RACF translations
for the Broadcom Top Secret privileges that can be reviewed.
6.2.7 Password
For conversion purposes, decide whether you want to keep the same password across the
conversion or if you want to change passwords for all the users. Usually, keeping the
password as a non-expired password is the preferred option.
Broadcom Top Secret user passwords are stored in the Broadcom Top Secret database.
You must set a temporary password in RACF for all users. Retrieve the Broadcom Top
Secret passwords by using the Broadcom Top Secret TSSINSTX exit. Modify this exit so
that the passwords can be retrieved for each user on the system.
Defining passwords to RACF

Some of the users in Broadcom Top Secret might not have a password. As of RACF 2.4,
users with no password can be set as protected user IDs by using the following command:
ADDUSER userid DFLTGRP(group) ... NOOIDCARD NOPASSWORD
Define a password for ALL users. By default, the password is the same as the default group
name. If this is unacceptable, issue an ALTUSER PASSWORD command similar to the one
shown in the following example to provide a password of your choice:
ALU USER1 PASSWORD(PASSW1) NOEXPIRE
For each user with a password, you can issue the ALTUSER PASSWORD NOEXPIRE
command from a Systems Level SPECIAL user ID to set the password and have it not expire.
Defining password interval

Some users are not required to change their password and some might be required to
change their password on a frequency different than the system default. You can determine
the password interval for each user from a listing of the users. Use the PASSWORD
INTERVAL command to set the interval for each user. The following examples show how to
set an interval of 30 days for a specific user and how to set a user so that they are not
required to change their password:
PASSWORD USER5 NOINTERVAL
PASSWORD USER3 INTERVAL(30)
Password intervals must be set equal to or less than the system default interval defined in the
Systems Options (SETROPTS).
6.2.8 Other Broadcom Top Secret user ACID parameters

The previous conversion methodologies for fields within the Broadcom Top Secret user ACID
are some of the major methodologies to consider for each of the fields in use in the Broadcom
Top Secret database. Additional information that is needed from the user ACID records will

need a conversion methodology that is designed to convert those fields and user-defined
fields to RACF when applicable.
Statistics and history

The statistics and history of a user’s access to the system is recorded in the RACF database
as the user begins using the system. The Statistical and History Information from the
Broadcom Top Secret database is not usually carried into the new database. If you want the
information in the database, write code to propagate it because there is no command to set
statistics. Alternatively, you can record the information in the copy of the database or flatfile of
the database that you keep to provide historical data.
User attributes
The user attributes are converted to similar attributes in RACF.
򐂰 AUDIT. Both products can AUDIT users of the system and both are called AUDIT. RACF
also has options for levels of Auditing in the Systems Options, such as SAUDIT,
OPERAUDIT, and LOGOPTIONS.
򐂰 SUSPEND/ASUSPEND. Both the SUSPEND and ASUSPEND users can be converted as
REVOKED users in RACF. To continue ASUSPEND Function, several design
considerations are required.
򐂰 BYPASSING. Broadcom Top Secret allows bypassing of security checking at granular
levels such as NOVOLCHK, NODSNCHK, NORESCHK and NOLCFCHK. z/OS allows
bypassing by use of the Program Property Table (PPT) and RACF allows bypassing for
some users, such as started task TRUSTED function. Otherwise, access will be checked
for resources.
6.3 Converting data sets

The way Broadcom Top Secret protects data sets and all other resources is sometimes
referred to as protection based on the user. What this means is that, when deciding whether a
user can access a certain data set, Broadcom Top Secret starts with the user ACID, and then
checks for the appropriate XA DATASET rule.
The way RACF protects data sets (and all other resources) is sometimes referred to as
protection based On the resource. This means that, when deciding whether a user can access
a certain data set, RACF starts with the data set profile, and then checks the access list of
that profile for an appropriate user ID or group.
This difference can create an issue when trying to convert Broadcom Top Secret data set
protection and other resources to RACF. The following discussion illustrates the problem.
6.3.1 User-based versus resource-based protection

In Broadcom Top Secret, authorization to access data sets is given to each user by checking
through the XA DATASET rules that are assigned specifically to that user or in PROFILES
defined to the user. For simplicity, the following discussion assumes that data sets are given
at the user Level.

Consider three Broadcom Top Secret users who have the following XA DATASET rules
assigned to them, and what would happen if each of them tried to access SYS1.LINKLIB:
򐂰 USER 1 is assigned:
XA DATASET = SYS1.
ACCESS = UPDATE
XA DATASET = SYS1.LINK
ACCESS = UPDATE
XA DATASET = SYS1.LINKLIB
ACCESS = READ
In Broadcom Top Secret, all three users have READ access to SYS1.LINKLIB. USER1 and
USER2 have UPDATE access to SYS1.LINKLIB. The fact that USER3 has an XA DATASET
rule that more closely matches the data set (SYS1.LINKLIB) being accessed has no bearing
on whether USER1 and USER2 can access SYS1.LINKLIB. This is because when Broadcom
Top Secret determines whether a user should be given access to a particular data set, it looks
only at the XA DATASET rules that are associated with that particular user. Also, different XA
DATASET rules can be used to access the same data set.
To convert the preceding rules to RACF on a 1-to-1 basis, use the following RACF
commands:
ADDSD 'SYS1.**'
PERMIT 'SYS1.**' ID(USER1) ACCESS(UPDATE)
ADDSD 'SYS1.LINK*.**'
PERMIT 'SYS1.LINK*.**' ID(USER2) ACCESS(UPDATE)
ADDSD 'SYS1.LINKLIB*.**'
PERMIT 'SYS1.LINKLIB*.**' ID(USER3) ACCESS(READ)
To match the Broadcom Top Secret protection, put USER1 on the access list of all other
profiles that start with SYS1. Also, put USER2 on the access list of all other profiles that start
with SYS1.LINK. To do that, use the following additional PERMIT commands:
PERMIT 'SYS1.LINK*.**' ID(USER1) ACCESS(UPDATE)
PERMIT 'SYS1.LINKLIB*.**' ID(USER1) ACCESS(UPDATE)
PERMIT 'SYS1.LINKLIB*.**' ID(USER2) ACCESS(UPDATE)
After the commands are issued, USER1 can access any data set starting with SYS1.
because they are on the access list of all the data set profiles that start with SYS1. Similarly,
USER2 can now access any data set starting with SYS1.LINK because they are on the
access list of both profiles that start with SYS1.LINK.
The process of allowing users access to the correct resources by putting all users on the
access list is called undercutting and is similar to the undercutting philosophy used in
Broadcom Top Secret.
6.3.2 Data set conversion overview

This section describes how to convert a simple Broadcom Top Secret resource rule to the
commands necessary to create the corresponding RACF protection.

XA DATASET rule
In Broadcom Top Secret, the data sets a user can access are determined by checking the XA
DATASET rules related to that user. These rules are found in the individual user ACID, any
profile ACIDs the user has access to, and the ALL record. In Example 6-6, USER1 has three
XA DATASET rules in their user ACID:
Example 6-6 XA DATASET rules for User1

ACCESSORID = USER1 NAME = AARON AARDVARK
TYPE = USER FACILITY = CICSPROD
PROFILES = CICSPRF1 TSOPRF1
.
.
.
XA DATASET = CICS.USER OWNER(CICSDIV )
ACCESS = UPDATE,CONTROL
XA DATASET = SYS1. OWNER(SYS1 )
ACCESS = READ
XA DATASET = SYS1.PROCLIB OWNER(SYS1 )
ACCESS = UPDATE
When USER1 attempts to access a data set, the DSNAME of that data set is compared to XA
DATASET rules in the user ACID. If all the characters in the XA DATASET rule match the start
of the DSNAME in the exact order, then that rule is used to determine what access Level
USER1 has to the data set. If more than one XA DATASET rule could apply to the same data
set, then the rule with the largest number of matching characters is the one chosen. If no
rules apply in the user ACID, then Broadcom Top Secret checks for XA DATASET rules in any
profiles the user is associated with, which is usually in the profile order listed in the user ACID.
According to the previously stated rules, USER1 can access any of the following data sets:
򐂰 Data sets starting with CICS.USER, with either UPDATE or CONTROL Authority
򐂰 Data sets beginning with SYS1., with READ Authority
򐂰 Data sets beginning with SYS1.PROCLIB, with UPDATE Authority
Note that in the previous example, both the second and third rule could apply when USER1
accesses SYS1.PROCLIB. The third rule is used because it has a larger number of matching
characters.
6.3.3 Defining data set protection in RACF

In RACF, to allow USER1 access to the same data sets as in the previous example, first
define data set profiles to protect the data sets in question. The ADDSD command is used to
create these data set profiles. Typical ADDSD commands look like this:
ADDSD 'CICS.USER*.**' OWNER(CICSDIV) UACC(NONE) GENERIC
ADDSD 'SYS1.**' OWNER(SYS1 ) UACC(NONE) GENERIC
ADDSD 'SYS1.PROCLIB*.**' OWNER(SYS1 ) UACC(NONE) GENERIC
Issue PERMIT commands to add USER1 to the access list of the profiles protecting those
data sets. In addition, you must specify the access authority (READ, UPDATE) so that it
matches what USER1 had in Broadcom Top Secret, as follows:
PERMIT 'CICS.USER*.**' ID(USER1) ACCESS(CONTROL)
PERMIT 'SYS1.**' ID(USER1) ACCESS(READ)
PERMIT 'SYS1.PROCLIB*.**' ID(USER1) ACCESS(UPDATE)

Note: The use of the generic characters such as ** or *.** at the end of each profile is
needed to make the data sets covered by the RACF data set profile consistent with what
the XA DATASET rule allowed access to. For consistency, in this book, these same generic
characters are used whenever a RACF profile is created. For further information on the use
of generic characters, refer to the z/OS Security Server RACF Security Administrator's
Guide, SA23-2289.
6.3.4 Data control groups and the RACF high-level qualifier

RACF expects the high-level qualifier of every data set to be defined as a user ID or group
before it allows any data set profiles to be created that use that high-level qualifier. For data
sets that do not belong to a defined user, a RACF group must be defined before the data set
can be protected. RACF refers to these groups as data control groups. If, for example, the
high-level qualifier of CICS is not defined as a group before running the ADDSD
'CICS.USER*.**' command shown previously, then that ADDSD command would fail. To
correct the problem, the following command is run first:
ADDGROUP (CICS) SUPGROUP(CICSDEPT) OWNER(CICSDEPT)
RACF also requires the high-level qualifier for every data set to be fully qualified. Where you
have defined Broadcom Top Secret data set rules with generic characters or without a trailing
period, convert the rule to fully qualified rules for the actual data sets they are intended to
cover. Table 6-4 provides two examples of possible data sets in Broadcom Top Secret and
how they are converted as RACF rules. The period in the first rule limits the RACF rules to
any three alphanumeric characters preceded by ABC. The second rule restricts the first six
characters to XYZ111 but can have any number of alphanumeric characters after the first six.
Table 6-4 Broadcom Top Secret data sets converted to RACF rules
Broadcom Top Secret rule Matching RACF fully qualified rule
ABC+++.a ABCAAA
ABCBBB
ABC123
XYZ111b XYZ111
XYZ1112
XYZ11123
a. Generic characters, +++, if data sets exist
b. No period at the end
The exception to generics in the high-level qualifier is the Broadcom Top Secret rule in the
ACID to indicate the user has ALL access to their own data. This is the default in RACF, so a
rule is not needed.
XA DATASET = %.
ACCESS = ALL
If the access is not ALL, exits must be written to restrict user access to their own data.
6.3.5 Data set access

Broadcom Top Secret allows access to resources in several ways:
򐂰 Owning the data set
򐂰 Giving explicit access by XA DATASET rules in USER or PROFILE ACIDs

򐂰 Giving general access by XA DATASET in the ALL record
Standard access
The access Level a user has to a data set in Broadcom Top Secret, such as READ or
UPDATE, is determined by checking the ACCESS subparameter that immediately follows the
XA DATASET rule. The RACF equivalent to this is the ACCESS subparameter of the PERMIT
command. A suggested mapping chart to use when converting access authority in Broadcom
Top Secret to RACF is shown in Table 6-5. The list is arranged in order from highest to lowest
access authority. Throughout this book, the terms access and access authority often mean the
same thing.
Table 6-5 access level conversion

Broadcom Top RACF
Secret
ALL ALTER
ALTER ALTER
SCRATCH ALTER
CREATE ALTER
CONTROL CONTROL
WRITE UPDATE
UPDATE UPDATE
READ READ
FETCH EXECUTE
NONE NONE
In Broadcom Top Secret, if more than one value is listed in the ACCESS subparameter, then
when converting to RACF, choose the value that is the highest among all the values listed for
that data set in Broadcom Top Secret. In the example in 6.3.2, “Data set conversion overview”
on page 67, USER1 had both UPDATE and CONTROL access authority in Broadcom Top
Secret. When converting to RACF, the CONTROL value was chosen because it was the
higher of the two values.
Ownership access
You must add the owner of the data set to the access list with ALTER access if the data set is
owned by an individual. In the following example, USER1 will need to be on the access list for
any data set beginning with the high-level qualifier of DEPART1.
ACCESSORID = USER1 NAME = AARON AARDVARK
TYPE = DCA SIZE = 512 BYTES
CREATED = 03/25/98 LAST MOD = 07/01/2116:42
DATASET = DEPART1.
ACCESS = READ
Universal access
The Universal access (UACC) for a data set is equivalent to the resources in the Broadcom
Top Secret ALL record. Generally, the UACC should be NONE and the special access of ID(*)

added with the general access. For conversion, list the ALL record and give the access in the
record to each resource definition in RACF.
6.3.6 Undercutting considerations

The standard Broadcom Top Secret undercutting of the most specific rule applies in the
conversion. Depending on the TSSPARM authorization setting, the considerations differ.
Because RACF uses only the most specific rule defined in the database for any given data
set, any user who can access the data set from their user ACID or any permitted profile ACID
must be on the RACF access list. The following are examples of the undercutting issue in the
authorization scenarios.
AUTH(OVERRIDE,ALLOVER)
This is the most common setting and the default. Consider the following example:.
PROF1 PROF2
XA DATASET = SYS1.LINK XA DATASET = SYS1.LINKLIB
ACCESS = READ ACCESS = UPDATE
USER1
USER2
In Broadcom Top Secret, USER1 has READ access to SYS1.LINKLIB because PROF1 is
first in the list of profiles. USER2 has UPDATE access to SYS1.LINKLIB because PROF2 is
first in the list of profiles.
In RACF, when the resources from the profiles are converted, they have both USER1 and
USER2 connected to group PROF1 and group PROF2. The following access lists are the
result after the correction for the undercutting process discussed previously:
SYS1.LINK*.** SYS1.LINKLIB.**
PROF1/READ PROF1/READ
PROF2/UPDATE
USER 2 has the same access in both Broadcom Top Secret and RACF. USER1 would be
incorrect because they have UPDATE and previously had READ access. The authorization
flow for RACF shown in Figure 3-2 on page 25 shows that any user on an access list is used
before any functional groups (profiles). Therefore, to resolve that access issue, USER1 is put
on the access list as an individual user. Note that not only USER1 is on the access list
individually, but also add ALL users with PROF1 in this order.
For conversion, any data sets with similar or partial names must be reviewed to determine
that they are not in PROFILE lists for users so that the preceding problem is not created. If
such a situation exists, it should be corrected on the Broadcom Top Secret database, or each
affected user must be put in the access list for all the affected resources in the PROFILEs.

AUTH(MERGE,ALLOVER)
Using the following example, in Broadcom Top Secret both USER1 and USER2 has READ
access to SYS1.LINKLIB since it is the longest name that matches the requested resource in
any of the lists of PROFILES for the user.
PROF1 PROF2
XA DATASET = SYS1. XA DATASET = SYS1.LINKLIB
ACCESS = UPDATE ACCESS = READ
USER1
In Broadcom Top Secret, USER1 has READ access to SYS1.LINKLIB because the access is
found by using the longest matching name in all the Merged PROFILEs.
In RACF, when the resources from the profiles are converted, they have USER1 Connected to
group PROF1 and group PROF2. The following access lists are the result after the correction
for the undercutting process discussed previously:
SYS1.LINK*.** SYS1.LINKLIB.**
PROF1/UPDATE PROF1/UPDATE
PROF2/READ
USER1 is incorrect because they now have UPDATE and previously had READ access. The
authorization flow for RACF shown in Figure 3-2 on page 25 shows that any user on an
access list is used before any functional groups (profiles). Therefore, to resolve that access
issue, USER1 must put on the access list as an individual user. Note that not only USER1 is
on the access list individually. All users with PROF2 must be added.
To convert, any data sets with similar or partial names must be reviewed to ensure that they
are not in PROFILE Lists that can cause the problem described previously. If such a situation
exists, correct it on the Broadcom Top Secret database, or each affected user must be put in
the access list for all the affected resources in the PROFILEs.
AUTH(MERGE,ALLMERGE)
This option is closest to the RACF philosophy. However, this authorization is like the
AUTH(MERGE,ALLOVER) except that the ALL record must be considered in the merge
process.
6.3.7 Other Broadcom Top Secret to RACF data set migration Issues
This section details data set migration issues not covered previously.
ALL record
Sometimes in Broadcom Top Secret a user tries to access a data set, and there is no
appropriate XA DATASET rule in either the user ACID or any of the PROFILE ACIDs. The ALL
record is used by Broadcom Top Secret for those situations. This record is a list of resource
rules for data set and others that is similar to a profile, except it is almost always the last place
Broadcom Top Secret looks for a resource rule to check against. If an appropriate rule cannot
be found in the ALL record, then access to the resource depends on the overall security mode
that Broadcom Top Secret is in (WARN, IMPLEMENT, and so on). The functions of the ALL
record in Broadcom Top Secret are handled by the UACC (Universal Access Authority) in
RACF. The UACCs are not stored in one central RACF list, but are defined separately (default
access=NONE) for each RACF profile.

ACTION
In Broadcom Top Secret, the WARN Mode is used so that a user can access a data set at a
higher level than the XA DATASET rule normally allows but produces a message for audit
purposes each time this happens. For any one data set, you can selectively allow some users
to be in WARN Mode and others in FAIL Mode by use of the ACTION subparameter. For
example:
ACCESSORID = USER1
XA DATASET = SYS1.LINKLIB OWNER(TECHDIV )
ACCESS = READ
ACTION = WARN
In RACF, the ADDSD WARNING subparameter is also used for putting a data set in WARN
mode, but it applies to all accesses to that data set by everyone, and cannot be given
selectively to only certain users. By default, RACF rules are in FAIL or DENY equivalent
mode.
FAC
Any XA DATASET rules with the FAC must be evaluated for the access you want the user to
have in all conditions. Access to data sets is provided to the list of users regardless of the
application that they are using:
ACCESS = READ
FAC = TSO
ACCESS = UPDATE
FAC = BATCH
PRIVPGM and LIBRARY

Both products can control access to data sets. Broadcom Top Secret controls access by
through program pathing, and RACF controls access through program access to data sets
(PADS)
Broadcom Top Secret controls access through the data set rule by using the LIBRARY and/
PRIVPGM parameters.
RACF uses the PROGRAM class to define the controlled programs and libraries. On the data
set 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 conditions must be met:

򐂰 The PROGRAM must be protected.
򐂰 The conditional access list must be defined.
򐂰 PADCHK or NOPADCHK must be specified.
An example of the Broadcom Top Secret access rule entry is provided in Example 6-7.
Example 6-7 Broadcom Top Secret access rule entry

ACCESSORID = PROF1
XA DATASET = SYS1.PAYROLL
ACCESS = UPDATE
LIBRARY = PROD.LOADLIB
PRIVPGM = PAYUPDT

The code in Example 6-7 on page 73 results in the following RACF commands:
1. Define the program PAYUPDT in library 'PROD.LOADLIB' to the PROGRAM Class (the
library must be in the LNKLIST concatenation):
RDEFINE PROGRAM PAYUPDT -
ADDMEM('PROD.LOADLIB'//NOPADCHK) UACC(READ)
2. Permit group PROF1 (or USER1) to ALTER access to data set 'SYS1.PAYROLL' when
running program PAYUPDT from library 'PROD.LOADLIB':
PERMIT 'SYS1.PAYROLL' ID(PROF1) -
ACCESS(ALTER) WHEN(PROGRAM(PAYUPDT))
UNTIL
In Broadcom Top Secret, use the UNTIL parameter to create an XA DATASET rule that
expires on a specified date. In Example 6-8, USER1 has access to the SYS1.LINKLIB data
set with ALL authority Until 12/04/22, at which time the access is revoked.
Example 6-8 Broadcom Top Secret UNTIL

ACCESSORID = USER1
XA DATASET = SYS1.LINKLIB UNTIL(12/04/22)
ACCESS = ALL
These parameters can be converted by implementing the RESUME and REVOKE

parameters of the RACF CONNECT command. By creating a holding group for the resource
being Protected, connect the groups matching the UID String to this holding group and
specify the RESUME and REVOKE parameters to cover the period indicated by the UNTIL
parameters.
Example 6-9 RACF conversion of Broadcom Top Secret UNTIL

ADDGROUP (EXPIRE1)
ADDSD 'SYS1.LINKLIB*.**'
PERMIT 'SYS1.LINKLIB*.**' ID(EXPIRE1) ACCESS(ALTER)
CONNECT USER1 GROUP(EXPIRE1) REVOKE(12/04/22)
In Example 6-9, USER1 is granted ALTER access to SYS1.LINKLIB because they are
connected to the group EXPIRE1. This connection to that group will be revoked on 12/04/22,
and with it, their access to SYS1.LINKLIB.
6.3.8 More data set considerations

Some general observations on converting data set rules are provided in the this section.
Discrete versus generic profiles

Broadcom Top Secret TSSPARM has a parameter for Automatic Data Set Protection (ADSP).
RACF has the same option in the systems options. In both cases, it indicates that a data set is
to have the protect bit set in the DSCB. In RACF, this is called a discrete data set profile.
Discrete means that it covers only this specific data set on this specific volume or unit
combination and the data set control block (DSCB) protect flag is set. When such a data set is
opened, RACF searches for a discrete profile. If no such profile is found, it looks for a generic
profile that can cover the request. To help administration, use generic profiles whenever
reasonable. When one generic profile can cover many data sets, this also improves system
performance. However, using too many fully-qualified generic profiles can hurt both
performance and administration.

Even if the data set has no generic characters and is fully qualified in Broadcom Top Secret,
that is, it has single quotation marks around the name, it should be generated as a RACF fully
qualified generic in most cases. To ensure that a data set is generic, include the word
GENERIC or the abbreviation G on the ADDSD command (Example 6-10 and
Example 6-11).
Example 6-10 Broadcom Top Secret generic data set

XA DATASET = ‘SYS1.LINKLIB’ OWNER(DEPT1)
ACCESS = READ
XA DATASET = SYS1.PARM OWNER(DEPT1)
ACCESS = READ
Example 6-11 RACF generic data set

ADDSD SYS1.LINKLIB OWNER(DEPT1) UACC(NONE) GENERIC
ADDSD SYS1.PARM*.** OWNER(DEPT1) UACC(NONE) G
Note: Broadcom Top Secret ignores the DSCB protect bit if it is set and if the TSSPARM
specifies ADSP(NO). RACF always checks the discrete profiles, DSCB bit on, first. If it is
possible that any data sets were created with the DSCB protect bit set, you should run the
TSSPROT utility to find and reset the bits before conversion to RACF.
Erase-on-scratch
Use erase-on-scratch (EOS) for confidential data to ensure that residual data cannot be
accessed after deletion. Residual data is a potential security exposure for confidential data. In
Broadcom Top Secret, EOS is done on a system level, based on the TSSPARM AUTOERASE
and MODE options. In RACF, it can be done on a data set level, so it can be very selective
and used without causing performance problems.
6.4 Converting resources

The term resource rules is used to indicate the definitions in Broadcom Top Secret that
describe what resources any particular ACID is allowed to access. Data set resources are
discussed in 6.3, “Converting data sets” on page 66. This section focuses on the other
resources. Table 6-6 shows the resource rules and their RACF equivalents.
Table 6-6 Resource rules and RACF equivalents

Resource rule Typical RACF equivalent
FACILITY CLASS(APPL)
XA OTRAN CLASS(TCICSTRN/GCICSTRN) or
user-defined CICS or IMS Class
XA VOLUME CLASS(FACILITY) $DASDI
XA ACID CLASS(SURROGAT)
XA TERMINAL CLASS(TERMINAL)
XA PROGRAM CLASS(PROGRAM)
XA IBMGROUP GROUP
XA user-defined CLASS(user-defined)

It is important to note that there are many alternatives for converting non-data set protection.
The following examples are suggestions of how you can convert your non-data set rules.
There can be more than one correct answer when choosing an algorithm to use to convert
each of the resource rules. However, determine the most accurate and appropriate
conversion algorithm for each resource rule by performing the following steps:
1. Thoroughly understand what that rule protects in the Broadcom Top Secret environment.
2. Determine how RACF accomplishes the same protection.
3. Determine what RACF command is used to create that protection.
You can then create the necessary algorithm to convert that particular resource rule.
6.4.1 FACILITIES
A FACILITY in Broadcom Top Secret usually becomes an application in RACF. The APPL
general resource class is used by RACF to provide this type of protection. There is not always
a 1-to-1 correspondence between facilities and applications. Having access to a FACILITY in
Broadcom Top Secret often allows you access to more than one application. Some
applications that are defined as a FACILITY in Broadcom Top Secret, such as BATCH and
TSO, are not protected by the APPL class in RACF unless there is a product or application
that requires it.
The following steps are a suggested conversion approach:

1. Identify what you defined as facilities in your Broadcom Top Secret environment.
2. Document what specific applications are covered by each facility.
3. Determine what the VTAM ACBs are of these applications.
4. Determine other applications that you might want to protect that might not be listed in your
Broadcom Top Secret database.
5. Create RDEF APPL commands to define the applications to RACF.
6. Create PERMIT commands to allow access to the applications.
As an example, the FACILITY statements in Example 6-12 can be converted to the RACF
statements in
Example 6-12 Broadcom Top Secret FACILITY statements

ACCESSORID = PROF1
FACILITY = BATCH doesn't convert to an APPL in RACF.
FACILITY = CICSPROD allows access to CICS1, CICS2, CICS3.
Example 6-13 Resultant RAFC statements

RDEF APPL CICS1 UACC(NONE)
PERMIT CICS1 CLASS(APPL) ID(PROF1) ACCESS(READ)

6.4.2 Volume
XA VOLUME (Example 6-14) is a powerful rule in Broadcom Top Secret. Broadcom Top
Secret checks these rules before XA DATASET rules. Depending on how these rules are
coded, some users might have access to data sets through the XA VOLUME rule but not have
access to the data set through the XA DATASET rule. XA VOLUME is another Broadcom Top
Secret rule that is set up for security to protect your DASD volumes. Although there is a RACF
facility rule that is available that can be used to determine who can allocate space on a
volume, this is an obsolete way of handling the conversion of this Broadcom Top Secret rule.
A better way is to migrate to the IBM Storage Management Subsystem or DFDSS product,
which can handle the administration of your DASD volumes and administer your data that is
put on those volumes. RACF does not have a facility that allows someone access to a data
set that to which they are not authorized because of some sort of override that is based on
the volume the data set is on. Protection of that type is better handled by DFSMS routines.
You can use the information from these XA VOLUME rules to create a very limited type of
volume protection in RACF. For example, the FACILITY class in RACF can be used to
determine who can allocate space on a volume when creating data sets (Example 6-15). An
appropriate IGGPRE00 exit must be installed as well.
Also, the DASDVOL class in RACF can be used to grant access to data sets by volume
instead of by checking data set profiles. However, access is granted only when the user is
performing a DASD maintenance function, such as backing up a pack. Access is not granted
if the user is trying to browse or update the file.
For volume protection of BLP, RACF has the FACILITY class of ICHBLP to provide the same
function.
Example 6-14 Broadcom Top Secret listing

USER1 - XA VOLUME = TAPE
ACCESS = BLP,UPDATE
Example 6-15 RACF commands

RDEF FACILITY ICHBLP.TAPE UACC(NONE)
PERMIT ICHBLP.TAPE* CLASS(FACILITY) ID(USER1) ACCESS(UPDATE)
USER1 can now use Bypass Label processing on volumes starting with TAPE
For volume protection of ALL or READ, a special action, possibly an exit, is required to
preserve the function.
6.4.3 The Online Transaction (OTRAN)

For translating, online transactions require special consideration and planning. Before you
create the new online security definitions, understand how RACF protection works with the
individual products, particularly with CICS, and what performance issues are involved when
defining your transactions to RACF.
For CICS, recommendations include the following actions:

򐂰 Define your transactions to RACF in a manner that minimizes defining the same
transaction to multiple RACF profiles.
򐂰 Only permit the transaction profiles to groups, and not to individual users.

򐂰 Connect users who must use the transactions to the appropriate groups.
Example 6-16 and Example 6-17 list the Broadcom Top Secret and equivalent RACF
commands.
Example 6-16 Broadcom Top Secret XA OTRAN statements

ACCESSORID = PROF1
DEPT ACID = DPT1
XA OTRAN = CEMT
XA OTRAN = DC01
XA OTRAN = DC02
ACCESSORID = PROF2
DEPT ACID = DPT2
XA OTRAN = DC01
XA OTRAN = DC02
Example 6-17 Equivalent RACF commands

RDEF TCICSTRN CEMT UACC(NONE)
RDEF TCICSTRN DC01 UACC(NONE)
RDEF TCICSTRN DC02 UACC(NONE)
PERMIT CEMT CLASS(TCICSTRN) ID(PROF1) ACCESS(READ)
PERMIT DC01 CLASS(TCICSTRN) ID(PROF1,PROF2) ACCESS(READ)
PERMIT DC02 CLASS(TCICSTRN) ID(PROF1,PROF2) ACCESS(READ)
6.4.4 Limited Command Facility (LCF) AUTH/EXMP

LCF AUTH for transactions are converted the same as described previously for the OTRAN. If
there is an OTRAN and an LCF AUTH for the transaction, the OTRAN is the one to be
converted.
LCF AUTH for other than transactions must be evaluated. Often the facility is a TSO
command, which, if needed, can be converted to program protection for the module that is
called for the TSO command. Other facilities probably require new resource classes or exits
to control.
LCF EXMP commands can add many users to the access list with ACCESS(NONE) due to
undercutting issues. As previously stated, each PROFILE is a RACF group on the access list,
and the common way to prevent the group access from being used is to put individuals on the
access list. This method works for transactions and program protection. Other methods might
be required for other protected facilities.
6.4.5 Db2
There are three areas in which control of Db2 resources can be protected. These controls can
be implemented in both Broadcom Top Secret and RACF:
1. Control of access to Db2 subsystems
2. Control of access to Db2 secondary authorization IDs
3. Control of access to Db2 objects by using external security
Access to Db2 subsystems

Controlling access to the Db2 subsystem from different environments such as TSO, BATCH,
CICS, or IMS, is accomplished by Db2 issuing a Security Access Facility (SAF) call to see

whether the user is allowed access to the subsystem by using a specific environment.
Because this Db2 control is using SAF, conversion from Broadcom Top Secret can be
straightforward.
Broadcom Top Secret includes the following entries:

ACCESSORID = USER1
XA Db2 = DSNR.DBPROD.BATCH
XA Db2 = DSNR.DBPROD.DIST
The following entries are the RACF conversion:

RDEF DSNR DBPROD.BATCH UACC(NONE) OWNER(... )
PERMIT DBPROD.BATCH -
CLASS(DSNR) ID(USER1) ACCESS(READ )
RDEF DSNR DBPROD.DIST UACC(NONE) OWNER(... )
PERMIT DBPROD.DIST -
CLASS(DSNR) ID(USER1) ACCESS(READ )
Secondary authorization
An IBMGROUP in Broadcom Top Secret converts to a group in RACF. Define each XA
IBMGROUP rule to RACF by using the ADDGROUP command. The subgroup of each
IBMGROUP is the owner that is listed next to each XA IBMGROUP rule. Connect the
users who have these resource rules in their ACIDs to the corresponding groups in RACF.
For example:
Broadcom Top Secret has the following entries:

ACCESSORID = USER1
XA IBMGROUP= Db2GRP OWNER(Db2)
The RACF conversion includes the following lines:

ADDGROUP Db2GRP SUPGROUP(Db2)
CONNECT USER1 Db2GRP
Note that DB2GRP might be both a profile ACID and an IBMGROUP. This is allowable in
Broadcom Top Secret. However, in RACF you can use DB2GRP as a group or a user but not
as both. For example, if the same name was used as a PROFILE ACID and an IBMGROUP,
two groups with the same name would be created, which is not allowed. The people on the
connect list might not need both the secondary group and the functional group. You might
have to rename some of the IBMGROUPs or some ACIDs as part of the conversion effort.
Controlling access to Db2 objects

A user can have access to Db2 objects, such as tables and plans. Db2 has it own access
control mechanism to control these objects, maintained through Db2 administration. Control
of these objects can also be implemented by using Db2 external security. Broadcom Top
Secret has a Broadcom Top Secret subsystem feature to accomplish this. RACF provides this
access control through the RACF/Db2 External Security Module (ESM).
Controlling access to Db2 objects using external security and its implementation is different in
Broadcom Top Secret and RACF. Some of the Db2 privileges in the Broadcom Top Secret
external security subsystem do not directly translate on a one-to-one basis. Conversion and
careful attention to this is needed to ensure these privileges get mapped to the correct RACF
classes.

6.4.6 Terminal
XA TERMINAL corresponds to the TERMINAL class in RACF.
The following example is a Broadcom Top Secret entry:

ACCESSORID = USER1
XA TERMINAL= A11
The RACF conversion includes the following entry:

RDEF TERMINAL A11 UACC(NONE) OWNER(owner)
PERMIT A11 CLASS(TERMINAL) ID(USER1) ACCESS(READ)
After the RACF command is entered, USER1 can access the system through terminal A11.
Terminal definitions in RACF are for TCP/IP or LU definitions. The following steps
describe how to define this for RACF:
1. Define the terminal ID (VTAM LU name or TCP/IP address) as a protected resource to
RACF in class TERMINAL.
2. Run the following command:.
RDEFINE TERMINAL profile-name UACC(NONE)
3. Permit each user that can log on from this terminal (terminal id) by using the following
command:
PERMIT profile-name CLASS(TERMINAL) ID(userid) ACCESS(READ)
6.4.7 Program
RACF uses the PROGRAM class to define controlled programs and libraries. On the data set
profile, the additional statement WHEN(PROGRAM(xxx)) results in a conditional access list,
which is used to restrict access only through this program.
Program protection includes the following requirements:

򐂰 The program must be defined to the PROGRAM class.
򐂰 In the PROGRAM class, both the library name and the program name are specified.
Optionally, the volume for the library can be specified.
򐂰 Any aliases of the program being defined must also be included in the PROGRAM class
profile.
򐂰 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 task’s PRB must be controlled in a class
PROGRAM.
– All programs that link to, load or call the program that opens the data set must be
controlled in class PROGRAM.
򐂰 PADCHK can be difficult to establish and maintain, so it is rarely used.
Define the program PAYUPDT in library 'PROD.LOADLIB' to the PROGRAM class as in the
following example:
RDEFINE PROGRAM PAYUPDT -
ADDMEM('PROD.LOADLIB'/volser/NOPADCHK) UACC(READ)

6.4.8 XA ACID
XA ACID corresponds to the SURROGAT class in RACF.
The following Broadcom Top Secret entry is converted:

ACCESSORID = USER1
XA ACID = USER2
The following commands are the RACF conversion:

RDEF SURROGAT USER2.SUBMIT UACC(NONE) OWNER(USER2)
PERMIT USER2.SUBMIT CLASS(SURROGAT) ID(USER1) ACCESS(READ)
After running the commands, USER1 can submit jobs with USER=USER2. Typically, XA
ACID rules convert in a straightforward manner.
6.4.9 User-defined resources

If you created your own resources, either for a purchased product or for an application, then
you might have changed the TSSPARM to use an existing, pre-defined facility. Also, you might
have modified the Resource Descriptor Table (RDT) to create your own resource name.
RACF has an equivalent function, which is the class Descriptor Table (CDT). The CDT
contains the names of all known resources classes for RACF. To use your defined resources
or those defined to Broadcom Top Secret that are not in the CDT, you must add them to the
user portion of the CDT. The access to these resources can be converted using the same
methodology as other resources. For example:
The following example shows the Broadcom Top Secret commands:

ACCESSORID = USER1
XA MYDEFINE = MYDATA
ACCESS = READ
Use the RACF equivalent commands:

RDEF MYDEFINE MYDATA UACC(NONE) OWNER(DEPT1)
PERMIT MYDATA CLASS(MYDEFINE) ID(USER1) ACCESS(READ)
6.5 Other considerations

This section discusses considerations for other resources not previously covered, such as
Unix System Services (USS).
6.5.1 z/OS UNIX considerations

The UNIX group or the RACF group that contains the group ID or GID must be the current
connect group for the GID to take effect. With LIST of GROUPS CHECKING, most users do
not change their group when they log on. Therefore, for conversions, change the default
group of the users with OMVS segments to the DFLTGRP specified in the USER ACID and
connect the user to the appropriate department (Example 6-18 on page 82).

Example 6-18 Changing default groups
ACCESSORID = $USER3 NAME = AARON AARDVARK
TYPE = USER SIZE = 768 BYTES
CREATED = 11/11/99 LAST MOD = 24/03/21 12:34
GROUPS = OMVSGRP
DFLTGRP = OMVSGRP
MYDEFINE = MYDATA
---------- SEGMENT OMVS
HOME = /
OMVSPGM = /bin/sh
UID = 0000009303
Because the DEPT ACID group in the Broadcom Top Secret is DEPT1, the RACF conversion
typically starts with the following entry:
ADDUSER $USER3 DFLTGRP(DEPT1) OMVS(...
To instead assign the OMVSGRP as the default, use the following command:
ADDUSER $USER3 DFLTGRP(OMVSGRP) OWNER(OVMSGRP) OMVS(...
CO $USER3 GROUP(DEPT1) OWNER(DEPT1)
If the user is created by an automated process with all users, then the following command can
change the default group:
CO $USER3 GROUP(OMVSGRP) OWNER(OMVSGRP)
ALTUSER $USER3 DFLTGRP(OVMSGRP)
6.5.2 Started tasks (STC)

This section describes the conversion of started task authorization.
To retrieve the currently defined procedures and users that are associated with them, you can
use the Broadcom Top Secret command TSS LIST(STC). The output is listed in
Example 6-19
Example 6-19 Output of TSS LIST(STC) command

ACCESSORID = *STC* NAME = STARTED-TASKS
SIZE = 2816 BYTES
CREATED = 04/03/00 LAST MOD = 07/20/21 15:43
STC = *DEF* ACID = *BYPASS*
STC = APPC ACID = APPCTP
STC = ASCH ACID = APPCSCH
STC = ASCHINIT ACID = APPCINT
STC = BPXAS ACID = OMVS
STC = BPXOINIT ACID = OMVS
STC = CICSTEST ACID = CICSTST
STC = CICSPRDA ACID = CICSPRA
STC = CICSPRDB ACID = CICSPRB
STC = CICSPRDC ACID = CICSPRB
STC = DSNDBM1 ACID = Db2DBM1
STC = DSNMSTR ACID = Db2MSTR

STC = OMVS ACID = OMVS
STC = RMFGAT ACID = RMFGAT
STC = SPECIAL ACID = *BYPASS*
STC = TCPIP ACID = TCPIP
STC = VTAM ACID = NET
Note that there are some PROCs that use the same user ID as another PROC, and there are
some that are unique to the PROC. This is the same as in RACF. There might be more started
tasks required in RACF than are defined in Broadcom Top Secret because RACF is started
sooner in the IPL process than Broadcom Top Secret so that it can protect more system
functions.
RACF has two methods to support started tasks: Started Class and Started Table. The
recommended method is the started class. In both cases, RACF uses a class or table to
associate a user ID and group name with a started procedure. Normal access checking is
performed for all started procedures using the associated RACF user ID and group name
defined. It is important to have the user and group definitions match in the class or table. If
they do not, the entry is not used and the default or undefined user is used for the started
task.
You can indicate that selected started procedures are considered as TRUSTED similar to the
BYPASS option in Broadcom Top Secret. TRUSTED allows access to data sets without the
user being on the access List.
The class or table might include a generic entry similar to the *DEF* entry STC = *DEF* ACID
= *BYPASS* in Example 6-19 on page 82.
The generic entry applies to all started tasks not defined in the class or table. The following
example lists sample class entries:
RDEF STARTED CICSPRDA.* OWNER(xxxx)
STDATA(USER(CICSPRDA) GROUP(STCGROUP) TRUSTED(NO)
RDEF STARTED *.* OWNER(xxxx)
STDATA(USER(=MEMBER) GROUP(STCGROUP) TRUSTED(YES)
The following example lists sample STC Table entries:

DC CL8'CICSPRDA' STARTED PROC NAME
DC CL8'CICSPRDA' ASSIGNED USER
DC CL8'STCGROUP' ASSIGNED GROUP
DC XL8'0000000000000000' ATTRIBUTES
DC CL8'* ' STARTED PROC NAME
DC CL8'= ' ASSIGNED USER
DC CL8'STCGROUP' ASSIGNED GROUP
DC XL8'0400000000000000' ATTRIBUTES
For more information, see z/OS RACF System Programmer’s Guide, SA23-2287.
6.6 Converting system-wide options

This section describes some of the system-wide security options for both Broadcom Top
Secret and RACF. These options determine how the security product is protecting your
system. A table is included to show the most direct mapping of some of the Broadcom Top
Secret global system options to RACF’s system-wide options.

6.6.1 Common system-wide security options
Table 6-7 contains the system-wide options common to both Broadcom Top Secret and
RACF.
Table 6-7 System-wide options common to Broadcom Top Secret and RACF
Broadcom Top Secret RACF
ADSP ADSP/NOADSPa
AUTH(xxx,yyy) GRPLIST
AUTOERASE(NO) ERASE/NOERASE
MODE(...) PROTECTALL(...)/NOPROTECTALL
HPBPW(n) JES(EARLYVERIFY)) - required default
INACTIVE(nn) INACTIVE(nn)
NEWPW PASSWORD(...)b
PWEXP(nn) PASSWORD(INTERVAL(nn))
TAPE TAPEDSN/NOTAPEDSN
TEMPDS(NO) TEMPDS
a. Be sure to review “Discrete versus generic profiles” on page 74.
b. See PASSWORD options in Appendix B.4.1, “Passwords” on page 101.
6.6.2 The Command Propagation Facility (CPF)

The Command Propagation Facility (CPF) includes several statements in the TSSPARM such
as CPFNODES, CPFRCVUND, CPFTARGET, and CPFWAIT. RACF can also propagate
changes across systems by using the RACF Remote Sharing Facility (RRSF).
6.6.3 Protection modes

Both products can be set to enforce default data set protection, that is, denial of access to
data sets not covered by a Broadcom Top Secret definition or a RACF profile. When no
Broadcom Top Secret rule is found for a data set, the TSSPARM MODE option decides what
happens. If MODE is set to FAIL, the data set must have a matching rule set, otherwise
access is denied. If the global RACF option PROTECTALL(FAILURES) is set, RACF requires
a matching profile for all accessed data sets. Without a profile match, access is denied, so
Broadcom Top Secret’s MODE=FAIL and RACF’s PROTECTALL(FAILURES) both require all
data sets to be protected.
Passwords
Many of the password rules can be converted. Listed are some of the RACF options. The
PASSWORD parameter of Systems Options specifies the monitoring and checking of
passwords by indicating the following sub-operands.
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 one to eight 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, such as the
password cannot be equal to the user ID.
6.6.4 RACF options

This section describes some additional RACF options that are highly recommended when
defining system-wide protection for your installation. The SETROPTS LIST command returns
a list of all the current RACF options.
You can also specify the following RACF SETROPTS parameters:

򐂰 NOADDCREATOR
Specifies that if a user defines any new data set or general resource profile, RACF does
not place the profile creator's user ID on the profile's access.
򐂰 EGN
Activates enhanced generic naming (EGN). Use this option to specify the generic
character ** (in addition to the generic characters asterisks(*) and percent(%)).
򐂰 GENCMD(*)
Activates generic profile command processing for all classes and needs to be reissued
each time that a new class is added.
򐂰 GENERIC(*)
Activates generic profile checking for all classes except grouping classes and needs to be
reissued each time that a new class is added.
򐂰 GRPLIST
Specifies that authorization check processing is to perform list-of-groups access checking
for all system users. When you specify GRPLIST, a user's authority to access or define a
resource is not based only on the authority of the user's current-connect group. Access is
based on the authority of any group of which the user is a member.
򐂰 JES(BATCHALLRACF)
Specifies that JES is to test for the presence of a user ID and password on the job
statement or for propagated RACF identification information for all batch jobs. If the test
fails, JES is to fail the job.
򐂰 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. NOPROTECTALL specifies that a user can create or
access a data set that is not protected by a profile.
The following operands are used with PROTECTALL:
– 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. This option
should be used during initial conversion testing to assist in setting up data set security
protection.
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. Note that default protection of General resources can be controlled by
“catch-all” profiles, such as a profile definition of ‘*’ with UACC=NONE.
For more detailed information about RACF’s system-wide options, see z/OS Security Server
RACF Command Language Reference, SA23-2287.

7
Chapter 7. 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 z/OS users see only the
effects of the security system, and seldom issue commands directly to it. However, security
administrators frequently issue commands to the security subsystem, and the structure and
convenience of this process is important to them.

7.1 The administrative interface
RACF administration consists of several different categories of tasks:
1. Routine, day-to-day functions, such as adding users, resetting passwords, and adding
resource protection profiles.
2. Higher-level administration, such as adding new SPECIAL, GROUP SPECIAL, Users, and
setting AUDIT controls.
3. Setting global RACF controls.
4. Maintaining the database, in the sense of purging unwanted entries, detecting unwanted
situations, and monitoring the correctness of the security policy reflected by the database.
5. Monitoring the audit records written by RACF.
6. Maintaining the database with tasks such as performing backups, reorganizing, and
monitoring performance.
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 in the following sections.
There are many ways to address the fourth task, database quality maintenance. The use of
the RACF SEARCH command or the IRRRID00 utility is a starting point and might be all that
is required. In more demanding cases, you might need to write or obtain an application to
address this area.
The fifth task, monitoring audit records, involves listing selected SMF records. The RACF
report writer, which is no longer actively maintained by IBM, can be a starting point. There are
many SMF reporting programs including the SMF unload utility that is part of RACF, which
can be used with Db2 or DFSORT’s ICETOOL.
The sixth task, physical care of the database, involves several utilities that are supplied with
RACF and also involves normal z/OS tuning activities.
7.2 Commands
Broadcom Top Secret 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.
For more information about RACF commands and syntax, see z/OS Security Server RACF
Command Language Reference, SA23-2292.
RACF commands can be entered in several ways:

򐂰 TSO command line
򐂰 ISPF panels, which are provided with RACF
򐂰 Batch jobs, which issue the same commands as under TSO
򐂰 Application programs or third-party products that issue RACF commands
򐂰 z/OS operator consoles
Most commonly, TSO line commands and the ISPF panels are used for day-to-day
administration and batch jobs are useful for bulk updates.
RACF commands that are issued from a z/OS operator’s console are useful in critical
situations but are not intended for routine administration. The operator must perform a logon
function with password authentication before entering RACF commands.

Note: An exception exists for the operator command that switches to the backup RACF
database. An operator logon is not needed to issue this command.
Both products have many commands, and many of these are used by only the security
administrator or systems programmers. Only a small part of each command set is used daily
by other administrators, help desk personnel, and end users.
RACF has four general types of database entities (profiles): User, Group, Dataset, and
General Resources. Each of these types has associated commands to add, modify, delete,
and list profiles. Table 7-1 lists the basic commands for these operations. The table shows, for
example, that the ALTGROUP command is used to alter a group profile.
Table 7-1 RACF commands to add, modify, delete, and list resources
User Group Dataset General
resource
Add ADDUSER ADDGROUP ADDSD RDEFINE
Modify ALTUSER ALTGROUP ALTDSD RALTER
Delete DELUSER DELGROUP DELDSD RDELETE
List LISTUSER LISTGRP LISTDSD RLIST
This table is not intended to convey any of the ramifications of the indicated functions. More
detailed information on the functionality of the RACF commands can be found in Chapter 3,
“IBM z/OS Security Server RACF overview” on page 21. For complete definitions and the
syntax of the commands, see z/OS security Server RACF Command Language Reference,
SA23-2292-30.
The various privilege levels of RACF commands are described in detail in previous chapters.
The following list is a brief summary about the use of RACF commands:
򐂰 Someone with the SPECIAL privilege can issue any RACF command, except those
restricted to auditors. SPECIAL users can grant themselves 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 can 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 might have
Group-SPECIAL authority.
򐂰 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 can
access data sets protected by that profile and at what level. The primary command that is
involved is PERMIT.
In the PROTECTALL environment, a RACF profile exists for a user’s HLQ, which is created
when the user ID is added to RACF. A user can grant permission to other users to access
their files by using the PERMIT. The PERMIT command might be the only RACF command
that typical users issue. In a well-designed environment, with appropriate use of generic data
set profiles, most users never need to issue PERMIT commands.
Chapter 7. Administration and maintenance 89

RACF commands can be issued from z/OS operator consoles. The z/OS operator console is
not considered as a routine interface for RACF administration, but it can be 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 on to the z/OS operator console
before they can issue RACF commands.
When the basic command structure is understood, the use of RACF commands instead of
Broadcom Top Secret commands should not present any problems. The more important
migration issues are the organizational processes that occur before any commands are
issued.
In practice, Broadcom Top Secret and RACF commands are issued from ISPF panels or from
the TSO command line by more experienced administrators. In both cases, a good
understanding of the security policy in use and the use of consistent naming conventions and
Group conventions are 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.
7.3 RACF utilities

Several utilities are provided with RACF. These are normally used in batch jobs and address
some of the tasks previously listed:
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.
IRRUT200 This program copies 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, it might not produce a complete 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 merging multiple data sets back into one. IRRUT400
can rebuild internal index records, and generally corrects small
structural errors.
IRRADU00 This program unloads the security relevant SMF Records into
sequential records. It is readable by a person and can be used as
input to external programs.
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 to perform what-if searches.
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 replaces these departing user IDs
and groups.

7.4 Security reports
Reports are important for security administration to enable tracking and monitoring of events
and status of the established security environment and to uncover changes that might lower
or change the expected security level. The problem is to collect and get the correct data to
meet the objectives. Too many organizations collect too much data without a plan or strategy
for its use.
There are two levels of reporting for z/OS security subsystems, status monitoring and event
monitoring. Status monitoring reflects the contents of the security database and describes
what is protected and how it is protected. Event monitoring reflects the security events that
occurred during a particular period, for example, which users logged on to the system, or
what attempted security violations were detected.
For both Broadcom Top Secret and RACF, event monitoring uses SMF records. There are
many programs and products available for listing SMF records.
The usefulness of event monitoring depends on what is monitored and what causes an SMF
record to be written. Broadcom Top Secret and RACF have options to define which events
cause an SMF record to be written. RACF has an orderly structure of auditing controls.
Controls exist at both individual profile levels and at the global Level. Auditing controls can be
selective, and a profile can be used to protect a single data set or protect many data sets with
similar high-level qualifiers.
RACF controls can be set to write SMF records on either access failures in which data set
access was prevented by RACF, or on access successes in which data set access was
permitted by RACF. Typically, successful accesses are not recorded, partly because the
volume of SMF records becomes too large. However, successful access reporting might be
appropriate for a carefully selected set of application data sets. Access failure events are
typically used to create an SMF record, which the security administrator reviews.1
RACF can also log to SMF changes to the RACF database, and can create records that
indicate the changes to user profiles. 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 are related to auditing:
򐂰 Use SAUDIT to log all commands that need a SPECIAL User Privilege. Use the logs to
review activities by these privileged users. You can also use SAUDIT to re-create profiles
and commands from SMF data in an emergency.
򐂰 Use OPERAUDIT to log all data accesses that are granted to a user with the
OPERATIONS privilege because of this privilege. Accesses through normal access rights
are not logged.
򐂰 Use both SAUDIT and OPERAUDIT to enable auditing of privileged users and their
activities.
򐂰 Use CMDVIOL to switch RACF command reporting on and off. CMDVIOL records all
attempts to use RACF commands outside of a user’s authority.
򐂰 Use LOGOPTIONS to specify logging options for different resource classes from no
logging to full logging. Use LOGOPTIONS to globally force logging of resources in one
class to avoid specifying the AUDIT option on each profile.
1 There are many different approaches to this. Some installations want to review every access failure, and 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.

򐂰 GLOBALAUDIT 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 the 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
does not lower the logging requirement set by the LOGOPTIONS value for that class. All
profiles have a default AUDIT setting. For example, for data sets the default setting is
AUDIT(FAILURES).
Note: 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 database, and monitoring
changes to these controls. SMF records, which are written by RACF, are useful for detecting
changes. 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 data sets. 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.
򐂰 RACFRW (RACF Report Writer) is an ad hoc reporting program. The report writer is
stabilized, so new functions are not reported. The traditional RACF functions such as data
set and resource violations can be reported.
򐂰 The IRRDBU00, the RACF database unload utility, produces a sequential file that can be
used in various ways:
– Viewed directly or by using locally written programs
– Loaded into Db2 and searched there
– Used by a standard report-writing software
򐂰 The IRRADU00 the RACF SMF data unload utility, produces a sequential file of
security-related audit data, which can be used in a number of ways:
– Viewed directly or by using locally written programs
– Loaded into Db2 and searched there
– Used by a standard report-writing software
򐂰 The RACFICE reporting tool uses the ICETOOL function of DFSORT to produce various
reports by using the output of IRRDBU00 or IRRADU00 or both.
In summary, log and audit functions are an important part of an organization’s security policy.
The security policy must clearly define what is expected for logging and audit and how it is
used. This requires some skill and experience because a balance is needed between what is
practical, the effects on performance, and the problems of generating too much data.
7.5 Availability considerations

Broadcom Top Secret and RACF, when they are fully implemented and used, are both
functions critical to a z/OS production environment. Therefore, their availability and
recoverability must be carefully designed, planned, and tested. Due to the different technical
features and capabilities of the two products, recovery techniques and strategies differ.

Approaches to RACF recovery are discussed in this section. This section includes a
discussion of backup options. e Figure 7-1 shows the backup data sets.
Figure 7-1 RACF primary and backup data sets
7.5.1 RACF active backup option

A unique recovery feature in RACF is the active backup data set option, which is commonly
used to maintain a software mirror image of the primary RACF database.
Although RACF performs all authentication and authorization checking against its primary
database, all updates are automatically duplicated onto the active backup database. If 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
data set 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 that are independent of the active backup. You can
use the RACF verify utility program IRRUT200 to make the copies. IRRUT200 enqueues on
the input database during the copy process and has the additional advantage that it provides
an analysis of the database structure. Use the IRRUT200 list output to determine the degree
to which the database is full 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 backup database 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.
To avoid false alarms, this switching capability is 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.

7.5.2 Reorganizing the RACF database
Some organizations include periodic reorganizations of their RACF databases in their backup
and recovery plans. In a quiesced environment, use the RACF split/merge utility IRRUT400 to
create a logical copy of your RACF database by specifying one input and one output file. This
process eliminates control interval-like splits in the database structure and profiles that were
logically deleted because they have no pointers in the index structure but might physically still
be present.
7.6 RACF performance considerations

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 create conflict between security needs and performance needs. Extracting the best
performance from the security subsystem involves these areas:
򐂰 Using global options that short-circuit the rest of the security monitor
򐂰 Using some type of cache in main storage
򐂰 Using special coding options in applications that result in an unusually fast response by
the security subsystem
򐂰 Using a good design for sharing the database file among multiple systems, because the
need for a shared security database is common
򐂰 Using normal DASD tuning techniques to improve I/O response
Both Broadcom Top Secret and RACF provide options in all these categories. Some of these
are not only performance options. They affect the policy design of the security database and
should be considered part of your high-level design.
There are several key RACF features:

򐂰 Global Authorization Check (GAC). RACF uses the GAC 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.
򐂰 RACF can take advantage of the coupling facility to further improve performance
If not deflected by a trusted or privileged property, RACF checks the GAC before processing
an access request. The GAC is an in-storage table that is 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 data set with the same HLQ as the caller. That is, a user can work
with their own data sets (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 data
sets, then no SYS1 data sets 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, which is known as in-storage buffers. This space is in protected common storage. It is
pageable, 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 elements that are normally read-only, or write-through cache
data. The RACF database, on disk, must always reflect current data to other z/OS systems
sharing the same database.
RACF can manage a backup database and its primary database. Practically every
installation elects to have a backup RACF database, which should not be deleted. In
addition to profile updates, RACF writes statistical data in its database, for example, the
date and time of a user’s 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 that requires the use of the backup RACF database, some
statistical data will be missing. This is usually considered a reasonable tradeoff.
Customers can use the virtual lookaside facility (VLF) of z/OS to cache accessor environment
elements (ACEEs) and information for z/OS UNIX. If RACF finds information in VLF, it avoids
I/O to the database.
The IRRUT400 Utility, which is supplied with RACF, can be used to reorganize the database.
Database performance might degrade slightly over time as updates and changes occur. The
effect is minor, unless large databases are involved or many profiles were added and deleted.
A typical installation might use this utility to reorganize the database every six months.
7.6.1 Performance Of shared databases

Sharing a database between Broadcom Top Secret or RACF, among multiple z/OS images
has become common. This has several interesting effects on performance design:
򐂰 The use of cache functions becomes more restricted because the corresponding disk
record can be updated by another system, which makes the cached data invalid.
򐂰 Extensive use of RESERVE and RELEASE functions, disk locking commands, can
negatively impact the performance of a shared disk.
򐂰 The use of a disk API access method that is not optimized for shared system usage can
negatively impact performance.
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 elements of RACF operation that affect shared-system performance are all automatic.
There is no user tuning involved. The tuning items that are discussed are effective in both
single-system and multi-system environments.
The coupling facility allows z/OS and other software to share data concurrently among
multiple systems in the sysplex with the goal of maintaining a single system image. A sysplex
with a coupling facility significantly changes the way systems can share data. Data sharing is
the ability of concurrent subsystems or application programs to directly access and change
the same data, while maintaining system integrity. RACF can take advantage of the coupling
facility in the sysplex to provide security for the resources of all systems in a comprehensive
and centralized way. RACF allows you to use the coupling facility and shared RACF data to
help manage the security of resources for all systems in a sysplex.

7.6.2 Migration issues
Review the complete program propagation table (PPT) manually, as part of any migration
effort. Other performance elements, especially the GAC, should be created manually.
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. If the basic
migration process, which is normally done by using specialized software tools, provides
acceptable performance, then it might be advisable to postpone tuning these elements until
the end of the migration project.
A CICS installation would certainly want to enable FASTAUTH checking for its own
applications or program products as part of the migration. This should provide a substantial
performance improvement and integrate CICS usage into normal RACF operation.
7.6.3 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.

A
Appendix A. A Sample migration plan

A migration plan should include the following items. The durations that are listed are
representative, and can vary widely, depending on circumstances:
򐂰 Project team education
Although this depends on the availability of classes, about three weeks are needed for
attendance. There is little point in attempting to make a detailed project plan, which is the
next step, until key team members have received the necessary education.
򐂰 Detailed project planning
This might take two weeks. One of the results should be specific team assignments and
schedule targets. This activity requires:
– Knowledge of RACF, the existing security manager
– The routine operational activities of the installation, such as help desk functions,
auditing, and routine user administration
– Major production jobs.
򐂰 Planning RACF groups
This activity can easily take several weeks. This activity is the key to obtaining a RACF
structure that is manageable, well-designed, and one that meets your needs. This area is
where experience from other RACF migrations is most important.
򐂰 Create a test environment
This activity can parallel some of the other planning activity, and can take several weeks.
In general, it means cloning an existing z/OS, including all the subsystems, and providing
access for testing to appropriate production files.
򐂰 Database conversion
This can take up to a month. It typically involves using a tool to convert Broadcom Top
Secret Database entries to appropriate RACF entries. In practice, the conversion might be
done many times by changing the Broadcom TSS input or changing the tool's parameters
until the resulting RACF structure meets your design.
This activity is likely to be intermixed with unit testing and integration testing. After testing
a number of your production applications, you might decide that a slightly different RACF

design is better. You might want to change the conversion tool's parameters and convert
your Broadcom Top Secret again.
򐂰 Unit testing
Some effort is needed to test your important applications, and contain the testing effort
within a reasonable schedule. Two to four weeks might be a reasonable target. This phase
might require considerable assistance from application owners and production controllers.
򐂰 Function testing
This activity typically takes two weeks. It involves moving several selected
applications/users to the test system for production work and involves closely monitoring
potential problems.
򐂰 Production cutover
This activity involves the final conversion of the Broadcom Top Secret Database to RACF.
This phase should include at least three weeks of monitoring and support to address
specific situations. After this, the migration team can be released.

B
Appendix B. Security policy considerations

Various aspects of security policies are addressed throughout this document in the context of
specific technical discussions. This appendix is intended to consistently summarize policy
implementation and enforcement in RACF.
This appendix addresses general policies such as complete RACF control over Users and
Resources, naming conventions and resource ownership. It also includes discussions of
effective and efficient security administration policies and RACF resource usage.
This appendix does not address mandatory access control policies because they have not
been observed in commercial environments.

B.1 User identification
The recommended policy requires that, except for an initial migration, all users must be
identified and verified by RACF. Undefined users are not permitted. RACF principally allows
for undefined users for two reasons:
򐂰 To support an initial migration to a secured environment
򐂰 To ensure uninterrupted system availability
Techniques to prohibit undefined user IDs vary with the processing environments, as outlined
in the following sections.
B.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 in the job
statement or through propagation (inheritance).
B.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.
B.1.3 Started procedures

Started procedures are considered part of the computing environment that is essential to the
availability and functionality of the z/OS system. Therefore, IBM implemented RACF Started
Task Control (STC) support with focus on availability to allow rather than disrupt the start of
procedures. Procedures can start with an undefined user ID under the following conditions:
򐂰 The STC user ID (either assigned specifically or through the generic entry in the STC
table) is not a RACF-defined user ID.
򐂰 The user ID is not connected to the group specified in the table.
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.
User IDs that are assigned to started procedures should have the PROTECTED attribute.
Protected user IDs are user IDs that have both the NOPASSWORD and NOOIDCARD
attribute. Protected user IDs cannot be used to logon to the system, and are protected from
being revoked through incorrect password attempts.
A Started Procedure can gain access to RACF-Protected Resources in the following ways:
򐂰 By the user ID or Group Name assigned, as for any other user of the system.
򐂰 By having the Privileged Attribute, which allows the Started Procedure to pass all
authorization checking. No installation exits are called, no SMF records are generated,
and no statistics are updated. Use this option with extreme caution.

򐂰 By having the Trusted attribute, which means the same as Privileged, except that you can
request an audit by using the SETROPTS LOGOPTIONS command.
Policy enforcement for all environments can be complemented by monitoring SMF Audit Trails
and, if required, by coding a RACINIT exit that terminates all requests for establishing a RACF
environment for the default user ID.
B.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
vary with the type of resource, as described in the following sections.
B.3 Data sets

Default protection for data sets can be activated through SETROPTS PROTECTALL(FAIL).
When it is enabled, unprotected data sets can be accessed by only system-level SPECIAL
Users. WARN Mode is available to ease migration.
B.3.1 Transactions and other resources

Default protection over General Resources can be achieved through various controls:
򐂰 Program logic in resource managers calling RACF
򐂰 Settings in the RACF CDT
򐂰 Catch-all profiles with UACC=NONE and restrictive specific access
Catch-all profiles can be useful because the logic that is applied by resource managers might
not always be known, and you might not want to change CDT entries for existing resource
classes.
B.4 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 supported technique is RACF passtickets.
B.4.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, DES encryption 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, which are described in the
following list with generally recommended settings:
Appendix B. Security policy considerations 101

򐂰 RULE1(LENGTH(6,8) ALPHANUM(1,8). A minimum length of 6 alphanumeric characters
with a least one character being numeric
򐂰 INTERVAL(30). The user’s password expires after 30 days before the password expires.
򐂰 HISTORY(32). The previous 32 passwords cannot be used.
򐂰 REVOKE(3). Revoke the user ID after 3 invalid password attempts.
A related SETROPTS option is:

򐂰 INACTIVE(30). Revoke a user ID after 30 days of inactivity.
B.4.2 Passtickets
RACF offers advanced authentication through Passtickets, which are generated by specific
products supporting this form of User authentication.
B.5 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 in the following sections.
B.5.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 might not always be practical
because it limits the use of High-Level Generic Dataset Profiles (such as HLQ.**).
B.5.2 Other resources

The use of catch-all profiles helps enforce naming conventions for general resources. Generic
Profiles, if used, must be designed accordingly.
B.5.3 Users and groups

User IDs and Group Names are not controlled by RACF in a way that allows enforcement of
local naming standards.
B.6 Ownership
The 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 that the group structure reflects applications and
business areas adequately and that the custodians are properly assigned as group
administrators.

B.7 Security administration
Recommended policy addresses many aspects of security administration; some can be
supported by RACF, as discussed in the following sections.
B.7.1 Structure
Security administration tasks are typically performed within the following structures:
򐂰 Central security administration
򐂰 Group administration or functional delegation
򐂰 Help desk
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, or on a privilege that is 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 help desk functions such as user ID RESUME and password RESET can be
implemented through the RACF FACILITY class, Group-SPECIAL, or organizations have
chosen other (limited) solutions through special programs that run authorized and use
authorization schemes other than Group-SPECIAL.
B.7.2 Effectiveness
Recommended policy requires security administration to be effective 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
a REVOKE(date) in User definitions. For permissions, expiration dates can be established
indirectly through group connections.
B.7.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.
B.8 Audit considerations

Recommended policy requires a reasonably complete audit trail and firm procedures to
monitor and review security events and status information.

B.8.1 Logging
RACF provides an audit trail of security-related events through SMF. The nature and amount
of information that is recorded is controlled by RACF options and profile definitions:
򐂰 SETROPTS SAUDIT, OPERAUDIT CMDVIOL and INITSTATS are the recommended
standard settings, which include privileged user activities.
򐂰 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 carefully because it might create a significant amount of noise
records.
B.8.2 Event monitoring

Recommended policy requires regular event monitoring. RACF provides four reporting
options:
򐂰 Data Security Monitor (DSMON) provides pre-defined RACF database and z/OS auditing
reports.
򐂰 The RACF report writer allows for ad hoc violation reporting.
򐂰 You can use the RACF database unload utility and SMF unload feature to unload the
RACF database and violation records from SMF into flat files.
򐂰 The RACFICE reporting tool includes over 30 sample reports, and uses the DF/SORT
ICETOOL report generator.
B.8.3 Status review

Recommended policy requires periodic security status monitoring and full security audits.
The RACF DSMON utility provides basic event monitoring capabilities. The RACF database
unload utility converts SMF records into a format that can be easily processed by a relational
database or other tools. For detailed information on RACF reporting tools, see IBM Resource
Access Control Facility.
B.9 Resource usage

Recommended policy and general consensus require that the security monitor’s performance
impact is minimal.
B.9.1 Performance options

RACF offers key performance options that should be used to comply with policy:
򐂰 Resident blocks in the RACF data set name table with a recommended value of 255
򐂰 Global table entries for trivial access in class DATASET with a recommended entry of
&RACUID/ALTER

B.9.2 Potential performance impact
The following RACF practices might create performance issues: :
򐂰 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

C
Appendix C. Frequently asked questions

Q. When protecting an 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
create an artificial user ID? Why?
A. Defining a group is the normal approach and this is a normal use for group definitions.
Use user IDs for real users only. Some exceptions exist. Artificial user IDs might be used
for Started Task Control, for example. There is no strong technical reason for this
recommendation. Using group IDs provides a more orderly way to manage access to
application data sets.
Q. Can I prevent users from permitting 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 using IDCAMS?
A. IDCAMS is never needed with RACF. You can use the IRRUT200 utility that is provided
with RACF. You might use IEBGENER, although IEBGENER (or other similar utilities) do
not interlock with RACF to provide a self-consistent copy. IRRUT200 provides the proper
interlocks without effectively stopping RACF so that partly updated Profiles are not 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 write their own tools that are often based on
submitting jobs from CICS (through an internal reader) that runs the 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 access by using the RACF facility class parameter or 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 that are 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 ALTUSER command provides this function.
Q. What do I need to do to share my RACF database between multiple z/OS systems?

A. Nothing, this function is automatic, but you need the appropriate shared-DASD
hardware. If sysplex functions are available, a higher-performance mode of sharing can be
used.
A major difference between Sysplex and a conventional large computer system is the
improved growth potential and level of availability in a Sysplex. The coupling facility allows
z/OS and other software to share data concurrently among multiple systems in the
Sysplex, with the goal of maintaining a single system image.
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 might destroy your database, or, worse, introduce subtle errors that grow over
time. We recommend not using this level of interface unless you trust the design of the
program issuing the commands, or have an unusual requirement. There are helpful and
trustworthy programs that use ICHEINTY, but there is no easy way to determine whether
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 few 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. The RACFICE reporting tool is available, which includes over
30 sample reports, and uses the DF/SORT ICETOOL Report Generator.
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 might be used to inform users about any changes
in logon processing.
Your help desk staff and your group Administrators might require more education.

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 after they have been
encrypted.
Q. After I install RACF, can I run my z/OS system without it? What if I make a change that
locks out users?
A. After it is installed, you can run without RACF. This is a special mode, awkward to use,
and suitable for only a single user on the system. In effect, z/OS issues a console
message for every data set allocation, and the z/OS operator must reply to each message
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 109

Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this book.
Other publications
These publications are also relevant as further information sources:
򐂰 z/OS Security Server RACF System Programmer's Guide, SA23-2287-30
򐂰 z/OS Security Server RACF Security Administrator's Guide, SA23-2289-30
򐂰 z/OS Security Server RACF Security Auditor’s Guide, SA23-2290-30
򐂰 z/OS Security Server RACF Command Language Reference, SA23-2292-30
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services

򐂰 ibm.com/services

Abbreviations and acronyms
ACB Access Control Block
ACEE ACessor Environment
Element GID UNIX Group IDentifier
ACID ACcessor IDentifier GRS General Resources
ADSP Automatic Data Set Protection HFS Hierarchical File System
APPC Advanced HLQ High Level Qualifier

Program-to-Program ICB Inventory Control Block
Communications
IBM International Business
API Application Programming Machines Corporation
Interface
IMS Information Management
CBIPO Custom-Built Installation System
Process Offering
IPL Initial Program Load
CDSA Common Data Security
Architecture IPSec Information Protocol Security
CDT Class Descriptor Table ISPF/PDF Interactive System

Productivity Facility/Program
CICS Customer Information Control Development Facilityi
System
ISV Independent Software Vendor
CLAUTH CLass AUTHorization
ITSO International Technical
CLISTS Command Lists Support Organization
CMDF Commercial Data Masking JCL Job Control Language
Facility
JES Job Entry Subsystem
CPU Central Processing Unit
KDC Key Distribution Center
DASD Data Access Storage Device
LDAP Lightweight Directory Access
Db2 Database/2 Protocol, component of
DCE Distributed Computing SecureWay Security Server
Environment ,component of for z/OS
SecureWay Security Server LPA Link Pack Area
for z/OS
MVS Multiple Virtual Storage
DDN Data Definition Name
NAT Network Address Translation
DES Data Encryption Standard
NDS Novell Directory Services
DFDSS Data Facility/Data Storage
System NJE Network Job Entry
DFP Data Facility Product OCEP Open Cryptographic

Enhanced Plug-ins,
DFSMS Data component of SecureWay
Facility/System-Managed Security Server for z/OS
Storagey
OMVS Open Edition for MVS
DLF Data Lookaside Facility
OVM Open Edition for VM
DNS Domain Name Services
PADS Program Access to Data Sets
DSCB Data Set Control Block
PCICC PCI Cryptographic
DSMON Data Security Monitor Coprocessor
DSN Dataset Name PGM Program
EOS Erase On Scratch PKI Public Key Infrastructure
FTP File Transfer Protocol PL/I Programming Language/1
GAC Global Access Checking

RACF Resource Access Control
Facility, component of
SecureWay Security Server
for z/OS
RJE Remote Job Entry
RJP Remote Job Process
RRSF RACF Remote Sharing
Facility
SA Security Association
SAF System Authorization Facility
SDSF System Data Spool Facility
SMF System Management
Facilities
SMPO Software Migration Project
Office
SMS Storage Management
Subsystem
SNA Systems Network Architecture
SPT Started Procedures Table
STC Started Task Control
SYSRES System-resident pack
TME Tivoli Management
Environment
TMP Terminal Monitor Program
TSO Time Sharing Option
UACC Universal ACCess authority
UADS User Attribute Data Set
UID User IDentifier
USS UNIX System Services
VM Virtual Machinge
VOL Volume
VPN Virtual Private Network
VSAM Virtual System Access
Method
VTAM Virtual Telecommunications
Access Method

CA TopSecret to z/OS Security Server Migration Guide
(0.2”spine)
0.17”<->0.473”
90<->249 pages
®
CA TopSecret to
z/OS Security Server
Migration Guide
Broadcom Top Secret and the IBM® z/OS® Security
Server (RACF®) are both Mainframe Security products. In INTERNATIONAL
some areas their designs are similar, and in other areas the TECHNICAL
designs are very different. Planning a migration from SUPPORT
Broadcom Top Secret to z/OS Security Server RACF, ORGANIZATION
without unduly disrupting an z/OS 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. BUILDING TECHNICAL
This IBM Redbooks® publication will assist in INFORMATION BASED ON
understanding the higher-level issues and differences PRACTICAL EXPERIENCE
between the two products as an important starting point.
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
For more information:

ibm.com/redbooks
SG24-5677-01 ISBN 0738461628

SG 245677

Uploaded by

Copyright:

Available Formats

SG 245677

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SG 245677

Uploaded by

Copyright:

Available Formats

BFront

Broadcom Top Secret and

CA TopSecret to z/OS Security Server Migration Guide

Second Edition (August 2024)

© Copyright International Business Machines Corporation 2024. All rights reserved.

Chapter 1. The Value of the IBM z/OS Security Server RACF . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2. z/OS Security Server RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 3. IBM z/OS Security Server RACF overview . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 4. Broadcom Top Secret overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

© Copyright IBM Corp. 2024. iii

Chapter 5. RACF project overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 6. Database migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

iv CA TopSecret to z/OS Security Server Migration Guide

Chapter 7. Administration and maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Appendix A. A Sample migration plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Appendix B. Security policy considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Appendix C. Frequently asked questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION “AS IS”

© Copyright IBM Corp. 2024. vii

The following terms are trademarks of other companies:

viii CA TopSecret to z/OS Security Server Migration Guide

The team who wrote this book

Thanks to the authors of the previous editions of this book.

Now you can become a published author, too!

© Copyright IBM Corp. 2024. ix

Stay Connected to IBM Redbooks

x CA TopSecret to z/OS Security Server Migration Guide

Chapter 1. The Value of the IBM z/OS

© Copyright IBM Corp. 2024. 1

1.1.1 Business Benefits of the z/OS Security Server RACF

2 CA TopSecret to z/OS Security Server Migration Guide

1.1.2 Financial benefits of the z/OS Security Server

Identifying productivity savings

1.2 RACF added features and functions

The following list describes some of the new RACF features:

Chapter 1. The Value of the IBM z/OS Security Server RACF 3

1.2.1 RACF administrative enhancements

4 CA TopSecret to z/OS Security Server Migration Guide

etc. rename etc.

Figure 1-1 RRSF overview

RACF includes the following logging and reporting options:

Chapter 1. The Value of the IBM z/OS Security Server RACF 5

1.2.2 RACF/Db2 security administration overview

6 CA TopSecret to z/OS Security Server Migration Guide

DB2 Catalogs RACF Database

SYSIBM.SYSDATABASE etc. e.g. DSNADM1, MDSNTB1, etc

Figure 1-2 Db2 external security (RACF) overview

Benefits of using RACF to administer your Db2 security

Migration issues: Protection of Db2 resources via RACF

Chapter 1. The Value of the IBM z/OS Security Server RACF 7

Identifying financial savings based on product price

Identifying productivity savings

8 CA TopSecret to z/OS Security Server Migration Guide

1.3 RACF market penetration

Chapter 1. The Value of the IBM z/OS Security Server RACF 9

Chapter 2. z/OS Security Server RACF

© Copyright IBM Corp. 2024. 11

Security adm inistration