The OS/390 Security Server Meets Tivoli: Managing RACF with Tivoli … · 2021. 9. 3. · Tivoli management solution for a large telecommunications industry customer. Gavin Thomas

SG24-5339-00

International Technical Support Organization

http://www.redbooks.ibm.com

The OS/390 Security Server Meets Tivoli:Managing RACF with Tivoli Security Products

Richard Hawes, Paul de Graaff, Christoph Marti, Gavin Thomas, Yoh Shigehara

The OS/390 Security Server Meets Tivoli: Managing RACF with Tivoli Security Products

December 1998

SG24-5339-00

International Technical Support Organization

© Copyright International Business Machines Corporation 1998. All rights reservedNote to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

First Edition (December 1998)

This edition applies to versions 3.6 and 3.6.1 of the Tivoli Management Framework, Tivoli User Administration (TUA), Tivoli Security Management (TSM), TUA for OS/390 and TSM for OS/390. Most of the content will also be applicable to later releases.

Comments may be addressed to:IBM Corporation, International Technical Support OrganizationDept. DHHB Building 045 Internal Zip 2834 11400 Burnet Rd.Austin, Texas 78758-3493

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you.

Before using this information and the product it supports, be sure to read the general information in Appendix B, “Special Notices” on page 123.

Take Note!

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiThe Team That Wrote This Redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiTivoli Management Product Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiComments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Chapter 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 2. OS/390 Security Server and Tivoli Primer. . . . . . . . . . . . . . . 52.1 OS/390 Unix System Services Overview . . . . . . . . . . . . . . . . . . . . . . . 52.2 RACF Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 System Authorization Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 RACF Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 The RACF Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.2 RACF User and Group Management Concepts. . . . . . . . . . . . . . 102.4.3 RACF User Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.4 RACF Segments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.5 Managing RACF Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 The Tivoli Management Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5.1 Overview of the Tivoli Framework. . . . . . . . . . . . . . . . . . . . . . . . 152.5.2 Tivoli Management Agent on OS/390 . . . . . . . . . . . . . . . . . . . . . 18

2.6 Secure Delegation of Administration. . . . . . . . . . . . . . . . . . . . . . . . . . 192.6.1 TMR and Resource Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6.2 Policy Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6.3 Administrator Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.6.4 Profile Managers and Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.6.5 Tivoli Administrator to Endpoint ID Mapping . . . . . . . . . . . . . . . . 222.6.6 Administration through Tasks and Scripts . . . . . . . . . . . . . . . . . . 232.6.7 Default and Validation Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.7 Tivoli Security Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.7.1 Tivoli Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.7.2 Tivoli User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.8 RACF and Role Based Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Chapter 3. Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1 Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.1 Capacity Planning Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1.2 Automating Aspects of User Creation . . . . . . . . . . . . . . . . . . . . . 31

© Copyright IBM Corp. 1998 iii

3.1.3 Archival of Tivoli User and Security Data . . . . . . . . . . . . . . . . . . 323.1.4 Use of Tivoli Alongside RRSF. . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Preparation for Use of Tivoli Management . . . . . . . . . . . . . . . . . . . . . 333.2.1 Synchronize User Identification . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.2 User and Security Record Management . . . . . . . . . . . . . . . . . . . 343.2.3 Apply a Naming Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2.4 Synchronize Password Quality Rules . . . . . . . . . . . . . . . . . . . . . 35

3.3 Installation Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.1 TMR Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.2 Tivoli Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.3 OS/390 Tivoli Framework Installation . . . . . . . . . . . . . . . . . . . . . 373.3.4 TMA Method Preload Function . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.5 Tivoli User Administration for OS/390 . . . . . . . . . . . . . . . . . . . . . 433.3.6 Tivoli Security Management for OS/390 . . . . . . . . . . . . . . . . . . . 43

3.4 Endpoint Administrator Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4.1 OS/390 TMA Administrator Mapping. . . . . . . . . . . . . . . . . . . . . . 443.4.2 Creating an OS/390 Identity for Tivoli Security Administration . . 46

3.5 Starting OS/390 Tivoli Management Agent . . . . . . . . . . . . . . . . . . . . . 503.5.1 Configure the OS/390 TMA Shell Script . . . . . . . . . . . . . . . . . . . 503.5.2 Starting the Endpoint for the First Time . . . . . . . . . . . . . . . . . . . 503.5.3 Automated Start of the TMA Endpoint. . . . . . . . . . . . . . . . . . . . . 53

3.6 Checking the OS/390 Endpoint Installation. . . . . . . . . . . . . . . . . . . . . 543.6.1 Listing Tivoli Management Agent Properties . . . . . . . . . . . . . . . . 543.6.2 Checking Current Tivoli Management Agent Status . . . . . . . . . . 553.6.3 Viewing Tivoli Management Agent Files from a Web Browser. . . 56

3.7 Getting Started with Tivoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.7.1 The Tivoli Populate Function . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.7.2 User and Security Profile Distribution . . . . . . . . . . . . . . . . . . . . . 623.7.3 Task Library Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Chapter 4. User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.1 Creating a Policy Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2 Use of Default and Validation Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.2.1 Examples of Default and Validation Policy . . . . . . . . . . . . . . . . . 694.2.2 Modifying Default or Validation Policy . . . . . . . . . . . . . . . . . . . . . 694.2.3 Maintaining Policies across User Profiles . . . . . . . . . . . . . . . . . . 72

4.3 User Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3.1 Cloning Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3.2 Merging Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.3.3 Synchronizing Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.3.4 Disabling Default Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.4 Example of Creating an OS/390 UNIX User . . . . . . . . . . . . . . . . . . . . 774.4.1 Default Policy for RACF OMVS Segment . . . . . . . . . . . . . . . . . . 77

iv The OS/390 Security Server Meets Tivoli

4.4.2 Adding a Custom Action to a User Profile . . . . . . . . . . . . . . . . . . 784.4.3 Distributing a User Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.4.4 Checking A User Definition from a Tivoli Task . . . . . . . . . . . . . . 83

Chapter 5. Access Control Management . . . . . . . . . . . . . . . . . . . . . . . 895.1 Implementing TSM in RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.1.1 Tivoli Roles in RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.2 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925.3 Implementation Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.3.1 Exact Copy Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.3.2 Use of Access Warning Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 945.3.3 User Consideration when Adding a Resource . . . . . . . . . . . . . . . 94

5.4 Tape Volume Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.5 Customizing TSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Chapter 6. Auditing and Event Management . . . . . . . . . . . . . . . . . . . . 976.1 Standard Auditing in RACF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.1.1 Owner-Controlled Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 986.1.2 Auditor-Controlled Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.1.3 Auditing Tools Supplied with RACF . . . . . . . . . . . . . . . . . . . . . . 996.1.4 Additional RACF Auditing Tools . . . . . . . . . . . . . . . . . . . . . . . . 1066.1.5 Auditing Changes Made through Tivoli . . . . . . . . . . . . . . . . . . . 107

6.2 RACF Messages and TEC Event Integration . . . . . . . . . . . . . . . . . . 1076.2.1 Customizing NetView Automation Table for ICH Messages . . . 1096.2.2 Message Adapter Format File for RACF Messages . . . . . . . . . 1096.2.3 Creating New Event Classes for RACF Messages . . . . . . . . . . 1116.2.4 Sample RACF Event on TEC Console . . . . . . . . . . . . . . . . . . . 113

6.3 RACF System Management Facility Data . . . . . . . . . . . . . . . . . . . . . 1156.4 Integration with Other Logging Functions . . . . . . . . . . . . . . . . . . . . . 1166.5 Tivoli Notice Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6.5.1 Archiving Notice Group Data . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.6 OS/390 Event Integration Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Appendix A. RACF Pre-requisite APARs . . . . . . . . . . . . . . . . . . . . . . . . 119A.1 APAR OW26060 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.2 APAR OW26061 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Appendix B. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Appendix C. Related Publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127C.1 International Technical Support Organization Publications . . . . . . . . . . 127C.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

v

How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129How IBM Employees Can Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . 129How Customers Can Get ITSO Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . 130IBM Redbook Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

List of Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

vi The OS/390 Security Server Meets Tivoli

Figures

1. Tivoli User Administration Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22. OS/390 UNIX System Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 63. RACF’s Relationship to the Operating System . . . . . . . . . . . . . . . . . . . . . . 74. Conceptual Illustration of RACF Profile Checking . . . . . . . . . . . . . . . . . . . . 85. Tivoli Management Framework Overview . . . . . . . . . . . . . . . . . . . . . . . . . 166. Tivoli Management Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177. Tivoli Resource Management Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 218. Tivoli Administrator Properties - ID Mapping . . . . . . . . . . . . . . . . . . . . . . . 459. Principal ID in Tivoli Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4710. Sample Definition in TMEADMIN Class. . . . . . . . . . . . . . . . . . . . . . . . . . . 4811. Testing Operation Using wrunusrcmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4912. Tivoli Management Agent Status Page - Web Browsing . . . . . . . . . . . . . . 5713. Tivoli Management Agent Log file (lcfd.log) - Web Browsing . . . . . . . . . . 5814. Tivoli Management Agent Configuration File - Web Browsing. . . . . . . . . . 5915. Sample Task Source - get_disk_info.sh . . . . . . . . . . . . . . . . . . . . . . . . . . 6316. Create Task Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6417. OS/390 Task Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6518. Selecting a Region’s Managed Resources . . . . . . . . . . . . . . . . . . . . . . . . 6819. Default Policy Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6920. The Edit Default Policies Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7021. Edit Script Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7122. Editing Policy Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7223. Cloning a User Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7424. Create OMVS Home Directory Script - mkdir_omvs.sh . . . . . . . . . . . . . . . 7925. Distribute Profile Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8026. AEF Modified Distribute Profile Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8227. Running a RACF Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8628. RACF Task Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8729. Tivoli User and Security Profile Implementation . . . . . . . . . . . . . . . . . . . . 9130. Routing OS/390 Messages to TEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10831. Sample NetView Automation Definition for RACF ICH Messages. . . . . . 10932. Message Adapter Format File for RACF Messages . . . . . . . . . . . . . . . . 11033. Including RACF Format File in Base Format File . . . . . . . . . . . . . . . . . . 11134. Sample TEC BAROC File for RACF - tecad_racf.baroc . . . . . . . . . . . . . 11235. RACF Event on TEC Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11436. RACF Event Detail Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

© Copyright IBM Corp. 1998 vii

viii The OS/390 Security Server Meets Tivoli

Tables

1. Default Policy for OMVS Segment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

© Copyright IBM Corp. 1998 ix

x The OS/390 Security Server Meets Tivoli

Preface

This redbook describes how Tivoli systems management products can be used to manage the OS/390 Security Server component known as the Remote Access Control Facility (RACF). We describe the recently introduced Tivoli Management Agent for OS/390 and the Tivoli components that allow the integration of the RACF management function with that of distributed systems, such as UNIX and Windows NT.

This book is aimed at two groups of people: those familiar with RACF that wish to know more about Tivoli, and those familiar with Tivoli that need to know more about RACF. The aim is to describe how all the components work together and to identify the most important considerations to take into account when implementing these products. An introduction to the topic of managing the OS/390 Security Server RACF component in a distributed environment is provided.

The Team That Wrote This Redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin and Austin Centers.

Richard Hawes is a Senior Tivoli Security Specialist at the International Support Organization, Austin Center. He writes extensively on Tivoli framework and security issues and is a Tivoli Certified Enterprise Consultant. Before joining the ITSO in early 1997, Richard was based in the UK providing on-site server troubleshooting and problem management across Europe.

Paul de Graaff is a Certified IT Specialist at the International Technical Support Organization, Poughkeepsie Center. He writes extensively and teaches IBM classes worldwide on all areas of S/390 Security. Before joining the ITSO, Paul worked with IBM Global Services in The Netherlands as a senior IT Specialist.

Christoph Marti is an advisory IT specialist with IBM in Zurich. After studying mathematics (with a focus on computer science), Christoph Marti took his degree in mathematics from the Swiss Federal Institute of Technology Zurich (ETH, http://www.ethz.ch/) in 1976 and then joined IBM at the Zurich branch office as a Systems Engineer. He has worked for IBM for 22 years (including 15 years in Field Support Centers in Germany and Switzerland and four years in the Open Systems Center in Switzerland). His expertise is in MVS and RACF, Advanced Function Printing, and distributed computing (mainly DCE).

© Copyright IBM Corp. 1998 xi

His current focus is with security in a heterogeneous environment and his latest project involves the design and implementation of Tivoli User Administration and Security Management at a large customer.

Yoh Shigehara is an IT Engineer in IBM Japan. He has over two years of experience in distributed system management with Tivoli. His most recent engagement has involved a major Tivoli project in Japan, implementing a Tivoli management solution for a large telecommunications industry customer.

Gavin Thomas is an Advisory IT Specialist with IBM Global Services South Africa. He has over five years experience in 2nd and 3rd level support and development for mainframe systems and applications. His expertise includes security management within applications and the platforms in which they operate.

There is an intense development effort under way to produce best-of-breed OS/390 systems management, integrated with that of distributed systems. Despite the pressures of this environment many people gave time to help us make this a rich reference. We would especially like to thank the following people for their invaluable contributions to this project:

David CrowGary ColeGregg WilsonTim NoblesTivoli Security Development, Tivoli Systems Austin, TX

Bruce WellsEric RosenfeldMark NelsonMike OnghenaOS/390 Security Development, IBM Poughkeepsie, NY

Richard SzulewskiProgram Manager, Tivoli Systems Raleigh, NC

Sharon BidaureTivoli System Verification, Tivoli Systems Raleigh, NC

Daniel MackowayStrategic Application Evaluation Test, IBM Poughkeepsie, NY

Arne OlssonInternational Technical Support Organization, IBM Raleigh, NC

xii The OS/390 Security Server Meets Tivoli

Tivoli Management Product Names

In an effort to eliminate any confusion about the names for Tivoli’s expanding line of management products, Tivoli has recently been through a brand naming review. Those already familiar with the products mentioned in this publication will be used to seeing the names as TME 10 Security Management, TME 10 User Administration, and so on.

The new naming convention for these enterprise software management products will replace TME 10 with Tivoli. The new names are Tivoli Security Management and Tivoli User Administration. (This change may seem trivial, but the consistency comes from more dramatic changes on other products, such as Unison Destiny, which is now Tivoli Output Manager.)

Many Tivoli products current at the time of writing are still using the older names. However, throughout this publication, we have endeavored to use the new names wherever practical. This includes references to the Tivoli Management Agent, often referred to in the past as the Lightweight Client Framework (LCF).

Comments Welcome

Congratulation or Criticism. Your Comments are Important to Us.

We want our redbooks to be as helpful as possible. Please send us your comments about this, or other redbooks, in one of the following ways:

• Fax the evaluation form found in “ITSO Redbook Evaluation” on page 139 to the fax number shown on the form.

• Use the electronic evaluation form found on the Redbooks Web sites:

For Internet users http://www.redbooks.ibm.com

For IBM Intranet users http://w3.itso.ibm.com

• Send us a note at the following address:

[email protected]

xiii

xiv The OS/390 Security Server Meets Tivoli

Chapter 1. Introduction

In the IBM S/390 mainframe environment, security-related functions can be provided through a product called the OS/390 Security Server. This has a number of components related to security operations including one that is the main topic of this book, the Remote Access Control Facility (RACF).

The first question a RACF administrator may ask when discussing management through Tivoli might be “why do it?”. A seasoned RACF administrator would almost certainly be able to better manage RACF directly using commands under TSO rather than working with a GUI. Our answer would be that management through Tivoli is not intended to be the primary interface for the experienced RACF administrator. In fact, many functions will almost certainly still be managed directly, and certain capabilities are only available through direct manipulation.

The areas where Tivoli really makes a difference are in the combination of administration of RACF with that of distributed system security, such as for Windows NT domains, UNIX machines, and others. There are also cases where certain security management functions can be delegated to junior administrators, such as in a help desk, where a GUI would be easier to use. Tivoli provides a central repository for all your system management data. This data can be shared among management applications and by administrators of different system types.

There will always remain a distinction between the Security Officer and a Security Administrator. A Security Officer for OS/390 will be a senior RACF administrator who will most likely not make much use of the Tivoli interfaces and who will be responsible for the OS/390 security policy. The Security Administrator will handle a subset of the security management function. This subset will depend on the management policy of the organization but may include the creation of new user accounts on various systems, the resetting of passwords and so on. The capabilities of the security administrator (whether through Tivoli or some other means) will be guided by the security officer and resource owners.

This book discusses the integration of the management of the RACF component of the OS/390 Security Server with that of the distributed environment. This is made possible following the introduction of a Tivoli Management Agent (TMA) endpoint for OS/390 and through two products in Tivoli’s enterprise security discipline: Tivoli User Administration and Tivoli Security Management.

© Copyright IBM Corp. 1998 1

Figure 1 shows the way Tivoli User Administration can provide the mechanism for both centralized and distributed user management for many different security platforms. The situation is similar for access control administration through Tivoli Security Management.

Figure 1. Tivoli User Administration Capabilities

Having all systems managed through a consistent database and interface enables us to handle administration in a variety of models, such as administrators local to branch offices or centrally situated or the secure delegation of tasks to help-desks. Tivoli provides a number of mechanisms for accessing the management data that facilitate the use of existing information systems, such as a Human Resources database, in the generation and maintenance of the security management data.

The mixing of Tivoli and distributed environments with the world of OS/390 and RACF introduces some conflicts in the terminology used. By describing each environment in this book, and then highlighting terms as Tivoli-specific

TivoliUser

Administration

RACF DB

local

centralhelpdesk

Corporateinformation

systems

LAN

Local

CentralAdmin

FirewallNetWare

UNIXNTServer

LotusNotes/Domino

RDBMS’sAS/400

OS/2Server

Others...

CreateUpdateDelete

ImportCompare

Synchronize

2 The OS/390 Security Server Meets Tivoli

or RACF-specific, we hope to enable someone familiar with either environment to understand and work with the other.

Getting started in implementing such a major change to the way systems are administered requires a great deal of planning to yield the best return on the investment. We present some guidelines and pointers to help you get going with a solution design as well as highlighting facts important to ensure successful installation and configuration.

In the latter chapters of the book, we cover specific information on Tivoli User Administration and Tivoli Security Management. Each have special considerations in the OS/390 environment, and these chapters are equally important for those new to Tivoli security as well as those who already have some experience with Tivoli security products on other platforms.

The last chapter deals with a very important security topic, auditing. There is little point deciding on a comprehensive security policy without ensuring that it is being adhered to and that violations are quickly identified and resolved.

Introduction 3


Chapter 2. OS/390 Security Server and Tivoli Primer

The OS/390 Security Server contains a number of components related to security on the OS/390 mainframe. One of these components is an access control system known as the Resource Access Control Facility (RACF). This book deals with the management of RACF through the Tivoli security products. Refer to the OS/390 Security Server documentation for more details on the other components of that product.

This chapter provides background information on RACF and the Tivoli Enterprise Management Environment. Someone familiar with RACF can use the information in this chapter to understand the principles and terminology of Tivoli systems management and a person familiar with Tivoli will find this chapter useful in understanding the concepts and terminology behind RACF.

2.1 OS/390 Unix System Services Overview

The Tivoli Management Agent for OS/390 runs under the OS/390 UNIX System Services (previously known as MVS OpenEdition). It is therefore important to have an awareness of what OS/390 UNIX System services can do. From a Tivoli perspective, OS/390 UNIX System services capabilities are what we can achieve on the OS/390 system through the OS/390 Tivoli Management Agent (TMA or Endpoint).

Today, the OS/390 UNIX System Services are included with the standard OS/390 package. OS/390 Version 1 Release 2 has officially achieved the XPG4 UNIX Profile Brand from the X/Open organization. This means OS/390 UNIX System Services is accepted as a real version of UNIX.

OS/390 UNIX System Services provides support for two open systems interfaces:

• An application programming interface (API)

• An interactive shell interface

With the APIs, programs can run in any environment, including in batch jobs, in jobs submitted by TSO/E interactive users, or in any other MVS application task environment including most other started tasks. A started task in OS/390 is similar to a UNIX daemon, a long-running process. The programs can request:

• Only MVS services

• Only OS/390 UNIX System Services


• Both MVS and OS/390 UNIX System Services

The shell interface is an execution environment analogous to TSO/E with a programming language of shell commands compatible with the Restructured eXtended eXecutor (REXX) language. The shell work consists of:

• Programs run interactively by shell users

• Shell commands and scripts run interactively by shell users

• Shell commands and scripts run as batch jobs

Figure 2. OS/390 UNIX System Services Overview

You can find more information on OS/390 UNIX System Services in the product manuals or at the S/390 web site at http://www9.s390.ibm.com/oe/index.html. For more information about UNIX and initiatives, such as XPG4, visit the Open Group web site at http://www.opengroup.org.

2.2 RACF Overview

The Resource Access Control Facility (RACF) is a component of the OS/390 Security Server that verifies user identities, checks user requests to access resources, logs these access requests, and provides administrators with an interface to administer the contents of the RACF database.

OS/390 Operating System

Language Environment (LE)

OS/390 UNIX System Services

Callable Services

API InterfaceShell Interface(C Functions)(Commands)


To visualize how RACF works, assume that your identity has been authenticated (by RACF), and you then want to access, or modify, an existing RACF protected resource. The request to access a protected resource goes through a system resource manager (also called a control point). Examples of such control point functions could be the OPEN macro (for data sets) or the Transaction Control Program (for CICS transactions). The resource manager will, based on what RACF indicates, either grant an access request or deny it.

Figure 3 shows how RACF interacts with the operating system to allow access to a protected resource. The operating system interacts with RACF in a similar manner to identify and verify users.

Figure 3. RACF’s Relationship to the Operating System

1. A user requests access to a resource using a resource manager (for example, an access method).

2. The resource manager issues a RACROUTE request to see if the user can access the resource.

3. RACF refers to the RACF database or in-storage data.

4. Retrieves data for the profile.

5. Based on the information in the profile, RACF passes the resulting status code for the request to the resource manager.

6. The resource manager grants (or denies) the request.

Note that RACF does not decide whether the request is granted or not. It returns a status code to the resource manager, and the resource manager makes the decision. RACF will return one of four status codes meaning: Has the right, No access, Don’t know, or Not working. The resource manager uses this return to make a decision.

Userrequest

ResourceManager

Racrouteinterface

Operating System

RACFRACFdatabaseorin-storagedata

12

5

3

46

OS/390 Security Server and Tivoli Primer 7

During authorization checking, RACF checks the resource profile to ensure that the resource can be accessed in the way requested and that you have the proper authorization to access the resource. The necessary user/resource requirements must match before the resource manager grants the access request to a protected resource.

Figure 4 illustrates a conceptual model of how RACF checks profiles to ensure who (from user and group profiles) is accessing what and how (from a resource profile).

Figure 4. Conceptual Illustration of RACF Profile Checking

The boxes refer to the installation-assigned attributes and authorities for users and resources that determine which users can access which resources and in what manner.

2.3 System Authorization Facility

The System Authorization Facility (SAF) is a part of the OS/390 operating system that conditionally directs control to RACF, if present, or to a user-supplied processing routine, or both, when receiving a request (such as RACROUTE) from a resource manager. SAF does not require any other product as a prerequisite, but overall system security functions are greatly enhanced and complemented if it is used concurrently with RACF. The key

Request for a resource...

...is granted because the request line intersects all the “boxes”

Request for a resource...

...is denied because the requestline does not intersect all the “boxes”

Protected Resource

User and Group

Access Authority

Protected Resource

User and Group

Access Authority


element in SAF is the SAF router. The SAF router is always present, even when RACF is not present.

The SAF router is a system service that provides a common focal point for all products providing resource control. This focal point encourages the use of common control functions shared across products and across systems. The resource-managing components and subsystems call the SAF router as part of certain decision-making functions in their processing, such as access control checking and authorization related checking. These functions are called control points or resource managers.

2.4 RACF Details

This section provides more detail on the components of RACF.

2.4.1 The RACF DatabaseInformation about all your mainframe users, groups, data sets, and other resources is kept in the RACF database. The records in the database that describe all these objects are called profiles. Hence, we talk about RACF user profiles, data set profiles, and so forth. A resource profile that is used to protect a single resource (a data set (file), a transaction, a cryptographic key, and so on) is called a discrete profile, and a profile that protects multiple resources through wild-cards is called a generic profile.

RACF user profiles and group profiles mostly have a relationship to one another in that every user is a member of at least one group. When a user belongs to a group, we say in RACF that the user is connected to the group. A RACF user profile is divided into segments. Each segment contains the data for a particular aspect of OS/390 user administration, such as the user’s Unix System Services information or the user’s TSO information (see 2.4.4, “RACF Segments” on page 13 for more information).

Profiles that describe RACF protected resources also have an access list that tells which user IDs and what groups have the right to access the resource(s).

A RACF profile is a different term than a Tivoli profile. A RACF profile is roughly equivalent to a record within a Tivoli profile. Therefore, we have a RACF user profile that could be generated from a record within a Tivoli user profile, or a RACF resource profile that could be managed by a resource record within a Tivoli security profile.

Note


This is to say, that access to a resource is based on who you are or which group or groups you are connected to. Not only does the access list tell who is allowed to access the resource(s) but also at what access level (right) they are allowed access.

Remember, a RACF user profile is a description of one user as opposed to the user profiles described later in 2.7, “Tivoli Security Products” on page 24. There is also a difference in the way RACF groups are used within RACF and the way Tivoli terms and uses groups.

2.4.2 RACF User and Group Management ConceptsUser administration in the OS/390 Security Server (through RACF), as in most other systems for controlling user access to resources, should be based on a security policy. The policy sets out the principles of what resources should be protected, who is responsible for those resources, and what the organization that takes care of security looks like. There are many publications that deal with issues surrounding security policy, including an IBM Security Architecture manual (IBM order number SC28-8135) entitled Securing the Open Client/Server Distributed Enterprise. Security Policy is also discussed in more detail in the redbooks SG24-2021 Introducing TME 10 Security Management and SG24-5101 Tivoli Security Management Design Guide.

Based on this policy, you should build a security structure that can fulfill the requirements set out in the policy. When building this kind of a structure, you should try to make it transparent for the users who do not try to bend the rules, and at the same time, design the administration to be as simple as possible.

The basic principle in user administration is to allow the users to access only the resources they need to be able to carry out their job. You should also base access rights on a person's responsibilities, or job role, rather than on the individual's user ID. By sticking to these simple rules, you are making sure that you are not building a structure that will need constant administrative attention but will only require attention when you introduce new resources or when people change responsibilities or job roles.

The OS/390 Security Server (RACF) allows you to meet the above objectives by building a RACF group structure that reflects the many job roles and responsibilities that your company has. The important thing is to start your security implementation by mapping job roles and responsibilities into RACF groups and then to connect your users to the groups that correspond to the job roles they have. Having done this, you will then have to look at your


resources in order to decide what job roles, or responsibilities, should have access to the them and with what authority.

Experience shows that, if you spend time building a good group structure before you start protecting resources, you will not only have well-designed security, you will also have much easier administration. Failing to build a structure mostly implies that you will do custom administration based on individual access rights. This load of administration will tend to increase as you protect more and more resources. Quite soon, you will also find out that individuals not only have access to those resources they need to do their job but also to all those resources that reflect previous jobs and responsibilities. Needless to say, the administration will increase as time goes by, and the audit of this kind of an environment will be hard indeed.

User administration also includes decisions about what applications users need to have access to. Some of these access rights can be handled through group connections, but others have to be handled by defining user attributes or defining additional segments to the basic user profile. Basically, you will have to give users different roles to play and have to define for every role what applications and resources are necessary. RACF in itself does not allow you to define roles, but you can build user definitions that can serve as a model when adding new users to a given role.

Later on in Chapter 5, “Access Control Management” on page 89 there will be a discussion about the Tivoli Security Management product and the facilities to define roles using this product. You will have to consult the Tivoli Security Management documentation to see what RACF profiles and RACF profile classes can be handled with the product's role-based administration. However, the need for a good RACF security structure is equally necessary, whether you are using Tivoli Security Management or not.

2.4.3 RACF User AttributesLooking at the user profiles in a given OS/390 system, there are the normal users, there are managers and there are administrators. In RACF, there are a number of attributes that can give users special rights with respect to resources and with respect to what users are allowed to do with the RACF database. The four most interesting user attributes are:

• SPECIAL

• OPERATIONS

• AUDITOR

• REVOKE


SPECIAL, as a user attribute, means the user is a RACF administrator and has the right to do all the RACF commands and to define every kind of profile in the RACF database. Quite often, this attribute is thought of as having the right to access all the resources on a system (equivalent to the UNIX user root), but this is not the case. The administrator could give himself the rights to access all resources, but that would then show up both in the audit trail and the access lists. So SPECIAL really means you have the right to manage the contents of the RACF database, but with respect to the other OS/390 resources, you are just another user.

OPERATIONS as a user attribute means the user can access all the datasets, as well as resources, defined in a few additional resource classes in the system. The OPERATIONS user can also allocate datasets for any other user in the system. Given these kinds of rights you can easily understand that these rights should not been given lightly. As a matter of fact, there should only be temporary user IDs that have this attribute and that would typically be used in emergency situations. Given that you know who the OPERATIONS users are, you can still stop them from accessing resources by excluding them by use of the access list. All it takes is knowing the user IDs of those that have the OPERATIONS attribute.

AUDITOR, as a user attribute, designates a user who is responsible for auditing the RACF database as well as the system itself (the access logs and system integrity). The AUDITOR attribute gives a user the right to look at all the profiles in the RACF database and also to change the audit attributes for the system as well as for individual profiles. The auditor would also have to analyze the audit logs to follow up on violations and the utilization of certain protected resources.

SPECIAL, OPERATIONS, and AUDITOR attributes can also be given to a user as an attribute applied only to one or more of the user’s connect groups. This is called GROUP-SPECIAL, GROUP-OPERATIONS, and so on, and means you can only use the attribute as far as the scope-of-group extends. Scope-of-group includes all the resources that are owned by the group in which you have one of the special attributes, or any resource, owned by a subgroup owned by the group, and so on.

GROUP-SPECIAL is normally used to enable distributed administration where a department or branch office is taking care of their own RACF administration. Distributed administration requires a well built RACF security structure in order for it to work.

The REVOKE attribute is a way of stopping a RACF defined user from using the system. REVOKE can either be caused by guessing one’s password too


many times, from not logging on to the system for a predetermined number of days, or by an administrator revoking a user’s profile.

There is also a FACILITY class profile that is used by some applications to determine what rights a user has within that application. An example of its use in RACF would be to enable a user the ability to change passwords for other users without requiring the SPECIAL attribute.

2.4.4 RACF SegmentsSegments for RACF user and group profiles are optional extensions to the base profile where you store information that applies to a given application or a management function.

Let us take the user profile as an example. If you should be able to run Time Sharing Option (TSO), you need a TSO segment. To run Customer Information Control System (CICS), you need a CICS segment, and so forth. Each of these segments contain user information necessary for the particular application for which the segment is intended. Depending on your job role, you may need none, or several segments, added to your basic RACF user or group profile.

Tivoli adds segments to RACF group profiles to hold data that helps cross-reference them with Tivoli’s role-based implementation in RACF.

2.4.5 Managing RACF GroupsRACF groups can be used to serve different purposes, and the three most common group types are:

• Resource Protection groups

• Administrative groups

• Functional groups

Resource Protection groups are necessary when it comes to protecting data sets. There are two kinds of data sets: user data sets and group data sets. User data sets are the ones where the first-level qualifier is a user ID; all other data sets are basically group data sets. Before you can protect a group data set, the first level qualifier has to be defined as a RACF group. Before you can protect a data set, such as CICS41.LOADLIB, you would have to define a group with the name of CICS41. Only then can you define RACF data set profiles starting with CICS41 to protect the corresponding data sets.

Administrative groups can be used for information purposes. One common way of using such groups is to build a structure that emulates your company


organization with departments, divisions, etc., and then to connect the users belonging to a department to the corresponding group. When you need to know who works at a given department, you can find it out by listing the group that represents that department. This kind of information comes in handy when you want to know who to inform about a security violation or just need to know where a given user works.

Resource groups or administrative groups should not be used to give users access rights.

Functional groups are the groups that represent job roles or responsibilities and are what you use to give users their access rights. Let us assume there is an accountant job role, and you create the RACF group ACCOUNT to represent this job role. The first step is to connect all the accountants to this group, assuming they have the same access needs in the system. That being done, you would then enter the ACCOUNT group onto all the access lists for the resources that accountants need access. Keep in mind that, even if there is only a single person who has a given job role, you should still create a functional group for it. The idea behind the entire process is that people tend to move, to quit, etc., but the job is still there and has to be done by someone. By simply connecting whoever has a specific task to do to the corresponding functional group, or removing those who are changing jobs, you will also have granted or removed access to the resources necessary to perform the job. Had you instead chosen to give the individual user ID those access rights, you would then have had to revise all access lists twice-- first removing the previous user ID, and then adding the user ID of the successor.

The proper use of RACF groups, and the management of those groups, is a task that is key to the successful implementation of RACF based access control.

An implementation of RACF that uses functional and administrative groups is going to be easier to bring in to the Tivoli role-based security model. See 2.8, “RACF and Role Based Security” on page 26 for more information.

While assigning users to functional groups reduces the administrative overhead associated with someone’s change in status, the Tivoli solution reduces this overhead further by resolving problems, such as the need for users to be members of (or connected to) many functional groups, as well as the fact that Tivoli’s role-based implementation allows roles (similar to functional groups) to be used to specify resource access for resources across multiple platforms, even platforms of different types.


2.5 The Tivoli Management Framework

The following sections provide an overview of the Tivoli management environment. For more complete discussions on Tivoli, you should refer to the product manuals and the following redbooks:

• SG24 4948 - An Introduction to Tivoli’s TME 10

• SG24 2021 - Introducing TME 10 Security Management

• SG24 2015 - Getting Started with TME 10 User Administration

• SG24 2034 - TME 10 Internals and Problem Determination

2.5.1 Overview of the Tivoli FrameworkThe Tivoli Management Framework is the core of the Tivoli Management Environment. The framework is an object-based system that provides services to systems management applications and to Tivoli administrators. These services include scheduling, installation utilities, and notice handling. Administration occurs through a Graphical User Interface (GUI) and a Command Line Interface (CLI). Administration can be divided into Tivoli Management Regions (TMRs), where each TMR has a central server responsible for managing the administration data and authenticating administrators. Tivoli also publishes APIs through their Advanced Development Environment (ADE) and other ways of integrating and extending products, such as the Application Extension Facility (AEF).

Figure 5 is a pictorial representation of the Tivoli Management Framework and how the applications fit around it to utilize framework features.


Figure 5. Tivoli Management Framework Overview

The framework uses an object dispatcher (also known as the oserv daemon) to communicate with other systems in the Tivoli Environment. See Figure 6 for a diagram depicting the Tivoli Management Environment. Each Tivoli Management Region (TMR) is based around the TMR server. Multiple regions can be linked together to share administrative data.

TivoliManagement

PlatformTivoli

Tivoli

Tivoli

Tivoli

Tivoli

(hw and swinventory)

(Event mgmt.)

Tivoli AEF(Application Extension

Facility Toolkit)

Tivoli ADE(Advanced Developer’s

Environment Toolkit)

Tivoli EIF(Event Integration

Facility Toolkit)

Tivoli

Modules(3rd-Party Product

Integration)

InventorySoftware

Distribution

Others...

(Framework)

DistributedMonitoring

User

Tivoli

EnterpriseConsole

SecurityMgmt

Admin

Partner

AEF Extension

Multiple 3rd-PartyIntegration


Figure 6. Tivoli Management Environment

The TMR server maintains a database that is also distributed throughout the machines running the full framework within the TMR (such as the gateways). A gateway provides a fan-out and fan-in mechanism for distributing and collecting systems management data with the endpoints.

What constitutes an endpoint depends on the management function taking place. When we manage user data, endpoints will be servers and other user data systems, such as RACF, Windows NT domain controllers, NetWare servers, LDAP directories, and so on. When we wish to distribute software, or collect inventory data, the endpoints can be servers still, but more likely, we will be working with desktop machines and workstations.

With the installation of the full Tivoli framework (such as that on the TMR server or on gateways), certain application services will be loaded automatically. These include Profile Manager, End Point Manager, Scheduler, and Notices (the bulletin board). A system with the full Tivoli framework installed is known as a managed node. For user and security management, the capabilities of a managed node versus an endpoint are roughly the same. There are some considerations about the use of so-called dataless Tivoli profile managers, and these are explained in the Tivoli product manuals. Some other management operations (such as the use of the Tivoli CLI) may require a full managed node.

The Tivoli Management RegionThe Tivoli Management Region

OS/ 2OS/ 2

EndpointEndpointGatewayGateway


EndpointsEndpointsEndpointsEndpoints

TMR Server &TMR Server &EndpointEndpointManagerManager

Windows NTWindows NTUNIXUNIX


WindowsWindowsUNIXUNIX OS/ 390OS/ 390 OS/ 400OS/ 400


The Tivoli framework installation feature may be used to install other products, such as Tivoli User Administration and Tivoli Security Management, on systems throughout the enterprise.

2.5.2 Tivoli Management Agent on OS/390The Tivoli Management Agent (TMA) runs under OS/390 Unix Systems Services. The TMA communicates with a gateway in the TMR, typically receiving method code to execute management functions and exchanging the management data.

As with any other Tivoli Management Agent, the OS/390 TMA supports the framework Task Library features. With task libraries for OS/390 there is support for the following executables that will run on the OS/390 endpoint (through UNIX System Services).

• OS/390 executables

• Bourne/Korn Shell scripts • REXX exec • Perl scripts (if Perl is installed) • Command support • TSO command • OS/390 Unix commands

• Tivoli NetView for OS/390 release 2 support

• NetView commands • UNIX System Services commands • OS/390 operator commands • Communications Server for OS/390(VTAM and TCP/IP) commands

The terms Tivoli Management Agent (TMA), endpoint, and lcfd are often used interchangeably. TMA and lcfd are roughly equivalent because the TMA is implemented through a daemon usually named lcfd. Endpoint is sometimes used to refer to TMA systems as opposed to managed nodes. We tend to use the term endpoint to mean a target for a management operation. This means that endpoints can include TMAs and managed nodes.

The equivalent terms for TMA and lcfd for a managed node are Object

Terminology


3.7.3, “Task Library Example” on page 63 gives an example of the creation of a task library and a simple task. Refer to the product manuals and Chapter 3, “Getting Started” on page 29 for more information on TMA for OS/390.

At this time of writing, the TMA is the principle method for integration of OS/390 with Tivoli. Around the third quarter of 1999, it is intended that the TMR server function will be available on OS/390. You can watch Tivoli product announcements for details, or refer to Tivoli’s web pages, for product information (http://www.tivoli.com). Migration from one server platform type to another is a supported operation in Tivoli; therefore, starting with a platform available now and moving to OS/390 as a TMR server is feasible.

2.6 Secure Delegation of Administration

Within the Tivoli framework GUI, administrator access is controlled by the Tivoli Desktop. Each administrator’s desktop may be defined to only have access to specific functions within the Tivoli environment. Security from the CLI is controlled by the ID that the administrator has connected to the network. This ID is linked to the Tivoli administrator within the framework.

Tivoli achieves secure delegation of administration through a number of features that are discussed in this section:

• TMR Roles • Policy Regions • Administrator Desktop • Profile Managers and Profiles • Tivoli Administrator to endpoint ID mapping • Administration through tasks and scripts

For some of these features, see 3.1, “Design Guidelines” on page 29 for information on specific considerations for RACF .

Much of what can be determined for a Tivoli administrator can be defined through the Tivoli CLI commands, such as wcrtadmin and wsetadmin, allowing the creation and maintenance of administrators through scripts. Information about a Tivoli administrator, such as roles and notice group subscription, can be retrieved through the wgetadmin command.

2.6.1 TMR and Resource RolesTivoli administrators can be assigned ‘roles (not to be confused with Tivoli Security Management roles and role-based security discussed in 2.8, “RACF and Role Based Security” on page 26). These roles, combined with what is


made available on an administrator’s desktop, are a major way of determining what administrative functions that person can perform. The roles available depend on the application but include names, such as super, senior, user, and security_admin. For example, a Tivoli administrator cannot modify TSM security profiles without the security_admin role.

Depending upon implementation by the Tivoli application, roles can be assigned at the TMR level or at the resource level. TMR-level roles apply to the administrator across all resources in the TMR, and resource-level roles can specify what role a Tivoli administrator has over a particular resource.

2.6.1.1 Fine-Grain RolesWith release 3.6.1 of TSM, Tivoli is introducing a more granular approach to administrator roles. These so-called, fine-grain roles, allow a much finer definition of what an administrator can do.

In many cases, enterprises want to be able to delegate system administration tasks down to the department level and/or to support groups like help desks. In order to facilitate this requirement, Tivoli defines operational level authorization roles. These operational roles are defined for both Framework application services (such as Policy Regions, Profile Managers, and so on) and Tivoli applications themselves. For example, SecMgt_Mod_Group is a new role that allows the administrator assigned that role to modify TSM group records already defined in a Tivoli security profile, but not add new ones or remove existing ones.

There are 25 new fine-grain roles for TSM, and these are described in the release notes for TSM 3.6.1.

2.6.2 Policy RegionsA policy region is a way of logically grouping together resources that will be subject to a similar management policy. The region is only viewable if exposed to an administrator’s desktop and contains management resources, such as user and security profiles, sub-regions, profile managers, and so on.

Figure 7 shows the hierarchy of resources under regions.


Figure 7. Tivoli Resource Management Hierarchy

For each policy region, you can determine the following:

• What types of resources can be managed within that region. If a region does not have the user profile as a managed resource, then no administrator will be able to create a user profile within that region. An administrator with the right authority role in the TMR can determine which resources are managed in which policy regions.

TMRContains TMR Resources

(Administrators, Notice Board, Policy Regions, and so forth)

Contains Managed Resources(Nodes, Subregions, Profile Managers....)

Profile Manager Contains Profiles(For example a User or Security Profile)

Profile Contains Subscribers & Resource Records(Records of the Profile type/subtype)

Record Properties

Policy Region


Another possible use of managed resources might be to enable a particular resource to be managed in a policy region, create an instance of the resource, and then remove that resource type from those managed by the region. This would allow the existing resource to still be manipulated, but no new instances of that resource could be created. This works for certain resources, such as user profiles.

• Default and validation policies for all resources of certain types in the region.

2.6.3 Administrator DesktopAn administrator using the Tivoli desktop on a machine, other than a Tivoli managed node, has no way of administering systems other than through the desktop. Currently, on any Windows-capable system, or by using an X-windows session to a UNIX managed node, administrators can be given the desktop. Future implementations of the desktop will be Java based and will, therefore, run on any suitable Java platform.

An administrator’s desktop can be made to show only the systems and management data that the administrator should have access to.

2.6.4 Profile Managers and ProfilesWhat administrators can achieve will depend on what profile managers and profiles are on their desktops and what roles they have for the TMR or the resources. With the introduction of TMA endpoints, we have two types of profile managers: dataless and database.

A TMA endpoint subscribes to what is known as a dataless profile manager, thus called because, besides caching, the information from the profile manager is not maintained in a database on the subscriber (as opposed to managed nodes that do maintain profile databases). A system with the full Tivoli framework installed (such as a managed node) can be subscribed to a database profile manager. This requires a great deal more code and space on the managed node than is required for an endpoint. In most installations from 3.6 onward, the typical configuration for managed machines will be as TMA endpoints and not managed nodes.

Refer to the Framework product documentation for more information about profile manager types.

2.6.5 Tivoli Administrator to Endpoint ID MappingIn general, the Tivoli administrator needs to be mapped to a reasonably powerful administrator ID on the target system. For example, to administer


RACF through Tivoli, the Tivoli administrator’s ID must be mapped to a RACF user ID with the ‘SPECIAL attribute. You might consider giving administrators two RACF IDs, one mapped to a Tivoli administrator, and one used by the same person when logging on locally.

This allows an auditor to distinguish between administrative actions taken through Tivoli and locally. An action taken through Tivoli may require further investigation to determine who made the exact change, as it may not have been the same person who distributed the change to RACF. (See 6.5, “Tivoli Notice Groups” on page 116).

Also, you may not wish to allow a Tivoli administrator to log on using the same RACF user ID, as they will have the capability to perform any action in RACF.

2.6.6 Administration through Tasks and ScriptsA Tivoli administrator can be given very restricted roles within the TMR and achieve what is required for administration through Tivoli tasks and scripts that include Tivoli commands. The tasks can be defined to run with the required level of authority without the administrator initiating the task requiring the same level. The task can be made to run with an ID determined by the task’s author that has the required level of authority. See 3.7.3, “Task Library Example” on page 63 for more information about tasks.

2.6.7 Default and Validation PolicyDefault and validation policy are features that apply to Tivoli data stores such as records. Default policy determines what should go into a new record field if the administrator does not enter anything into that field. The policy can be script-based and can calculate a field entry based on what is entered in other fields ensuring consistency among different fields in the same record. This can result in a great deal of time saved when generating a new user, as many of the fields can be defined in default policy. Default policy is run when the administrator chooses Set Defaults when creating or editing a record, or when the record is closed after being created or edited.

Validation policy checks each updated field in a record to ensure that the field value is within preset criteria. Validation policy can also be script-based and is a powerful way of ensuring junior administrators define records conforming to an enterprise policy, or to avoid selecting values that are acceptable to RACF but that do not make sense in your environment. Validation policy is run when a record is populated, copied, or otherwise altered by an


administrator. If default policy is being run, such as at the closing of a record, then validation policy runs after it.

Tivoli provides a large number of default and validation policies for many of the fields in user and security records. However, it is very likely that an organization implementing Tivoli will want to either modify those in place or add their own.

Extending policies, along with altering the products through the Application Extension Facility (AEF), are common ways to add function to a Tivoli security implementation. Refer to 4.2.1, “Examples of Default and Validation Policy” on page 69 for more on default and validation policy, and see 4.4.2, “Adding a Custom Action to a User Profile” on page 78 for a simple example of extending function by adding an action to be executed when management data is sent to an endpoint.

2.7 Tivoli Security Products

The Tivoli Management Framework has a number of products in the security discipline, including single-signon. The two main security products we will work with for RACF administration are: Tivoli User Administration (TUA) and Tivoli Security Management (TSM). Tivoli User Administration is used to create and maintain RACF user profiles; TUA deals with fields, such as passwords, user accounts, default groups, and so on. TSM uses a role-based security model to grant access to resources. You can define RACF resources and groups and use Tivoli roles to determine access control.

In order to manage RACF, we use modules to extend TSM and TUA. The modules to manage RACF are called Tivoli Security Management for OS/390 and Tivoli User Administration for OS/390. Tivoli User Administration can be used independently of Tivoli Security Management in situations where only one or the other is required.

2.7.1 Tivoli Security ManagementTSM provides access control management for UNIX systems and Windows NT Domains. The product enforces a consistent security policy. This is achieved through various features, such as the distribution of a Tivoli profile to multiple endpoints and the control over what may be entered into a security record. The major innovation in Tivoli Security Management for OS/390 is the implementation of role-based security under RACF. Role-based security moves away from a traditional view of grouping users based on the access they require to resources (especially prevalent in UNIX systems but also used


in RACF). Instead, users are grouped logically, based on their job in an organization. All those with the same job can be grouped together.

The access to resources is determined by roles. A role equates to a job function and defines all the resources and access rights to enable someone with that job function, or role, to perform the desired tasks. So, for example, a technical author will have roles, such as Write book, which will define access to printers, writing applications, and data, as well as the systems that person might need access to. The same person might also have a role of Building 45 employee, defining access to a building, systems in use in that location, and so on. The technical author will be a member of a group of authors located in Building 45, and the group will be given the roles required to perform the task. A role may apply to many different groups; so, for example, many groups will have the Building 45 employee’ role.

Once implemented, management of access in a role-based system is greatly simplified. Using the previous example, if a new printer is placed in building 45 that needs to be accessible by all, it simply needs to be added to the Building 45 employee role and all people, in all groups with that role, will get the access. Also, if an employee changes jobs, then removing them from their existing group and placing them in a new group will delete all old access rights and create all the required new ones a single action to modify rights across multiple systems and many resources.

While Tivoli Security Management makes role-based security and single-action management possible, implementing good role-based security requires a great deal of planning and investigation of roles. The redbook, Tivoli Security Management Design Guide, SG24-5101, is on the subject of designing a security management implementation.

There are a few RACF classes not managed by TSM. Examples include VMEVENT and VMXEVENT. Refer to the product documentation for details.

2.7.2 Tivoli User AdministrationThe core TUA product manages UNIX, NetWare, and Windows NT user data, with other platforms and applications being supported through the add-on modules. Each module adds attributes to a Tivoli user record, enabling the same record to be used for all the endpoint types. Tivoli User Administration for OS/390 supports all RACF user segments. Previously, Tivoli managed a limited set of RACF user segments through a product called TME 10 Global Enterprise Manager (GEM) User Administration. The GEM User Administration function has been moved out of the GEM product and into TUA for OS/390, which supports all user segments. TUA for OS/390 also


implements default and validation policy, which GEM User Administration did not.

2.8 RACF and Role Based Security

As mentioned earlier, RACF does not natively support role-based security to the degree available through Tivoli. What you can do is to build a structure of groups, where the functional groups can be used to represent a given job role. A functional group is entered onto each resource access list that is necessary for someone in a particular job role. Each user is then connected to those functional groups that represent all the job roles and functions he/she is to perform. In other words, one or more functional group can be used to represent a role, but RACF, in itself, does not recognize roles nor does it treat one group differently from another. Therefore, it is up to the RACF administrator to build a structure that lends itself to defining the roles. RACF, as a tool, will allow for any structure that makes sense to you.

Whatever you do, you should never plan on allowing access based on individual user IDs. It is all too easy to say just this once, but after a while, you will have created a structure that needs more and more revision every time a user changes jobs or moves to another department.

The Tivoli model of role-based security provides a three-tier hierarchy for configuring access to resources. The lowest level of the tier are the resources themselves. A resource can be many different things such as various dataset types in OS/390, or TCP/IP services in UNIX, or shares in Windows NT, and so on. The resource record also defines the default access any user would have to that resource if no other access rights are defined. The second tier of our hierarchy is the role. A role defines specific access rights to resources and groups. These resources together are to be managed as a single unit. A group is then assigned one or more roles, and by membership of that group, a user will have the access permissions defined in the associated roles to the resources in those roles.

The benefits of role-based security include:

• A single Tivoli role can define access to many different types of resources across all the platforms supported by TSM. Therefore, the redbook Writer role can define access to applications on UNIX and WIndows NT, datasets on OS/390, a database on OS/400, and so on. Any group with the redbook Writer role will be given the correct access rights to all the resources on all the platforms to which the Tivoli security profile is distributed.


• Large number of access permission updates can be achieved in a single action. Moving a user from one Tivoli security group to another can result in access rights changing for hundreds of resources defined in the many roles of multiple platforms. Users do not accumulate access as they move around the company, unless you want them to.

• Group membership is simplified. Users will typically become members of a very small number of groups, maybe just one or two. The group will define the job they do, and the roles they perform in that job will be matched by Tivoli security roles defining access to the required resources.

• Adding new resources is easy. Adding a resource to a role makes it available to all the users in all the groups that have that role. See 5.3.3, “User Consideration when Adding a Resource” on page 94.

In a Tivoli security profile, we can define RACF resources and manage them in Tivoli, or we can simply refer to the resources that exist on the endpoints by name. RACF resources for TSM may be discrete dataset profiles, generic dataset profiles, and general resource profiles.



Chapter 3. Getting Started

This chapter includes information related to the installation and initial configuration of the Tivoli products in an OS/390 environment. We will cover some design considerations, preparation for the target environment, tips on getting the installation right, setting up administrators, checking the installation of the OS/390 endpoint, and a few items on getting the first data into Tivoli.

3.1 Design Guidelines

This section details some information that should be considered when designing the Tivoli solution. Some items are actually not used until implementation but should be understood to ensure a good design.

3.1.1 Capacity Planning IntroductionDue to the variable nature of the data involved, it is difficult to provide exact data to assist in capacity planning. The product release notes and the product program directory documents provide some basic information, such as space requirements for the code and other prerequisites.

During our experimenting with the products, we found that capacity planning should take into consideration the following factors:

• Number of users in a Tivoli user profile

• Number of platforms supported by the profile

• Number of changes before a distribution of a profile

• Number of layers in the distribution

A description of each consideration now follows:

3.1.1.1 Number of Users in a Tivoli User ProfileThis factor effects distributions (see “Number of Changes Before Distribution of a Profile” on page 31) and the performance of the GUI. Displaying a GUI table that has a few hundred users is a relatively fast and trivial task. On a reasonable desktop system with a good connection to the server, the display time would be in the order of seconds. However, displaying ten thousand users could increase the time required to a number of minutes.

The number of records also determines how long it will take to complete a populate, or distribute, action. The actual time will depend on network connectivity, speed of systems, and so on, but a populate of 5000 records


into a Tivoli security profile (such as a mix of groups roles and resources) could take a number of hours. This may not be too much of a problem for populate, as it is generally only run a few times to get things set up. However, distributing many thousands of new security definitions in one profile can also take in the order of hours. The first distribution after a populate will take the longest, as all records are distributed after the initial population. Subsequent distributions only send the changed records.

Populating and distributing RACF group information through Tivoli security groups is a more complex task for the code than roles and resources and will take longer.

What is reasonable in your own environment will depend on factors, such as the number of changes between distributions, the amount of GUI versus command line usage, and so on. It is possible to manage a Tivoli user profile with around 2000-5000 records and a security profile of a similar size. In a large organization, it is often necessary to divide administration among administrators (either in a central team or in remote locations). The boundaries of administrative responsibility are one way to divide up the user population into manageable pieces. One administrator may handle twenty profiles of 1000 users in each. 100,000 users in this model would be manageable by five administrators. In each case, it is important to model the administration burden and test it.

3.1.1.2 Number of Platforms Supported by the ProfileTo improve performance, platforms that are unused in a profile can be removed from the GUI (through AEF) and, at the very least, default and validation policies should be disabled to prevent the running of many unnecessary scripts. The more platforms supported in the same profile, the more data storage required for each user and the more policies that will be run during user updates. Also, one thing to consider is the fact that when a record changes, the whole record is sent to the subscribing endpoints. This means that the OS/390 endpoint could also receive the data for Windows NT, NetWare, UNIX, and so on. This distribution of the whole user record has

Internal testing of large populations (10000+ records) occasionally resulted in a SIGXCPU error being logged in the lcfd.log under UNIX Systems Services on the OS/390 endpoint. These errors were eliminated by increasing the values for MAXCPUTIME and MAXASSIZE. The system in question improved with SETOMVS MAXCPUTIME=100000. Check the product manuals and release notes in case further details have been recorded there.

SIGXCPU Error


some performance advantages in terms of calculations required during a distribution but introduces potential delays related to the volume of traffic (see also “Number of Changes Before Distribution of a Profile” on page 31).

Depending on the administrative design, it may be reasonable, in some implementations, to limit profiles to specific platforms. Links can still be made between profiles to achieve cross-platform management (such as the placement of users into security groups).

3.1.1.3 Number of Changes Before Distribution of a ProfileWhen a change is made to a record in a profile, whether it is a user record in a user profile, or a group, role, or resource record in a security profile, that record is marked as changed, and only changed records are distributed at the next profile distribution. The exception is if you use the EXACT COPY distribution option, which sends all of the records in the profile to the endpoint.

Therefore, the more records that are changed before a distribution, the longer a distribution will take. If your environment is one in which every user experiences a configuration change every week, you will need to maintain users in smaller (200-500) Tivoli user profiles to reduce the time it takes to distribute each profile.

3.1.1.4 Number of Layers in the DistributionWhen a TMR design includes a hierarchy of Tivoli profile managers (hierarchical profile manager design is covered in the product manuals and in SG24-5108 Tivoli User Administration Design Guide), there is processing involved at each level during an all levels distribution. This is one reason for the recommendation of a reasonably flat profile manager hierarchy.

3.1.2 Automating Aspects of User CreationA number of ideas exist regarding the partial automation of the definition of user records, including:

• Skeleton user records

• Default policy enhancements

• Corporate databases as user data sources

TUA allows you to clone existing users to create new ones. A profile can be created that is never distributed to endpoints. Its purpose is simply to contain user records resembling the most common types of users in an organization with many of the attributes already set. A new user is then cloned from the

Getting Started 31

existing records and placed in a user profile that will be distributed to the required endpoints.

Many TUA implementations involve some sort of customizing. Apart from adding actions and new fields with AEF, it can be very useful to modify default and validation policies for attributes. A default policy can provide values for attribute fields automatically when an administrator does not provide a value. See 4.2.1, “Examples of Default and Validation Policy” on page 69 for more information.

The creation of users can be performed from the command line, and user records can be merged. These two facts provide the capability to generate users based on information that already exists in databases, such as a corporate human resources database. We can use a script to take information from an HR database and place details into a Tivoli user profile record. That record could be merged with a standard record for that type of user, and so on, to produce a user record with most of the data filled in.

3.1.3 Archival of Tivoli User and Security DataIn some installations, it is desirable to maintain archives of the user and security data used to manage systems. There are a number of pieces to this, some of which can be handled within Tivoli.

System-specific utilities Many systems provide some way of logging the state of user and security data. In the event of a query, that data can be reviewed to determine the user and security state of a system for any given period of time. The use of dedicated tools to do this is likely to be the best way to achieve this capability.

Archival of Tivoli Profiles It may be that, rather than identifying the state of the system files at any given time, the requirement is to know the state of the Tivoli data at any given time. At the simplest level, much of this can be determined from the notices logged by TSM and TUA following administrator actions. If it is necessary to know details of how a particular Tivoli user record looked, another possibility is to initiate some process for the archival of Tivoli profile data. Suggested methods include the scheduled, or triggered, use of scripts to export Tivoli data to flat files to be archived, or the use of Tivoli profiles in profile managers reserved for the purpose of archives. These archival profiles are never distributed to endpoints. A deleted user could be first cloned to an archival profile, so that, if that user will need recreating for some reason, the user record can be easily retrieved.


3.1.4 Use of Tivoli Alongside RRSFThe RACF Remote Sharing Facility (RRSF) allows RACF to communicate with other MVS systems that use RACF, allowing the maintenance of remote RACF databases. RRSF enables the automatic synchronization of RACF databases; when a change is made in one database, RACF can automatically make the change to other RACF databases. This can apply to all, or just certain selected parts, of the database. A similar capability is available through Tivoli, in that we can use the same central Tivoli management data and distribute it to multiple RACF databases.

We found no special considerations regarding the choice of RRSF or Tivoli for the management of multiple RACF databases. The choice of how to use either or both will depend on existing configurations and administrative preferences.

Note that a given RACF node should not receive the same updates from both RRSF and Tivoli. This wastes network bandwidth and generates superfluous database I/Os. In an RRSF configuration, the source RACF database would be the one subscribed to Tivoli profiles.

However, we found at least one case where using Tivoli had an advantage over RRSF. Suppose you create a UNIX System Services user segment in a RACF user profile. This action through RACF or Tivoli does not create a home directory for that user that is a separate manual action. With Tivoli, we can achieve this through a single script that is run at each endpoint when the Tivoli user record is distributed to RACF (see 4.4.2, “Adding a Custom Action to a User Profile” on page 78). With RRSF, we would need some, perhaps more complicated, procedure to create the home directory in UNIX System Services on each OS/390 system where the RACF database information was replicated.

3.2 Preparation for Use of Tivoli Management

Before installing a system of management through Tivoli, the initial planning and preparation should include:

• Synchronize user IDs

• User and Security Record Management

• Apply a naming convention

• Synchronize password quality rules

These topics are discussed in more detail in the following sections.

Getting Started 33

3.2.1 Synchronize User IdentificationAll hosts of the same operating system type should ideally use the same user ID for a single person. This synchronization should also extend to all related items, such as home directories (if there are more than one) and accounting information. This enables us to manage the user from a single Tivoli user record. The record, as one of many in a Tivoli user profile, will be distributed to all subscribing endpoints. If two of the desired endpoints use a different user ID, or other data, the same person must use two different user records and subscribe each of them to one of the two machines.

Synchronizing data on like platforms reduces the number of Tivoli records required. A single user record can define different parameters (such as the user ID) for different platform types, so it is not essential to synchronize data across all platforms although that can also help to reduce management effort.

There are some examples where the user data cannot be synchronized on multiple systems. Suppose, for example, you have a user in two MVS systems that are in different DCE cells. Each RACF user profile must have some unique data associated with the DCE cell. This would require two records in a Tivoli user profile, each holding the unique DCE data. In cases like this, there may be alternatives. For example, it may be possible to manage the DCE data separately through a DCE management module in Tivoli, or the administrative hierarchy might be that most of the user data (minus the DCE data) is managed in a single Tivoli user profile. But two DCE administrators at a lower level in the distribution hierarchy maintain their own Tivoli profile with their own copy of the user record including their own DCE data. Such a design would have to ensure that lower level data is not overwritten by all-level distributions.

3.2.2 User and Security Record ManagementAn ideal role-based implementation can result in a great many changes occurring automatically in response to simple administrative instructions. For example, by moving a user from one Tivoli security group to another, all previous access rights associated with that group through the Tivoli security role can be removed from that user, and all new access rights can be created, or the addition of a resource to a role can grant the necessary access to those resources to all users that are in the member list of the Tivoli security groups.

This is a very powerful feature and one that can save a lot of administrator time. However, there are a number of considerations that should be accounted for.


The right groups should be in place on any system where they are referred to by a role. This can be largely dealt with by defining those groups within Tivoli but if the profiles that contain the groups are separate from those that contain the roles, then they must also be distributed to the same endpoints as the roles.

3.2.3 Apply a Naming ConventionThere is likely to be some advantage in utilizing a naming convention. This topic is handled in more detail in the redbooks SG24-5101 Tivoli Security Management Design Guide and SG24-5108 Tivoli User Administration Design Guide. A naming convention for users and groups helps reduce the number of Tivoli records and profiles required (see “Synchronize User Identification” on page 34), and naming conventions for Tivoli management objects help in the scripting of administrative tasks.

Whatever is determined to be acceptable for object names, it is very important to have it well documented and to ensure that the convention is adhered to.

3.2.4 Synchronize Password Quality RulesTivoli provides tools to reset passwords for all endpoints subscribed to a particular user record. Therefore, using wpasswd, or the OnePassword web tool, an administrator or the user, can reset a user password on all platforms. However, different platforms can have different password quality rules. What may succeed as a password on one system, can fail on another. This could result in the password being changed on some platforms and not others.

The user must exist on any system where access to a new resource is to be added. TSM does not perform any cross-checking with TUA to ensure a user listed in a Tivoli group record will actually exist on the endpoint. This may require an awareness that a Tivoli user profile must, in some cases, be distributed before a Tivoli security profile.

Note

As with Windows NT global and local groups, RACF groups are managed entirely through TSM group records in the security profile. The TUA group profile has no effect on RACF groups.

Note

Getting Started 35

If the password quality rules are as close as possible on all systems, and the user is directed to always use the most strict rules, then this problem can be avoided. Another option is to utilize some password changing tool that performs the checks and then calls wpasswd to perform the change on all the systems. Scripts and tools that work with user IDs and passwords from RACF, as well as distributed systems, need to be sensitive to implications of upper and lower case usage.

Note that there are some extra considerations when using wpasswd. For example, wpasswd requires the object dispatcher (oserv) to be running on the machine where the command is issued, as well as on the TMR server. Refer to the Tivoli User Administration User and Group Management Guide for more information on wpasswd.

3.3 Installation Tips

This section includes information based on our installation experiences. It is most likely to be of interest to those familiar with OS/390.

Check all product release notes and the OS/390 product documentation, such as the program directory notes, before attempting an install. There follows a description of our test environment. This is followed by items to note about installation. Note that this is not intended to be complete step-by-step install instructions. These are items you need to be aware of to ensure a successful install.

3.3.1 TMR ServerOur test TMR server was an IBM PC Pentium 166Mhz running Windows NT 4.0 with Service Pack 2 installed. In a live environment, the TMR server should be a powerful PC or UNIX system with adequate disk space and RAM. Refer to the Tivoli Management Framework Planning and Installation Guide for more guidance.

We installed the following Tivoli products on the TMR to manage the RACF component of the OS/390 Security Server:

The OnePassword web password changing tool was a Technology Preview item at the time of writing. This is not supported in the same way as other Tivoli products. Refer to the documentation for OnePassword for details.

Note


• Tivoli Framework 3.6

+ Tivoli Framework patch 3.6-TMF-0005 (Tivoli Support of OS/390 Agents)

• Tivoli User Administration 3.6

• Tivoli User Administration Services for OS/390 - Tivoli Server Install Pack

(This contains the AEF-based enhancements for the TUA v3.6 product)

• Tivoli Security Management 3.6

+ Tivoli Security Management patch 3.6-SEC-0003

• Tivoli Security Management for OS/390 - Tivoli Server Install Pack

(This contains the AEF-based enhancements for the TSM v3.6 product)

3.3.2 Tivoli GatewayIn the test environment, we used the TMR server as our endpoint gateway. In live environments, there will typically be a number of Tivoli managed nodes designated as gateways. We installed the following Tivoli gateway software:

• Tivoli User Administration 3.6 Gateway Package

• Tivoli User Administration Services for OS/390 3.6 - Tivoli Gateway Install Pack

• Tivoli Security Management 3.6 Gateway Package

• Tivoli Security Management for OS/390 3.6 - Tivoli Gateway Install Pack

3.3.3 OS/390 Tivoli Framework InstallationThe Tivoli Framework is installed through normal SMP/E installation procedures, either through a version or release upgrade of OS/390, or a specific Tivoli product installation through the CBPDO process.

3.3.3.1 SYS1.PARMLIB update for the OS/390 TMAThe Tivoli Framework code is installed in both OS/390 data sets and in the UNIX Hierarchical File System (HFS).

The Tivoli Framework target libraries are:

• hlq.SFMEMOD1 • hlq.SFMELPA1

The data set ending with SFMEMOD1 needs to be added to the so called LINKLIST by adding the library definition to member PROGxx (for a dynamic linklist definition) or LNKLSTxx (for a static linklist definition).

Getting Started 37

The data set ending with SFMELPA1 needs to be added to the so called LPALIST by adding the library definition to member LPALSTxx.

The OS/390 system needs to be re-IPL-ed for the changes to the LPALIST to take effect. After the system has been IPL-ed, the rest of the installation steps can continue.

3.3.3.2 SMP/E Installation of the OS/390 TMAAfter the SMP/E RECEIVE process, you should run job FMEISDKD to create the Tivoli Framework HFS (Hierarchical File System) structure. This job will execute the FMEMKDIR REXX procedure to actually create the HFS. You might have to tailor the invocation of this REXX procedure to suit your installation. Our invocation of the REXX procedure looked like this:

FMEMKDIR /

Therefore, we installed our Tivoli Framework HFS from the root.

After successful completion of this job, you can continue the SMP/E APPLY and ACCEPT process.

After installation, you should have the following HFS directory structure:

Base Install Directory /usr/lpp/Tivoli/lcf/

Endpoint Executable /usr/lpp/Tivoli/lcf/bin/os390/mrt/lcfd

DLLs /usr/lpp/Tivoli/lcf/lib/os390/

LNKLST Add Name(LNKLST00) Dsname(SYS1.SFMEMOD1)

Menu Utilities Compilers Help BROWSE SYS1.PARMLIB(LPALST00) - 01.09 Line 00000000 Col 001 080 ********************************* Top of Data **********************************SYS1.LPALIB, ISF.SISFLPA, ISP.SISPLPA, SYS1.ISAMLPA, SYS1.SORTLPA, SYS1.SICELPA, TCPIP.SEZALPA, EOY.SEOYLPA, SDF2.V1R4M0.SDGILPA, CICS.V4R1M0.SDFHLPA(ICFCIC), SYS1.SFMELPA1 ******************************** Bottom of Data ********************************


Preload /usr/lpp/Tivoli/lcf/preload/

Runtime Data Location etc/Tivoli/lcf/dat **

** This is the default directory specified in the lcfd.sh shell script. It must be writeable because the program creates files and directories while it executes. You can select any directory for the runtime files, but if you choose another directory, you should copy lcfd.sh to that directory and edit it to set LCF_DATDIR to the desired directory.

The following directories are used by SMP/E for installation and must not be deleted:

/usr/lpp/Tivoli/lcf/bin/os390/mrt/lcfd/IBM

/usr/lpp/Tivoli/lcf/lib/os390/endpoint/IBM

3.3.3.3 Configuration of the OS/390 Security Server (RACF) The Tivoli Management Agent (TMA) requires some security definitions to let the TMA function properly on OS/390.

The TMA runs a so called started task on OS/390. Each started task will need a user ID associated with it for access control purposes. To associate a user ID with a started task, you can either define a profile in the RACF STARTED class or in the Started Procedure Table (ICHRIN03). To define a profile in the STARTED class, you use the RACF RDEFINE command. Resource names in the STARTED class are of the form member.job, where:

member is the 1-to-8 character name of a member of a partitioned data set that contains the source JCL for the task to be started. The member can be a job or a cataloged procedure.

job is the name identifying the task to be started.

Profiles in the STARTED class include the STDATA segment, which contains fields for user ID, group ID, trusted flag, privileged flag, and trace flag:

• The user ID can be a RACF user ID or the character string =MEMBER, which indicates that the member name is to be used as the user ID.

• The group ID can be a RACF group ID or the character string =MEMBER, which indicates that the member name is to be used as the group ID.

Although you are not required to install into the subdirectory /usr/lpp/Tivoli/, you are required to maintain the directory structure, as described above.

Note

Getting Started 39

• If tracing is specified, RACF issues operator message IRR812I during RACROUTE REQUEST=VERIFY or VERIFYX to indicate which profile is used.

We will start the endpoint (TMA) automatically, so it will be assigned LCFD as defined in /etc/rc file (see section 3.5, “Starting OS/390 Tivoli Management Agent” on page 50). The RDEFINE command will look like this:

RDEFINE STARTED LCFD.** STDATA(USER(OMVSKERN) GROUP(OMVSGRP) TRACE(YES))

The RACF class STARTED is a RACLISTED class, which means that a copy of all the profiles in that class are copied in to memory rather then having to access the profiles from the RACF database. Therefore, when this new definition is made, you probably would have to refresh the STARTED class through the RACF SETROPTS command, as shown here:

SETROPTS RACLIST(STARTED) REFRESH

If your installation has not migrated yet from the static Started Procedures Table (ICHRIN03) to the RACF STARTED class, your definition would look like this:

Note: This represents only part of the assembler source of a given ICHRIN03.

In case the user ID OMVSKERN and group OMVSGRP do not exist in your installation, they need to be defined as follows:

ADDGROUP OMVSGRP SUPGROUP(xxxx) OWNER(yyyy) OMVS(GID(1))

where xxxx is the RACF superior group, and yyyy is the RACF owner of this group.

ICHRIN03 CSECT TITLE ’ICHRIN03 - STARTED PROCEDURES TABLE’ EJECT DC XL2’800B’ NEW FORMAT - 11 ENTRIES * DC CL8’JES2 ’ PROCNAME - SPECIFY YOUR JES DC CL8’XXXXXXXX’ USERID DC CL8’YYYYYYYY’ GROUP DC XL1’40’ TRUSTED DC XL7’00’ RESERVED * DC CL8’LCFD ’ PROCNAME DC CL8’OMVSKERN’ USERID DC CL8’OMVSGRP ’ GROUP DC XL1’00’ NOT TRUSTED DC XL7’00’ RESERVED


ADDUSER OMVSKERN DFLTGRP(OMVSGRP) OWNER(OMVSGRP) OMVS(UID(0) HOME(’/’) PROGRAM(’/BIN/SH’))

As described in section 3.3.4, “TMA Method Preload Function” on page 42, there are specific security considerations for OS/390 as an endpoint. To enable what is known as MVS-level security, we will have to set up RACF program control for specific libraries, such as the TMA code itself and the language environment libraries.

In most installations, RACF program control is already active to check whether program control is active, issue the following command:

SETROPTS LISTATTRIBUTES = INITSTATS WHEN(PROGRAM) SAUDIT CMDVIOL OPERAUDIT

In the attribute section of the SETROPTS output, you will see either when(program) or nowhen(program). When (program) means that program control is active.

You need to define a RACF PROGRAM profile called * (asterisk) and add the following libraries to that definition:

LE370.V1R7M0.SCEERUN The language environment runtime library

SYS1.LINKLIB The system link library

hlq.SFMEMOD1 The Tivoli Management Agent code

The profile is added with the RACF RDEFINE command:

RDEFINE PROGRAM * ADDMEM(’LE370.V1R7M0.SCEERUN’/xxxxxx/NOPADCHK,’SYS1.LINKLIB’/xxxxxx/NOPADCHK,’hlq.SFMEMOD1/xxxxxx/NOPADCHK) UACC(READ)

where xxxxx - is the volume serial where the library resides. This has become optional in later versions of the RACF component of the OS/390 Security Server.

Here is an overview of what our definition looked like:

Note: The UACC(READ) is essential. If you forget to specify that, nobody will be able to execute any program out of those libraries.

Note

Getting Started 41

When a new definition is added to the PROGRAM class, it needs to be refreshed as well. This is done with the following command:

SETROPTS WHEN(PROGRAM) REFRESH

The TMA requires a default user ID called NOBODY. This user ID should have an OMVS segment with nonsuperuser authority.

This user ID can be defined with the RACF ADDUSER command, such as:

ADDUSER NOBODY DFLTGRP(xxxxxx) OWNER(yyyyyy) NAME(’TMA default userid) OMVS(UID(555) HOME(’/’) PROGRAM(’/BIN/SH’))

Where xxxxx is the RACF default group for the user ID, and yyyyy is the owner of the TMA default user ID.

There will be other security definitions required depending on how the TMA is started. Refer to section 3.5, “Starting OS/390 Tivoli Management Agent” on page 50 for more information.

3.3.4 TMA Method Preload FunctionIn many of the supported endpoint platforms, the Tivoli application methods that perform the management functions are downloaded from a gateway to an endpoint and then executed. These methods can be cached on the endpoint, so that the next time the same method is invoked, a local copy can be used rather than downloading it from the gateway again.

RLIST PROGRAM * ALLCLASS NAME ----- ---- PROGRAM * MEMBER CLASS NAME ------ ----- ---- PMBR DATA SET NAME VOLSER PADS CHECKING -------------------------------------------- ------ ------------- CEE.SCEERUN NO IMW.SIMWMOD1 NO SYS1.CSSLIB NO SYS1.LINKLIB NO SYS1.TIVOLI.SFMEMOD1 NO TCPIP.SEZALINK NO LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING ----- -------- ---------------- ----------- ------- 00 BOCHE READ READ NO


For the OS/390 endpoint, downloading executables in this manner has some complicated security implications. Therefore, for the OS/390 endpoint, a new way of pre-loading the method cache is supported. You can specify a directory that has methods loaded into it at install time. This preload is required for methods that must be executed out of controlled MVS data sets (as opposed to the UNIX System Service Hierarchical File System, or HFS), including MVS-protected APF-authorized libraries.Therefore, if you are operating in a secure OS/390 environment, preload may be required to satisfy OS/390 security requirement. If MVS-level security is not enabled, or if the specific application methods do not need to be in MVS-controlled data sets, then preload is optional.

To support preload, the OS/390 endpoint has an additional lcfd parameter: -Dpreload=pathname. It specifies the absolute path of a preload area that will be checked for down-call method implementations and dependencies before the cache is checked. Files in the preload area will not be checked for version differences with the gateway and are neither updated nor deleted by the endpoint. If preload option is used, but the file is not found in the directory, the cache will be checked, and an attempt will be made to update it as usual.

The SMP/E install places the TSM (SecEpt) and TUA (Umboskel) methods in the preload directory you specify by default. These methods require APF authorization when MVS-level security is enabled.

3.3.5 Tivoli User Administration for OS/390There are no specific OS/390 tasks for the Tivoli User Administration support for OS/390 as an endpoint. Check the release notes and program directory for any last-minute updates.

3.3.6 Tivoli Security Management for OS/390A log file needs to be pre-allocated in the directory denoted by setting of RUNDIR in the lcfd.sh script. After changing to the correct directory, enter the following commands to create this log file for Tivoli Security Management:

touch SecRacfLogchmod 666 SecRacfLogchown NOBODY SecRacfLog

3.4 Endpoint Administrator Mapping

In order to manage an endpoint, the Tivoli administrator needs some form of identity on that system to execute commands and start programs. Tivoli

Getting Started 43

provides two mechanisms for mapping Tivoli administrators to IDs on the OS/390 endpoint. These two mechanisms have the following two functions:

TMA Administration This allows the Tivoli administrator to work with the OS/390 UNIX system Services, manage the TMA daemon (lcfd), and so on.

Security Administration This is required to allow a Tivoli administrator to manage objects in the RACF database. This management takes place directly in RACF through the R_Admin interface and is not related to the UNIX user IDs maintained for Tivoli administrators under UNIX System Services.

3.4.1 OS/390 TMA Administrator MappingTivoli Administrator properties, User Login Name and Group Name, correspond to an account name that will be used on the systems where Tivoli actions take place. In a multi-platform environment, the administrators of these systems may have different user and group account names. For example, the super-user is typically root on UNIX systems and Administrator on Windows NT systems. To allow administrators to perform some Tivoli operational task with a single user name, regardless of the system they are currently using, Tivoli provides ID mappings. The widmap command can be used to define a user name for each platform (interpreter) type. Without this mapping, Tivoli will use the name of the Tivoli administrator from wherever they logged on to perform Tivoli administration. The exception is where the task being performed specifies the user to be used.

An ID map is specified in the properties for the Tivoli administrator. We can specify a user map in the User Login Name field and/or a group map in the Group Name field. Instead of a direct name to use, we place a name beginning with a dollar sign ($). This is the name of the ID map.


Figure 8. Tivoli Administrator Properties - ID Mapping

From 3.6, Tivoli supports the new os390 interpreter type in the ID map. You can define your OS/390 operational user ID to current default ID mapping through the following steps:

• Listing current ID maps

In this example, Tivoli has two default ID maps, root_user and root_group.

• Getting information about ID mapping

You can see the definition of these ID maps using the following command:

This shows that, if the interpreter type does not match, we will use the ID, root. If the interpreter type is nw3, then commands issued by this administrator will be run as supervisor and, so on. As there is no entry for os390, the default would be to use root.

• Defining a user ID in the map for the OS/390 interpreter

# widmap list_mapsroot_group root_user

# widmap list_entries root_userdefault rootnw3 supervisornw4 Adminos400-v3r2 QTIVROOTos400-v3r7 QTIVROOTw32-ix86 Administrator

Getting Started 45

In this example, we define yoh who is a super user in the OS/390 UNIX system to the os390 interpreter type. We did this in our case because our OS/390 UNIX system doesn’t have a user who has the name of root.

See the Tivoli Management Framework User’s Guide or the redbook SG24 2034 Tivoli Internals and Problem Determination for more information on ID mapping.

3.4.2 Creating an OS/390 Identity for Tivoli Security AdministrationAn OS/390 identity must be established for a Tivoli Administrator to manage RACF from Tivoli User Administration and Security Management. The request to update RACF profile information will run under the authority of the RACF user ID associated with the Tivoli Administrator.

A RACF general resource profile in the TMEADMIN class must be defined to associate a Tivoli Administrator with a RACF user ID. The profile name is the administrator’s Tivoli principal ID. If Kerberos is in use, the Tivoli principal is a Kerberos principal name. If Kerberos is not in use, the principal ID is a combination of the operating system login ID and the host name.

3.4.2.1 Identifying a Tivoli Administrator ’s Principal NameThe easiest way to identify an administrator’s name is from the desktop. You can look at your own desktop, or an administrator with a suitable role can look at other administrators desktops in the same way as follows:

# widmap add_entry root_user os390 yoh

# widmap list_entries root_userdefault rootnw3 supervisornw4 Adminos400-v3r2 QTIVROOTos400-v3r7 QTIVROOTw32-ix86 Administratoros390 yoh

It is possible for two different users in a UNIX or NT environment to have the same user IDs with different cases (such as johndoe and JohnDoe). RACF only uses upper case, therefore these two users would be regarded as the same by RACF.

Note


Figure 9. Principal ID in Tivoli Desktop

A similar task for an administrator to discover their own principal would be to run the TSM wrunseccmd with no TMEADMIN profile defined. The resulting error message will tell you which principal user ID could not be mapped.

Also, you can use the following commands to determine what principal Tivoli is using in the current shell or command line:

OID=objcall 0.0.0 get_oservobjcall $OID o_get_principal

Here is an example of how it looks:

Tivoli allows you to define through the administrator Set Login Names dialog, which systems and under what user name an administrator can log in.

3.4.2.2 Defining a General Resource Profile in the TMEADMIN ClassNow, to define a general resource profile in the TMEADMIN class to associate the principal ID RH2420B\[email protected] with RACF user ID YOH, a RACF administrator with SPECIAL authority would issue:

The principal ID for this Tivoli Administrator

C:\>objcall 0.0.0 get_oserv1783233652.2.2C:\>objcall 1783233652.2.2 o_get_principalRH2420B\[email protected] principal ID

Getting Started 47

RDEFINE TMEADMIN RH2420B\[email protected] APPLDATA(’YOH’)

Of course, we could issue this through a Tivoli command (and, therefore, in a script or task) using wrunusrcmd or wrunseccmd. Note, however, that the user issuing the Tivoli command would need to have had the TMEADMIN profile already set up for them

3.4.2.3 Listing a TMEADMIN Class ProfileYou can list a TMEADMIN class profile in RACF using the RLIST command. For example, to list a TMEADMIN class profile for Tivoli Administrator who has the principal ID RH2420B\[email protected], from an OS/390 TSO command line, enter:

RLIST TMEADMIN RH2420B\[email protected]

The following is a sample of the output you might expect:

Figure 10. Sample Definition in TMEADMIN Class

3.4.2.4 Checking Configuration for Tivoli RACF ManagementYou need to create an OS/390 Identity correctly for TUA and TSM to access the RACF interface.

CLASS NAME ----- ---- TMEADMIN RH2420B:[email protected]

LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING ----- -------- ---------------- ----------- ------- 00 MARTI NONE NONE NO INSTALLATION DATA ----------------- NONE APPLICATION DATA ---------------- YOH AUDITING -------- FAILURES(READ) GLOBALAUDIT ----------- NONE NOTIFY ------ NO USER TO BE NOTIFIED


The RACF LISTUSER command is a good read-only command for testing. Using the wrunusrcmd or wrunseccmd ensures that Tivoli can talk to the endpoint and that the administrator mapping is taking place sufficiently to run the LISTUSER.

Figure 11. Testing Operation Using wrunusrcmd

If your configuration is not correct from an authorization perspective, you will get something like the following message and will need to check your OS/390 identity. In the first release, you may find that wrunseccmd provides better error message text than wrunusrcmd.

C:\tivoli\bin\w32-ix86>wrunusrcmd @Endpoint:WTSC57 "LU"RACF Command request SAF Return Code: 0 RACF Return Code: 0 RACF Reason Code: 0

USER=YOH NAME=YOH OWNER=GRAAFF CREATED=98.273 DEFAULT-GROUP=TSO PASSDATE=98.273 PASS-INTERVAL=180 ATTRIBUTES=SPECIAL ATTRIBUTES=AUDITOR REVOKE DATE=NONE RESUME DATE=NONE LAST-ACCESS=98.289/18:36:19 CLASS AUTHORIZATIONS=NONE NO-INSTALLATION-DATA NO-MODEL-NAME LOGON ALLOWED (DAYS) (TIME) --------------------------------------------- ANYDAY ANYTIME GROUP=TSO AUTH=USE CONNECT-OWNER=GRAAFF CONNECT-DATE=98.273 CONNECTS= 83 UACC=NONE LAST-CONNECT=98.289/18:36:19 CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE GROUP=SYS1 AUTH=USE CONNECT-OWNER=MARTI CONNECT-DATE=98.281 CONNECTS= 00 UACC=NONE LAST-CONNECT=UNKNOWN CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE GROUP=OMVSGRP AUTH=USE CONNECT-OWNER=MARTI CONNECT-DATE=98.281 CONNECTS= 00 UACC=NONE LAST-CONNECT=UNKNOWN

# wrunusrcmd @Endpoint:WTSC57 "LISTUSER"RACF Command request SAF Return Code: 0 RACF Return Code: 0 RACF Reason Code: 0

USER=YOH NAME=YOH OWNER=GRAAFF CREATED=98.273 DEFAULT-GROUP=TSO PASSDATE=98.273 PASS-INTERVAL=180 ATTRIBUTES=SPECIAL ATTRIBUTES=AUDITOR REVOKE DATE=NONE RESUME DATE=NONE LAST-ACCESS=98.289/18:36:19 CLASS AUTHORIZATIONS=NONE NO-INSTALLATION-DATA NO-MODEL-NAME LOGON ALLOWED (DAYS) (TIME) --------------------------------------------- ANYDAY ANYTIME GROUP=TSO AUTH=USE CONNECT-OWNER=GRAAFF CONNECT-DATE=98.273 CONNECTS= 83 UACC=NONE LAST-CONNECT=98.289/18:36:19 CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE GROUP=SYS1 AUTH=USE CONNECT-OWNER=MARTI CONNECT-DATE=98.281 CONNECTS= 00 UACC=NONE LAST-CONNECT=UNKNOWN CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE GROUP=OMVSGRP AUTH=USE CONNECT-OWNER=MARTI CONNECT-DATE=98.281 CONNECTS= 00 UACC=NONE LAST-CONNECT=UNKNOWN CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONESECURITY-LEVEL=NONE SPECIFIEDCATEGORY-AUTHORIZATION NONE SPECIFIEDSECURITY-LABEL=NONE SPECIFIED RACF Command request successful

# wrunusrcmd WTSC57 "LISTUSER"RACF Command request Return code = 2The requested MINS_login() function failed to log into the server (ApplRC and ApplRsn contain the return and reason codes from the server login function)

Getting Started 49

3.5 Starting OS/390 Tivoli Management Agent

Before you can start the OS/390 Tivoli Management Agent (TMA), you need to configure the Shell Script, lcfd.sh.

3.5.1 Configure the OS/390 TMA Shell ScriptTivoli recommends that you copy the file named lcfd.sh from the directory /usr/lpp/Tivoli/lcf/bin/os390/mrt/ to /etc/Tivoli/lcf/dat/ (a writeable directory). Refer to the Tivoli Framework Reference Manual for more information about these options.

After copying this file to the suggested location, you can set the variables according to your installation. You have the option of changing the defaults for the following parameters (directories):

• The endpoint install directory (LCFROOT in lcfd.sh)

• The cache directory (specified by cache_loc on the command line or in the file last.cfg)

For OS/390, you can specify an additional directory location; the endpoint runtime data directory can be defined in the LCF_DATDIR environment variable.

The default directory into which the endpoint is installed (/usr/lpp/Tivoli) is usually read-only. You can specify a separate directory for LCF_DATDIR either by editing lcfd.sh or by setting the LCF_DATDIR environment variable. The directory needs to be in a writeable area and need not be under the endpoint installation directory.

In our test environment, we did not change any defaults and kept the file as it was.

3.5.2 Starting the Endpoint for the First TimeThe first time we started the endpoint (also referred to as the initial login), we did this from UNIX System Services by invoking OMVS from a TSO session. When we were in UNIX System Services, we then changed our directory to the directory that we copied the lcfd.sh (shell script) to. In our case, /etc/Tivoli/lcf/dat. We then started the endpoint by issuing the following command:

lcfd.sh install -d 4 -Dlcs.login_interfaces=9.12.14.247

The -d 4 parameter defines the level of debug messages written to the lcfd.log file.


The lcs.login_interfaces parameter specifies the IP address, or host name, and port number of one or more Tivoli gateways to which an endpoint will send its login packet. Without this parameter, the endpoint will send a subnet broadcast in an attempt to find a gateway (this activity can be configured).

The parameters for the lcfd.sh shell script are discussed in the Tivoli Framework Reference manual.

Here is an example of the messages you get from a successful start of the endpoint from UNIX System Services:

To be able to start the TMA daemon, you either have to be a UNIX super user (UID=0), or you have to have access to the following RACF FACILITY class profiles:

BPX.SUPERUSER To switch to super user state through the SU command

BPX.DAEMON To start the endpoint

If these profiles have not been defined yet, then these are the RACF commands to define them:

RDEFINE FACILITY BPX.SUPERUSER UACC(NONE) PERMIT BPX.SUPERUSER CLASS(FACILITY) ID(xxxxx) ACCESS(READ)RDEFINE FACILITY BPX.DAEMON UACC(NONE)PERMIT BPX.DAEMON CLASS(FACILITY) ID(xxxxx) ACCESS(READ)SETROPTS RACLIST(FACILITY) REFRESH

Where xxxxx is the user ID that will start the TMA Daemon.

GRAAFF:/u/graaff: >cd /etc/Tivoli/lcf/dat GRAAFF:/etc/Tivoli/lcf/dat: >lcfd.sh -d 4 Nov 29 21:17:11 1 lcfd Command line argvÝ0̈ ='/usr/lpp/Tivoli/lcf/bin/os390/mrt/lcfd'Nov 29 21:17:11 1 lcfd Command line argvÝ1̈ ='-d' Nov 29 21:17:11 1 lcfd Command line argvÝ2̈ ='4' Nov 29 21:17:11 2 lcfd Writing GCS file: /etc/Tivoli/lcf/dat/last.cfg Nov 29 21:17:11 1 lcfd Starting Unix daemon GRAAFF:/etc/Tivoli/lcf/dat: >

===> INPUTESC=¢ 1=Help 2=SubCmd 3=HlpRetrn 4=Top 5=Bottom 6=TSO 7=BackScr 8=Scroll 9=NextSess 10=Refresh 11=FwdRetr 12=Retrieve

Getting Started 51

When you have started the TMA Daemon you can check whether it was successful by looking at the system log and issuing the OS/390 operator command display active, list:

Because it was started from UNIX System Services under userid GRAAFF, a unix process has started that shows a started task of GRAAFF5. To get a list of all the active UNIX processes and the TMA daemon’s process issue the D OMVS,A=ALL command, as follows:

If these FACILITY class profiles have not been defined and you need to define them, be aware that this may impact other UNIX System Services users and applications.

Note

D A,L IEE114I 21.30.55 1998.333 ACTIVITY 662 JOBS M/S TS USERS SYSAS INITS ACTIVE/MAX VTAM OAS 00004 00015 00001 00025 00033 00001/00025 00011 LLA LLA LLA NSW S JES2 JES2 IEFPROC NSW S APPC APPC APPC NSW S ASCH ASCH ASCH NSW S VLF VLF VLF NSW S NET NET NET NSW S RMF RMF IEFPROC NSW S CSF CSF NSW S RACF RACF RACF NSW S ITCPIP ITCPIP TCPIP NSW SO TSO TSO STEP1 OWT S INETD1 STEP1 OMVSKERN OWT AO DB51MSTR DB51MSTR IEFPROC NSW S PORTMAP5 STEP1 STC OWT AO FTPD1 STEP1 OMVSKERN OWT AO DB51IRLM DB51IRLM NSW S DB51DBM1 DB51DBM1 IEFPROC NSW S DB51DIST DB51DIST IEFPROC NSW SO GRAAFF5 STEP1 GRAAFF OWT AO GRAAFF IN O


You can also use UNIX commands in UNIX System Services to obtain similar information, such as ps -ef (which you may wish to grep for Tivoli or lcfd). To stop the TMA daemon, you can issue the lcfd.sh stop command.

For subsequent endpoint starts, all you would have to do is run the lcfd.sh without the install option, such as this:

lcfd.sh -D 4

3.5.3 Automated Start of the TMA EndpointOnce the endpoint has logged in initially, you can have the TMA endpoint automatically started after each IPL of the system. This is most likely the preferred method once you have taken Tivoli into your production environment.

You have two options of automating the endpoint start-up:

1. Starting the endpoint from a UNIX System Services environmentor

2. Starting the endpoint as a started task through NetView or any other form of automated operations

D OMVS,A=ALL BPXO040I 21.34.44 DISPLAY OMVS 666 OMVS 000E ACTIVE OMVS=(00) USER JOBNAME ASID PID PPID STATE START CT_SECS STC BPXOINIT 0022 1 0 MFI 10.30.27 .097 LATCHWAITPID= 0 CMD=BPXPINPR SERVER=Init Process AF= 0 MF=65535 TYPE=FILE STC ITCPIP 0044 50331650 1 1F 10.31.48 7018.332 LATCHWAITPID= 0 CMD=EZASASUB STC DB51DIST 00FD 184549379 1 MR 10.34.01 15.596 LATCHWAITPID= 0 CMD=DSNVEUS3 STC ITCPIP 0044 16777220 1 MR 10.30.55 7018.332 LATCHWAITPID= 0 CMD=EZBTCPIP OMVSKERN INETD1 0023 33554437 1 1FI 10.33.03 .120 LATCHWAITPID= 0 CMD=INETD GRAAFF GRAAFF5 004A 83886094 1 1FI 21.17.11 .157 LATCHWAITPID= 0 CMD=/usr/lpp/Tivoli/lcf/bin/os390/mrt/lcfd GRAAFF GRAAFF 0043 117440535 1 1R 20.39.16 5.616 LATCHWAITPID= 0 CMD=EXEC

The first time we ran lcfd.sh install, there was a short delay of about 30 seconds before we could see the endpoint from our Tivoli Desktop.

Note

Getting Started 53

To enable automated start-up of the endpoint from a UNIX System Services environment, you have to do the following:

1. Edit the /etc/init.options file to include the rc shell script name (if it has not already been done) by adding this line:

-sc /etc/rc

This causes the rc shell script to be executed when OS/390 UNIX System Services is initialized.

2. Add the following lines to the /etc/rc file:

_BPX_JOBNAME=’LCFD’ /etc/Tivoli/lcf/dat/lcfd.sh &

The next time the OS/390 system is IPL-ed, the endpoint will be automatically started.

To enable automated start-up of the endpoint from an OS/390 perspective, you can either add the supplied started task FMEESTRT to the NetView automation tables or any other form of automated operations you have within your installation.

3.6 Checking the OS/390 Endpoint Installation

This section gives some tips on checking that the endpoint installation and configuration completed successfully.

3.6.1 Listing Tivoli Management Agent PropertiesYou can list the OS/390 TMA information from any managed node using the wep command shown here:

If you use this method of startup, make sure you have a RACF STARTED profile definition to identify this new started task and associate it with user ID OMVSKERN or your installation-defined user ID for UNIX System Services.

Note


The wep command returns the following information about a TMA endpoint:

object The Tivoli Object Identifier (OID) and object name in the form #object_type_class::object_type#. Note the OID for a TMA endpoint ends in a plus sign (+).

label The label associated with this endpoint by the administrator.

id A unique ID for the endpoint.

gateway The Tivoli gateway to which the endpoint is assigned.

netload Current netload setting or OBJECT_NIL if not set.

interp The endpoint interpreter type.

address The IP address and port the gateway records as the one to use to communicate with the endpoint.

policy The policy region in which the endpoint resides or OBJECT_NIL if the endpoint has not yet been added to a policy region.

httpd The user name and (by default) randomly generated password used to modify endpoint information using a web browser. (The password can be set by the wep command).

alias Defined alias, or OBJECT_NIL if not defined.

Refer to the Tivoli Framework Reference Manual and the Tivoli Framework Planning and Installation Guide for more information on the wep command and endpoint configuration.

3.6.2 Checking Current Tivoli Management Agent StatusYou can check the OS/390 TMA status from a managed node using the status parameter on the wep command:

# wep WTSC57

object 1783233652.4.508+#TMF_Endpoint::Endpoint# label WTSC57 id 151785207 gateway 1783233652.1.530#TMF_Gateway::Gateway# netload OBJECT_NIL interp os390 address 9.12.14.247+8039 policy OBJECT_NIL httpd tivoli:](}HxUs* alias OBJECT_NIL

Getting Started 55

This quick check will return the above message if communications with the lcfd at the endpoint are fine. If the status could not be determined, then the message will read “endpoint may be unreachable”.

3.6.3 Viewing Tivoli Management Agent Files from a Web BrowserYou can view the TMA log and configuration information using a web browser. To access this information enter the following URL in the Location field of your web browser:

http://{TMA’s host name or TMA’s IP address}:port

You can get the port information using the wep command as shown in section 3.6.1. The following are samples of the TMA web pages. Figure 12 shows the status. This is similar to a combination of the wep endpoint and wep endpoint

status commands.

# wep WTSC57 statusWTSC57 is alive.


Figure 12. Tivoli Management Agent Status Page - Web Browsing

Figure 13 shows the log file. If the file is longer than 200 lines, only the last 200 lines are displayed.

Getting Started 57

Figure 13. Tivoli Management Agent Log file (lcfd.log) - Web Browsing

You can also display the current configuration settings for the endpoint. An example of this is shown in Figure 14.


Figure 14. Tivoli Management Agent Configuration File - Web Browsing

Other web views include a list of the method cache, usage statistics, and network address configuration. Refer to the Framework product manuals for more information about this feature.

3.7 Getting Started with Tivoli

Having gotten the endpoint installed, running, and configured, we can now proceed to get started managing the endpoint from within Tivoli. The remainder of this chapter introduces the following three aspects:

• Getting existing data into Tivoli

• Distributing changes to endpoints

• Using Tivoli Task Libraries

Getting Started 59

3.7.1 The Tivoli Populate FunctionThe Tivoli populate function enables us to gather user and group information from the RACF database or other system’s security files and add that information to a Tivoli user profile or security profile.

Because of the potential for many thousands of records, the population of a Tivoli user profile from the RACF database, the Tivoli GUI, or the wpopulate command is not implemented. We can use wpopusrs or wpopsec from the command line to populate Tivoli user profiles and security profiles, respectively. In addition, TSM allows the use of wpopulate to populate Tivoli security profiles from the RACF database. These commands allow us to populate specified profiles with system data defined by an input file.

For Tivoli user profiles, the input file simply needs to be a list of RACF IDs. When we issue the wpopusrs command, we can specify the list, which Tivoli profile the data is to go in, and what endpoint to get the data from. Tivoli User Administration then goes out to the endpoint with the list of RACF IDs and requests the RACF profile data for each of those IDs.

For Tivoli security profiles, population from the GUI allows the population of a single type (group, resource, or role), a list of items or an entire RACF class (a RACF general resource class or dataset-GEN to get all RACF data set profiles). TSM does not populate from a file in the way TUA does. An alternative way to achieve the same thing would be to create a file similar to that used for user data and use a script to make wpopsec calls using the data in the file.

It is usually going to be advisable to select a subset of user data for Tivoli user profile population. This will keep the number of users in a Tivoli profile to manageable levels (see also 3.1.1, “Capacity Planning Introduction” on page 29 for a discussion on user profiles). There are a few ways of obtaining a suitable list. If you want to perform searches and sorts based on various pieces of data held by RACF, you can perform an unload of the RACF database into a flat file using RACF unload utility (IRRDBU00). Once the RACF data is unloaded to a file, you can perform searches and sorts to extract lists of users. If you don’t need the rest of the RACF data to be unloaded, you can just obtain a list of users into a file by using the RACF SEARCH command. You can use masks or filters when using the SEARCH command. The SEARCH command might be useful when you use a naming convention for RACF user IDs. For example, say that all user IDs of the accounting department started with acc, you could make a list of all these user IDs by issuing the following command:

SEARCH MASK(ACC) CLASS(USER) CLIST(“) NOLIST


This would dynamically allocate a file called userid.exec.racf.clist, which contains a list of all the user IDs starting with acc. Be aware that the list file is in number on mode and the input file to the wpopusrs requires the user ID to start on position one (1). Therefore, you would have to edit the file to shift the user ID eight characters to the left.

Another way of getting a list of user IDs might be by listing the so called administrative group the users belong to. In many installations, the administrative group can be used for a Tivoli profile population. To do this, you would issue the RACF LISTGROUP command with the administrative group name as a parameter:

This would need more editing because it shows more information than required.

From the user list file, you can populate user records to a Tivoli User profile with the wpopusrs command.

LISTGROUP OMVSGRPINFORMATION FOR GROUP OMVSGRP SUPERIOR GROUP=SYS1 OWNER=RCONWAY NO INSTALLATION DATA NO MODEL DATA SET TERMUACC NO SUBGROUPS USER(S)= ACCESS= ACCESS COUNT= UNIVERSAL ACCESS= BPXROOT USE 000000 NONE CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE OMVSKERN USE 000053 NONE CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE JJONES USE 000000 NONE CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE YOH USE 000000 NONE CONNECT ATTRIBUTES=NONE REVOKE DATE=NONE RESUME DATE=NONE

Although we did not see this problem in our own populate testing for this book, Tivoli testing found a “corruption, failure point: ‘string’” message. This was still being investigated at the time of writing. If you experience this problem you should seek the resolution to APAR OW35833. The work-around is to manually edit the user’s password field of newly populated users before attempting to edit other fields in the record.

Populate ‘Corruption’ error

Getting Started 61

Refer to the Tivoli User Administration User and Group Management Guide for more information about Tivoli user profile population and managing profiles. The Tivoli User Administration User’s Guide Supplement for OS/390 gives an example of how to unload and sort the RACF database. See the OS/390 Security Server (RACF) Security Administrator’s Guide for details about the RACF database unload utility.

3.7.2 User and Security Profile DistributionAs with other platforms, there are some special considerations for the order in which you distribute Tivoli user and security profiles. There may be dependencies that must be accommodated. For example, a group must be defined in RACF before a user can be created with that group as their default group. Creating the group through Tivoli would mean distributing a security profile with the group information before the user profile. If the security profile was also to define something that depended on a particular user being present, then a user profile would need to be distributed to define that user before the group profile was distributed. An awareness of potential problems and a careful Tivoli profile manager design will help avoid possible error situations.

Note that it is possible to define groups, roles, and resources in the same Tivoli security profile that have dependencies on each other. When the profile is distributed to RACF, the records will be created in the right order to resolve the dependencies. Dependencies that cannot be satisfied by Tivoli will be highlighted by errors returned during distributions.

In a case where such a dependency exists then the solution may be a direct update of the RACF database, possibly through the Tivoli command line such as:

wrunseccmd RACF-endpoint addgroup <newgroup>

Of course this can be placed into a Tivoli task to make it easier to use by less experienced administrators. See the next section for an example.

Tivoli manages a great deal of the data associated with a user or their access capabilities. However, there may be other functions required as part of the distribution of user and security data that are not currently a part of the product. Tivoli provides a number of mechanisms to help here. One example is the use of action scripts. It is possible to specify that every time a profile is distributed, a certain script is run. This might perform functions such as refreshing the RACF RACLIST or adding some other data related to a user. An example of adding such an action is given in 4.4.2, “Adding a Custom Action to a User Profile” on page 78.


Note that authorized TSO commands, such as SETROPTS RACLIST(class) REFRESH suggested in the last paragraph, will not run by default in the TSO shell command from UNIX System Services. OS/390 UNIX System Services have a Tips and Toys web site where there exists a utility called tsocmd that can run authorized TSO commands. The Tips and Toys section can be reached at:

http://www.s390.ibm.com/oe/bpxa1toy.html

With the tools available through Tivoli’s Application Extension Facility (AEF), TUA and TSM can be customized further through changes to the GUI and the manipulation of data.

3.7.3 Task Library ExampleCommands and operations that are executed frequently with little or no change can be built into Tivoli tasks. In Tivoli, we can give specific administrators the ability to execute tasks, accept input parameters, schedule a task to run, or build, all these pieces into a single entity that Tivoli calls a job.

The following is an example of the steps required to create Tivoli tasks for OS/390. See the Tivoli Management Framework User’s Guide for more information on building task libraries. Note that while we are using shell script here, we can use any form executable on the endpoint, including REXX for OS/390. Administrators often try to stick with a single script type that can execute on all platforms unless the task really is specific to a particular interpreter type. See 4.4.4, “Checking A User Definition from a Tivoli Task” on page 83 for another example of a task.

1. Create and Test a script on OS/390 UNIX system

First you create and test a script. Figure 15 is a sample script to list current disk information under OS/390 UNIX System Services:

Figure 15. Sample Task Source - get_disk_info.sh

2. Download this script to the managed node

#!/bin/sh. /etc/profiledf -kexit

Getting Started 63

As mentioned in 3.6, Tivoli doesn’t create Tivoli Task directories from scripts on Tivoli Management Agent endpoints. The scripts must reside on a managed node (such as a gateway) in the TMR.

You need to download the script to a managed node, and from this script, you can create a Tivoli Task.

3. Create a Tivoli task with this script (GUI shown here)

Tivoli supports the new platform-type of os390 in the Create Task dialog.

Figure 16. Create Task Dialog

FTP of the script from UNIX Systems Services to a Windows NT managed node can alter the carriage return/line feed (CR/LF) characteristics of the script. For this reason, it is preferable to use a UNIX managed node as a location for the script and source for the task.

Note


We have set this task to be executable by any administrator with the user role. Note that the administrator would also need to be able to see this task library on their desktop. When the task executes, it will run with the root user ID under UNIX System Services.

4. We can use the GUI or, wruntask, to run the task on the OS/390 Tivoli Management Agent.

The is output of this task is as such:

Figure 17. OS/390 Task Output

Considerations regarding auditing who executed tasks are similar to auditing other actions taken by administrators. Refer to 6.5, “Tivoli Notice Groups” on page 116 for a discussion of this topic.

Getting Started 65


Chapter 4. User Administration

This chapter explains how to manage OS/390 Security Server (RACF) user account information through Tivoli User Administration (TUA) with TUA for OS/390 installed to add the OS/390 attributes to Tivoli User Profiles.

4.1 Creating a Policy Region

As discussed in 2.6.2, “Policy Regions” on page 20 Tivoli policy regions and subregions are one way of determining the capabilities of systems management administrators. An existing administrator with the required authorization role in the TMR (senior) can define new policy regions either from the wcrtpr command or from the Tivoli desktop. The process for creating a new policy region is documented in the Tivoli Management Framework User’s Guide.

This icon is the Tivoli symbol for a Policy Region. If you ever get to Austin, Texas, you can see the original. The icon resembles the Texas State Capitol building, the top-level policy region.

You should refer to the manuals for details on policy regions, and the redbook SG24-5108 Tivoli User Administration Design Guide gives design tips for region hierarchy. However, one important step in the definition of a policy region is the specification of the resources that can be managed through this Policy Region. Without this step no administrator can manage resources in this region. For example, it would not be possible to create a Tivoli profile manager or any type of Tivoli application profile.

To add managed resources to a policy region, you need to right click on the region icon on the desktop and then choose the Managed Resources... option. The following box will appear that will allow you to choose the resources to be managed in this region:


.

Figure 18. Selecting a Region’s Managed Resources

The same action can performed through the wgetpr and wsetpr commands.

An optional additional step would be to alter the managed resource policies for certain types of managed resources in a policy region. This is done by right clicking on the policy region icon on the Tivoli desktop and then choosing Managed Resource Policies....

From the resulting dialog, you can choose default and validation policies per managed resource for major resources, such as profile managers and managed nodes. See the next section and 2.6.7, “Default and Validation Policy” on page 23, and the Framework and application manuals for more information on default, validation policies, and how to modify them for attributes within a Tivoli profile record.

4.2 Use of Default and Validation Policy

Tivoli user profiles contain a set of default and validation policies. Default policies provide default values for attributes for the creation of users. This can reduce the amount of information entered when creating a new user record in a Tivoli user profile, as well as limiting the possibility of errors during data capture. Validation policies can be used to ensure user records have been defined correctly according to standards determined to be suitable within the organization.

This section provides examples of default and validation policies and describes how to manage a set of default and validation policies in your user administration environment.


4.2.1 Examples of Default and Validation PolicyDefault and validation policies consist of a constant or a script (validation policies can also use regular expressions). In the example of default policy in Figure 19, the Dept attribute of the RACF WORKATTR segment subcategory is generated from the Department field of the Identification subcategory. Identification is one of the subcategories in the General category. TUA attributes are grouped into categories. For example, General, RACF or NetWare, and subcategories, such as Identification or RACF CICS Account.

Figure 19. Default Policy Example

4.2.2 Modifying Default or Validation PolicyThe following steps show a GUI example of editing Default policy in a Tivoli user profile:

1. Double-click on a Tivoli user profile icon to display the User Profile Properties window (the top dialog in Figure 20).

User Administration 69

Figure 20. The Edit Default Policies Window

2. Select Default Policies... from Edit menu to display Edit Default Policies window as shown in Figure 20.

We could also have selected Validation Policies... from the Edit menu to get a similar display for editing validation policies. This window shows a list of attributes for which we can alter the policy. If we have a hierarchical administration scheme where one level of administrators distribute data to another level we can set here whether the second and subsequent levels, or the subscribers, can edit the policy in the Subscribers can edit selection.


.

Figure 21. Edit Script Arguments

3. In Figure 21, we Select the racf_work_wadept attribute from the Attributes scrolling list. If no script is defined so far for this attribute, we must select Script in the Default Type drop-down list. This is where we choose between constant, script, and in the case of validation policy, regular expression. The pre-defined default, validation policies, and their attribute names are listed in the TUA User and Group Management Guide and the TUA for OS/390 User’s Guide Supplement. You can list the default and validation policy methods for a Tivoli profile using the wlspolm command. This is described in the Tivoli Framework Reference Manual, and an example for a Tivoli user profile would be:

wlspolm -v @UserProfile:UserProfileName


4. Pressing the Edit Script Arguments... button displays the Policy Script Arguments dialog. We select the Department argument from the Attributes scrolling list and move this attribute to Script Arguments scrolling list. The Department attribute is the one from the Identification subcategory.

5. Press Change & Close to add this argument. This argument will be passed to the policy script when this default policy is called.

6. Pressing the Edit Script Body... button displays the Edit Policy Script dialog shown in Figure 22.

Figure 22. Editing Policy Scripts

Now we can add our script:

#!bin/shecho $1exit 0

This script just echoes the first argument passed to this script. Therefore, this script sets the racf_work_wadept attribute to the same as the Department attribute.

4.2.3 Maintaining Policies across User ProfilesTivoli provides two levels for applying policy scripts. Policy region-based policies apply to all resources of that type in a policy region. Once the policy is changed, all new resources of that type must conform to the new policy. This will affect resources, such as task libraries and profile managers. This was mentioned at the beginning of this chapter and is covered in the product manuals.


In profile-based policy, each profile contains its own set of default and validation policies as we have described, and these are specific to that profile. Tivoli user and security profiles (among others) have this profile-based policy. Therefore, when you change some default policy of one user profile, this only applies to that user profile and not others. If you want to apply this change to another profile, you need to employ one of the following methods:

• Cloning a User Profile

• Exporting and Importing Policy

A subscriber to a profile can be another profile manager containing a copy of that profile. Optionally, an administrator of the lower-level profile can modify the default and validation policy of that copy of the profile, making it different than that of the higher-level (source) profile.

4.2.3.1 Cloning a User ProfileIf you need to create a Profile that has the same Default and Validation Policies as a customized profile, you may clone a User Profile. It is important to note that no user records are copied during a clone profile operation. This just copies the profile definitions, such as default and validation policy.

This operation can be achieved from the CLI by using the -c switch on the wcrtprf command. From the GUI, click a User profile that you want to clone and Select Edit -> Profiles -> Clone...to display the Profile Clone window shown in Figure 23.


Figure 23. Cloning a User Profile

Select a target profile manager from the Clone to Profile Manager scrolling list, enter the new profile name and press Clone & Close (or just Clone to leave the dialog available to select another target). The new user profile will have the same policies as the source profile but has no user records created.

4.2.3.2 Export Policy and Import It to a User ProfileA policy that is contained in a user profile can be extracted by using the wgetpolm command. You can then put it into the target user profile by using the wputpolm command. Here is an example of each command:

wgetpolm -d @UserProfile:Sample_USR racf_work_wadept > filewputpolm -d arg=’$department’ @UserProfile:Target_USR racf_work_wadept < file

4.3 User Management Tasks

The following section discusses common tasks for managing RACF users through Tivoli User Administration.

4.3.1 Cloning UsersThrough the role-based security principle used within TSM, the creation of users, with not only the same attributes but also the same access rights as existing users, is made simple.

Much of the detail of a user account may be created using default policies (see Chapter 4.2, “Use of Default and Validation Policy” on page 68). It is


important for the administrators to understand the default policy that has been set up within the profile where they are adding users since they would need to know the minimum requirements of data capture. In the example in the previous section, the administrator would need to know that the Department attribute in the Identification subcategory needs to be entered to enable the racf_work_wadept attribute to be defaulted correctly. Another obvious example of data that would need to be entered is the User Name.

Adding a user is amply documented in the product manuals and has no special considerations for RACF user records. It is also possible to clone a user record in order to create a new user having the same attributes as another user. We can use the wcpusr command, or we can copy a user record through the GUI. The easiest way to achieve this is in the GUI is to use the User Locator to find the user you wish to copy, select the user or users to copy and the target profile, and hit the Copy button. You might also specify a single Tivoli user profile as a master, which contains typical users you create often. This master would then always be the source for cloning new users.

Once the user record has been created, it may then be linked to one or more Tivoli security groups, which in turn, are linked to the roles that determine what access the user will have and to which resources.

4.3.2 Merging RecordsThe copy and move functions may be used to merge records from many Profile Managers into one. It is important to remember when copying, or moving users, they may not already exist in the Profile Manager to which they are being sent. Users will not be ignored or overwritten; the whole function will simply abort. When copying a number of users from one profile manager to another, validation policy is run. This can cause the process of moving, or copying, large numbers of users to be a time consuming task. If the source data is known to be accurate, a possible solution to this problem could be to switch validation off before the copy or move and back on again after the copy, or move, is completed. If there are differences between the receiving and sending profiles, it is probably better to validate the records while copying or moving them.

If this is a common operation then it might best be placed into a script that could also be built into a Tivoli task. The script would take a name as input, would disable specific validation policies in the target profile with wputpolm -n, copy the user, and then re-enable the disabled policies.

Note that anything that disables policies temporarily assumes that no other administrator is going to be modifying the same profile at the same time. If


they were, then the policy may be disabled at the point they make their modification. Tivoli locks individual records, but policy applies to all records in a profile.

4.3.3 Synchronizing ProfilesUser profiles may become out of synchronization if the system files and databases of a profile endpoint are changed without using Tivoli. Should this happen, it is possible to synchronize the Tivoli profiles to accurately reflect the endpoint’s configuration. Refer to the TUA User and Group Management Guide for more detailed step by step procedures on synchronizing profiles from the GUI or the wchkusrs command. The implementation of synchronization varies for the different platforms. At the time of writing, this option was not available for OS/390 endpoints.

Another issue arises as a result of delegation of administration. It is possible to distribute Tivoli profiles to other profile managers where other administrators can make changes to them before they reach the endpoints. If this capability is exploited, the top-level administrators will need to be able to read the lower-level profiles or be able to access the actual system data in order to know what the actual configuration of a user on any one system may be. The modification of the lower level profile is not reflected back up the chain to the higher profile manager. Whether this presents a problem depends on your administrator policy. Generally, the lower level administrators are given the capability to modify the user data because they are responsible for the user on the target system, not the higher-level administrator.

4.3.4 Disabling Default PolicyWhen you create or modify a record in a Tivoli user profile, the default policy scripts are run against all attributes in the user profile, including all platforms provided by default (Windows NT, NetWare, UNIX) and any others added through modules such as OS/400, OS/2, Lotus Domino/Notes, and so on. This can add overhead to creating new users.

There is a blanket command called wsetdefpol that can be used to disable default policy for a built-in category for each profile. The built-in categories are Windows NT, UNIX, and NetWare. This can be set for any profile individually or for a profile that is later used to clone to other profiles. Therefore, if you don’t have NetWare in your environment, you should disable NetWare default policy in all your Tivoli user profiles.


To disable default policy for added categories, you will need to use the wputpolm command for each policy individually.

4.4 Example of Creating an OS/390 UNIX User

The following description covers many aspects of TUA. We will demonstrate some common custom configuration options and show much of the user creation scenario. At the time of writing, OS/390 UNIX System Services is not one of the UNIX platforms natively supported by TUA. Some pieces of the UNIX System Services environment can be defined through TUA using the OMVS segment in the RACF pieces of the Tivoli user profile. Areas not covered by the OMVS segment need to handled differently, and we present examples on how to achieve this.

4.4.1 Default Policy for RACF OMVS SegmentWhen you define a new OS/390 UNIX user, you can specify the following information in the OMVS segment of the user’s profile:

HOME User’s OS/390 initial directory path name

PROGRAM User’s OS/390 program path name, such as the default shell program

UID User’s OS/390 Unix user identifier

Ideally, you need to define default settings for this information. After that, you can create default policies for the Tivoli user profile to generate this information automatically when the operator adds a user to a Tivoli user profile. The operator will then not need to know a great deal about the OMVS environment to get the user configured to use it. The following table is a sample default policy we could add for the OMVS segment.

Table 1. Default Policy for OMVS Segment

GUI Field Name

Attribute Policy Name

Policy Type

Script Arguments

Script body or constant

User ID racf_omvs_uid script UNIX User ID

#!/bin/shecho $1exit 0

HomeDirectory

racf_home_directory script CommonLogin Name

#!/bin/shLOGIN=$1echo /u/$LOGINexit 0

Program racf_omvs_program constant N/A /bin/sh


In this default policy, the User ID for an OS/390 UNIX user is the same as the UNIX category User ID. The UNIX User ID is generated from a Tivoli wallocid command when default policy is executed. Tivoli manages UID in its database, and the wallocid command allocates a new UID that is unique in the UNIX environment as far as Tivoli can ascertain. See more details in the Tivoli User Administration User and Group Management Guide.

Therefore, you can manage a user who has both a UNIX user and an OS/390 UNIX user, giving them the same UID through this Tivoli user profile. If you don’t need to give this user a UNIX UID, you can disable default policy for UNIX and copy the default policy for the UNIX User ID to the racf_omvs_uid attribute.

The Home Directory attribute is generated with the user’s common name. If a user has rhawes as his common login name, his home directory will be assigned as /u/rhawes.

Note that we are setting the home directory to a name based on the common login name. There is an assumption here that this will generate the same name as the UNIX user ID as that is also generated from the common login name.

4.4.2 Adding a Custom Action to a User ProfileWith our policies in place, we can distribute the Tivoli user profile and create a user for OS/390 Unix System Services in the RACF database. However, the distribution of a Tivoli user profile to RACF does not create the user’s home directory, so you need to create the user’s home directory after the distribution.

If all that is required to complete the creation of this user is the creation of the home directory, then it is obviously not good for an operator to have to switch to some other interface like TSO or the OMVS shell interface. Tivoli provides the capability of adding a custom action to the user profile and executing this action on the target after the profile distribution. With this capability, we can create a user profile that has an action to create the user’s home directory. When we distribute this profile to OS/390 endpoint, the user’s UNIX System Services home directory is created automatically.

The following is a sample script for creating a user’s home directory on OS/390 UNIX System Services:


Figure 24. Create OMVS Home Directory Script - mkdir_omvs.sh

This script needs two arguments for execution. The first argument is used as the directory name to be created, and the second is the owner of this directory. The Tivoli user profile can pass the information that is contained in its profile to this custom action by arguments. In a production environment, you will probably wish to add logging and error handling capabilities to such a script.

You can add this script as a custom action (mkdir_omvs) to your user profile with the following command:

waddaction -A -c @UserProfile:OMVS_USR mkdir_omvs \args=’$racf_home_directory’,’$racf_userid’ < mkdir_omvs.sh

The back slash (\) indicates the command is spread over two lines. The -A option means this action should be run on each endpoint after the profile is distributed to its subscribers, and the -c option means that this action is associated with the creation of profile records.

You can list the actions that you added to your user profiles with the wlsactions command, but this command requires that you have installed Tivoli Application Extension Facility (AEF):

#!/bin/sh

if [ $# != "2" ]thenecho "Usage: mkdir_omvs <dir_name> <user-id>" >> /tmp/mkdir_omvs.logexit 1

fi

D_MODE=755D_NAME=$1D_OWNER=$2

mkdir $1 >> /tmp/mkdir_omvs.logchmod $D_MODE $1 >> /tmp/mkdir_omvs.logchown -R $2 $1 >> /tmp/mkdir_omvs.logexit 0

# wlsactions -A -c @UserProfile:OMVS_USRmkdir_omvs


4.4.3 Distributing a User ProfileWhen data is distributed to the endpoint, the administrator is presented with a number of options. One of these is whether to preserve local modifications to the profile (just send the changed records) or to make the target an exact copy. The effect of an exact copy distribution will vary depending on the endpoint type, so it is important to become familiar with exact copy distribution from the manuals specific to each product. For example, the TUA User and Group Management Guide for UNIX and Windows NT and the supplement for RACF.

On some platforms, if you distribute a profile with a set number of users in it using exact copy, only those users and certain reserved system IDs will remain on the endpoint after the distribution. Any others that were on the endpoint are implicitly deleted. For RACF, users are only deleted if they previously existed in a profile and were explicitly deleted from that profile before it was distributed (regardless of whether exact copy is used).

It may be that, for some profiles, you might wish to avoid the option of exact copy being shown in the Distribute Profile dialog (see Figure 25).

Figure 25. Distribute Profile Window

What follows is an example of the type of customization that can be achieved using the Application Extension Facility (AEF). This is shipped with the Framework and is a separately installed product. We can hide the make exact copy option from the Distribute Profile dialog, just as we can modify most Tivoli dialogs through AEF.


The following describes the steps for customizing this dialog.

1. Finding the dialog name

You can list the dialog names that a Tivoli user profile has using the wlsdialog command:

Among many others, Tivoli user profiles have a dialog named distribute. This dialog is for the Distribute Profile window. We can confirm this by getting the dialog and reverse-compiling it to a text file.

2. Getting the distribute dialog to a text file

We extract the dialog using the wgetdialog command and reverse compile the dialog description language with the rdsl command:

wgetdialog -r UserGui distribute > distribute.d

rdsl distribute.d > distribute.dsl

3. Edit the dsl file

Now we can edit the dsl file and disable the exact copy option by commenting out line 120 of the file.

Modifications should be tested first in an isolated test environment. Always backup the Tivoli database before making changes.

You should not modify any default profiles (such as TivoliDefaultUserProfile or TivoliDefaultSecurityProfile), as these may be changed by product upgrades. It is recommended to modify your own profiles and clone them rather than modifying the default.

Note

# wlsdialog -r UserGuidialog name (customization status)

AddEditUserDelUserConfirmEmptyPageI.................distribute.........


4. Compile and replace the dialog

We need to compile this file again using the dsl command.

dsl distribute.dsl > distribute.d

Now we can install this dialog in a particular instance of user profile.

wputdialog -l @UserProfile:OMVS_USR distribute < distribute.d

This customization becomes available after the Tivoli desktop is restarted.

Figure 26. AEF Modified Distribute Profile Dialog

Command Dialog.............................................lines deleted..........

Choice{Border = YES;Choices =Msg(TableMgrCat,"Preserve modifications .... of the profile",42){FORCE_SOME};

/* Msg(TableMgrCat,"Make each ....an EXACT COPY ....profile",43){FORCE_ALL}; */Layout = VERTICAL;Name = will;Show = ALL;Sort = NO;TellModify = YES;Title = Msg(TableMgrCat,"Distribution Will",41);TitlePos = TOP;}


4.4.4 Checking A User Definition from a Tivoli TaskAfter creating an OS/390 UNIX System Services user, you will want to display the user’s information that you created and confirm that the user was created how you intended. You can do this from the TSO interface, but Tivoli provides commands with TUA and TSM called wrunusrcmd and wrunseccmd to execute RACF commands from a managed node that has TUA for OS/390 or TSM for OS/390 installed.

You must establish an OS/390 identity correctly to execute RACF operations from a Tivoli managed node. See more details in 3.4, “Endpoint Administrator Mapping” on page 43.

You can display a user’s OMVS segment information using wrunusrcmd with the RACF command listuser user-id omvs noracf:

If you are performing this sort of action regularly, you can create a Tivoli task with this wrunusrcmd command. With this Tivoli task, you can execute this kind of RACF operation from the Tivoli Desktop. This is very useful for an operator who can execute this operation from the same interface from which they created and distributed a new user.

The following is the Task Library source. You can install this task with the wtll command. See 3.7.3, “Task Library Example” on page 63 for another example and more details. Also, refer to the Tivoli Task Library Language Developer’s Guide.

Be careful, when defining tasks, not to give a Tivoli administrator an option that goes beyond their security scope.

C:\>wrunusrcmd WTSC57 listuser yoh omvs noracfRACF Command request SAF Return Code: 0 RACF Return Code: 0 RACF Reason Code: 0

USER=YOH

OMVS INFORMATION----------------UID= 0000000000HOME= /u/yohPROGRAM= /bin/sh RACF Command request successful


This task library source creates the task library OS/390 RACF TaskLibrary, and this library has only one task named RacfCommand.

This RacfCommand Task needs two arguments for its execution. One is an OS/390 system name (Tivoli Management Agent endpoint name), and the other is a command string that you want to execute to RACF. You can input

#ifndef TASK_BINDIR#define TASK_BINDIR "./"#endifTaskLibrary "OS/390 RACF TaskLibrary" { Context = ("","*",1); Distribute = ("","ALI",1); HelpMessage = ("","Tasks for OS/390 RACF",1); Require = ("",">2.1",1); Version = ("","1.0",1);

ArgLayout Endpoint { TextChoice Resource "Endpoint"; ButtonLabel = ("","Endpoint ...",1); };

ArgLayout Command { Text; };

Task RacfCommand { Description = ("","Racf Command",1); Uid = ("_!_","$root_user",1); Gid = ("_!_","$root_group",1);

HelpMessage = ("","This task will execute Racf command.",1);

Roles = ("","user",1); Argument ("","Target OS/390 System",1) { Layout = ("","Endpoint",1); };

Argument ("","Command",1) { Layout = ("","Command",1);

};

Implementation ( "w32-ix86" ) .#!/bin/sh .SYSTEMROOT=/winnt .EP=$1 .COMMAND=$2 .. $SYSTEMROOT/system32/drivers/etc/Tivoli/setup_env.sh .wrunusrcmd $1 $2 .exit 0 ; };}


this information through the Tivoli desktop when this task is executed. Of course, we could also define the task to always perform a certain command or sequence of commands and just ask the operator for a system name.

You need to execute this task from a managed node because the wrunusrcmd or wrunseccmd commands will reside on a managed node that has TUA or TSM for OS/390 installed. To avoid the operator having to specify the source managed node for the task, you can encapsulate it into a Tivoli job that already has the information about where this task will be executed.

To execute this job would then require a few simple steps:

1. Double-Click this OS/390 RACF TaskLibrary icon to open a list of tasks and jobs

2. Double-click RacfCommand job to execute this job

3. Push Endpoint... and select WTSC57 (this is an OS/390 TMA) and click Set & Close

4. Input RACF command into the command box

5. Click Set & Execute to execute this Task

These steps are shown in Figure 27.


Figure 27. Running a RACF Task

An example of the output returned through the desktop is shown in Figure 28.

1&2

3

4

5


Figure 28. RACF Task Output

Using the same technique, you can create other Tivoli Tasks that execute various RACF operations. You can integrate operations in one interface. As tasks can be executed with predetermined user IDs, they can be made available to administrators that otherwise have restricted access, allowing them to perform specific operations.



Chapter 5. Access Control Management

In user administration, we are likely to have many design issues related to the authority of many types of administrator, from the help desk, to the most senior RACF administrator. When managing access control, most administration is likely to be under the control of dedicated security administrators.

Although User Administration is probably more challenging to implement, Security Management still has its own set of considerations. This chapter looks specifically at access control management using the Tivoli Security Management product.

5.1 Implementing TSM in RACF

The most significant feature provided through the Tivoli management of RACF is the implementation of role-based security. See 2.8, “RACF and Role Based Security” on page 26 for an overview of role-based security. In this section, we will look at how this is implemented in RACF.

While a Tivoli user profile has a single type of record, the user record, a Tivoli security profile consists of four record types:

System Policy The System Policy record is not used for RACF in the current (3.6) release. For platforms, such as Windows NT and UNIX, it is used to manage machine-wide policy, such as password rules. It may be that a future release will include some RACF attributes in here to implement SETROPTS functions.

Resource The Resource record can be used to define a RACF resource profile. We can specify resource types, such as ACCTNUM or DATASET (generic or discrete), and so on. In a resource record, we also set the default access to that resource. Defining RACF resource profiles to Tivoli is optional. We may just wish to control access to existing resources through roles without having to define all the resources in Tivoli. We can do that by specifying the resources by name without having them defined in Tivoli resource records.

Role The role record identifies a list of resources, either resources defined in Tivoli resource records or just named using an endpoint-type specific convention. The resources


can be from any platform supported by TSM. For each resource, the role defines what access someone with that role will get to resource. Roles can seed from other (parent) roles to define similar sets of resources where only a few things need to be changed. The role record is linked to the group record such tha, when a group is given a particular role, that role record also knows the name(s) of the group(s) it is associated with.

Group The Tivoli security group record can contain user names from a Tivoli TUA user profile or directly named users by platform type. A group record is also associated with one or more roles that ultimately determine the access rights of the users within that group. The connection to a group can also be made from within TUA. In either case, the connection takes place when the Tivoli security profile is distributed to the RACF endpoint.

5.1.1 Tivoli Roles in RACFTo implement Tivoli security roles in RACF, we use a new RACF general resource class called ROLE. This class is added as part of the PTF for APAR OW26060 (See Appendix A.1, “APAR OW26060” on page 119).

The RACF ROLE profiles are used to store role configuration data. The access checking mechanism is not altered from what RACF normally uses. The relationship of RACF ROLE profiles to the other RACF access components is shown in Figure 29.

Note that RACF does not use ROLE profiles for access checking. During distribution, the group-role-resource relationships are resolved to group-resource. That is, the RACF group is added to the (conditional) access list of the RACF resource profile, such that the traditional access checking may then be used.


Figure 29. Tivoli User and Security Profile Implementation

The security data from the Tivoli management database is reflected in RACF through TME segments added to RACF Group and Resource profiles and through the new RACF Role profile. The connections of users to groups, the permit operations between groups, and resources in RACF occur at the time Tivoli user and security profiles are distributed to the OS/390 endpoint. When a Tivoli security profile is distributed and applied to RACF, the following actions occur:

• The RACF role profile is created/updated with the role data, such as parent and child roles, group list, and resource list.

• All the resource profiles referenced in the role resource list are updated in two ways:

• The TME segment is updated to include the role. This happens whether the resource is a Tivoli-defined resource or simply a RACF resource named in the role. The data in this segment contains the role name along with the access level required. The format of the entries vary. If a conditional access is specified, then that data is placed on the end of the entry for that resource.

• The ACL data is updated through PERMIT commands to reflect the group information provided in the role’s group list.

Resource

Role Profile

User Group

Role List

ParentChild ListGroup ListResource List

TME Segment

Profiles

RACF

Profiles

Role ListTME Segment


ProfilesBase OMVS.... ....

Base OMVS.... ....

Base OMVS.... ....

Base OMVS.... ....

Base OMVS.... ....


ACL Data


ACL Data

Managed by TSMManaged by TUA

PERMIT

CONNECT

Access Control Management 91

• All the group profiles referenced in the role’s group list have their TME segment updated to include the role. As with resources, this occurs whether the group is a Tivoli-defined group or simply a RACF group named in the role.

Also, when the Tivoli security profile is distributed, any modification to the Tivoli group records will cause the following actions:

• Tivoli-defined groups that are not already defined in RACF will be created.

• Users listed in the Tivoli security profile group record are CONNECTed to the correct group or groups. The RACF user profiles must already exist in RACF, having been defined natively or having been defined and distributed from TUA user profiles. The user list may have come from TUA or may have been entered directly.

• Users in an existing RACF group who do not appear in the Tivoli security profile group record are removed from the RACF group.

Similarly, the distribution of the Tivoli security profile with resource modifications will make the following happen:

• Tivoli-defined resources not defined in RACF resource profiles will cause the creation of RACF resource profiles.

• The RACF resource profile UACC will be set, or modified, to reflect the default access defined in the Tivoli resource record.

A user defined to a role by virtue of their group membership will have their access request checked using the normal RACF procedure of checking the resource ACL.

5.2 Security Policy

TSM and the Tivoli Framework employ a number of techniques to implement an organization’s security policy. Administrative policy, through policy regions and other features, is discussed in 2.6, “Secure Delegation of Administration” on page 19. As with TUA, TSM employs default and validation policy to ensure Tivoli security records are created and modified according to rules determined by the target platforms or by the security policy of the company. Section 4.2, “Use of Default and Validation Policy” on page 68 applies equally to TSM as it does to TUA.

One of the record types in a TSM security profile is the System Policy record. System policy is not implemented in 3.6 for the OS/390 endpoint. In Windows NT and UNIX, this is used to cover policy that applies to the whole machine


rather than individual users. System policy would include password policy. For example, where the password rules for the domain or the system are specified. System policy for OS/390 is under review in development and may be used to implement certain attributes. For example, the kind of thing typically set through SETROPTS .

The remainder of security policy is implemented through role-based security, defining the access that groups of users have to sets of resources.

5.3 Implementation Considerations

This section describes considerations specific to TSM in a RACF environment.

5.3.1 Exact Copy DistributionThe Tivoli distribution option, MAKE EXACT COPY, has different effects on different platforms. For TSM on RACF, as with TUA, no implicit deletions are made. That means that a security profile distributed to RACF with MAKE EXACT COPY that does not specify all the RACF group profiles already present in RACF will not cause those group profiles to be deleted from RACF.

Regardless of whether you are using make exact copy or not, if a group is specified in TSM and distributed to RACF, then the connections to that group in RACF will be made to match those specified by the user list for the group in TSM. Also, if the group is subsequently deleted from the Tivoli security profile and the profile is distributed to RACF, then that group will also be deleted from RACF. If you wish to stop managing a resource, such as a group that you have been managing in Tivoli, the procedure is to move the resource to a temporary profile and delete it from that profile. You then need to ensure that the temporary profile is never distributed. It is safest to delete the temporary profile (the temporary profile should never have any subscribers).

Note that it is difficult to remove a user from a single subscribed RACF endpoint through Tivoli. If you move the user to another Tivoli profile, the RACF endpoint will not implicitly remove a user just because that user is no longer in the profile it receives. The RACF endpoint will only remove the RACF user profile if the user record is deleted from the Tivoli profile, and that profile is then distributed to the RACF endpoint. It is likely to be better, in these circumstances, to use native tools to remove the user from RACF, and then remove that RACF subscriber from the Tivoli profile manager. If this is a common operation, the removal from RACF and the removal of a subscription of an endpoint can be placed into a Tivoli task. Different endpoints treat the removal of users in different ways, and it is also affected by the use of


database or data-less profile managers. Refer to the TUA product manuals and release notes for further information.

5.3.2 Use of Access Warning ModeThose familiar with the warning mode for resources in TACF on UNIX will understand the RACF warning mode. It is used for the same purpose. In RACF, we can define access control for a resource and specify the RACF warning mode for the resource. This will mean that an access request will be checked, but access by RACF will always be granted. If the check would normally result in a failure, then an audit record is logged stating this.

The difference in TACF is that there is the default UNIX security below TACF in the native Owner/Group/Everyone access bits of the file system.

5.3.3 User Consideration when Adding a ResourceAdding a new resource and placing it in a TSM role will make that resource accessible to all users in associated groups following the next distribution. This is a very powerful operation. However, when a new resource is added to TSM, it must be taken into account that, when that resource is linked to a Role and then to a Group, it is possible that a user in that group may not have an ID on the system in which the new resource resides. An example of this scenario is as follows: A resource for a new system, SYSTEMA, is added to an existing Role AdminDept. This role is linked to group AUSADM in which user TOMJ belongs. A problem arises when user TOMJ does not exist on SYSTEMA.

When the Tivoli security profile is distributed, an attempt will be made to connect TOMJ to the AUSADM group. This will fail, with a message returned to the administrator. Correction through Tivoli would involve adding the user to a Tivoli user profile subscribed to by SYSTEMA, distributing that user profile, and then redistributing the security profile. Administrators need to be aware of this consideration and should plan resource creation activities if they wish to avoid errors.

5.4 Tape Volume Management

We would suggest that, at least for release 3.6, it does not make sense to manage RACF profiles in the TAPEVOL class through TSM. However, it is reasonable to use Tivoli roles to manage the access rights to TAPEVOL resources that are defined in RACF.


5.5 Customizing TSM

As with TUA, TSM can be customized through the Application Extension Facility (AEF). For example, you may have RACF resources that are not in the default classes supported by TSM. The TSM AEF facility allows you to add those custom classes to TSM, so that they can be managed through TSM in the same way as any of the default classes.

RACF classes can be added to using the waddsecrestype command. It’s easiest to find an existing class with the attributes you want for your new class, and clone the existing class:

waddsecrestype -e RF -d MYCLASS -c FACILITY myprofile

This example adds a RACF resource (-e RF) called MYCLASS , cloning it from the existing class FACILITY. The new resource type will be added to the Tivoli security profile called myprofile.

After this is done, you will see the new class in the list you get when adding a new resource record. You will also be able to associate a record of this type with a role definition.

Tivoli provides the ability to define all aspects of a security system to be managed, including permissions, attributes, and properties, and even an endpoint (waddseceptype). As with TUA, you can specify actions that take place when the profile is distributed. Refer to the Tivoli Security Management User’s Guide for details on the AEF tools and commands available for TSM.



Chapter 6. Auditing and Event Management

This chapter looks at tracking what is going on through auditing and event handling functions. As well as using the existing auditing capabilities of a platform, Tivoli adds additional logging facilities as well as the management of security events through the Tivoli Enterprise Console (TEC).

For those unfamiliar with RACF’s powerful auditing features, the first section of this chapter provides a comprehensive introduction.

6.1 Standard Auditing in RACF

Logging, the recording of data about specific events, is the key to auditing the use of RACF at your installation. You must ensure that RACF logs the information you need. RACF uses the System Management Facility (SMF) to log data about various RACF events. RACF writes SMF records to an SMF data set (see also 6.3, “RACF System Management Facility Data” on page 115).

RACF always logs information about certain events because knowing about these events is essential to an effective data-security mechanism.

The events that RACF always logs are:

• Every use of the RVARY or SETROPTS command.

If you are using the RACF subsystem on MVS and issue RVARY as an MVS operator command, the job name information is propagated in the SMF record. This distinguishes it from an RVARY command issued from a TSO session.

• Every time a VERIFY request fails.

• Every time the console operator grants access to a resource as part of the failsoft processing performed when RACF is inactive.

• When a user not defined as a UNIX System Services user tries to dub a process.

• When a user not defined as a super user tries to mount or unmount a file system.

For more details on OS/390 UNIX System Services events for which audit records are always written, refer to OS/390 UNIX System Services Planning.


RACF never logs some events because knowing about these events is not essential to effective data security. RACF never logs any use of the following RACF commands: LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH.

In addition to the events that RACF always logs and never logs, other events RACF can optionally log. Optional logging is under the control of either a resource-profile owner or the auditor.

6.1.1 Owner-Controlled LoggingOwners of resources can specify, in the resource profile, what types of accesses to log (successes, failures, or both) and what level of access to log (READ, UPDATE, CONTROL, or ALTER). Owners can also specify that no logging is to occur for an access that is a success or failure. Owner-controlled logging is not directly under your control, but you should verify that resource owners request a level of logging that is consistent with the sensitivity of the resource. Furthermore, your installation can use three methods to override the logging that an owner specifies in the resource profile:

1. You can suppress auditing for all resources in a specific class by specifying LOGOPTIONS(NEVER(class-name)) on the SETROPTS command. Likewise, you can activate auditing for all access attempts for all resources in a specific class by specifying LOGOPTIONS(ALWAYS(class-name)).

2. If you have the AUDITOR attribute, you can specify additional logging that supersedes the owner’s logging specification for a specific resource by adding audit controls to the resource profile. Note that you cannot change the owner’s logging specifications for a specific resource profile, only add to them. You can do this for specific resource profiles by specifying the GLOBALAUDIT operand on the ALTDSD or RALTER command.

3. For resources that have their authority checked by RACROUTE REQUEST=AUTH, your installation can bypass a profile owner’s logging specification by using the RACROUTE REQUEST=AUTH post-processing exit routine. This exit routine can, for certain accesses, specify unconditional logging or unconditionally suppress logging. For example:

• An installation might use the exit routine to specify unconditional logging for accesses to a highly classified resource.

• An installation might suppress logging when the exit routine recognizes READ access to common system resources, such as SYS1.MACLIB.


6.1.2 Auditor-Controlled LoggingThe auditor can direct RACF to log additional events. These events are:

• Changes to any RACF profiles. • All RACF commands that a SPECIAL or group-SPECIAL user issues. • All unauthorized attempts to use RACF commands. • All RACF-related activities of specific users. • All accesses to resources (data sets and general resources) that RACF

allows because the user has the OPERATIONS or group-OPERATIONS attribute.

• All accesses to specific data sets. • All accesses to specific general resources. • All accesses to resources protected by specific profiles in the SECLABEL

class. • All accesses to a specified class of resources at an access level indicated

on the LOGOPTIONS keyword of the SETROPTS command. • Selected events in related APPC/MVS transactions. • UNIX System Services events. See OS/390 Security Server (RACF)

Macros and Interfaces for event codes and a table of event code qualifiers.

You can identify which of these events apply to your installation's security goals and use audit controls to direct RACF to log the events you require.

6.1.3 Auditing Tools Supplied with RACFThe RACF component of the OS/390 Security Server comes with several auditing tools, for example:

• The RACF Cross Reference Utility (IRRUT100)

• The RACF Report Writer (RACFRW)

• The RACF Database Unload Utility (IRRDBU00)

• The RACF SMF Unload Utility program (IRRADU00)

• The Data Set Security Monitor (ICHDSMON)

Owner-controlled logging for UNIX System Services files is specified in the file security packet (FSP) instead of a profile, the access levels are different, and logging is set with the Chaudit command. For more information about this command, see OS/390 UNIX System Services User's Guide.

Note to UNIX System Services Users

Auditing and Event Management 99

6.1.3.1 RACF Cross Reference UtilityIf you have the AUDITOR or SPECIAL attribute, you can use the RACF cross-reference utility to find and list occurrences of a user ID or group name in the RACF database.

If you have the group-AUDITOR or group-SPECIAL attribute, you can use these utilities only for a user ID or group that is within your scope of authority.

You can also process your profile or profiles that you own.

The RACF Cross Reference utility is a batch utility that is invoked by executing the following JCL:

In this example, IRRUT100 locates all occurrences of the group name RACG0001 and the user ID RACU002 in the RACF database and prints these occurrences on the system output device.

The output of the RACF Cross Reference Utility program might look something like this:

//XREF JOB//STEP EXEC PGM=IRRUT100//SYSUT1 DD UNIT=SYSDA,SPACE=(TRK,(5,1))//SYSPRINT DD SYSOUT=A//SYSIN DD *RACG0001 RACU002/END


For more information on the RACF Cross Reference Utility program (IRRUT100), see the OS/390 Security Server (RACF) System Programmer’s Guide.

Occurrences of GROUPMID Owner of DASDVOL DOWNER In standard access list of general resource profile DASDVOL DGROUP Create group of profile USERMID.GROUP.TEST (G) Owner of profile HILDE.OWNER.DATASET First qualifier of profile GROUPMID.SAMPLE.DATASET In standard access list of dataset profile GROUPLOW.ACCESS.DATASET Owner of connect profile USERMID2/SYS1 Owner of connect profile USERMID1/SYS1 Owner of group GROUPOWN Superior group of group GROUPOWN Group name exists Superior group of group GROUPLOW In subgroup list of group GROUPHI Connect group for user USER3 Connect group for user USER2 Connect group for user USER1 Connect group for user USERMID1 Owner of user USERMID1 Connect group for user USERMID Default group for user USERMID Connect group for user HILDE (G) - Entity name is generic.

Occurrences of USER1

In notify field of general resource profile DASDVOL DUSER1 In conditional access list of general resource profile DASDVOL DUSER1 Owner of profile USER2.OWN.DATASET Owner of profile USER1.SAMPLE.DATASET First qualifier of profile USER1.SAMPLE.DATASET In standard access list of data set profile USERMID.GROUP.TEST (G) In notify field of data set profile HILDE.NOTIFY.CNTL In conditional access list of data set profile HILDE.COND.ACCESS Owner of connect profile USER2/SYS1 Owner of connect profile USER2/GROUPMID Owner of group UGRP1 In access list of group SYS1 In access list of group GROUPMID RACLINK entry is present in user profile USER2 as MVS1.USER1 Owner of user USER2 User entry exists RACLINK entry is present in user profile MONTAGU as MVS2.USER1 Qualifier of general resource profile FILE FP1.USER1.DIR1.MIKAELA.MEM Qualifierof general resource profile DIRECTRY FP1.USER1.** (G)

(G) - Entity name is generic.


6.1.3.2 RACF Report WriterThe profile listings the RACF commands provide can help you to verify the audit controls that exist at any particular time. The RACF report writer helps you to monitor RACF-related activity during system operation and to verify that these activities are consistent with your installation’s security goals. It provides printed reports based on the data your audit controls directed RACF to log.

The report writer makes use of certain SMF records to obtain information. You can control the selection of these records and the format and type of report that the report writer produces through the use of the RACFRW command and its subcommands.

To invoke the RACF Report Writer, you can use the following JCL example:

The output of a given RACF Report Writer report might look like this:

The report writer supports audit records for RACF release 1.9.2 and earlier. It does not support most of the audit records introduced in the RACF Version 2 releases. IBM recommends that you now use the SMF Unload Utility program as discussed in Part 6.1.3.4, “RACF SMF Data Unload Utility Program” on page 104.

Note

//RACFRW2 EXEC PGM=IKJEFT01//SORTWKxx DD your sort work files//SYSPRINT DD SYSOUT=*//SYSTSPRT DD SYSOUT=*//RSMFIN DD DISP=(SHR,PASS,DELETE),DSN=SMF.INPUT.DATASET//SYSTSIN DD *,DLM=XXRACFRW TITLE(’RACF REPORTS’) GENSUMSELECT VIOLATIONSLIST TITLE(’ACCESS VIOLATIONS SUMMARY REPORT’)SUMMARY RESOURCE BY(USER)ENDXX


6.1.3.3 RACF Database Unload Utility ProgramYou can also use the RACF database unload utility to provide flexibility in analyzing RACF profile information. The output from this utility is a sequential file that is a relational representation of a restructured RACF database.

If the output is loaded into a database management system (such as DB2), you can issue your own queries. For example, you can find and list occurrences of a user ID or group name in the RACF database. You can list members of a group by name rather than user ID.

Your input database must be in the restructured format, and you must have UPDATE authority to it.

To invoke the RACF Database Unload Utility Program (IRRDBU00), you can use the following JCL example:

The output file can then be loaded into a relational database manager, such as DB2. Sample DB2 load statements and sample queries are supplied in the SYS1.SAMPLIB.

For more information on the RACF Database Unload Utility program, see the OS/390 Security Server (RACF) Security Administrator’s Guide.

90.053 13:51:40 RACF REPORT - LISTING OF PROCESS RECORDSEV QE U

*JOB/USER *STEP/ --TERMINAL-- N ADATE TIME SYSID NAME GROUP ID LVL T L90.053 12:15:03 R190 IBMUSER SYS1 LEO2 0 1 0 JOBID=(IBMUSER 90.053 12:15:01),USERDATA=(),

OWNER= AUTH=(NONE),REASON=(NONE)90.053 12:15:08 R190 IBMUSER SYS1 LEO2 0 2 0 JOBID=(IBMUSER 90.053 12:15:01),USERDATA=(),

OWNER=IBMUSERGEORGE JONES AUTH=(NORMAL),REASON=(ENTITY OR FAILSOFT

PROCESSING) LOGSTR=’LOGSTR DATA’USER SECLABEL=SYSHIGH,SESSION=TSO LOGON,TERMINAL=LEO2DATASET=SYS1.BROADCAST,GENPROF=SYS1.BRODCAST,VOLUME=SPOOL1,LEVEL=00INTENT=READ,ALLOWED=ALTER

//USER01 JOB Job card...//UNLOAD EXEC PGM=IRRDBU00,PARM=NOLOCKINPUT//SYSPRINT DD SYSOUT=*//INDD1 DD DISP=SHR,DSN=SYS1.RACFDB//OUTDD DD DISP=SHR,DSN=SYS1.RACFDB.FLATFILE


6.1.3.4 RACF SMF Data Unload Utility ProgramThe RACF SMF data unload utility is the IBM-recommended utility for processing RACF audit records. With it, you can create a sequential file from the security relevant audit data. You can use the sequential file in several ways. You can:

• View the file directly

• Use the file as input for installation-written programs

• Manipulate the file with sort/merge utilities

You can also upload the file to a database manager (for example, DB2) to process complex inquiries and create installation-tailored reports. Sample DB2 load statements and sample queries are supplied in the SYS1.SAMPLIB.

To invoke the SMF Data Unload Utility Program (IRRADU00), you can use the following JCL:

For more information on the SMF Data Unload Utility Program, see OS/390 Security Server (RACF) Security Administrator’s Guide.

6.1.3.5 RACF Data Security MonitorRACF enables you to protect resources, but the protection is only as good as the implementation. You need a way to verify that the security mechanisms actually in effect are the ones intended. DSMON (ICHDSMON) helps provide this information.

DSMON is a program that 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 current status of your installation's system security environment by comparing the actual system characteristics and resource-protection levels with the intended

//SMFUNLD JOB ,’SMF DATA UNLOAD’,MSGLEVEL=(1,1),TYPRUN=HOLD //SMFDUMP EXEC PGM=IFASMFDP //SYSPRINT DD SYSOUT=A //ADUPRINT DD SYSOUT=A //OUTDD DD DISP=SHR,DSN=USER01.RACF.IRRADU00//SMFDATA DD DISP=SHR,DSN=USER01.RACF.SMFDATA//SMFOUT DD DUMMY//SYSIN DD * INDD(SMFDATA,OPTIONS(DUMP))OUTDD(SMFOUT,TYPE(000:255))USER2(IRRADU00)USER3(IRRADU86)/*


characteristics and levels. You can also control the reporting that DSMON does by specifying control statements that request certain functions for user input.

DSMON is a program that normally runs while RACF is active.

To run the DSMON program, you must have one of the following:

• The AUDITOR attribute

• At least EXECUTE access authority to the PROGRAM profile protecting DSMON if DSMON is a controlled program

READ access authority may be required by other programs if DSMON runs in a TSO environment.

You can specify DSMON control statements to produce the reports you want and control the number of lines per page for each report. The output from DSMON consists of a message data set and an output data set for the reports.

To invoke the DSMON program, you can use the following JCL:

One of the reports that the DSMON can generate is a RACF Group Tree Structure report that shows you the hierarchy within RACF groups, for example:

//stepname EXEC PGM=ICHDSM00//SYSPRINT DD SYSOUT=a//SYSUT2 DD SYSOUT=a//SYSIN DD *LINECOUNT 55FUNCTION allUSEROPT USRDSN sivle.memo.text


6.1.4 Additional RACF Auditing ToolsBesides the supplied auditing tools with RACF, there are also some other RACF auditing tools available through the RACF web page:

http://www.s390.ibm.com/products/racf/racfhp.html.

These auditing tools are:

• RACFICE

RACFICE is a set of examples using the ICETOOL program, supplied with the DF/SORT product, to do RACF reporting on both the RACF Database Unload Utility Program and the SMF Data Unload Utility Program output.

• OS390ART

The OS390ART utility program was written during several ITSO residencies and is documented in redbook SG24-4820, OS/390 Security Server Auditing and Reporting Tool. OS390ART is an ISPF/QMF/DB2 based application that gives the auditor all the relevant auditing information on-line from the TSO/ISPF session. Inputs to the application are the DB2 tables that contain both the RACF Database Unload Utility Program output and the SMF Data Unload Utility Program Output.

R A C F G R O U P T R E E R E P O R T LEVEL GROUP (OWNER)

----------------------------------------------------------------------- 1 SYS1 (IBMUSER ) 2 | ALL (IBMUSER ) | 2 | C49TEST (IBMUSER ) | 2 | INFO (IBMUSER ) | 2 | JESS (IBMUSER ) | 2 | LIBS (IBMUSER ) | 2 | MASTER (IBMUSER ) | 2 | OPERCNTL (IBMUSER ) | 2 | OPERRD (IBMUSER ) | 2 | OPERUP (IBMUSER )


6.1.5 Auditing Changes Made through TivoliNote that when a Tivoli administrator initiates a RACF change, the ID that is logged in the audit trail is that of the administrator mapped from whoever performed the distribution. There is no record in the standard audit trail of who changed the Tivoli profile. That information is held in the Tivoli notices database. See 6.5, “Tivoli Notice Groups” on page 116 for more details.

6.2 RACF Messages and TEC Event Integration

You can use the Tivoli NetView for OS/390 Event/Automation Service to forward RACF console messages to the Tivoli Enterprise Console. These messages are also known as Write to Operator or WTO messages. RACF uses the message prefixes ICH and IRR, but there may be other message types we would be interested in, such as jobs starting and stopping, and so on.

The forwarding of OS/390 WTO messages to TEC is covered in the NetView for OS/390 manuals and the redbook SG24-5224 An Introduction to Tivoli NetView for OS/390 V1R2. An overview of the message flow is shown in Figure 30 and we provide an example of how to get this working starting with 6.2.1, “Customizing NetView Automation Table for ICH Messages” on page 109.

Prior to Tivoli NetView for OS/390 V1 R2, the Event/Automation Service was a component of the integration services provided with the Tivoli Global Enterprise Manager (GEM).

Note


Figure 30. Routing OS/390 Messages to TEC

The sequence for forwarding a message to TEC is as follows:

1. The NetView automation table drives commands that route the message to the main task of the Event/Automation service.

2. The main task routes the message to the appropriate message adapter.

3. The message adapter converts the message to an event and sends the event to the Event Integration Facility (EIF) component of the adapter.

4. The EIF passes the event through filtering and, if necessary, sends the event over a TCP/IP pipe to the TEC event server.

In order to implement message forwarding, the messages to be forwarded are identified in the NetView Automation table. The Event/Automation services provide a default mapping of OS/390 messages to TEC events, and this can be used or modified as required. There are some OS/390 message handling rules provided with TEC (tecad_nv390msg.rls), and you can add more sophisticated rules, such as the correlation of security events, from OS/390 with other platforms.

The remainder of this section gives a sample TEC configuration for RACF ICH messages. Remember that there may be other messages you will want to forward to TEC, such as all IRR messages and some job messages. For example:

IEF695I START DCEKERN WITH JOBNAME DCEKERN IS ASSIGNED TO USER DCEKERN , GROUP DCEGRP

OS/390 TEC Server

Netview Event/AutomationService

AutomationTable M

ain

Task

Convert EIFtecad_nv390msg.rls

1 2 3 4


This example shows you how to configure the Tivoli Enterprise Console (TEC) and Tivoli NetView for OS/390 to have some RACF messages forwarded by NetView to the TEC server.

The flow is depicted in Figure 30. We will describe the major configuration required for the components of that flow.

6.2.1 Customizing NetView Automation Table for ICH MessagesYou should add the following statement to your NetView automation table. This will cause any message starting with ICH to be forwarded to the message adapter in the Event/Automation Service.

Figure 31. Sample NetView Automation Definition for RACF ICH Messages

6.2.2 Message Adapter Format File for RACF MessagesThe message adapter uses a format file to map a message to a specific event. The following is a sample FMT file for the message adapter (IHSARACF):

IF MSGID = ’ICH’ . THEN EXEC(CMD(’PIPE SAFE * | PPI TECROUTE IHSATEC’) ROUTE(ONE AUTO1)) CONTINUE(Y);


Figure 32. Message Adapter Format File for RACF Messages

With this format file, you can map the messages that have an ICH prefix and a W (warning suffix) to the RACF_Warning event class and all other messages with the ICH prefix to the RACF_Default event class. We are also including an example here of managing an individual message (ICH408I).

/* ------------------------------------------------------------------ */ /* Licensed Materials - Property of IBM */ /* 5697-B82 */ /* (C) Copyright IBM Corp. 1997. All rights reserved. */ /* */ /* US Government Users Restricted Rights - Use, duplication or */ /* disclosure restricted by GSA ADP Schedule Contract with IBM Corp. */ /* ****************************************************************** */ /* */ /* Description: */ /* Format statements for RACF messages */ /* Adapter. */ /* */ /* IHSAracf CHANGE ACTIVITY: */ /* CHANGE CODE DATE DESCRIPTION */ /* ----------- -------- ------------------------------------------*/ /* Note: The Rules (e.g. tecad_nv390msg.rls) in the T/EC Event Server */ /* only fire against leaf class events in the baroc file, e.g. */ /* tecad_nv390msg.baroc. So if you want the rules to fire, take */ /* care to build leaf class events here in the FMT file. */ /* ------------------------------------------------------------------ */ /* ------------------------------------------------------------------ */ /* ------------------------------------------------------------------ */ /* RACF componet messages. */ /* ------------------------------------------------------------------ */ FORMAT RACF_Default FOLLOWS NV390MSG_Event ICH%s %s* severity "HARMLESS" sub_source "Security" END /* ------------------------------------------------------------------ *//* RACF Warning messages *//* ------------------------------------------------------------------ */FORMAT RACF_Warning FOLLOWS NV390MSG_EventICH%sW %s*severity "WARNING"sub_source "Security"END/* ------------------------------------------------------------------ */ /* RACF Unauthorized messages */ /* ------------------------------------------------------------------ */ FORMAT RACF_Unauthorized FOLLOWS RACF_Default ICH408I %s* severity "WARNING" sub_source "Security" END


You can include this format file in the IHSAFMT message adapter’s base format file.

Figure 33. Including RACF Format File in Base Format File

6.2.3 Creating New Event Classes for RACF MessagesAs when forwarding any other messages, you should define to TEC new event classes for RACF. Each adapter comes with a Basic Recorder of Objects in C (BAROC) file describing the various classes and subclasses of alarms the adapter supports. This file is not used by the adapter itself but serves as a mandatory link between the adapter and the event server that must load this file before it is able to understand messages received from the adapter. The following tecad_racf.baroc file is a sample BAROC file that has three event leaf classes for RACF messages:

/* ------------------------------------------------------------------ */ /* Licensed Materials - Property of IBM */ /* 5697-B82 */ /* (C) Copyright IBM Corp. 1997. All rights reserved. */ /* */ /* US Government Users Restricted Rights - Use, duplication or */ /* disclosure restricted by GSA ADP Schedule Contract with IBM Corp. */ /* ****************************************************************** */ /* */ /* Description: */ /* Default set of Format statements for the T/EC NetView/390 Message*/ /* Adapter. */ /* */ /* IHSAMFMT CHANGE ACTIVITY: */ /* CHANGE CODE DATE DESCRIPTION */ /* ----------- -------- ------------------------------------------*/ /* OW26301,V1R1,04/10/97,RLF: Enable APM support. */

.................

................./* ------------------------------------------------------------------ */ /* Uncomment the following line to Include RACF events */ /* ------------------------------------------------------------------ */ %INCLUDE IHSARACF


Figure 34. Sample TEC BAROC File for RACF - tecad_racf.baroc

The RACF_Event class is a parent class for all RACF related event classes. The RACF_Unauthorized class is for those messages that have message code ICH408I. The RACF_Warning class is to deal with all ICH warning messages, and the RACF_Default class is for all other RACF messages that

#*====================================================================*# Licensed Materials - Property of IBM# (C) Copyright IBM Corp. 1998. All rights reserved.## US Government Users Restricted Rights - Use, duplication or# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.#**********************************************************************## Description:tecad_racf.baroc# T/EC message class definitions for IBM’s RACF messages## Note: The Rules in the T/EC Event Server# only fire against leaf class events. So be careful if you decide# to subclass an existing class here in the tecad_nv390msg.baroc# file, because if you accidentally change a leaf class to a non-leaf# class by adding a new subclass, then the rules will no longer fire# against events received from the now non-leaf class.##*====================================================================*

TEC_CLASS : RACF_Event ISA NV390MSG_Event DEFINES { sub_source: default="RACF", dup_detect=yes; };END

## RACF subclasses follow.#

# Leaf class for ICH408I

TEC_CLASS : RACF_Unauthorized ISA RACF_Event;END

# Leaf class for any Warning messages from RACF (ICHxxxW)

TEC_CLASS : RACF_Warning ISA RACF_Event;END

# Leaf class for any other messages from RACF (ICHxxxy)

TEC_CLASS : RACF_Default ISA RACF_Event;END


have the prefix ICH. All these event classes are for RACF inherited slot information from the NV390MSG_Event event class. Therefore, you don’t need to define event slots for RACF messages over again unless you want to add RACF specific slots.

If you want to send RACF messages that mapped with other event classes to the TEC server, you can add the event class definition to this BAROC file easily.

After creating this BAROC file, you need to import this file into your Rule Base. If your new BAROC file has its parent class in another BAROC file, your BAROC file must be inserted after the parent BAROC file.

Your Rule Base needs to re-compiled and reloaded to activate your new event class. The TEC Server must be restarted. See the Tivoli Enterprise Console User’s Guide for a more detailed description about RuleBase operation.

6.2.4 Sample RACF Event on TEC ConsoleOur example means you will get the event shown in Figure 35 when a TSO user tries to logon to the system with the wrong password.

You should be careful in your design of event hierarchy because the Rules in the TEC Server only fire against leaf event classes. Therefore, if you change a leaf class to a non-leaf class by adding a new class, then the rules will no longer fire against events received from what is now a non-leaf class. Refer to the TEC product documentation for more details.

Note


Figure 35. RACF Event on TEC Console

You can see more detailed information about the event in the event detail window shown in Figure 36.


Figure 36. RACF Event Detail Window

6.3 RACF System Management Facility Data

The OS/390 System Management Facility (SMF) is the part of the MVS operating system that collects and records system information in SMF datasets. Many functions and subsystems, including RACF, cause SMF records to be written to the SMF log. These records can be very detailed.

See 6.1, “Standard Auditing in RACF” on page 97 and 6.1.3.4, “RACF SMF Data Unload Utility Program” on page 104 for a description of the existing use of SMF with RACF.


As one SMF dataset becomes full, the writer switches to the next available SMF dataset, and usually the full SMF dataset is unloaded to a sequential dataset on disk or tape. This presents at least two possible solutions for utilizing the SMF data.

The first possibility would involve post-processing the unloaded SMF data, probably in combination with the RACF SMF data unload utility program (IRRADU00). We can filter out the RACF related records (types 20, 30, 80, 81, and 83) and send that data to Tivoli through an event adapter or store it in an archive.

The second approach would be to use an SMF exit (IEFU83) to catch the records while they are being written and relay them to another process (such as NetView) to send them to Tivoli. One relatively simple way to achieve this would be to use IEFU83 to create WTO messages that can be captured like any other message in NetView.

A sample IEFU83 exit routine is provided in SYS1.SAMPLIB in member SMFEXITS.

6.4 Integration with Other Logging Functions

TSM provides a number of TEC rules related to security events. These can be extended to include RACF events, or as shown in 6.2, “RACF Messages and TEC Event Integration” on page 107, other rules can be written to perform required actions based on known risks.

Through the open nature of the Tivoli Management Framework, other options are available for integrating more security functions with RACF management. Examples include best-of-breed products available as Tivoli Plus modules to cover features such as intrusion detection, firewall management, and anti-virus control.

6.5 Tivoli Notice Groups

Tivoli administrative actions are logged to Tivoli notice groups. Applications and Tivoli Management Framework components maintain their own notice groups. Administrators can be subscribed to these notice groups to enable them to review information about management operations, including those performed by other administrators. See the TME 10 Framework User’s Guide for more details on notice group subscription.


Among other information, TUA and TSM log details of changes made to user and security profiles. For user profiles, TUA will log the administrator that made the change and the record in the profile that was changed. For security profiles, TSM will log even more information, including exactly what modifications were made to each attribute of a security record.

Refer to the warning note below. In many instances, these notice logs are better viewed as problem-solving sources rather than a day-to-day administrator feature.

6.5.1 Archiving Notice Group DataNotices in the notice groups expire after a preset time. Notices are stored when a backup of the Tivoli database is performed, but to read those notices they would have to be restored into a TMR first. If it is necessary to keep a long-term record of administrator notices, then it would be better to export the notices to some form of archive.

One way of achieving this is to use the Tivoli command wlsnotif. This command allows the exporting of the notices text from specific notice groups or all notice groups. In some environments, it may be better not to have administrators reviewing notices directly. Instead, all notices would be exported to an archive, and wexpnotif can be used to expire them from the notice group once the export has taken place.

For more details on the notice commands, see the Tivoli Framework Reference Manual.

For TUA, if multiple administrators modify the same user profile, the notices will not tell you which administrator changed which attribute in the profile. Any changes made at the endpoint itself during a distribution will be made under the name of the administrator performing the distribution (or some mapped ID). If you have specific attributes for which you wish to track changes (such as the RACF system SPECIAL attribute) then some other method would have to be employed to do that tracking. One suggestion would be to add some logging to a file in the validation policy script for that attribute. It is likely that Tivoli will provide more detailed logging here in a future release, as they do with TSM attribute updates.

Note


6.6 OS/390 Event Integration Facility

The Tivoli Event Integration Facility (EIF) is a mechanism for routing UNIX events to the Tivoli Enterprise Console (TEC). A version of EIF for OS/390 UNIX System Services is provided in SMP/E install format with TEC v3.6. This means that Tivoli applications on the endpoint, and any other applications in UNIX Systems Services, can send their events to TEC directly through this EIF function in the same way as is common for Tivoli in the distributed environment.


Appendix A. RACF Pre-requisite APARs

This appendix documents the two APARs that are pre-requisites for Tivoli’s management of RACF using TUA and TSM for OS/390. Refer to your service representative for further information about these APARs.

A.1 APAR OW26060

NEW FUNCTION FOR TME10 AND FOR PASSWORD RESET WITHOUT REQUIRING EXCESSIVE RACF PRIVILEGE

With the OS/390 Security Server (RACF), support for Tivoli Management Environment (TME) 10, Tivoli users can enter Resource Access Control Facility (RACF) commands and manage a subset of security information from a TME 10 desktop. This support provides extensions to the OS/390 Security Server (RACF) to provide role, resource, and group support through TME 10.

In addition, this support adds the ability to set a password that doesn't need to be changed at next logon. This provides value to OS/390 Security Server (RACF) customers even in the absence of TME 10. It is further enhanced by not requiring the traditional RACF privilege to reset passwords (that is, system SPECIAL, group SPECIAL, or owner of the user profile). This allows, for example, a help desk administrator to reset passwords without requiring excessive RACF privilege.

USERS EFFECTED: All at HRF2230 or HRF2240 that require either RACF support for the Tivoli Management Environment or who have a requirement for help desk or similar personnel to be able to reset passwords without requiring excessive RACF privilege.

The support consists of:

• Extensions to the R_admin callable service to support groups. This function will support every field in every segment of group profiles.

• Extensions to the R_admin callable service to support connects and removes of users to groups. This function will support all of the group connection attributes.

• Extensions to the R_admin callable service to support data sets and general resources. This function will support every field in every segment of data set and general resource profiles.

• Extensions to the R_admin callable service to support permits to data sets and general resources.


• Addition of a new ROLE general resource class.

• Addition of a TME segment to group, data set, and general resource profiles. Along with dynamic parse (command) updates, this entails changes to:

• the OS/390 Security Server (RACF) database templates

• updates to the Database Unload utility

• updates to the IRRUT100 and IRRRID00 utilities.

• Addition of an EXPIRED/NOEXPIRED keyword to ALTUSER. This includes the corresponding update to the ISPF panels. The function is further enhanced by not requiring the traditional RACF privilege to reset passwords (that is, system SPECIAL, group SPECIAL, or owner of the user profile). This allows, for example, a help desk administrator to reset passwords without requiring excessive RACF privilege.

• Extensions to the R_admin callable service to support the EXPIRED/NOEXPIRED keyword of ALTUSER.

• Generation of GTF TRACE records for R_admin and addition of a GTF formatting exit.

NOTE: The complete documentation changes associated with this APAR (OW26060) have been shipped in the PTF as the IRR26060 member of SYS1.SAMPLIB. Also, see APAR OW26061 for related updates to the IRRPCOMP macro.

A.2 APAR OW26061

This APAR is not Tivoli-specific. It defines the interface to the R_ADMIN service.

IRRPCOMP UPDATES IN SUPPORT OF OW26060 R_ADMIN CALLABLE SERVICE

This APAR provides updates to the Common SAF/RACF Parameter list for OS/390 Unix System Services (COMP). These updates correspond to R_admin callable service extensions provided by APAR OW26060. The COMP data area, mapped by macro IRRPCOMP, may be used by invokers of the R_admin callable service to exploit these extensions.

USERS EFFECTED: Those wishing to exploit the OS/390 Security Server (RACF) R_admin interface enhancements provided by APAR OW26060.

DESCRIPTION:


OS/390 Security Server (RACF) APAR OW26060 provides a number of enhancements to the R_admin callable service, including:

• Extensions to the R_admin callable service to support groups. This function will support every field in every segment of group profiles.

• Extensions to the R_admin callable service to support connects and removes of users to groups. This function will support all of the group connection attributes.

• Extensions to the R_admin callable service to support data sets and general resources. This function will support every field in every segment of data set and general resource profiles.

• Extensions to the R_admin callable service to support permits to data sets and general resources.

• Extensions to the R_admin callable service to support the EXPIRED/NOEXPIRED keyword of ALTUSER.

This APAR (OW26061) provides corresponding updates to the Common SAF/RACF Parameter list for OS/390 UNIX System Services (COMP). The COMP data area, mapped by macro IRRPCOMP, may be used by invokers of the R_admin callable service to exploit these extensions.

NOTE: The complete documentation changes associated with the R_admin callable service extensions are shipped with APAR OW26060 as the IRR26060 member in SYS1.SAMPLIB.

RACF Pre-requisite APARs 121


Appendix B. Special Notices

This publication is intended to help technical professionals understand and implement Tivoli security management products in an OS/390 environment. The information in this publication is not intended as the specification of any programming interfaces that are provided by Tivoli or IBM security products. See the PUBLICATIONS section of the IBM Programming Announcements for Tivoli Systems Management Products for more information about what publications are considered to be product documentation.

References in this publication to IBM products, programs, or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM product, program, or service may be used. Any functionally equivalent program that does not infringe any of IBM intellectual property rights may be used instead of the IBM product, program or service.

Information in this book was developed in conjunction with use of the equipment specified and is limited in application to those specific hardware and software products and levels.

IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594 USA.

Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.

Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee.

The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The information about non-IBM ("vendor") products in this manual has been supplied by the vendor and IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While each item may have


been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites.

Any performance data contained in this document was determined in a controlled environment, and therefore, the results that may be obtained in other operating environments may vary significantly. Users of this document should verify the applicable data for their specific environment.

The following document contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples contain the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

Reference to PTF numbers that have not been released through the normal distribution process does not imply general availability. The purpose of including these reference numbers is to alert IBM customers to specific information relative to the implementation of the PTF when it becomes available to each customer according to the normal IBM PTF distribution process.

The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:

The following terms are trademarks of other companies:

Java and HotJava are trademarks of Sun Microsystems, Incorporated.

Microsoft, Windows, Windows NT, and the Windows 95 logo are trademarksor registered trademarks of Microsoft Corporation.

Pentium, MMX, ProShare, LANDesk, and ActionMedia are trademarks orregistered trademarks of Intel Corporation in the U.S. and othercountries.

AIX AS/400BookManager IBMMVS OS/2OS/390 OS/400RACF ‘


UNIX is a registered trademark in the United States and othercountries licensed exclusively through X/Open Company Limited.

Other company, product, and service names may be trademarks orservice marks of others.

Special Notices 125


Appendix C. Related Publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.

C.1 International Technical Support Organization Publications

For information on ordering these ITSO publications see “How to Get ITSO Redbooks” on page 129.

• Getting Started with TME 10 User Administration, SG24-2015

• Managing Access from Desktop to Datacenter: Introducing TME 10 Security Management, SG24-2021

• Tivoli User Administration Design Guide, SG24-5108

• Tivoli Security Management Design Guide, SG24-5101

C.2 Redbooks on CD-ROMs

Redbooks are also available on CD-ROMs. Order a subscription and receive updates 2-4 times a year at significant savings.

CD-ROM Title Subscription Number

Collection Kit Number

System/390 Redbooks Collection SBOF-7201 SK2T-2177Networking and Systems Management Redbooks Collection SBOF-7370 SK2T-6022Transaction Processing and Data Management Redbook SBOF-7240 SK2T-8038

Lotus Redbooks Collection SBOF-6899 SK2T-8039Tivoli Redbooks Collection SBOF-6898 SK2T-8044AS/400 Redbooks Collection SBOF-7270 SK2T-2849

RS/6000 Redbooks Collection (HTML, BkMgr) SBOF-7230 SK2T-8040RS/6000 Redbooks Collection (PostScript) SBOF-7205 SK2T-8041RS/6000 Redbooks Collection (PDF Format) SBOF-8700 SK2T-8043

Application Development Redbooks Collection SBOF-7290 SK2T-8037



How to Get ITSO Redbooks

This section explains how both customers and IBM employees can find out about ITSO redbooks, CD-ROMs, workshops, and residencies. A form for ordering books and CD-ROMs is also provided.

This information was current at the time of publication, but is continually subject to change. The latest information may be found at http://www.redbooks.ibm.com/.

How IBM Employees Can Get ITSO Redbooks

Employees may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and information about redbooks, workshops, and residencies in the following ways:

• Redbooks Web Site on the World Wide Web

http://w3.itso.ibm.com/

• PUBORDER – to order hardcopies in the United States

• Tools Disks

To get LIST3820s of redbooks, type one of the following commands:

TOOLCAT REDPRINT TOOLS SENDTO EHONE4 TOOLS2 REDPRINT GET SG24xxxx PACKAGE TOOLS SENDTO CANVM2 TOOLS REDPRINT GET SG24xxxx PACKAGE (Canadian users only)

To get BokkManager BOOKs of redbooks, type the following command:

TOOLCAT REDBOOKS

To get lists of redbooks, type the following command:

TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET ITSOCAT TXT

To register for information on workshops, residencies, and redbooks, type the following command:

TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ITSOREGI 1998

• REDBOOKS Category on INEWS

• Online – send orders to: USIB6FPL at IBMMAIL or DKIBMBSH at IBMMAIL

For information so current it is still in the process of being written, look at "Redpieces" on the Redbooks Web Site (http://www.redbooks.ibm.com/redpieces.html). Redpieces are redbooks in progress; not all redbooks become redpieces, and sometimes just a few chapters will be published this way. The intent is to get the information out much quicker than the formal publishing process allows.

Redpieces


How Customers Can Get ITSO Redbooks

Customers may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and information about redbooks, workshops, and residencies in the following ways:

• Online Orders – send orders to:

• Telephone Orders

• Mail Orders – send orders to:

• Fax – send orders to:

• 1-800-IBM-4FAX (United States) or (+1) 408 256 5422 (Outside USA) – ask for:

Index # 4421 Abstracts of new redbooksIndex # 4422 IBM redbooksIndex # 4420 Redbooks for last six months

• On the World Wide Web

In United StatesIn CanadaOutside North America

IBMMAILusib6fpl at ibmmailcaibmbkz at ibmmaildkibmbsh at ibmmail

[email protected]@[email protected]

United States (toll free)Canada (toll free)

1-800-879-27551-800-IBM-4YOU

Outside North America(+45) 4810-1320 - Danish(+45) 4810-1420 - Dutch(+45) 4810-1540 - English(+45) 4810-1670 - Finnish(+45) 4810-1220 - French

(long distance charges apply)(+45) 4810-1020 - German(+45) 4810-1620 - Italian(+45) 4810-1270 - Norwegian(+45) 4810-1120 - Spanish(+45) 4810-1170 - Swedish

IBM PublicationsPublications Customer SupportP.O. Box 29570Raleigh, NC 27626-0570USA

IBM Publications144-4th Avenue, S.W.Calgary, Alberta T2P 3N5Canada

IBM Direct ServicesSortemosevej 21DK-3450 AllerødDenmark

United States (toll free)CanadaOutside North America

1-800-445-92691-800-267-4455(+45) 48 14 2207 (long distance charge)

Redbooks Web SiteIBM Direct Publications Catalog

http://www.redbooks.ibm.comhttp://www.elink.ibmlink.ibm.com/pbl/pbl

For information so current it is still in the process of being written, look at "Redpieces" on the Redbooks Web Site (http://www.redbooks.ibm.com/redpieces.html). Redpieces are redbooks in progress; not all redbooks become redpieces, and sometimes just a few chapters will be published this way. The intent is to get the information out much quicker than the formal publishing process allows.

Redpieces


IBM Redbook Order Form

Please send me the following:

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card notavailable in all countries. Signature mandatory for credit card payment.

Title Order Number Quantity

First name Last name

Company

Address

City Postal code

Telephone number Telefax number VAT number

Invoice to customer number

Country

Credit card number

Credit card expiration date SignatureCard issued to

131


List of Abbreviations

ACL Access List (RACF) or Access Control List (Windows NT)

ADE Application Development Environment

AEF Application Extension Facility

AIX Advanced Interactive Executive (IBM UNIX)

APAR Authorized Program Analysis Report

APF Authorized Program Facility

API Application Programming Interface

BAROC Basic Recorder of Objects in C

CBPDO Custom Built Product Delivery Offering

CICS Customer Information Control System

CLI Command Line Interface

DB2 IBM DataBase 2

DCE Distributed Computing Environment

EIF Event Integration Facility

FMT Message Adapter Format File

FSP File Security Packet

GEM Global Enterprise Manager

GID Group Identifier

GTF Generalized Trace Facility

© Copyright IBM Corp. 1998

GUI Graphical User Interface

HFS Hierarchical File System

HR Human Resources

IBM International Business Machines Corporation

ITSO International Technical Support Organization

JCL Job Control Language

LAN Local Area Network

LCF Lightweight Client Framework (now known as the Tivoli Management Agent)

LDAP Lightweight Directory Access Protocol

LE Language Environment

MVS Multiple Virtual Storage

OID Object Identifier

PTF Program Temporary Fix

RACF Remote Access Control Facility

RAM Random Access Memory

RDBMS Relational DataBase Management System

REXX Restructured Extended Executor Language

RRSF RACF Remote Sharing Facility

SAF System Authorization Facility

SMF System Management Facility

SMP/E System Modification Program Extended

133

TACF Tivoli Access Control Facility

TCP/IP Transmission Control Protocol/Internet Protocol

TEC Tivoli Enterprise Console

TMA Tivoli Management Agent

TME Tivoli Management Environment (now known as Tivoli Enterprise)

TMR Tivoli Management Region

TSM Tivoli Security Management

TSO Time Sharing Option

TSO/E TSO Extensions

TUA Tivoli User Administration

UACC Universal Access Authority

UID User Identifier

VM Virtual Machine

WTO Write To Operator

XPG/4 X/Open Portability Guide Issue 4


Index

Aabbreviations 133access control 89ACL 91acronyms 133administrator

mapping IDs 43AEF

See Application Extension FacilityApplication Extension Facility 80, 95archival of Tivoli data 32auditing 97, 107AUDITOR attribute 12automation table 109

BBAROC 111

Ccache 50

See also preloadcapacity planning 29clone users 31, 75CONNECT 92corruption error on populate 61custom action 78

Ddefault policy 23, 68

disabling 76delegation of administration 19design 29desktop (Tivoli) 22dialog, modifying 81dsl 81, 82

EEIF

See Event Integration Facilityendpoint 17

See also Tivoli Management Agentstart

automating 53starting 50

© Copyright IBM Corp. 1998

stop 53Event Integration Facility 108, 118Event/Automation Service 107exact copy distribution 93

FFACILITY RACF class 13, 51fine-grain roles 20FMEESTRT 54FMEISDKD 38FMEMKDIR 38

GGEM

See TME 10 Global Enterprise Managergroup

RACF 13Tivoli Security Management 34, 90

group profileRACF 9Tivoli User Administration 35

GROUP-OPERATIONS 12GROUP-SPECIAL 12

IICHDSMON 104ICHRIN03 39, 40ID mapping 22, 44IEFU83 SMF exit 116IHSAFMT 111IHSARACF 109IRRDBU00 60, 103IRRUT100 100

LLCF

See Lightweight Client Frameworklcfd 18lcfd.sh 39, 50, 53Lightweight Client Framework xiiiLINKLIST 37LISTGROUP 61LISTUSER 49LNKLST 38LPALIST 38

135

Mmanaged resources 67MAXASSIZE 30MAXCPUTIME 30merge Tivoli records 75message adapter 109messages 107

forwarding RACF to TEC 108method preload 43MVS-level security 41

Nnaming convention 35notice group 116

OOMVSGRP 40OMVSKERN 40OnePassword 35OpenEdition

See OS/390 UNIX System ServicesOPERATIONS attribute 12OS/390 Security Server

See also Resource Access Control FacilityOS/390 System Management Facility 97, 115

Data Unload Utility 104OS/390 UNIX System Services 5, 77OS390ART 106oserv 16, 18OW26060 119OW26061 120

PPERMIT 91policy region 20, 67

managed resources 67populate 60preload 42, 43profile

RACF 9Tivoli 22

cloning 73custom actions 78distribution 80export policy 74

profile manager 22

RR_admin 119, 121RACF

See Resource Access Control Facility 5RACF Cross Reference Utility 100RACF Data Security Monitor 104RACF database unload 60, 103RACF Remote Sharing Facility 33RACF Report Writer 102RACFICE 106RACFRW 102RACLIST 63RACLISTED 40RACROUTE 7RDEFINE 40, 48rdsl 81resource 89Resource Access Control Facility 5

access checking 8administrator attributes 11connect function 9database 7, 9group 13Overview 6profile 9See also OS/390 Security Serversegment 9, 13

resource profile (RACF) 9resource roles 19REVOKE attribute 12REXX 18RLIST 48role

administrative 19fine-grain 20

RACF profile 90Tivoli Security Management 25, 26, 89

role-based security 24, 26RRSF

See RACF Remote Sharing FacilityRVARY 97

SSAF

See System Authorization Facility 8SecEpt 43security officer 1security operator 1


security policy 92segment 9, 13SETROPTS 40, 63, 93, 97SFMELPA1 38SFMEMOD1 37SIGXCPU 30SMF

See OS/390 System Management FacilitySPECIAL attribute 11, 23started task 39synchronize Tivoli with endpoint 76SYS1.PARMLIB 37System Authorization Facility 8system policy 89

TTAPEVOL 94task 83task library 18, 63, 83tecad_racf.baroc 111Tivoli desktop 22Tivoli Enterprise Console 108

event classes 111Tivoli Management Agent

on OS/390 18status 55web interface 56

Tivoli Management Framework 15Tivoli Management Region 15

roles 19server 17

on OS/390 19Tivoli NetView for OS/390 107Tivoli notice group 116Tivoli product names xiiiTivoli Security Management 24, 89Tivoli User Administration 25, 67TivoliDefaultSecurityProfile 81TivoliDefaultUserProfile 81TMA

See Tivoli Management AgentTME 10 xiiiTME 10 Global Enterprise Manager 25TMEADMIN 46, 48TMR

See Tivoli Management RegionTSM

See Tivoli Security Management

TUASee Tivoli User Administration

UUACC 41, 92Umboskel 43UNIX System Services 99

authorized TSO commands 63See OS/390 UNIX System Services

User Locator 75user profile

RACF 9Tivoli 29

Vvalidation policy 23, 68VERIFY 97

Wwaddaction 79waddseceptype 95waddsecrestype 95wallocid 78warning mode 94wchkusrs 76wcpusr 75wcrtadmin 19wcrtpr 67wcrtprf 73wep 55wexpnotif 117wgetdialog 81wgetpolm 74wgetpr 68widmap 44wlsactions 79wlsdialog 81wlsnotif 117wlspolm 71wpasswd 35wpopsec 60wpopulate 60wpopusrs 60wputdialog 82wputpolm 74, 75, 77write to operator messages 107wrunseccmd 49, 83

137

wruntask 65wrunusrcmd 49, 83wsetdefpol 76wsetpr 68wtll 83



ITSO Redbook Evaluation

The OS/390 Security Server Meets Tivoli: Managing RACF with Tivoli Security Products SG24-5339-00

Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this questionnaire and return it using one of the following methods:

• Use the online evaluation form found at http://www.redbooks.ibm.com • Fax this form to: USA International Access Code + 1 914 432 8264 • Send your comments in an Internet note to [email protected]

Which of the following best describes you?_ Customer _ Business Partner _ Solution Developer _ IBM employee_ None of the above

Please rate your overall satisfaction with this book using the scale:(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)

Overall Satisfaction __________

Please answer the following questions:

Was this redbook published in time for your needs? Yes___ No___

If no, please explain:

What other redbooks would you like to see published?

Comments/Suggestions: (THANK YOU FOR YOUR FEEDBACK!)

Pri

nted

in t

he U

.S.A

.SG

24-5

339-

00

The OS/390 Security Server Meets Tivoli: Managing RACF with Tivoli Security Products SG24-5339-00

Documents

The OS/390 Security Server Meets Tivoli: Managing RACF with Tivoli … · 2021. 9. 3. · Tivoli management solution for a large telecommunications industry customer. Gavin Thomas