pd/mq administration guide - ibmpublib.boulder.ibm.com/tividd/td/mq37/sc24-6041-00/en_us/pdf/... ·...

Tivoli®

Policy Director for MQSeries®

Administration Guide3.7.1

SC24-6041-00

Tivoli Policy Director for MQSeries® Version 3.7.1 Administration Guide (November 2001)

Copyright Notice:

© Copyright IBM Corporation 2001. All rights reserved. May only be used pursuant to a Tivoli Systems SoftwareLicense Agreement, an IBM Software License Agreement, or Addendum for Tivoli Products to IBM Customer orLicense Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrievalsystem, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic,optical, chemical, manual, or otherwise, without prior written permission of IBM Corporation. IBM Corporationgrants you limited permission to make hardcopy or other reproductions of any machine-readable documentation foryour own use, provided that each such reproduction shall carry the IBM Corporation copyright notice. No otherrights under copyright are granted without prior written permission of IBM Corporation. The document is notintended for production and is furnished “as is” without warranty of any kind. All warranties on this documentare hereby disclaimed, including the warranties of merchantability and fitness for a particular purpose.

U.S. Government Users Restricted Rights—Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corporation.

Trademarks

The following product names are trademarks or registered trademarks of International Business Machines Corp. orTivoli Systems Inc. in the United States, other countries, or both:v AIX®

v BookManager®

v CICS®

v IBM®

v IBM Library Reader

v IBMLink

v MQSeries®

v OS/390®

v RACF®

v SecureWay®

v Tivoli®

v z/OS

Microsoft, Windows, and Windows NT are trademarks or registered trademarks of Microsoft Corporation in theUnited States, other countries, or both.

UNIX is a registered trademark in the United States and other countries licensed exclusively through The OpenGroup.

Java and all Java-based trademarks or logos are trademarks of Sun Microsystems, Inc.

Other company, product, and service names mentioned in this document may be trademarks or servicemarks ofothers.

Notices

References in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they willbe available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, orservices is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used.Subject to valid intellectual property or other legally protectable right of Tivoli Systems or IBM, any functionally

equivalent product, program, or service can be used instead of the referenced product, program, or service. Theevaluation and verification of operation in conjunction with other products, except those expressly designated byTivoli Systems or IBM, are the responsibility of the user.

Tivoli Systems or 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, inwriting, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785,U.S.A.

© Copyright International Business Machines Corporation 2001. All rights reserved.US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contractwith IBM Corp.

iii

iv PD/MQ Administration Guide

Contents

Tables . . . . . . . . . . . . . . . vii

Figures . . . . . . . . . . . . . . . ix

Preface . . . . . . . . . . . . . . . xiWho Should Read This Guide . . . . . . . . xiPrerequisite and Related Documents . . . . . . xiWhat This Guide Contains . . . . . . . . . xiiConventions Used in This Guide . . . . . . . xiiAccessing Publications Online . . . . . . . . xiii

Tivoli Publications . . . . . . . . . . . xiiiz/OS and OS/390 Publications from IBM . . . xiii

Ordering Publications. . . . . . . . . . . xiiiProviding Feedback about Publications . . . . . xiiiContacting Customer Support . . . . . . . . xiv

Chapter 1. Understanding PD/MQ forz/OS and OS/390 . . . . . . . . . . . 1PD/MQ Compatibility . . . . . . . . . . . 2PD/MQ Components and Dependencies . . . . . 2

Policy Director Authorization Services for z/OSand OS/390 . . . . . . . . . . . . . 3Lightweight Directory Access Protocol (LDAP) . . 3Public Key Infrastructure (PKI) and RACF . . . 3

How PD/MQ Works . . . . . . . . . . . 4How Queues Work . . . . . . . . . . . 4How PD/MQ Works on z/OS and OS/390 . . . 4How Applications are Enabled for PD/MQ . . . 5How the Message Queue Interface (MQI) is Used 6

Chapter 2. Installing PD/MQ for z/OS andOS/390 . . . . . . . . . . . . . . . 7PD/MQ for z/OS and OS/390 InstallationPrerequisites . . . . . . . . . . . . . . 7Installation of PD/MQ on a z/OS or OS/390Platform . . . . . . . . . . . . . . . . 8PD/MQ Post-Installation Tasks . . . . . . . . 8

Making PD/MQ for z/OS Operational . . . . 9Updating the SCHEDxx member ofSYS1.PARMLIB for PD/MQ . . . . . . . 10

Chapter 3. Configuring PD/MQ for z/OSand OS/390 . . . . . . . . . . . . . 13Overview of the Configuration Process . . . . . 13Defining the PD/MQ Processes to z/OS or OS/390 13

PD/MQ Server . . . . . . . . . . . . 13PD/MQ Data Services Daemon. . . . . . . 13

Default OMVS Segments . . . . . . . . . . 16Customizing the PD/MQ Server Processes . . . . 16Customizing the PD/MQ Data Services Daemon . . 17Using Digital Certificates in PD/MQ . . . . . . 20How PD/MQ Uses Key Rings . . . . . . . . 21Authorizing Access to the RACF RACDCERTCommand . . . . . . . . . . . . . . . 21

Creating the Certificates and Key Rings . . . . . 22Defining a Local Certificate Authority Certificate 22Creating a Digital Certificate with a Private Key 22Creating the RACF Key Rings . . . . . . . 23Connecting the Certificates to the Key Rings . . 23Key Ring Verification . . . . . . . . . . 23

Summary of the Certificate-Related Operations . . 24Configuring a Non-z/OS-Resident PKI . . . . . 25Configuring Policy Director Authorization Servicesfor z/OS . . . . . . . . . . . . . . . 26Configuring or Joining an Existing Policy DirectorSecure Domain . . . . . . . . . . . . . 26Configuring the PD/MQ Protected Object Space . . 26

Example of Invoking the pdmqcfg Utility . . . 28

Chapter 4. Administering PD/MQ forz/OS and OS/390 . . . . . . . . . . 29Defining MQSeries Resources . . . . . . . . 29

Adding MQSeries Objects to Policy Director . . 30Defining PD/MQ Extended ConfigurationAttributes to Policy Director Protected Objects. . 32

Configuration Information for Global Data . . 33Configuration Information for/PDMQ/Queue/QueueManager-name . . . 33Configuration Information for/PDMQ/Queue/QueueManager-name/Queue-name . . . . . . . . . . 33

Defining Identities for Applications . . . . . . 36Creating Policy Director Identities for Users . . . 36Mapping Policy Director Users to z/OS User IDs. . 37

Mapping Policy Director Users to z/OS andOS/390 Host Identities . . . . . . . . . 37How Certificates are Used by PD/MQ . . . . 38X.509 V3 Certificates and Key Usage . . . . . 40Creating X.509 V3 Digital Certificates . . . . . 41Scenarios for Defining PKI Operations . . . . 42

Scenario 1 - Using a Host-Based CertificateAuthority . . . . . . . . . . . . . 42Scenario 2 - Using an Outboard CertificateAuthority . . . . . . . . . . . . . 44

Importing Application or End-User Certificatesfor Encryption . . . . . . . . . . . . 44

Mapping PKI Identities to Policy Director Users . . 45Creating the secPKIMap Object Class in LDAP 47Adding secPKIMap Objects to Existing secMapObjects . . . . . . . . . . . . . . . 49

Defining and Attaching Policy Templates . . . . 51Specifying Authorization for PD/MQ Operations 51Specifying the PD/MQ Protected Object Policy(POP) . . . . . . . . . . . . . . . 52ACL Evaluation and Queue Name Resolution . . 53

A PD/MQ Scenario. . . . . . . . . . . . 53

Chapter 5. MQSeries and ApplicationEnvironment Considerations . . . . . 55

© Copyright IBM Corp. 2001 v

PD/MQ for z/OS and OS/390 Interaction withMQSeries Authorization . . . . . . . . . . 55Dynamic Queues, Generated Names, and PD/MQ 55

How PD/MQ Detects Dynamically-GeneratedQueues . . . . . . . . . . . . . . . 57

Application Environments and Enabling for PD/MQ 58Enabling Applications for PD/MQ in the UNIXSystem Services Environment . . . . . . . 58Enabling BATCH and BATCH-RRS Applicationsfor PD/MQ . . . . . . . . . . . . . 59Enabling CICS Transactions that Use theMQSeries-CICS Adapter for PD/MQ . . . . . 59

MQSeries Limitations and UnsupportedConfigurations . . . . . . . . . . . . . 60Limitations to Supported Environments . . . . . 60PD/MQ and Maximum Message Sizes . . . . . 61

Chapter 6. Error Handling in PD/MQ forz/OS and OS/390 . . . . . . . . . . 63

Chapter 7. Messages for PD/MQ forz/OS and OS/390 . . . . . . . . . . 65

Chapter 8. Auditing PD/MQ for z/OSand OS/390 . . . . . . . . . . . . . 77

Appendix. PD/MQ SMF Audit Records 79

Bibliography . . . . . . . . . . . . 85PD/MQ . . . . . . . . . . . . . . . 85Books for Installation on z/OS . . . . . . . . 85Books for Installation on OS/390 . . . . . . . 85Policy Director . . . . . . . . . . . . . 85Policy Director Authorization Services . . . . . 85MQSeries . . . . . . . . . . . . . . . 85Security Server for z/OS . . . . . . . . . . 85

LDAP . . . . . . . . . . . . . . . 85RACF . . . . . . . . . . . . . . . 85

Security Server for OS/390 . . . . . . . . . 85LDAP . . . . . . . . . . . . . . . 86RACF . . . . . . . . . . . . . . . 86

SMF . . . . . . . . . . . . . . . . . 86SSL . . . . . . . . . . . . . . . . . 86UNIX System Services . . . . . . . . . . . 86

Index . . . . . . . . . . . . . . . 87

vi PD/MQ Administration Guide

Tables

1. Options that Can be Customized . . . . . 162. Parameters for the pdmqcfg utility. . . . . 273. PD/MQ Abend Codes . . . . . . . . . 654. PD/MQ-Generated SMF Records . . . . . 795. SMF Flags . . . . . . . . . . . . . 816. SMF Record Version Level . . . . . . . 81

7. MQSeries Operation Code Constants . . . . 818. PD/MQ Access Decision Codes . . . . . . 829. PD/MQ Signature Algorithm Codes . . . . 82

10. PD/MQ Encryption Strength Codes . . . . 8211. PD/MQ Protection Operation Codes . . . . 8212. PD/MQ Audit Codes . . . . . . . . . 83

© Copyright IBM Corp. 2001 vii

viii PD/MQ Administration Guide

Figures

1. PD/MQ for z/OS and OS/390 Environment 22. Overview of PD/MQ for z/OS and OS/390 53. Sample IFAPRDxx Member of SYS1.PARMLIB 104. The SCHEDxx Member of SYS1.PARMLIB 115. Sample JCL for the PD/MQ Data Services

Daemon Process . . . . . . . . . . . 186. Invoking pdmqcfg Utility . . . . . . . . 287. The PD/MQ Protected Namespace. . . . . 308. Conceptual View of PD/MQ Extended

Attributes . . . . . . . . . . . . . 329. The “Create Policy Director User” Screen of

Policy Director Web Portal Manager . . . . 3810. How Certificates are Used by PD/MQ . . . 3911. Policy Director User and Group Entries in an

LDAP Directory . . . . . . . . . . . 45

12. The secMap Object Maps Policy Director UserEntries to Authorization Database Information . 46

13. Extending the secMap Object with secPKIMap 4714. Creating the Object Class . . . . . . . . 4815. Adding secAuthority and secCertSerialNumber

as Optional Attributes . . . . . . . . . 4816. Updating the secPKIMap Object with the

Certificate Data for this Policy Director User . 4917. Browsing the Tree of Existing secMap Objects 4918. Attaching a secPKIMap Object to an Existing

secMap Object . . . . . . . . . . . 5019. Creating the Attributes of the secPKIMap

Object Class . . . . . . . . . . . . 5120. Request-Reply Application Example . . . . 57

© Copyright IBM Corp. 2001 ix

x PD/MQ Administration Guide

Preface

Welcome to the Tivoli Policy Director for MQSeries Administration Guide 3.7.1.This is the guide for the part of the product that runs on the IBM® z/OS™ andOS/390® operating systems. Policy Director for MQSeries (PD/MQ) protectsMQSeries messages. PD/MQ is an extension of Tivoli’s industry-leading PolicyDirector product. PD/MQ allows MQSeries applications to send data withconfidentiality and integrity using keys associated with the sending and receivingusers. The Policy Director Authorization Services for z/OS and OS/390 providesaccess control to MQSeries based services, restricting which users can and cannotget access to messages on queues. PD/MQ has the following benefits:v Defines and enforces centralized authorization policies (including data

protection) for MQSeries resources (queues and messages on those queues) usingthe Policy Director infrastructure, which already provides:– A common, scalable and reliable policy repository– An extendable resource namespace and extendable permission sets– A common console for managing policy

v Provides protection for MQSeries data as it flows across the network and as itsits in the queue, using public key infrastructure (PKI) technology.

v Provides protection to existing MQSeries applications. MQSeries applicationsneed not change in order to be protected by PD/MQ.

IBM MQSeries provides:v Simple, multi-platform APIv Assured message deliveryv Time independent processingv Partner applications have independent statev Application parallelism

PD/MQ protection can be used in conjunction with MQSeries built-in security (forexample the Object Authority Manager and the Message Channel exits).

Who Should Read This GuideThe target audience for this guide is System Administrators who are familiar withMQSeries.

Prerequisite and Related Documentsv Tivoli: Policy Director for MQSeries Administration Guide 3.7.1. This book, which is

for PD/MQ running on z/OS or OS/390.v Tivoli: Policy Director for MQSeries Administration Guide 3.7.1. This is the book for

PD/MQ running on AIX™, Sun™ Solaris™, or Microsoft® Windows NT®.v Tivoli: Program Directory for Tivoli Policy Director for MQSeries for z/OS and OS/390.

This book provides the installation instructions and other important information.v Tivoli SecureWay: Policy Director Base Administration Guide 3.7.1.v IBM Policy Director Authorization Services for z/OS and OS/390: Customization and

Use

v MQSeries for OS/390 V5R2: Concepts and Planning Guide

© Copyright IBM Corp. 2001 xi

v MQSeries for OS/390 V5R2: System Administration Guide

v z/OS: SecureWay Security Server LDAP Server Administration and Use, R10 andlater

v z/OS: SecureWay Security Server RACF Security Administrator’s Guide, R10 andlater

v z/OS: SecureWay Security Server RACF Command Language Reference R10 and laterv z/OS: System Secure Sockets Layer Programming

There are other publications that you may need just for the installation of PD/MQ.They are listed in “Installation of PD/MQ on a z/OS or OS/390 Platform” onpage 8. An even more comprehensive list of publications is in “Bibliography” onpage 85. For books that have order numbers, this is where you will find them.

What This Guide ContainsThis book, Tivoli Policy Director for MQSeries Administration Guide, contains thesesections:v “Chapter 1. Understanding PD/MQ for z/OS and OS/390” on page 1 lists

PD/MQ functions and describes key components and dependencies.v “Chapter 2. Installing PD/MQ for z/OS and OS/390” on page 7 describes the

installation of Policy Director for MQSeries and its components andprerequisites.

v “Chapter 3. Configuring PD/MQ for z/OS and OS/390” on page 13 describesthe configuration of PD/MQ.

v “Chapter 4. Administering PD/MQ for z/OS and OS/390” on page 29 describesthe details of deploying Policy Director for MQSeries in a typical MQSeriesenvironment. It provides scenarios of an MQSeries setup and illustrates PolicyDirector for MQSeries configuration for such a deployment.

v “Chapter 5. MQSeries and Application Environment Considerations” on page 55discusses interoperational considerations for MQSeries and PD/MQ.

v “Chapter 6. Error Handling in PD/MQ for z/OS and OS/390” on page 63describes how the PD/MQ error queue works.

v “Chapter 7. Messages for PD/MQ for z/OS and OS/390” on page 65.v “Chapter 8. Auditing PD/MQ for z/OS and OS/390” on page 77 describes the

Policy Director audit function for PD/MQ.

Conventions Used in This GuideThe guide uses several typeface conventions for special terms and actions. Theseconventions have the following meaning:

Bold Commands, keywords, file names, authorization roles, Webaddresses, or other information that you must use literally appearlike this, in bold. Names of windows, dialogs, and other controlsalso appear like this, in bold.

Italics Variables and values that you must provide appear like this, initalics. Words and phrases that are emphasized also appear like this,in italics.

Monospace Code examples, output, and system messages appear like this, ina monospace font.

xii PD/MQ Administration Guide

Accessing Publications Online

Tivoli PublicationsThe Tivoli Customer Support Web site (http://www.tivoli.com/support/) offers aguide to support services (the Customer Support Handbook); frequently askedquestions (FAQs); and technical information, including release notes, user’s guides,redbooks, and white papers. You can access Tivoli publications online athttp://www.tivoli.com/support/documents/. The documentation for some productsis available in PDF and HTML formats. Translated documents are also available forsome products.

To access most of the documentation, you need an ID and a password. To obtainan ID for use on the support Web site, go tohttp://www.tivoli.com/support/getting/.

Resellers should refer to http://www.tivoli.com/support/smb/ for more informationabout obtaining Tivoli technical documentation and support.

Business Partners should refer to “Ordering Publications” for more informationabout obtaining Tivoli technical documentation.

z/OS and OS/390 Publications from IBMThe softcopy z/OS and OS/390 publications are available in Portable DocumentFormat (PDF) versions for viewing or printing using this URL:http://www.ibm.com/servers/eserver/zseries/zos/bkserv/

The z/OS library is also available on a CD-ROM, z/OS Collection, SK3T-4269. TheCD-ROM online library collection is a set of unlicensed books for z/OS and relatedproducts that includes the IBM Library Reader™. This is a program that enablesyou to view the BookManager® files. This CD-ROM also contains the PDF files.You can view or print these files with the Adobe Acrobat Reader.

Ordering Publications

This publication is not available in hardcopy form. However, if you need otherpublications from Tivoli, this section tells you how to get them. Order Tivolipublications online athttp://www.tivoli.com/support/public/Prodman/public_manuals/td/TD_PROD_LIST.htmlor by calling one of the following telephone numbers:v U.S. customers: (800) 879-2755

v Canadian customers: (800) 426-4968

To order z/OS and OS/390 publications, see your IBM representative or the IBMbranch office serving your locality.

Providing Feedback about PublicationsWe are very interested in hearing about your experience with Tivoli products anddocumentation, and we welcome your suggestions for improvements. If you havecomments or suggestions about our products and documentation, contact us in oneof the following ways:v Send e-mail to [email protected] Fill out our customer feedback survey at http://www.tivoli.com/support/survey/.

Preface xiii

Tivoli does not want to receive confidential or proprietary information from you.Please note that any information or material sent to Tivoli will be deemed NOT tobe confidential. By sending Tivoli any information or material, you grant Tivoli anunrestricted, irrevocable license to use, reproduce, display, perform, modify,transmit and distribute those materials or information, and you also agree thatTivoli is free to use any ideas, concepts, know-how or techniques that you send usfor any purpose. However, we will not release your name or otherwise publicizethe fact that you submitted material or other information to us unless: (a) weobtain your permission to use your name; or (b) we first notify you that thematerials or other information you submit to a particular part of this site will bepublished or otherwise used with your name on it; or (c) we are required to do soby law.

Contacting Customer SupportYou can contact Customer Support in one of the following ways:v Submit a problem management record (PMR) electronically through the

IBMLink™ system. For information about IBMLink registration and access, referto the IBM Web page at http://www.ibmlink.ibm.com.

v Customers in the U.S. can call 1-800-IBM SERV (1-800-426-7378).

When you contact Customer Support, be prepared to provide the customer numberfor your company so that support personnel can assist you more readily.

xiv PD/MQ Administration Guide

Chapter 1. Understanding PD/MQ for z/OS and OS/390

Policy Director for MQSeries for z/OS and OS/390 operates in conjunction withthe IBM Policy Director Authorization Services for z/OS and OS/390. Throughoutthe remainder of this book, Policy Director for MQSeries for z/OS and OS/390 willbe referred to as PD/MQ for z/OS or just PD/MQ, and IBM Policy DirectorAuthorization Services for z/OS and OS/390 will be referred to as Policy DirectorAuthorization Services.

With PD/MQ for z/OS you can:v Secure sensitive or high value messages processed by IBM MQSeries for z/OS

(hereafter called MQSeries)v Control which users have access to specific queues. A “user” may be a human

user or an applicationv Detect and remove rogue or unauthorized messages before they are processed

by a receiving applicationv Generate detailed auditing records showing which messages were expressly

authorized and encryptedv Verify that messages were not modified while in transit from queue to queuev Centrally define authorization policies (including quality of data protection) for

MQSeries resources (queues and messages on those queues) using a commonconsole for heterogeneous servers across their enterprise

v Protect your data as it flows across the network and as it sits in a queuev Secure existing off-the-shelf and customer-written applications for MQSeries for

z/OS

PD/MQ for z/OS augments the security provided by IBM Resource Access ControlFacility (RACF®) and MQSeries with these functions:v A centralized authorization service defining access control policies for MQSeries

queues and messages on these queues, through Policy Director AuthorizationServices.

v Confidentiality, in the form of encryption, and integrity, in the form of checksagainst message modification, so that senders and receivers of MQSeriesmessages can exchange messages with complete security. PD/MQ for z/OSprovides these services while the message is in transit as well as when themessages are stored in the message queues.

v Integrates public key infrastructure (PKI) technology into MQSeries. PD/MQ forz/OS identifies MQSeries users with identities that are operating system andnetwork independent.

v Provides message-level security transparently to MQSeries applications. Theseapplications do not have to be modified to be protected by PD/MQ for z/OS.

Note: Either RACF or a functionally-equivalent z/OS security product may beused to provide these functions.

This chapter contains the following sections:v “PD/MQ Compatibility” on page 2v “PD/MQ Components and Dependencies” on page 2v “How PD/MQ Works” on page 4

© Copyright IBM Corp. 2001 1

PD/MQ CompatibilityPD/MQ for z/OS depends on several technology components to provide a securityinfrastructure. PD/MQ does not require you to license any additional Tivoliproducts to use this solution. PD/MQ is, however, compatible with the followingTivoli products:v Tivoli Policy Director Version 3.7.1v Tivoli Policy Director for MQSeries Version 3.7.1. This is the part of the product

that runs on AIX, Sun Solaris, and Microsoft Windows NT.v Tivoli Public Key Infrastructure

PD/MQ Components and DependenciesThe PD/MQ for z/OS libraries intercept MQSeries application programminginterface (API) calls, thus enabling MQSeries applications to be secured withoutany application program changes. Figure 1 shows a block diagram of the corePD/MQ components and the security infrastructure components (in shaded areas).

The diagram shows two LDAP directories that reside off of the z/OS or OS/390platform. However, a single LDAP directory may be used by both Policy Directorand the PKI provider. An instance of the z/OS SecureWay® Security Server LDAPdirectory server is required on z/OS, even if the Policy Director LDAP-based userregistry resides on another platform. This is because the z/OS LDAP directoryserver provides the communication infrastructure to a remote LDAP directoryserver for the Policy Director services that reside on the z/OS or OS/390 platform.

LDAP DirectoryServer

Policy DirectorMaster PolicyServer

Policy DirectorConsoler

LDAPDirectoryforCertificates

CertificateAuthority

PKIProvider

IBM Policy DirectorAuthorizationServices for z/OS

Z/OSSecurity ServerRACF

Z/OS System SSLIntegratedCryptographicService Facility

Z/OSLDAP DirectoryServer

MQSeries Application

PD/MQ for z/OS and OS/390

Z/OS and OS/390 Operating

System Platform

IBM MQSeries for z/OS and OS/390

Figure 1. PD/MQ for z/OS and OS/390 Environment

2 PD/MQ Administration Guide

PD/MQ is dependent on:v IBM Policy Director Authorization Services for z/OS and OS/390v z/OS SecureWay Security Server LDAP Serverv z/OS SecureWay Security Server RACFv z/OS System Secure Sockets Layer (SSL)

In the following sections, an overview of the function and relationship of each ofthese components is discussed

Policy Director Authorization Services for z/OS and OS/390Policy Director Authorization Services for z/OS and OS/390 is the centralized,cross-platform authorization policy management system used by PD/MQ forz/OS. PD/MQ for z/OS relies on Policy Director Authorization Services for thefollowing functions:v An enterprise user registry for Policy Director users, which is implemented as an

LDAP directoryv A centralized system to define authorization and data protection policy for

access to MQSeries resources (queues). This centralized policy is distributed, thatis, the policy is imposed for MQSeries on both z/OS and distributed platforms.

PD/MQ for z/OS uses Policy Director Authorization Services to obtain dataprotection and authorization policy. See IBM Policy Director Authorization Services forz/OS and OS/390: Customization and Use for customization instructions. Forplatforms other than z/OS or OS/390, see the installation instructions for thechosen platform.

Lightweight Directory Access Protocol (LDAP)The Policy Director Authorization Services requires an LDAP directory to be usedas the user registry. This LDAP directory server, which may reside either on thez/OS or OS/390 platform, or on another supported platform, must be installedand configured prior to the installation of Policy Director Authorization Services.

The LDAP server contained in z/OS or OS/390 SecureWay Security Server is usedwith the LDAP Directory supplied with the Tivoli Policy Director function shippedwith Policy Director Authorization Services for z/OS and OS/390. The supportedworkstation platforms are AIX, Windows/NT, and Windows/2000. The z/OS andOS/390 SecureWay Security Server LDAP Server can also be used in place of theLDAP Directory that is supplied with the Tivoli Policy Director function. Install thez/OS LDAP directory server on a machine designated to be your official datarepository. Refer to the appropriate LDAP installation instructions for the platformwhere you are installing it.

Public Key Infrastructure (PKI) and RACFPD/MQ for z/OS uses the runtime services of the underlying z/OS securityinfrastructure, which provides the required primitives for storing, retrieving andmanaging X.509 V3 digital certificates used in the security processing of MQSeriesmessages.

You must also use a host security product, such as z/OS SecureWay SecurityServer RACF, which allows the user to request and store digital certificates. RACFprovides safe and secure storage of the cryptographic keys that are used byPD/MQ for z/OS to ensure the integrity and confidentially of messages sent orreceived through the IBM MQSeries queues.

Chapter 1. Understanding PD/MQ for z/OS and OS/390 3

How PD/MQ WorksThis section explains:v How queues workv How PD/MQ works on z/OS and OS/390v How applications are enabled for PD/MQv How the Message Queue Interface is used

How Queues WorkMessage queuing is a method of program-to-program communication. Programswithin an application communicate by writing and retrieving application-specificdata (messages) to or from queues, without having a private, dedicated, logicalconnection to link them. Messaging means that programs communicate with eachother by sending data in messages and not by calling each other directly.

For the user of MQSeries services, the underlying protocol is transparent. MQSeriescan be used in a client-server or distributed environment. Programs belonging toan application can run in one workstation or in different machines on differentplatforms. Since MQSeries communicates through queues, it can be referred to asusing indirect program-to-program communication. The programmer does notspecify the name of the target application to which a message is sent, rather theprogrammer specifies a target queue name; and each queue is typically associatedwith a program. An application can have one or more input queues and may haveseveral output queues containing information for other servers to process, or forresponses for the client that initiated the transaction.

If the target program is not available, the messages remain on a queue and getprocessed later. The queue is either in the sending machine or in the targetmachine, depending on whether the connection between the two systems can beestablished.

PD/MQ provides the mechanism to enforce a data-protection policy and acentralized, cross-platform access-control policy for applications based onMQSeries.

An MQSeries queue is defined to Policy Director Authorization Services with a setof permissions, and a policy that identifies the quality of protection to be appliedto messages sent or received on protected MQSeries queues. When a user accessesa queue, PD/MQ checks whether the user is authorized to the queue for theintended operation, such as PUT or GET. Keep in mind that a “user” can be ahuman user or an application. Although a user may be authorized to access thequeue, that user must also be able to decrypt a message if the message wasencrypted. This requirement is enforced by the quality of protection associatedwith a defined MQSeries queue.

How PD/MQ Works on z/OS and OS/390Referring to Figure 2 on page 5, PD/MQ logically intercepts Message QueueInterface (MQI) requests from the sending or receiving application. The set of MQIrequests that PD/MQ pre- and post-processes is MQCONN, MQOPEN, MQPUT,MQPUT1, MQGET, MQCLOSE, and MQDISC. Depending on the MQI requestbeing processed, PD/MQ calls Policy Director Authorization Services to determineif the user ID associated with this application is authorized to the queue, and to


retrieve the attributes specific to the queue, such as the quality of protection,error-handling queue, encryption strength, and list of intended recipients.

Depending on these attributes, the user ID of the application, and the MQI servicebeing invoked by the application, PD/MQ invokes System Authorization Services(SAF) to retrieve the certificates and keys managed by RACF. These certificates andkeys are required, in order to protect the message (if the policy for the protectedqueue specifies a quality of protection of integrity or privacy). PD/MQ uses theservices provided by the z/OS or OS/390 System Secure Sockets Layer (SSL). SSLmay invoke the Integrated Cryptographic Services Facility (ICSF), in the processingof the message to be either protected or unprotected.

If policy for a protected queue requires that integrity or privacy for messagesplaced or received from a protected queue be enforced, the message once protectedby PD/MQ remains protected until it is removed from the protected queue by theapplication authorized to receive (GET) the protected message. Therefore, if themessage is queued, pending processing by the receiving application, the messageremains in a protected state until it is processed by the intended recipient.

How Applications are Enabled for PD/MQPD/MQ does not require applications to change their logic. This means that theprotection of application messages is intended to be transparent to applications.From a run-time environment perspective, an application becomesPD/MQ-enabled when:v The queue manager and queue are defined to Policy Director, with the attributes

that define the quality of protection and other security policy information alsodefined.

v Users, groups, and access control have been defined.

Sending

ApplicationReceivingApplication

MQCONN

MQOPEN

MQPUT

MQCONN

MQOPEN

MQGET

Application

Data

MQI

PD/MQ

ProtectedApplicationdata

z/OSSecurityServerRACF

z/OSSecurityServerRACF

z/OS SystemSSL

IntegratedCryptographic

ServicesFacility

IBM PolicyDirectorAuthorizationServices

MQ Series MQ Series

MQI

PD/MQ


MQ Message Transmission


Application

Data

LDAP

z/OS SystemSSL

IntegratedCryptographic

ServicesFacility

RACFDBRACF

DB

Aut

horiza

tion

Che

ck

Authorization

Check

Message

Prote

ction

Policy ACLsand QueueAttributes

Message Protection

Key Rings, andCertificates

Figure 2. Overview of PD/MQ for z/OS and OS/390

Chapter 1. Understanding PD/MQ for z/OS and OS/390 5

v X.509 V3 certificates have been generated and populated in RACF-managed keyrings.

v A STEPLIB statement was added to the application’s Job Control Language (JCL)for the set of applications that you wish to protect with PD/MQ. This statementincludes the PDMQ dataset that allows PD/MQ to intercept MQI requests fromthat application. Thus, you can selectively enable some applications andsubsystems to use PD/MQ while choosing not to enable others. Once youprotect a queue, all applications that PUT or GET to that queue must be PD/MQenabled.

For more information on how to enable MQSeries applications for PD/MQ forz/OS, see “Chapter 5. MQSeries and Application Environment Considerations” onpage 55.

How the Message Queue Interface (MQI) is UsedPD/MQ intercepts a subset of the MQI calls, in order to pre- and post-processthem. When an application puts a message to a queue, PD/MQ modifies the bufferto include digital-signing information (for integrity) and, optionally, to encrypt thedata (for privacy). Similarly, PD/MQ decrypts and verifies a message prior topresenting it to the application.


Chapter 2. Installing PD/MQ for z/OS and OS/390

This chapter describes the installation of PD/MQ for z/OS and OS/390. It tellsyou how to get ready to install, sends you to the Program Directory for the specificinstallation steps, and then tells you how to perform post-installation tasks.

This chapter consists of the following sections:v “PD/MQ for z/OS and OS/390 Installation Prerequisites”v “Installation of PD/MQ on a z/OS or OS/390 Platform” on page 8v “PD/MQ Post-Installation Tasks” on page 8

PD/MQ for z/OS and OS/390 Installation PrerequisitesBefore installing PD/MQ for z/OS, the following software must be installed andconfigured in your environment. PD/MQ cannot be installed if these dependenciesare not met.v Software required for PD/MQ:

– z/OS Version 1 Release 1 or later, or OS/390 Version 2 Release 10, includingProgram Temporary Fixes (PTFs). See the Tivoli: Program Directory for TivoliPolicy Director for MQSeries for z/OS and OS/390 for the PTFs that need to beapplied.

– IBM MQSeries Version 5 Release 2, with required service installed, includingPTF UQ59993.

– Policy Director Authorization Services for z/OS and OS/390, ProgramNumber 5655-F95.

– The following products are elements of z/OS or OS/390 that will be used byPD/MQ:- SecureWay Security Server Resource Access Control Facility (RACF).

PTFs UW99369 and UW99370 must be installed.- SecureWay Security Server Lightweight Directory Access Protocol (LDAP)

Server. PTFs UW99407 and UW99408 must be installed.- System Secure Sockets Layer (SSL). PTFs UW84118, UW84119, UW84120,

and UW84121 must be installed.– Policy Director User Registry

Policy Director Authorization Services maintains its users and groups on anLDAP-based user registry. Install and configure an LDAP server for PolicyDirector usage (schema loading) prior to installing Policy Director.

Note: An instance of the z/OS SecureWay Security Server LDAP server mustbe resident on z/OS or OS/390, even if another directory server hasbeen chosen that physically resides on a platform other than z/OS orOS/390.

– A Certificate Authority (CA)

PD/MQ for z/OS uses the z/OS System Secure Sockets Layer (SSL), whichprovides the functions to sign, verify, encrypt, and decrypt MQSeriesmessages. In addition, PD/MQ for z/OS uses key rings that are managed byRACF to store certificates and keys used in the signing, message verification,encryption and decryption of messages processed by PD/MQ for z/OS. If


you have chosen a PKI infrastructure for certificate generation other than thatprovided by z/OS, the following certificate providers are supported:- Tivoli SecureWay Public Key Infrastructure (PKI) 3.7- Entrust® Web Connector™ 5.0- iPlanet™ Certificate Management System (CMS) 4.2

– A security manager for Policy Director. You have these choices:- Tivoli Policy Director Web Portal Manager

The Web Portal Manager is a Web-based graphical application used tomanage security policy for the Policy Director secure domain. The WebPortal Manager provides management and administration of users, group,roles, permissions, policies, and application access provisioning. The WebPortal Manager provides a limited range of tasks.

- The pdadmin command line utility provides a means for performing allPolicy Director administrative tasks. The pdadmin command line utilityprovides the same administrative capabilities as the Web Portal Managercommands plus commands not supported by the Web Portal Manager.

v Optional software:– CICS® Transaction Server Version 1 Release 3 for z/OS or OS/390. The CICS

bridge is not supported by PD/MQ for z/OS and OS/390.v Prerequisites for each machine that will run PD/MQ:

– See the documentation included with the installation media for yourappropriate platforms.

Installation of PD/MQ on a z/OS or OS/390 PlatformThe installation of PD/MQ on OS/390 and z/OS requires you to be familiar withthe SMP/E tool that manages the installation and modifications to productsinstalled on your z/OS or OS/390 system. You can find more information aboutSMP/E in the following publications:v For z/OS systems:

– z/OS: SMP/E Commands

– z/OS: SMP/E Messages, Codes, and Diagnosis

– z/OS: SMP/E Reference

– z/OS: SMP/E User’s Guide

v For OS/390 systems:– OS/390: SMP/E Commands

– OS/390: SMP/E Messages and Codes

– OS/390: SMP/E Diagnosis Guide

– OS/390: SMP/E Reference

– OS/390: SMP/E User’s Guide

See the Tivoli: Program Directory for Tivoli Policy Director for MQSeries for z/OS andOS/390for the installation instructions.

PD/MQ Post-Installation TasksPerform these tasks when your installation of PD/MQ for z/OS is complete:1. Update the LNKLST. Add DRQ.SDRQLINK to your LNKLSTxx or PROGxx

member of PARMLIB.


2. APF authorize the PD/MQ datasets. Update your PROGxx to addDRQ.SDRQLOAD, DRQ.SDRQLINK, and DRQ.SDRQAUTH to the APF list.

3. Add a PPT entry for PD/MQ. Copy DRQ.SDRQSAMP(DRQSCHED) to yourSCHEDxx member of PARMLIB.

4. Update your product registration member. Copy sampleDRQ.SDRQSAMP(DRQPRDXX) to your IFAPRDxx member of PARMLIB.

5. Add PD/MQ JCL to your system PROCLIB. Copy sample membersDRQ.SDRQSAMP(PDMQ) and DRQ.SDRQSAMP(PDMQD) to your systemPROCLIB. Update any dataset names as needed.

6. Activate the changes. Use operator commands or re-IPL the system so thePARMLIB changes take effect prior to starting PD/MQ.

Tivoli recommends that PD/MQ be installed in the same SMP/E zone asMQSeries. This will provide access to the ACSQMOD distribution library data setneeded for the installation of PD/MQ. If you choose to install PD/MQ in anotherSMP/E zone, a data definition card (DDEF) for ACSQMOD will be needed in thePD/MQ zone, and SMP/E cross zone facilities will have to keep the futuremaintenance levels current.

See also “Customizing the PD/MQ Server Processes” on page 16.

Making PD/MQ for z/OS OperationalPD/MQ requires updates to be made to members in SYS1.PARMLIB before theprogram can be operational. During installation, an entry must exist in theIFAPRDxx member pointed to by PROD= in IEASYSxx in SYS1.PARMLIB. If acorrect entry does not exist, PD/MQ initialization will not complete, and themessage DRQZS0101E will be issued, with a reason code of 105.

Change the IFAPRDxx member of SYS1.PARMLIB, which defines the enablementpolicy for products or product features. The policy lists the products and features,as well as the system environment in which they are enabled to run.

PD/MQ supplies a tailored IFAPRDxx member of SYS1.PARMLIB, which can befound in the samples dataset, ’HLQ.’SDRQSAMP(DRQPRD00). The sampleIFAPRDxx member as supplied with PD/MQ should look like this:

Chapter 2. Installing PD/MQ for z/OS and OS/390 9

To enable PD/MQ, you add it to the policy; that is, you add the product to anIFAPRDxx member, then activate the member. For information about how to defineproducts to the IFAPRDxx member of SYS1.PARMLIB, see:v z/OS: MVS Initialization and Tuning Reference

v OS/390: MVS Initialization and Tuning Reference

If product registration to the MVS IFAEDREG service fails, the PD/MQ server willnot initialize. Any application code that calls MQI services that are intercepted byPD/MQ will fail with a “not authorized” return code.

Updating the SCHEDxx member of SYS1.PARMLIB for PD/MQThe PD/MQ Server must run in storage protection key of 7, and benon-swappable. The sample SCHEDxx member can be found in the samplesdataset, ’HLQ.’SDRQSAMP (DRQSCHED).

You must add the following entry to the SCHEDxx member of SYS1.PARMLIB:

/*******************************************//* *//* Licensed Materials - Property of IBM *//* 5698-PDM *//* (c) Copyright IBM Corp. 2001 *//* *//* Status = HDMQ100 *//* *//*******************************************/

/**********************************************//* *//* This is a sample IFAPRDxx member for PDMQ. *//* *//* This member is used to enable the PDMQ *//* product. PDMQ registers with the system *//* using the owner, name, id, an feature *//* shown below. *//* *//* To use this member, copy the statements *//* below and add them to your system IFAPRDxx *//* member of parmlib. *//* *//* For more information about the syntax of *//* IFAPRDxx, see the z/OS Initialization *//* and Tuning Reference manual. *//* *//**********************************************/

PRODUCT OWNER('IBM CORP') /* PDMQ */NAME('POLICY DIRECTOR')ID(5698-PDM)VERSION(*) RELEASE(*) MOD(*)FEATURENAME(PDMQ)STATE(ENABLED)

Figure 3. Sample IFAPRDxx Member of SYS1.PARMLIB


This entry defines the PD/MQ server as non-swappable and executes in storageprotection key 7. After you complete these changes, you must activate the changesthat you have made to IFAPRDxx and SCHEDxx members of SYS1.PARMLIB.

For more information on the SCHEDxx member of SYS1.PARMLIB, see:v z/OS: MVS Initialization and Tuning Reference

v OS/390: MVS Initialization and Tuning Reference

/*******************************************//* *//* Licensed Materials - Property of IBM *//* 5698-PDM *//* (c) Copyright IBM Corp. 2001 *//* *//* Status = HDMQ100 *//* *//*******************************************/

/**********************************************//* This is a sample SCHEDxx member for PDMQ. *//* *//* This statements in this member define the *//* PDMQ server as being non-swappable and *//* running in key 7. These attributes are *//* required for the server. *//* *//* To use this member, copy the statements *//* below into your system SCHEDxx member of *//* parmlib. *//* *//* For more information on the syntax of *//* SCHEDxx, see the z/OS Initialization and *//* tuning reference manual. *//* *//**********************************************/

PPT PGMNAME(DRQHCTL) /* PDMQ Server */NOSWAP /* Non-Swappable */KEY(7) /*

Figure 4. The SCHEDxx Member of SYS1.PARMLIB

Chapter 2. Installing PD/MQ for z/OS and OS/390 11

Chapter 3. Configuring PD/MQ for z/OS and OS/390

PD/MQ for z/OS and OS/390 introduces two server processes. These twoprocesses are:v The PD/MQ Server

– The PD/MQ Server processes and retains information about the applications,queue managers, and queues that applications have connected to and opened.

– The PD/MQ interceptor communicates with the PD/MQ Server to obtain andupdate an application’s use of MQSeries resources.

v The PD/MQ data services daemon– The data services daemon provides the set of services that, among other tasks,

interface with the cryptographic services provided by the z/OS and OS/390System SSL components that are used in the protection of MQSeries messagesthat originate or are received by an application.

– The data services daemon also provides the LDAP communication servicesthat are also used in the protection processing of application messages.

Overview of the Configuration ProcessThe configuration of PD/MQ for z/OS consists of several steps:v Defining the PD/MQ processes to z/OS or OS/390v Customizing the PD/MQ server processesv Configuring Policy Director Authorization Services for z/OS and OS/390v Configuring or joining an existing Policy Director Secure Domainv Optionally, configuring a non-z/OS-resident PKIv Configuring the PD/MQ protected object space

These configuration steps should be done in the order specified.

Note: Not all of the configuration tasks are done on the z/OS or OS/390 platform.Some are done on the platform that contains the Policy Director MasterDatabase.

Defining the PD/MQ Processes to z/OS or OS/390PD/MQ for z/OS relies on the local security provided by the z/OS or OS/390platform. PD/MQ has two processes that run as started tasks. These started tasksshould be defined to RACF with an identity (user ID), and must be set up asdescribed in the following paragraphs.

PD/MQ ServerThe PD/MQ server and daemon need a local user ID to run under. It isrecommended that this be the same z/OS user ID for both, however, this is notrequired. The PD/MQ data services daemon requires that the user ID have anOMVS segment defined in RACF.

PD/MQ Data Services DaemonA daemon process is a process that runs in the background environment and is notassociated with any particular terminal or user. Daemons that have superuser


authority can issue restricted commands such as setuid(), seteuid(), and spawn() tochange the identity of a user’s process. A server application is an application thatprovides a service for clients. For instance, a server could be part of a softwareproduct that runs on any company’s z/OS computing environment, or it might bewritten by your application programmers for your own company’s use.

The PD/MQ data services daemon has characteristics of both a daemon and aserver, that is, it is not associated with one specific user, but rather provides aservice, which is the cryptographic processing of intercepted and protectedMQSeries messages. The PD/MQ data services daemon is a privileged process as ittemporarily assumes the RACF identity of the users that it works on behalf of.

The PD/MQ data services daemon requires a user ID that allows the daemon to beknown as a UNIX System Services process. In addition, the users that the daemonworks on behalf of must also have an appropriate definition of a UNIX UID andGID (group ID) so these users will be known as UNIX System Services users. Formore information on defining UNIX System Services UIDs and GIDs, see z/OS:SecureWay Security Server RACF Security Administrator’s Guide.

z/OS: UNIX System Services Planning compares traditional UNIX security to z/OSand OS/390 UNIX security. The primary difference between traditional UNIXsecurity and z/OS and OS/390 security is that the Kernel services support twolevels of appropriate privileges: UNIX level and z/OS UNIX level. Having a z/OSlevel of privileges lets you distinguish superusers from daemons.

Depending on your installation’s security policy, the PD/MQ data services daemonmay either run with superuser authority (uid(0)), or with its RACF identitypermitted to the RACF FACILITY CLASS BPX.DAEMON and BPX.SERVERprofiles, as this daemon must be able to assume the RACF identity of its users. Ifthe latter method is used, the PD/MQ data services daemon code must reside inRACF program-controlled libraries. Tivoli recommends that you review the z/OS:UNIX System Services Planning or OS/390: UNIX System Services Planning to ensurethat you understand the security differences between traditional UNIX securityand Z/OS and OS/390 UNIX security. This will allow you to administer thePD/MQ data services daemon according to your installation’s security policy fordeploying and running privileged UNIX System Services processes. For reference,the publications useful to this review are:v z/OS: UNIX System Services Planning

v OS/390: UNIX System Services Planning

v z/OS: SecureWay Security Server RACF Security Administrator’s Guide

v OS/390: SecureWay Security Server RACF Security Administrator’s Guide

Note: Choose the user ID for the daemon carefully, because the recipientcertificates may be loaded into a key ring associated with this user ID. Thisconsideration is discussed in “Creating the Certificates and Key Rings” onpage 22.

The example that follows assumes that superuser authority is being granted to thePD/MQ data services daemon. These are the RACF commands for setting up theuser ID for the daemon:1. First define a RACF user profile for the PD/MQ Server, if you have not already

done so:ADDUSER PDMQ NAME('PDMQ Server') OMVS (UID(x))


where x is the UID you have selected for the PD/MQ data services daemon. Ifyou specify a UID of zero, PD/MQ has superuser authority. Note that thecurrent connect group for the PD/MQ userID must have an OMVS segmentwith a group ID or GID assigned. For more details on how to define user andgroup profiles see z/OS: SecureWay Security Server RACF Security Administrator’sGuide.

2. Determine if the RACF STARTED class is active; if not, activate the RACFSTARTED class:SETR CLASSACT(STARTED)

3. Define a started class profile for PD/MQ, specifying the user ID that youcreated for the PD/MQ server and daemon, in step 1 on page 14:RDEFINE STARTED PDMQ*.* STDATA(USER(PDMQ))

Note: The examples in this section assume that you have activated genericprofile command processing for the RACF STARTED, FACILITY, andSURROGAT classes and generic profile checking. For more informationon how RACF handles generic profiles, see z/OS: SecureWay SecurityServer RACF Command Language Reference.

4. Use the SETROPTS RACF command to refresh the in-storage RACLISTedstarted class profiles:SETR RACLIST(STARTED)REFRESH

5. The PD/MQ data services daemon temporarily assumes the identity of the hostuser ID of the client requestor during protection processing of MQSeriesmessages. Therefore, it is necessary to define profiles in the SURROGAT classfor each user ID that can make requests. This can be done with a single genericprofile if the RACF SURROGAT class is active. The check is ignored if theSURROGAT class is not active. The SURROGAT profiles needed are describedin z/OS: UNIX System Services Planning.To define profiles in the SURROGAT class:a. Activate the RACF SURROGAT class using the RACF SETROPS command:

setr classact(surrogat)

b. Activate generic profile command processing for the RACF SURROGATclass:setr generic(surrogat)

c. Activate generic profile command processing for the RACF SURROGATclass:setr gencmd(surrogat)

d. Define a surrogate class generic profile:rdefine surrogat bpx.srv.* uacc(none)

e. Permit the User ID of the PD/MQ data services daemon to the genericSURROGAT class profile:permit bpx.srv.* class(surrogat) id(pdmq) acc(read)

You can define more specific profiles if you want to restrict specific users tobeing processed by the daemon, as described in z/OS: UNIX System ServicesPlanning.

6. The PD/MQ data services daemon uses the facilities provided by the z/OSSystem SSL services to open RACF managed key rings. The underlying SystemAuthorization Facility (SAF) that accesses the contents of the key rings iscontrolled by RACF.This service is the IRRSDL00 (R_datalib) callable service. This callable service isprotected with the same profiles, used to protect the RACF RACDCERT

Chapter 3. Configuring PD/MQ for z/OS and OS/390 15

commands that are defined to the RACF FACILITY class. Thus, the user ID ofthe PD/MQ data services daemon must be permitted to the profiles using thesecommands:a. If you have not already done so, define a RACF generic profile to the RACF

FACILITY class that protects the RACDCERT command and the IRRSDL00callable service:rdefine facility irr.digtcert.**

b. Grant authority to the user ID of the PD/MQ data services daemon to theRACF generic profile:permit irr.digtcert.** class(facility) id(pdmq) acc(control)

Default OMVS SegmentsThe PD/MQ data services daemon assumes the identity temporarily of its clients;that is, the daemon acts as a surrogate of the z/OS or OS/390 user ID of users ofPD/MQ during the processing of MQSeries messages to queues that are protectedby PD/MQ. In order for the daemon to assume the z/OS identity of a user thatresides on z/OS or OS/390, the client z/OS user ID must have a defined OMVSsegment associated with its user profile. As an administration aid, RACF providesthe ability to define a default OMVS segment that may be associated with RACFuser and group profiles. This default is used if the z/OS user ID or group profiledoes not have an OMVS segment explicitly defined. If you have a large number ofusers who need access to z/OS or OS/390 UNIX applications, you can set upRACF to automatically use default OMVS segments for users and groups that donot have OMVS segments in their USER or GROUP profiles.

The z/OS: SecureWay Security Server RACF Security Administrator’s Guide and theOS/390: SecureWay Security Server RACF Security Administrator’s Guide contain thedetailed procedure for defining default OMVS segments. Tivoli recommends thatyou review the procedure as outlined in these publications to determine if thedefinition of default OMVS segments in RACF User and Group profiles isappropriate to your installation.

You have completed the basic definitions of the user identities that are required forthe PD/MQ data server and data services daemon.

Customizing the PD/MQ Server ProcessesThe PD/MQ processes are started tasks that require customizing prior to beingstarted in your environment. These processes must be configured and alreadyexecuting before any PD/MQ-enabled application attempts to use MQSeriesmessaging services.

The PD/MQ Server customizing is controlled through startup options that are readfrom the PARM= keyword of the EXEC statement of the JCL. Although all startupoptions are optional, note that a syntax error in any option will cause initializationof the PD/MQ server to fail.

The options that may be customized are:

Table 1. Options that Can be Customized

Key word Description Default

FOLDMSG | FMNOFOLDMSG | NOFM

Fold messages to upper case. Issuemessages as is.

Messages are notfolded to upper case.


Table 1. Options that Can be Customized (continued)

Key word Description Default

ARM NOARM Register server with automatic restartmanager ARM). Do not registerserver with ARM.

The PD/MQ serverregisters with ARM.

TRACE | TR=ON TRACE |TR=OFF

Enable trace. Trace should be usedonly under Tivoli supervision.Disable trace.

Disable trace.

SMF=NO | nnn Disable SMF recording or enableusing record number nnn.

The default recordnumber is 180.

DEBUG | DB NODEBUG |NODB

Enable debug mode. Debug modeshould be used only under Tivolisupervision. Disable debug mode

Debug mode isdisabled.

The options can appear in any order and are separated by commas. Whenduplicate options are specified, the last one found is used. The defaults shown inTable 1 on page 16 are in effect unless you either modify the sample JCL procedurefor the PD/MQ server, or override the defaults (in the case where the server isstarted by an operator command).

The supplied PD/MQ procedure, as shown below, defines a symbol &P to simplifyentering options from the operator’s console

Here is the sample JCL procedure for the PD/MQ server://PDMQ PROC P='TR=OFF'//*//* Procedure to start the PDMQ server//*//* Licensed Materials - Property of IBM//* 5698-PDM//* (c) Copyright IBM Corp. 2001//*//* Status = HDMQ100//*//PDMQ EXEC PGM=DRQHCTL,REGION=0M,TIME=NOLIMIT,PARM='&P'//*//STEPLIB DD DSN=DRQ.SDRQLOAD,DISP=SHR//*

For example, the operator could issue:S PDMQ,P='TR=ON'

to enable tracing when the server is started from the operator’s console.

Note that you can tailor the SMF record number of the audit records that aregenerated by PD/MQ. By default, PD/MQ uses a user-defined SMF recordnumber of 180. You can change this record number so that audit records producedby PD/MQ can be processed by applications that you have to reduce SMF data.See “Chapter 8. Auditing PD/MQ for z/OS and OS/390” on page 77, for furtherinformation.

Customizing the PD/MQ Data Services DaemonThe data services daemon provides the set of services that, among other tasks,interface with the cryptographic services provided by the z/OS and OS/390System SSL components. These services are used in the protection of MQSeriesmessages that originate from or are received from applications. The data services


daemon also provides LDAP communication services, which are also used in theprotection processing of application messages.

The PD/MQ data services daemon executes as a started task with a defaultprocedure name of PDMQD. A sample JCL procedure is shown in Figure 5. ThisJCL sample is supplied with PD/MQ as part of the installation procedure.

The PD/MQ data services daemon requires access to the z/OS or OS/390 SystemSSL services. This can be implemented either by a STEPLIB associated with thePD/MQ data services daemon, or by adding the DLL dataset to the LNKLSTconcatenation. Note that if the DLL is included in a STEPLIB, it must beAPF-authorized since the PD/MQ data services daemon also requires APFauthorization.

As shown in Figure 5, the PD/MQ data services daemon contains a default path,which is /usr/lpp/pdmq/samples. This directory path may be customized for yourspecific installation. This path is used to locate an environment variable file, whichhas by default, the name drqdserv.envars. Note that JCL restricts the length of anEXEC PARM statement to 100 characters. Here is a sample environment variablefile:## PDMQ Environment Variables File## Licensed Materials - Property of IBM## Restricted Materials of IBM# 5698-PDM# (C) Copyright IBM Corporation 2001## Status = HDMQ100

//PDMQD PROC OCLASS=*, Sysout class// SEG=10, File segment// TZ='EST5EDT', Time zone// DIR='/usr/lpp/pdmq/samples', Default path// FN='drqdserv.envars', Envars file name// STDO='1>DD:STDOUT',// STDE='2>DD:STDERR'//*//* Procedure to start the PDMQ data services daemon//*//* Licensed Materials - Property of IBM//* 5698-PDM//* (c) Copyright IBM Corp. 2001//*//* Status = HDMQ100//*//PDMQD EXEC PGM=DRQSERVD,REGION=0M,TIME=NOLIMIT,// PARM=('ENVAR("_CEE_ENVFILE=&DIR./&FN","TZ=&TZ") / &STDO &STDE')//*//STEPLIB DD DSN=DRQ.SDRQLOAD,DISP=SHR//*//STDOUT DD SYSOUT=&OCLASS,SEGMENT=&SEG//STDERR DD SYSOUT=&OCLASS,SEGMENT=&SEG//SYSOUT DD SYSOUT=&OCLASS//*//CEEDUMP DD SYSOUT=&OCLASS

Figure 5. Sample JCL for the PD/MQ Data Services Daemon Process


## This file consists of the various environment variables used# by the Tivoli Policy Director/MQ Data Services Daemon.## This file is referenced by the PDMQD started task. If another# file is to be used, change the PDMQD JCL to reference the path# for that file.## The _DRQSERV_MSG_LOGGING variable specifies whether message logging is to# be written to stderr or stdout.## _DRQSERV_MSG_LOGGING=stdout_logging - indicates to write all messages# to stdout as well as writing the error and severe messages to stderr.## _DRQSERV_MSG_LOGGING=stderr_logging - indicates to write verbose, debug,# informational, and warning messages to stdout and error and severe messages# to stderr. This is the default._DRQSERV_MSG_LOGGING=stderr_logging## The _DRQSERV_MSG_LEVEL variable specifies the subcomponent and message# level that is to be logged. An asterisk indicates all subcomponents# to be logged. The severity levels are:# S - severe messages# E - error and severe messages# W - warning, error, and severe messages# W - informational, warning, error, and severe messages# D - debug mode# V - verbose mode# Currently the Data Service daemon consists of just one component# DRQD, so the following 2 values for DRQSERV_MSG_LEVEL are equivalent and# also the default value if not specified.## _DRQSERV_MSG_LEVEL=*.w# _DRQSERV_MSG_LEVEL=DRQD.w_DRQSERV_MSG_LEVEL=*.w## The _DRQ_INIT_THREADS variable specifies the number of threads to create# when Data Services daemon initializes. The default value is 20.#_DRQ_INIT_THREADS=20## The _DRQ_MAX_THREADS variable specifies the maximum number of threads# the Data Services daemon will create. (The daemon creates more threads when# a backlog of requests build up). The default value is 200.#_DRQ_MAX_THREADS=100## The following defines the path for the message catalog.NLSPATH=/usr/lpp/pdmq/lib/nls/msg/%L/%N:/usr/lpp/pdmq/lib/nls/msg/En_US.IBM-1047/%N:$NLSPATH### The following defines the LDAP configuration parameters._DRQ_LDAP_CONFIG_FILE=/usr/lpp/pdmq/samples/drqdldap.config

The configuration file, drqdldap.config, contains LDAP bind information for theLDAP server that holds the Policy Director user registry, with one line per item.The items must be specified in the order:1. LDAP server name2. LDAP server port number3. LDAP distinguished name (DN) to use in binding to the specified LDAP

directory4. The LDAP password for the bind DN.


Tivoli recommends that only the user ID of the PD/MQ data services daemonhave read access to this file. In addition, the LDAP distinguished name specified inthe configuration file must have LDAP authority to read the secPKIMap objectsthat will be defined to the LDAP directory. The LDAP directory is the same LDAPdirectory used as your Policy Director user registry.

Here is an example of a configuration file to assist you:## Licensed Materials - Property of IBM# 5698-PDM# (c) Copyright IBM Corp. 2001## Status = HDMQ100### This file is used by the PD/MQ daemon to access the ldap server# that contains the relevant Policy Director (PD) secMap# objectClasses and the PD/MQ secPKIMap objectClasses. Only the# PD/MQ daemon should have authority to this file. The daemon will# only read the file. The data in this file should be in the local# code page of the PD/MQ daemon.## This file contains 4 lines of required data plus any number of# comments. Every line other than the 4 data lines must begin with a# '#'.## The data must be in this order:## ldap host name = the host name of the ldap server. PD/MQ uses# this as a parameter on an ldap_init()# function call# ldap port number = the port number of the ldap server on the# ldap host. This is also used on the# ldap_init() function call.# ldap userid = the userid that the PD/MQ daemon will use to# access the ldap server. It will be used as a# parameter on the ldap_simple_bind_s() function# call. This user must have the authority to# read the PD secMap and PD/MQ secPKIMap data.# ldap user pw = the password to be used for the ldap userid.# It will also be passed on the ldap_simple_bind_s()# function call.## place the ldap server host name on the next lineldap.server.host.name# place the ldap port number on the next line389# place the ldap userid on the next linecn=root# place the ldap userid password on the next line123

Using Digital Certificates in PD/MQPD/MQ for z/OS uses X.509 V3 digital certificates in the protection-processing ofmessages placed on or received from MQSeries queues. PD/MQ itself does notcreate or manage the life cycle of these certificates; that function is provided by aPKI. PD/MQ supports certificates created by RACF and other PKI providers listedin on page 7. Whether or not a z/OS or non-z/OS resident PKI is used, PD/MQfor z/OS uses only key rings that are managed by RACF or its equivalent to accesscertificates. These key rings are based on Security Authorization Facility (SAF) andare the repository used by PD/MQ to retrieve certificates for originators andrecipients of messages placed on or received from MQSeries queues. RACF


includes the capability for importing certificates and private keys intoRACF-managed key rings. See the z/OS SecureWay Security Server RACFpublications for detailed examples of how to load certificates to RACF-managedkey rings. If your installation is using one of the supported PKI products, refer tothe publications that accompany the product for information on how to deploy it.

PD/MQ implements two levels of protection, integrity and privacy. With integrity,messages are signed using the private key of the originator (the application doingthe MQPUT). Integrity provides detection of message modification, but themessage text itself is not encrypted. With privacy, the message is not only signed,but is also encrypted. The message is encrypted using the public key of eachpossible message recipient (the application doing the MQGET). The private andpublic keys are associated with certificates stored in key rings.

When a message that is protected with privacy is dequeued by a recipientapplication doing an MQGET, the message must be decrypted. Because it wasencrypted using the recipient’s public key, it must be decrypted using therecipient’s private key found in a key ring.

How PD/MQ Uses Key RingsPD/MQ makes use of existing RACF key ring services to define and manage thecertificates needed for signing and encryption. Security products that arefunctionally equivalent to RACF may be used instead of RACF if they provide thesame level of support. Efficient use of key rings can reduce the administrationneeded to manage the certificates. Once a certificate is generated (or imported), itmust be connected to a key ring to become accessible. The same certificate can beconnected to more than one key ring.

For messages that originate from z/OS or OS/390 and are protected by either apolicy of integrity or privacy, the certificate and private key of the originating userID must be stored in a RACF-managed key ring that is associated with the z/OSuser ID of the message originator. If a protection policy of privacy has beenselected for the message queue, PD/MQ uses a recipient key ring associated withthe z/OS user ID of the PD/MQ daemon process that contains the digitalcertificate of each message recipient.

PD/MQ uses a key ring name of drq.pdmq.keyring when searching forcertificates. The certificate containing the private key used for decryption may haveany label but must be connected as the default certificate. To simplify theimplementation, the certificate with the private key must be connected to the keyring owned by the user who originated the message. The recipient certificates mustbe connected to a key ring associated with the user ID of the PD/MQ data servicesdaemon. Digital certificates and key rings are managed in RACF primarily byusing the RACDCERT command. For more information about certificates, labels,and the RACDCERT command, see z/OS: SecureWay Security Server RACF CommandLanguage Reference and z/OS: SecureWay Security Server RACF SecurityAdministrator’s Guide.

Authorizing Access to the RACF RACDCERT CommandThe following commands are needed to allow access to the RACF RACDCERTcommand:RDEFINE FACILITY IRR.DIGTCERT.* UACC(CONTROL)PERMIT IRR.DIGTCERT.* ID(admin) ACCESS(CONTROL)SETROPTS RACLIST(FACILITY) REFRESH


In this example, admin specifies the user IDs and group names of RACF-definedusers or groups whose authority to access this resource you are giving, removing,or changing.

Note: The uacc shown here allows all users access to the command, but you willprobably want to restrict the command to administrators. Also, profiles canbe created to restrict specific functions such as LIST and ADD. The completeset of profiles is described in z/OS: SecureWay Security Server RACF SecurityAdministrator’s Guide.

Creating the Certificates and Key RingsThis section documents the steps required to create the certificates and key ringsnecessary for PD/MQ.

In the examples that follow, user1 is the originator of a message, user2 is therecipient. The user ID of the PD/MQ daemon is PDMQ. This example illustratesonly the setup of the key rings and certificates, not the additional administrativesteps required to define the queue to Policy Director. All of the commands in thefollowing examples are issued from ISPF option 6 by the administrative user IDadmin.

Defining a Local Certificate Authority CertificateIf you will be using RACF as your CA, you will need to create a certificateauthority certificate, if you have not already done so. The following commandcreates a certificate authority (or signer) certificate. This example creates a certificatecalled RACFCA to be used when creating subsequent certificates that reflect theidentity of PD/MQ users and applications. This command may be modified,specifically subjectsdn, to reflect the naming structure and conventions used atyour installationRACDCERT CERTAUTH GENCERT SUBJECTSDN(CN('RACFCA') O('ibm') C('us'))KEYUSAGE(CERTSIGN) WITHLABEL('RACFCA')

Note: Certificates signed with this local certificate authority certificate show anissuer of cn=RACFCA,o=ibm,c=us when listed with the RACDCERT LISTcommand.

Creating a Digital Certificate with a Private KeyA digital certificate with a private key must be generated for each PD/MQ user. Inthe following example, RACDCERT commands are used to generate certificates foruser1 and user2, which are signed with the local CA certificate identified by thelabel RACFCA.RACDCERT ID(user1) GENCERT SUBJECTSDN(CN('user1') O('ibm') C('us'))WITHLABEL('user1') SIGNWITH(CERTAUTH LABEL('RACFCA'))KEYUSAGE(HANDSHAKE DATAENCRYPT DOCSIGN)

RACDCERT ID(user2) GENCERT SUBJECTSDN(CN('user2') O('ibm') C('us'))WITHLABEL('user2') SIGNWITH(CERTAUTH LABEL('RACFCA'))KEYUSAGE(HANDSHAKE DATAENCRYPT DOCSIGN)

RACDCERT ID(user1) ALTER (LABEL('user1')) TRUSTRACDCERT ID(user2) ALTER (LABEL('user2')) TRUST

The RACDCERT ALTER command is required to add the TRUST attribute to thecertificate. When a certificate is first created using this procedure, it has a differentvalid date range than the signing certificate. As a result, RACF marks it as


NOTRUST,which means that the certificate is not to be used. Use the RACDCERTALTER command to set the TRUST attribute. The KEYUSAGE attributesHANDSHAKE, DATAENCRYPT and DOCSIGN must be specified for certificatesused by PD/MQ.

Creating the RACF Key RingsThe following commands create a key ring for RACF-defined user IDs user1,user2, and the PD/MQ data services daemon PDMQ.

The key ring name is fixed by PD/MQ and must be coded as shown, withoutquotes. The name is case-sensitive.RACDCERT ID(user1) ADDRING(drq.pdmq.keyring)RACDCERT ID(user2) ADDRING(drq.pdmq.keyring)RACDCERT ID(PDMQ) ADDRING(drq.pdmq.keyring)

Connecting the Certificates to the Key RingsConnect the user and CA certificates to the key rings:RACDCERT ID(user1) CONNECT(CERTAUTH(LABEL('RACFCA')RING(drq.pdmq.keyring))

RACDCERT ID(user2) CONNECT(CERTAUTH(LABEL('RACFCA')RING(drq.pdmq.keyring))

RACDCERT ID(PDMQ) CONNECT(CERTAUTH(LABEL('RACFCA')RING(drq.pdmq.keyring))

RACDCERT ID(user1) CONNECT(ID(user1)LABEL('user1')RING(drq.pdmq.keyring) DEFAULT USAGE(PERSONAL))

RACDCERT ID(user2) CONNECT(ID(user2)LABEL('user2')RING(drq.pdmq.keyring) DEFAULT USAGE(PERSONAL))

RACDCERT ID(PDMQ) CONNECT(ID(user2)LABEL('user2')RING(drq.pdmq.keyring)USAGE(SITE))

The certificate containing the private key used for decryption must be connected asthe default certificate.

The RACDCERT usage(site) attribute prevents the private key from beingaccessible in the key ring, while the RACDCERT usage(personal) attribute allowsthe private key to be used, if it exists.

Key Ring VerificationThe key ring should appear as follows after all commands have been entered:RACDCERT ID(user1) LISTRING(drq.pdmq.keyring)

Digital ring information for user USER1:Ring:

>drq.pdmq.keyring<

Certificate Label Name Cert Owner USAGE DEFAULT-------------------------------- ------------ -------- -------user1 ID(USER1) PERSONAL YESRACFCA CERTAUTH CERTAUTH NO

RACDCERT ID(user1) LISTRING(drq.pdmq.keyring)

Digital ring information for user USER2:Ring:

>drq.pdmq.keyring<


Certificate Label Name Cert Owner USAGE DEFAULT-------------------------------- ------------ -------- -------user2 ID(USER2) PERSONAL YESRACFCA CERTAUTH CERTAUTH NO

RACDCERT ID(PDMQ) LISTRING(drq.pdmq.keyring)

Digital ring information for user PDMQ:Ring:

>drq.pdmq.keyring<

Certificate Label Name Cert Owner USAGE DEFAULT-------------------------------- ------------ -------- -------RACFCA CERTAUTH CERTAUTH NOuser2 ID(USER2) SITE NO

Listing the individual certificates also shows the ring association.RACDCERT ID(user2)LIST(label('user2'))

Digital certificate information for user USER2:

***Label: user2Certificate ID: 2QfH8Pny9/LzpKKFmfFAStatus: TRUSTStart Date: 2001/10/12 22:59:53End Date: 2002/10/13 22:59:52Serial Number:

>15<Issuer's Name:

>OU=RACFCA.O=ibm.C=us<Subject's Name:

>CN=user2.O=ibm.C=us<Key Usage: HANDSHAKE, DATAENCRYPT, DOCSIGNPrivate Key Type: Non-ICSFPrivate Key Size: 1024Ring Associations:

Ring Owner: USER2Ring:

>drq.pdmq.keyring<Ring Owner: PDMQRing:

>drq.pdmq.keyring<

Summary of the Certificate-Related OperationsTo use PD/MQ for z/OS and OS/390 to enqueue messages on MQSeries-protectedqueues having a message protection level of privacy or integrity, PD/MQ musthave access to two pieces of data:v The X.509 V3 certificate and private key for the user enqueuing the messagev If the data protection policy is privacy, the X.509 V3 certificate of the intended

recipients. The intended recipients are defined to Policy Director by theQ-recipients extended attribute, which is defined for each protected queue.

For processes and applications that run on z/OS or OS/390, PD/MQ must havecertificates in two places:v In a RACF-managed key ring associated with the RACF identity of the sending

application (the application that enqueues the protected message). The certificate


that PD/MQ locates is the default certificate, and must include the private key.PD/MQ assumes the z/OS or OS/390 identity of the sending application. Thatis, it acts as a surrogate, so it can access the user’s private key.

v For recipients of these protected messages, which may or may not bez/OS-defined users, the PD/MQ data services daemon examines a key ringassociated with the z/OS or OS/390 identity of the PD/MQ data servicesdaemon. Only the certificate (not the private key), must reside in the daemon’skey ring.

The CA certificate, which is used to verify the authenticity of user and recipientcertificates, must be loaded and connected to both the user and PD/MQ dataservices daemon key rings, and marked as a CA certificate, which is a trusted rootcertificate.

The earlier examples shown have used RACF as the local CA, however, you mayuse another PKI provider (Certificate Authority) at your installation. If you intendto use another PKI product, remember that the private key and the certificate mustbe imported into a key ring associated with the z/OS or OS/390 RACF user IDsthat will originate MQSeries messages protected by PD/MQ. You may use theRACF RACDCERT command as the mechanism to generate certificate requests,which may be exported and sent to the PKI provider of your choice to be filled.

Here is a summary of the certificate-related steps:1. Request the creation of a CA certificate, one in which RACF is the local CA.

Omit this step if you are using another PKI provider.2. Generate user certificates signed by the CA.3. Create the key rings for the users and the PDMQ daemon ID.4. Connect the user CA certificate to the keyrings. Connect the user certificate to

the user key ring with the default attribute.5. Connect the recipients certificates to the PD/MQ daemon key ring using the

usage(site) attribute.

You must do this for each certificate you wish to add to the ring.

Configuring a Non-z/OS-Resident PKIPD/MQ for z/OS and OS/390 uses X.509 V3 digital certificates in theprotection-processing of messages placed on or received from IBM MQSeriesqueues. PD/MQ itself does not create or manage the life cycle of these certificates;that function is provided by a public key infrastructure (PKI). The examples in thispublication that illustrate the use of certificates use z/OS SecureWay SecurityServer RACF to fill certificate requests.

Whether or not a z/OS or non-z/OS resident PKI is used, PD/MQ for z/OS usesonly key rings that are managed by RACF or its equivalent. These key rings arebased on Security Authorization Facility (SAF) and are the repository used byPD/MQ to retrieve certificates for originators and recipients of messages placed onor received from MQSeries queues. For messages that are originated from z/OS orOS/390, which are protected by either integrity or encryption policy, the certificateand private key of the originating user ID must be stored in an SAF-managed keyring that is associated with the OS/390 user ID of the message originator.


If encryption message-processing has been selected, PD/MQ uses a recipient keyring that contains the digital certificate of each message recipient associated withthe z/OS user ID of the PD/MQ daemon process.

RACF includes the capability for importing certificates and private keys intoRACF-managed key rings. See the z/OS SecureWay Security Server RACFpublications for the details and examples of how to load certificates to RACFmanaged key rings.

If your installation is using one of the supported PKI products, refer to thepublications that accompany the product for information on how to deploy it.

Configuring Policy Director Authorization Services for z/OSPD/MQ for z/OS depends on Policy Director Authorization Services, whichenables policy for MQSeries queues to be shared across multiple systems such asz/OS, OS/390, AIX, and Windows NT/2000. Please refer to the publication IBMPolicy Director Authorization Services for z/OS and OS/390: Customization and Use forthe steps required to configure Policy Director Authorization Services.

Configuring or Joining an Existing Policy Director Secure DomainA secure domain is the group of users, systems, and resources that share commonservices and a common security policy. There must be only one instance of thePolicy Director Management server in any secure domain that replicates policy tothe participating systems and applications within the bounds of the secure domain.

IBM Policy Director Authorization Services enables z/OS and OS/390 systems tojoin an existing Policy Director secure domain, if for example, you have alreadydeployed Tivoli’s Policy Director in your enterprise. See the publication IBM PolicyDirector Authorization Services for z/OS and OS/390: Customization and Use for thesteps required to configure z/OS and OS/390 into an existing Policy Directorsecure domain.

Configuring the PD/MQ Protected Object SpaceA Policy Director secure domain contains physical resources that need some levelof access protection. The Policy Director security model depends on access controllists (ACLs) and protected object policies (POP) to provide fine-grained protectionfor resources. Policy Director Authorization Services permits or denies access toresources based on user credentials and the specific permissions and conditions setin the ACL and POP.

In order to apply ACL and POP and allow Policy Director Authorization Servicesto perform security checks, Policy Director uses a virtual object representation ofsecure domain resources called the protected object space.

If you are installing PD/MQ for the first time, and the installation is beingperformed initially on z/OS or OS/390, PD/MQ for z/OS includes an executablefile, pdmqcfg, to assist you. This file is found in the hierarchical file system in thedirectory /usr/lpp/pdmq/bin.

The pdmqcfg utility defines the protected object space to Policy Director, andestablishes default policies that are used by PD/MQ. This portion of theconfiguration should be run only once, from the first machine installed withPD/MQ.


The PD/MQ utility pdmqcfg creates the pdadmin commands that define theprotected object space root for PD/MQ. The output of this utility should first beredirected to a file, which is then downloaded to the platform where the masterpolicy server is located, and finally, executed.

PD/MQ uses D (for Dequeue) and E (for Enqueue) permissions. Dequeuepermission can be thought of as the permission required to GET a message froman MQSeries message queue, and Enqueue permission can be thought of as theprivilege to PUT to an MQSeries protected message queue. These permissions arecreated by pdmqcfg under an action group called PDMQ.

The syntax for pdmqcfg is:pdmqcfg -config|-unconfig|-help -admin sec_master -pwd sec_master_password[-pkisystem acme ][-pkiencqop STRONG|MEDIUM|WEAK|DEFAULT ][-pkisigqop MD2|MD5|SHA1|DEFAULT ][-queueres local|remote ][-help ]

The parameters that can be specified on the pdmqcfg utility have these meanings:

Table 2. Parameters for the pdmqcfg utility.

Parameter Meaning

-config Creates the PD/MQ configuration data in the Policy Director masterpolicy database.

-unconfig Removes PD/MQ configuration data from the Policy Director masterpolicy database.

-admin Specifies the Policy Director administrative user ID. This is a requiredparameter.

-pwd Specifies the Policy Director administrative user’s password. This is arequired parameter. See notes below.

-pkisystem Ignored. The z/OS implementation of PD/MQ uses the z/OSsystem-provided security services.

-pkiencqop Specifies the data privacy algorithm. The allowable values for thisparameter are: STRONG, MEDIUM or WEAK. The default value isSTRONG.

These data privacy values correspond to the following data encryptionstandards:

STRONG Triple DES or DES3. This is a 168-bit encryption key.

MEDIUM DES. This is a 56-bit encryption key.

WEAK RC2

-pkisigqop Specifies the data integrity algorithm. The allowable values are: MD2,MD5, SHA1. The default value is MD2.

-queueres Specifies the queue name resolution. The allowable values are: LOCAL,REMOTE. The default is LOCAL This is not supported on z/OS orOS/390.

-help Prints help information. This is an optional parameter.

Note: If your installation plans to or has enabled the z/OS or OS/390 IntegratedCryptographic Service Facility (ICSF), Tivoli recommends that you changethe default of pkisigqop from MD2 to either SHA1 or MD5, as thesehashing algorithms are supported by ICSF.


Example of Invoking the pdmqcfg UtilityIn the example that follows, the LDAP user ID for the Policy Directoradministrator is sec_master, and that user’s LDAP password is pdmq4zos. Giventhe applications that use MQSeries on z/OS, the administrator has determined thatthe encryption quality of protection will be STRONG. The signature algorithm thatthe administrator has selected is SHA1.

The administrator logs on to z/OS and enters a UNIX System Services shellenvironment. The administrator checks that the path used by the shell includes thedirectory that contains the pdmqcfg executable, and adjusts the path environmentvariable to include the directory that contains the pdmqcfg utility. In this example,the pdmqcfg utility was installed into /usr/lpp/pdmq/bin.

The dollar sign is the prompt character used by the shell. Here is how theadministrator invokes the pdmqcfg utility:

The output script file is transferred to the system that hosts the Master PolicyDatabase and executed.

$ echo $PATH/u/admin:/usr/tools:/bin:/u/rcsbld/bin:.$ export PATH=$PATH:/usr/lpp/pdmq/bin$pdmqcfg -config -admin sec_master -pwd pdmq4zos -pkiencqop STRONG-pkisigqop SHA1 >pdmqcfgout.sh$ ls -ltotal 16-rw------- 1 ADMIN1 ADMGRP 3859 Sep 24 11:04 pdmqcfgout.sh$

The output from these commands is:

pdadmin -a sec_master -p pdmq4zosobjectspace create /PDMQ "PDMQ Object Space Container" 13object create /PDMQ/Queue "Queue Object" 13 ispolicyattachable yesaction group create PDMQaction create D Dqueue Dqueue PDMQaction create E Enqueue Enqueue PDMQobject modify /PDMQ set attribute PKI-system acmeobject modify /PDMQ set attribute PKI-enc-strength STRONGobject modify /PDMQ set attribute PKI-sig-algorithm SHA1object modify /PDMQ set attribute Qname-resolution localCONFIG successful. pdadmin commands for configure were written to STDOUT.config finished successfully.

Figure 6. Invoking pdmqcfg Utility


Chapter 4. Administering PD/MQ for z/OS and OS/390

This chapter describes the details of deploying PD/MQ for z/OS in a typicalMQSeries environment. It provides scenarios of an MQSeries setup and illustratesPD/MQ configuration for such a deployment.

The steps to take for successfully deploying PD/MQ for the z/OS and OS/390environments is:1. Identify and define MQSeries resources (queues and queue managers) for the

set of PD/MQ-enabled applications for the Policy Director secure domain.2. Define PKI identities for the set of applications using MQSeries in the secure

domain that you wish to secure using PD/MQ.3. Define PKI identities for all users using these applications.4. Provide Policy Director user registry mappings for the set of users and groups

that are defined to Policy Director and PD/MQ.5. Define and attach Policy Templates in the form of Protected Object Policies

(POP) and Access Control Lists (ACLs) for all PD/MQ-defined resources.6. Enabler the application environment to invoke PD/MQ.

Defining MQSeries ResourcesThe first and most important task in the deployment of PD/MQ is for the securityadministrators to work with the MQSeries administrative staff to identify theresources to be protected by PD/MQ. The identification of MQSeries resources willbe influenced by the applications and the security policy for the application datathat is transmitted between applications and systems using MQSeries. Thisidentification of MQSeries resources, and the user community that accesses themare key activities in determining the set of MQSeries resources and the stepsrequired to administer and deploy PD/MQ. The definition of resources includesdefining MQSeries objects, such as queue managers and queues, users and groups,to Policy Director, and mapping Policy Director user IDs to z/OS or OS/390 localhost user IDs for host-resident users. Once the definition of resources and usershas been completed, Tivoli recommends that you thoroughly test the applicationsthat you intend to enable PD/MQ protection for. The testing phase allows you toidentify and correct early any gaps in either your security policy or in theadministrative tasks that you have performed, before the applications are stagedinto a production environment.

In installations where MQSeries has been deployed on z/OS or OS/390 prior tothe installation of Policy Director and PD/MQ, you may want to review thesecurity definitions on z/OS for your host security product, such as RACF. Thisreview of the definition of MQ resources, and the users that can access them, mayhelp you to determine the MQ resources and the security policy appropriate forthe resources to be enforced by PD/MQ on z/OS.

In existing PD/MQ installations where MQSeries is already deployed, much of thisactivity has been completed prior to the installation of PD/MQ for z/OS andOS/390. In this case, you may have already determined which queues andapplications are eligible to be protected by PD/MQ, and which queues andapplications are accessible on z/OS and OS/390, and which ones are not. If the


results of this sort of analysis are available, you may be able to use it to develop aplan to stage the deployment of PD/MQ on z/OS and OS/390.

If an existing z/OS or OS/390 system will be joining a Policy Director securedomain, you must determine which applications and MQ resources, and the set ofusers that access these applications, should be protected by PD/MQ. If you aredefining new applications and queues on z/OS or OS/390 that you want to protectwith PD/MQ, refer to the following MQSeries publications when definingMQSeries objects:v MQSeries for OS/390 V5R2: Concepts and Planning Guide


After all MQSeries resources are defined and operational, the next step is topopulate these resources in the Policy Director protected object namespace. Theobjects that appear in this hierarchical namespace represent the actual protectedresources. Policy Director attaches access control templates to these resources.

PD/MQ for z/OS and OS/390 is not a substitute for the security provided byRACF or equivalent products, but rather it augments and complements the localsecurity provided by RACF. PD/MQ provides a mechanism for enforcingcross-platform message security and cross-platform access control to MQSeriesresources. A comprehensive security policy includes a strong local security policy,plus a security policy that takes into account applications that may be distributedacross multiple platforms within an enterprise.

Adding MQSeries Objects to Policy DirectorAs shown in Figure 7, the PD/MQ protected object space defines MQSeries objectsin a hierarchical fashion. Under the PD/MQ root object, the type of objects that areprotected are queues. MQSeries queue managers are defined at the next level inthat hierarchy, and the individual queues that a queue manager manages are at thelowest level of this hierarchical tree.

WebSEAL

PDMQ PDMQ RootPDMQ Root

Object typeObject type

Queues

QueueQueue

BOX2.QM

BOX2.IN.QUEUE

BOX2.OUT.QUEUE

BOX2.QM

BOX2.IN.QUEUE

BOX2.OUT.QUEUE

BOX2.QM

BOX2.IN.QUEUE

BOX2.OUT.QUEUE

BOX1.QMBOX1.QM Queue ManagerQueue Manager

Figure 7. The PD/MQ Protected Namespace


It is the administrator’s task to identify the MQSeries queue managers and queuesthat should be protected by PD/MQ. The administrator must determine whereeach MQSeries object resides, what its characteristics are, and who has access to it.The administrator can determine, manage and monitor the MQSeries resources byuse of the commands, operations, and control panels, or the utility programssupplied with MQSeries for z/OS and OS/390.

Using native MQSeries administration techniques on z/OS and OS/390, theMQSeries administrator can work with the PD/MQ administrator to determinewhich queue managers and queues on z/OS or OS/390 should be defined toPD/MQ. Once the z/OS-based queue managers, queues, and users of those queueshave been identified, the MQSeries administrator, working with the PD/MQadministrator, uses the administrative interfaces provided by Policy Director todefine:v The protected object name space for each of the z/OS MQSeries queue managersv The MQSeries queuesv The users that have authority to PUT and GET (Enqueue and Dequeue

respectively) to those queues

Once you have identified the MQSeries resources and the users needing theauthority to enqueue or dequeue messages from these queues, the next step is todetermine the level of message protection that is appropriate for each queue. Forexample, for application data that is not sensitive, which may not warrant privacyor integrity, you may elect a message protection of none. In contrast, forapplication messages that require verification of their origin or protection againstmodification, you may elect to enforce a message protection of integrity. Similarly,high value messages, which perhaps contain personal or financial information, maywarrant privacy, that is encryption of the message contents for the intendedrecipients of the message. Consider the overall data security policy that yourinstallation specifies when making this determination.

Be aware that the higher levels of message security increase the message sizes andthe overhead required to process messages. Therefore, defining a security policythat adequately and appropriately protects the MQSeries message traffic betweenyour applications, will make the best use of your installation’s computingresources, while enforcing a security policy that meets your installation’srequirements.

Your installation may already have created installation-specific tools that aid in themanagement of MQSeries on z/OS or OS/390. For example, these tools may usethe system input command queue, or use MQSeries-supplied utility programs,such as CSQUTIL, which can aid in the management of MQSeries objects.

Depending on what facilities you use in managing MQSeries, one approach indefining objects (queue managers, and queues) to Policy Director, is to build a listof these resources, which can then be incorporated into a script. This script, whichconsists of the appropriate pdadmin commands, when run on the master policyserver defines the MQSeries objects to Policy Director. A scripting techniqueprovides the ability to rapidly define a large number of objects to Policy Director.

As an alternative, depending on the number of queue managers and queues to beprotected by PD/MQ, you may use one of these administrative mechanisms todefine these objects to Policy Director:v The pdadmin commands issued from the master policy server

Chapter 4. Administering PD/MQ for z/OS and OS/390 31

v The Tivoli Policy Director Web Portal Manager as the administrative graphicaluser interface, if you have installed it

Any of these methods define MQSeries queue managers, queues, user accounts,and security policy information (such as message protection and extendedattributes that play a role in enforcing the security policy for the protected objects).

Given your installation’s environment, the following publications may help you todetermine which approach provides the greatest administrative efficiency:v MQSeries for OS/390 V5R2: System Administration Guide

v MQSeries for OS/390 V5R2: System Setup Guide

v Tivoli: Policy Director for MQSeries Administration Guide 3.7.1. This is the book forPD/MQ on the distributed platforms (AIX, Sun Solaris, and Windows NT).

v IBM Policy Director Authorization Services for z/OS and OS/390: Customization andUse

Note: PD/MQ for z/OS does not provide protection, or data protection, for queuenames (including those for modal queues) that begin with the reserved highlevel qualifier (HLQ) of SYSTEM.

Defining PD/MQ Extended Configuration Attributes to PolicyDirector Protected Objects

As shown in Figure 8, PD/MQ uses Policy Director extended attributes that areassociated with objects defined to the Policy Director Protected namespace.

These attributes define PD/MQ specific data that may be used:v Globally for all queues defined to Policy Directorv Specifically associated with a queue manager, orv Associated on a per queue basis

The Policy Director extended attributes are managed using the Policy Directorpdadmin commands or with the Policy Director Web Portal Manager.

PDMQ

Queue

BOX2.IN.QUEUE

BOX2.OUT.QUEUE

BOX1.QM

Q - enc - strength

Q - sig - algorithmQ - recipients

Qname - resolutionPki - enc - strength

Pki -sig - algorithm

Error - handling - Q

Global

Per Queue Manager

Per Queue

Figure 8. Conceptual View of PD/MQ Extended Attributes


Configuration Information for Global DataThe pdmqcfg utility, described in “Configuring the PD/MQ Protected ObjectSpace” on page 26, is used to defined the values for the signature algorithm andencryption strength to be used if they are not specified at the queue level.

Configuration Information for /PDMQ/Queue/QueueManager-nameThe Error-handling-Q attribute is required for each queue manager.Error-handling-Q is the queue name of the MQSeries-defined error-handling queuefor a given queue manager. Under certain conditions, such as when the sender hasinsufficient authority to write to this queue, PD/MQ routes messages received toan error-handling queue if one of the set of conditions is found. See “Chapter 6.Error Handling in PD/MQ for z/OS and OS/390” on page 63 for information onthe error-handling queue and the conditions under which PD/MQ for z/OS routesmessages to the defined error queue.

Note: PD/MQ does not have a default for the Error-handling-Q attribute. UsingMQSeries administrative interfaces, the MQSeries administrator can definean error-handling queue for a protected queue manager, if it does notalready exist. You must use MQSeries administration interface commands tocreate this queue as PD/MQ does not create it. See the publication, MQSeriesfor OS/390 V5R2: System Administration Guide, for a discussion of thecommand interfaces that may be used on z/OS and OS/390.

The Policy Director pdadmin command is used to set the extended attributes, suchas the Error-Handling-Q attribute. In the example shown below, replaceQueueManager with your actual queue manager name. The pdadmin commandshown below logs you on to Policy Director:pdadmin -a sec_master -p sec_master_ password

The pdadmin command responds with a prompt of pdadmin> if the logon toPolicy Director was successful. The pdadmin object modify command, as shownin the example below, enables you to set the error-handling queue name for thespecified queue manager.pdadmin>object modify /PDMQ/Queue/QueueManager-nameset attribute Error-handling-Q queue-name-of-PDMQ-error-handlingqueue

Note: Neither the pdadmin command nor the Policy Director Web Portal Managervalidates the name or value of the Error-handling-Q attribute, so be certainto enter it as it appears on the host as reported by MQSeries.

Example: In the context of this example, assume the password for the sec_masteradministrative account is cee5xda, and the OS/390 queue manager is MVS1, whichhas been defined previously. The error queue defined by the MQSeriesadministrator for this queue manager is PDMQ.ERROR.QUEUE. The administratorissues the following pdadmin commands:pdadmin -a sec_master -p cee5xdapdadmin> object modify /PDMQ/Queue/MVS1 set attribute Error-handling-QPDMQ.ERROR.QUEUE

Configuration Information for /PDMQ/Queue/QueueManager-name/Queue-nameIn defining the security policy associated for MQSeries queues, the administratormust determine the quality of protection appropriate for the protected queues.PD/MQ supports these quality-of-protection values:

privacy The contents of messages from applications, issued by way of


MQSeries, are signed and encrypted. The message is signed usingthe private key of the sender and encrypted using the certificate ofthe intended recipient.

integrity The contents of a message from an application, issued by way ofMQSeries, is cryptographically signed. This enables PD/MQ todetermine if the message was tampered with in transit. The originof the message is verified by PD/MQ.

none PD/MQ does not encrypt or cryptographically sign messages thatthe application issues.

The quality of protection as defined in the Protected Object Policy or POP isdiscussed in “Specifying the PD/MQ Protected Object Policy (POP)” on page 52. Itis discussed briefly here, as, depending on the quality of protection specified bythe POP, you may need to populate the Q-recipients extended attribute.

If a quality of protection desired for a given queue is privacy, which means thatthe message is encrypted, the PD/MQ administrator must set the followingextended attributes:Q-recipients =DN of recipientQ-enc-strength =STRONG/MEDIUM/WEAKQ-sig-algorithm =MD2/MD5/SHA1

Notes:

1. Q-enc-strength and Q-sig-algorithm must be specified only if you wish thevalues to be different from those you specified with the pdmqcfg utility.

2. If your installation plans to or has enabled the z/OS or OS/390 IntegratedCryptographic Service Facility (ICSF), Tivoli recommends that you change thevalue of Q-sig-algorithm from MD2 to either SHA1 or MD5, as thesealgorithms are supported by ICSF.

The extended attribute Q-recipients is the distinguished name of the intendedrecipient for the message delivered by MQSeries. The Q-enc-strength extendedattribute establishes the strength of encryption PD/MQ applies to thecryptographic protection associated with a given queue.

If the QoP of a message is integrity, Q-recipients and Q-enc-strength should notbe specified. The pdadmin commands to set these parameters are shown below. Ineach case, replace QueueManager and Queue with the actual queue manager andqueue names.

This pdadmin command authenticates the PD administrator whose account issec_master:pdadmin -a sec_master -p sec_master_password

The following pdadmin object modify command specifies the entry in theprotected name space and sets the extended attribute Q-recipients. This extendedattribute is the distinguished name (as defined in the certificate you created in“Creating the Certificates and Key Rings” on page 22) for an intended recipient formessages enqueued on the protected MQSeries queue:pdadmin object modify /PDMQ/Queue/QueueManager-name/Queue-name set attributeQ-recipients “CN=xxx;O=abc;C=us "

Note: When specifying distinguished names (DNs) in extended attributes, youmust use the following format:


v Component names (such as C, CN, O, OU) must be specified in uppercase.

v Each component must be separated by a semicolon (;).v You can add multiple recipients by repeating the pdadmin command that

sets the Q-recipients attribute.

The administrator issues the pdadmin object modify command for the secondintended recipient:pdadmin>object modify /PDMQ/Queue/QueueManager-name/Queue-nameset attribute Q-recipients "CN=yyy"

The PD/MQ administrator then establishes the strength of encryption that is usedto encrypt the application message:pdadmin>object modify /PDMQ/Queue/QueueManager-name/Queue-nameset attribute Q-enc-strength STRONG|MEDIUM|WEAK

The PD/MQ administrator then specifies the digital signature algorithm thatPD/MQ will use:pdadmin>object modify /PDMQ/Queue/QueueManager-name/Queue-nameset attribute Q-sig-algorithm MD2|MD5|SHA1

Note: Neither the pdadmin command nor the Policy Director Web Portal Managervalidate the attribute names or value of the Q-recipients attribute. Be sure toenter them correctly.

Example: Assume that the password for the sec_master administrative account iscee5xda, and the OS/390 queue manager is MQS1, which has been definedpreviously. The queue name is AUTHALL.QOPSEAL.APPL, which has also beenpreviously defined to the Policy Director protected object space.

The queue recipients are the distinguished names common name of user1, in theorganization of org, in the country of the United States (cn=user1, o=org, c=us)and the common name of user2, in the organization of org, in the country of theUnited States (cn=user2, o=org, c=us). Based on the installation’s security policy,the encryption strength for the queue is strong cryptography, and the signaturealgorithm specified is MD5.

The PD/MQ Administrator issues the following pdadmin commands:pdadmin -a sec_master -p cee5xda

object modify /PDMQ/Queue/MQS1/AUTHALL.QOPSEAL.APPLset attribute Q-recipients "CN=user1;O=org;C=us"

object modify /PDMQ/Queue/MQS1/AUTHALL.QOPSEAL.APPLset attribute Q-recipients "CN=user2;O=org;C=us"

object modify /PDMQ/Queue/MQS1/AUTHALL.QOPSEAL.APPLset attribute Q-enc-strength STRONG

object modify /PDMQ/Queue/MQS1/AUTHALL.QOPSEAL.APPLset attribute Q-sig-algorithm MD5


Defining Identities for ApplicationsPD/MQ for z/OS can be considered a resource manager that mediates access andenforces a quality of protection to MQSeries applications. In order for PD/MQ toenforce your installation’s security policy, PD/MQ must be able to deal with aform of identity: a user that wants to access a protected resource.

With RACF, the z/OS and OS/390 platforms have a strong concept of user identityin the z/OS user ID. RACF, along with the underlying operating system platform,manages an application’s security environment, which includes the identity or userID under which applications execute and access resources in a controlled manner.

PD/MQ and Policy Director Authorization Services augment the security providedby the z/OS operating system platform and RACF by adding a cross-platformidentity and access-control semantic.

In enforcing a security policy that spans the non-host to the host environment, it isimportant that a consistent view of identity is maintained as applications transitionbetween these environments.

This section focuses on the definition of identities as they apply to users andapplications on z/OS, and also on the non-z/OS view of a user or application’sidentity.

For each PD/MQ user, the PKI administrator, working with the securityadministrative staff, must:1. Create a Policy Director identity through the Web Portal Manager or with the

pdadmin commands.2. Map the Policy Director identity to the corresponding RACF-defined user ID

for z/OS- and OS/390-based applications.3. Request and store a digital certificate using RACF or a functionally-equivalent

product.4. Associate or map the PKI identity to a Policy Director identity.

Creating Policy Director Identities for UsersThe PD/MQ Administrator creates Policy Directory identities or valid PolicyDirector user accounts using the Policy Director Web Portal Manager. The LDAPPolicy Director user registry maintains a centralized registry that contains accountentries for all valid users that participate in the Policy Director secure domain. Inaddition to the valid user accounts, groups and other user-specific information ismaintained in the LDAP registry. The only type of registry that PD/MQ for z/OSsupports is an LDAP-based user account registry.

The LDAP Policy Director user registry, which may be resident off of the z/OSplatform, enables z/OS to become a participant in an existing Policy Directorsecure domain. If you wish, the LDAP user registry may reside on the z/OSplatform within the z/OS SecureWay LDAP directory server.

The steps to create a Policy Director user account are discussed in the TivoliSecureWay: Policy Director Web Portal Manager Administration Guide 3.8.


Mapping Policy Director Users to z/OS User IDsPD/MQ for z/OS must be able to translate or map between a Policy Director userID and the local host-based user ID. This enables PD/MQ to identify and thereforeauthenticate z/OS-based applications, and seamlessly translate between a user’shost identity and the corresponding Policy Director user ID. PD/MQ uses keyrings for the safe storage of certificates and keys, which are managed by the RACFcomponent of the host security infrastructure, and are dependent on the z/OS orOS/390 user ID.

The identity mapping information that enables PD/MQ to translate between aPolicy Director user ID and the corresponding z/OS user ID is maintained in theLDAP registry. In planning for the deployment of Policy Director AuthorizationServices, the administrative staff will have identified which z/OS users and PolicyDirector user IDs have been mapped in the LDAP registry.

In deploying PD/MQ for z/OS, Tivoli recommends that you determine the set ofhost-based user IDs that are authorized to use MQSeries-based applications, and asdiscussed in the previous paragraph, define Policy Director accounts, and set themapping between the host user ID and the corresponding Policy Director account.

Mapping Policy Director Users to z/OS and OS/390 HostIdentities

For new PD/MQ installations, which initially must define their Policy Directorprincipals in their LDAP-based user registry, either of the following methods maybe used:v If you use the Policy Director pdadmin user commands to create users, use the

same value for the username argument as the user’s host identity. For example,user Jane Doe’s host user ID is jmdoe, so fill in jmdoe as the value for User IDwhen defining the user’s Policy Director account to the LDAP user registry. Thisis an example of the command:pdadmin> user create jmdoe "cn=Jane Doe,o=ibm,c=us" "Jane Doe" jmdoe password

This procedure establishes a naming convention in which the user’s host identityand Policy Director user identity are the same user ID.

v If you use the Web Portal Manager to create users, use the same value for UserID as the user’s host identity. For example, user Jane Doe’s host user ID isjmdoe, so fill in jmdoe as the value for User ID on the Web Portal Manager“Create Policy Director User” screen, as shown in Figure 9 on page 38.


In both of these cases, the host identity is stored with the LDAP uid attribute forthe new user.

If you have already populated your user registry and just need to add the uidattribute to an existing directory entry, you can use the ldapmodify command toestablish the association between Policy Director users and their host identities.

For example, assuming you have an existing entry with a DN of cn=JaneDoe,o=org, to add a uid to this entry, you would provide the following LDIF intoan ldapmodify command:dn: cn=Jane Doe,o=org,c=uschangetype: modifyadd: uiduid: jmdoe

You can use the ldapmodify command on any supported platform. Refer to z/OS:SecureWay Security Server LDAP Client Programming for information about theldapmodify command.

How Certificates are Used by PD/MQIf the quality of protection for the protected queue specifies either integrity orprivacy, PD/MQ uses X.509 V3 digital certificates in the processing of MQSeriesmessages. Figure 10 on page 39, shows two applications, Application A executing

Figure 9. The “Create Policy Director User” Screen of Policy Director Web Portal Manager


on a z/OS host that is enqueuing messages to a protected queue. Application B,also executing on a z/OS host, is dequeuing messages off of the protected queue.For this example, assume that the quality of protection for the protected queue isprivacy, and that the appropriate administrative tasks have been performed.

The z/OS user ID of Application A is APLUSER. This user ID is defined to RACF,and a named key ring, drq.pdmq.keyring, is associated with that user ID. This keyring contains a certificate and a private key that PD/MQ will use in the protectionof messages PUT onto the protected queue by Application A.

Since the policy for this protected queue is privacy, the message is encrypted withthe intended recipient of Application B. The certificate that identifies Application Bmust reside in a key ring owned by the PD/MQ data services daemon. The z/OSuser ID of the PD/MQ data services daemon on this system is PDMQ. ThePD/MQ data services daemon has associated with the RACF user ID of PDMQ anamed key ring also, whose name is drq.pdmq.keyring. The certificate of therecipient (Application B) has been loaded in that key ring. In processing themessage originating from Application A, PD/MQ accesses the certificate andprivate key that identify Application A. PD/MQ also accesses the public key ofApplication B. Once the message has been protected, it is passed on to MQSeries.

From Application B’s perspective, the application issues a MQGET from theprotected queue. PD/MQ processes the MQGET by dequeuing a protectedmessage from the queue. In processing the protected message, PD/MQ determinesthat Application B is the intended recipient. The PD/MQ data services daemon,which is PDMQ1, uses the z/OS identity of Application B, RECPUSR, when itaccesses the named key ring drq.pdmq.keyring. It does this in order to useApplication B’s private key in the unprotection processing of the dequeuedmessage. In this flow, the certificate in PDMQ1’s key ring, which identifies themessage originator of APLUSER, is not used. However, if Application B were toissue a reply to Application A, then Application A’s certificate in PDMQ1’s keyring would be used in order to encrypt the reply for the recipient of Application A.

Application

A

UserID = APLUSER

MQPUT

PD/MQ MQSeries PD/MQApplication

B

MQGET

z/OS Security ServerRACF

RACF DBRACF UserProfile

APLUSER

RACF UserProfile

PDMQ Keyring for: APLUSERKeyring name: drq.pdmq.kingring

Keyring for: PDMQKeyring name: DRQ.PDMQ.KEYRING

CN=APLUSER,O=Myinsco

Private Key associated with Cert

UserID = RECPUSR

CN=RECPUSR,O=Myinsco

No Private Key associated with Cert

UserID = PDMQ

z/OS Security ServerRACF

Keyring for: RECPUSRKeyring name: drq.pdmq.keyring

Keyring for: PDMQ1Keyring name: drq.pdmq.keyring

CN=RECPUSR,O=Myinsco

Private Key associated with Cert

CN=APLUSER,O=Myinsco

No Private Key associated with Cert

RACF DBRACF UserProfile

RECPUSR

RACF UserProfile

PDMQ1

UserID = PDMQ1

Figure 10. How Certificates are Used by PD/MQ


This example illustrates the use of certificates by PD/MQ and their associationwith the platform identity of applications executing on z/OS and OS/390. Keep inmind that, although this example uses z/OS, the interoperability of PD/MQ spansthe set of non-mainframe platforms supported by PD/MQ. The primary differencewith respect to PKI, is in the tools and repository used by non-mainframeimplementations of PD/MQ.

For simplicity, in this example, we ignored the fact that there is another certificatethat comes into play. This is the CA certificate, which is used in validating theapplication certificates, certificates that are used in processing messages enqueuedor dequeued to protected MQSeries queues. The CA certificate must reside in az/OS or OS/390 RACF-managed key ring.

X.509 V3 Certificates and Key UsageThe key usage extension of an X.509 V3 digital certificate defines how the publickey contained within the certificate may be used. For example, a key usageextension of dataEncipherment indicates that the certificate may be used toencrypt user data.

PD/MQ and the underlying functions that use X.509 V3 certificates in theprotection of messages honor the key usage fields contained in the certificates thatrepresent users of applications. Whether or not you are using a host-basedcertificate provider, such as RACF, or a non-host resident certificate provider, suchas Tivoli PKI, keep in mind for what purpose the issued certificates will be used,that is, for message integrity or message privacy.

Certificates used by PD/MQ that are used for data integrity, must have the keyusage fields in the certificate set appropriately by the CA, that is for signingmessages, the key usage field must be set to nonRepudiation anddigitalSignature. For certificates used for data privacy, that is for encryptingmessages, the key usage field must also include the dataEncipherment andkeyEncipherment settings.

From a z/OS and OS/390 perspective, the certificates used by PD/MQ aremaintained in key rings associated with the RACF user IDs of message originatorsand receivers. And, for the recipients of messages originating on z/OS or OS/390,the certificates are maintained in a key ring associated with the PD/MQ dataservices daemon. The key rings used by PD/MQ are named drq.pdmq.keyring,whether associated with a user’s RACF user ID or the PD/MQ RACF user ID ofthe data services daemon. PD/MQ uses the certificate and private key of the userfor processing messages with integrity or privacy that are enqueued on z/OS orOS/390, and it uses the key ring of the data services daemon to obtain thecertificate of the intended recipients, based on the extended attribute Q-recipients,which is related to the protected queue.

Your installation’s security policy is probably not static. It changes based onbusiness need, and applications change to meet that business need. Therefore, tosimplify ongoing administration you may consider that for PD/MQ:v Certificate requests are filled by one CA, which serves both the non-host and

host (host meaning z/OS or OS/390) instances of PD/MQ-protected applicationsv All certificates are generated with the nonRepudiation, digitalSignature,

dataEncipherment, and keyEncipherment key usage fields set. This allows forchanges in policy, for example in which a queue whose messages are initially


subject to integrity checking later changing to privacy, without the need togenerate and populate another set of certificates with the appropriate key usagefields set for privacy.

If you are using RACF as the certificate generating mechanism, note that thenonRepudiation, digitalSignature, dataEncipherment, and keyEncipherment keyusage fields map to the following RACDCERT KEYUSAGE command operands:

HANDSHAKE Facilitates identification and key exchange duringsecurity handshakes, such as SSL. Sets thedigitalSignature and keyEncipherment indicators.

DATAENCRYPT Encrypts data. Sets the dataEnciphermentindicator.

DOCSIGN Specifies a legally binding signature. Sets thenonRepudiation indicator.

Additional information about the RACF RACDCERT command can be found in:v z/OS: SecureWay Security Server RACF Command Language Reference

v OS/390: SecureWay Security Server RACF Command Language Reference

Creating X.509 V3 Digital CertificatesPD/MQ for z/OS uses key database files or key rings, which are managed byRACF on z/OS or OS/390. Key rings are a named collection of certificates for aspecific user or server application used to determine the trustworthiness of a clientor peer entity. The PD/MQ product uses the certificates contained in key rings inthe protection processing of MQSeries messages sent from or received byapplications.

A user certificate is signed by a mutually trusted third party: a CertificateAuthority (CA). In order to validate the authenticity of a user certificate, thecertificate of the CA must be loaded in a key ring on the z/OS platform.

The CA may be a third party product, a service offering, or z/OS Security ServerRACF may be used to issue the certificates used by PD/MQ. In deciding whethera non-z/OS or non-OS/390 PKI is used in the deployment of PD/MQ on z/OS,consider:v For protected messages that originate from z/OS-based applications and users,

the private key associated with the user’s or application’s certificate must residein a z/OS-resident key ring.

v For message recipients residing off the z/OS platform when the messageoriginates on z/OS, the digital certificate of the intended recipient must beloaded (without the private key) into a key ring associated with the PD/MQdata services daemon.

v For message recipients residing on the z/OS platform, the private key associatedwith the recipient’s certificate must reside in a z/OS-resident key ring.

This section discusses the procedure for obtaining certificates for z/OS users andapplications. To create a certificate, the first step is to generate the public/privatekey pair and request a certificate from your PKI provider. In addition, thecertificate of the CA that issues the application or user certificate must be importedinto a RACF-managed key ring, and marked as a trusted root certificate.


There are three publications Tivoli recommends that you review to aid in yourunderstanding of how to manage, import, and generate certificate requests usingthe capabilities of RACF. These publications are:v z/OS: SecureWay Security Server RACF Security Administrator’s Guide

v z/OS: SecureWay Security Server RACF Command Language Reference

v OS/390 Security Server 1999 Updates: Installation Guide, SG24-5629-00

This last publication is a technical “red book” from IBM’s International TechnicalSupport Organization. This book contains a number of practical examples thatillustrate importing certificates into RACF. Tivoli recommends that this book beused to improve your understanding of how RACF manages digital certificates.The redbook can be obtained from the website: http://www.ibm.com/redbooks

Note: Certificates used by PD/MQ must have the key usage fields in the certificateset appropriately by the CA. In certificates used for integrity, that is, signingmessages, the key usage field must be set to nonRepudiation,digitalSignature, and keyEncipherment. In certificates used for dataprivacy, that is, encrypting messages, the key usage field must also includethe dataEncipherment and keyEncipherment settings.

Scenarios for Defining PKI OperationsThe scenarios shown here outline the steps required to set up the certificates usedby PD/MQ on z/OS or OS/390. These two scenarios focus on the z/OS host andthe steps required to associate certificates and private keys.

These scenarios assume the following:v The enterprise Myinsco.com is an insurance company. The company’s security

policy requires all applications that process insurance policy information useencryption when information is being sent or received from the z/OS host. Theinsurance policy database resides and is managed on the z/OS host.

v The MQSeries application that Myinsco.com uses on z/OS is a started task,which opens a well-known server queue and replies to client requests onwell-known application queues. In the context of this example, the term“well-known” implies that naming conventions are used in this request-replymodel application.

v For brevity, this scenario discusses only two users. One user accesses theMyinsco application directly through the z/OS host, and the other user accessesthe Myinsco MQSeries z/OS application though a client application that residesoff of the z/OS platform. The z/OS-based user is Ken Smith and thenon-resident z/OS user is Janet Jones.

v These employees of Myinsco work on a subset of the overall insurance policies,and this group of users are authorized to share policy information only amongthis set of two users. The z/OS user ID for Ken Smith is KSMITH. Janet Jonesdoes not have a z/OS user ID defined. Ken Smith and Janet Jones may beconsidered recipients of MQSeries traffic originated by each other.

v The z/OS resident queue manager has a connection to an off-platform queuemanager. The queue managers are ZMQ1 and QM_xseries, on z/OS and thedistributed platform (Windows NT) respectively.

Scenario 1 - Using a Host-Based Certificate AuthorityFor messages that originate on z/OS or OS/390, PD/MQ requires that thecertificates and private keys for the user generating the message be resident onz/OS or OS/390. Only the certificates of the intended message recipients have toreside in a PD/MQ-owned key ring.


For messages that originate off the z/OS or OS/390 platform, and whose intendedrecipients are users on, and defined to, z/OS or OS/390, the recipient’s certificateand private key must be stored on z/OS or OS/390 in a key ring associated withthe recipient’s z/OS user ID.

Given this requirement, and the sample scenario, the following steps are taken:1. If you have not already done so, create a local certificate authority certificate.

This certificate is used to sign certificates created for users and processes bothfor z/OS resident and non-z/OS resident applications.RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN('RACFCA') O('Myinsco') C('us'))KEYUSAGE(CERTSIGN) WITHLABEL('RACFCA')

2. For the systems and users that have certificate requests filled by RACF, connectthis CA certificate into the key databases (or key rings) for these users. Forz/OS users, use the RACDCERT command. For other platforms, export this asshown in step 4.RACDCERT ID(KSMITH) CONNECT(CERTAUTH(LABEL('RACFCA')RING(drq.pdmq.keyring))

3. For the z/OS user ID KSMITH, a key pair (public and private key) andcertificate are generated and stored in the named key ring drq.pdmq.keyringassociated with the z/OS user ID KSMITH.RACDCERT ID(KSMITH) GENCERT SUBJECTSDN(CN('KSMITH')O('Myinsco')C('us'))WITHLABEL('KSMITH') SIGNWITH(CERTAUTH LABEL('RACFCA'))KEYUSAGE(HANDSHAKE DATAENCRYPT DOCSIGN)

RACDCERT ID(KSMITH) ALTER (LABEL('KSMITH')) TRUST

4. Generate a key pair (public and private keys) and a certificate request for JanetJones on the system that this user will be accessing the PD/MQ-protectedapplications from. Export and transfer the certificate request to the z/OS orOS/390 system. The key usage fields dataEncipherment, keyEncipherment,digitalSignature, and nonRepudiation, of the certificate must be set. The z/OSsecurity administrator approves the certificate request for Janet Jones, and loadsthe generated certificate in the key ring drq.pdmq.keyring associated with thez/OS user ID of the PD/MQ data services daemon. The administrator thendownloads the completed certificate from the z/OS system to the system wherethe certificate request originated, and loads the key database with Janet’scertificate. Note that Janet’s private key resides only in the GSKIT key databaseon the system that this user accesses the PD/MQ protected applications from.

5. FTP the certificate request to a dataset. Generate the certificate using thisdataset.RACDCERT ID(ADMIN) GENCERT('jjones.certreq') SUBJECTSDN(CN('JanetJones')O('Myinsco')C('us')) WITHLABEL('jjones') SIGNWITH(CERTAUTH LABEL('RACFCA')) KEYUSAGE(HANDSHAKE DATAENCRYPT DOCSIGN)

RACDCERT ID(ADMIN) ALTER(LABEL('jjones')) TRUST

6. Connect the certificate containing Janet Jones’s public key to thepdmq.drq.keyring associated with the PD/MQ data services daemon ID.RACDCERT ID(PDMQ) CONNECT(ID(ADMIN)LABEL('jjones')RING(drq.pdmq.keyring)USAGE(SITE))

7. Export the certificate to a dataset in CERTDER format. Export the RACF CAcertificate to a dataset. FTP both datasets to the system on which the certificaterequest was created. Import both certificates to your key ring managementutility to complete the certificate request.RACDCERT ID(ADMIN) EXPORT(LABEL('jjones')) DSN('jjones.cert')FORMAT(CERTDER)


Once your key rings have been populated, see “Mapping PKI Identities to PolicyDirector Users” on page 45 for the next steps.

Scenario 2 - Using an Outboard Certificate AuthorityAn “outboard” PKI is a non-z/OS- or non-OS/390-resident public keyinfrastructure, which includes a certificate authority or CA. Some examples of anoutboard PKI are: Tivoli SecureWay Public Key Infrastructure and Entrust WebConnector PKI.

The basic steps are the same as in using a host-based CA, however, the mechanicsare different as you must ensure that the certificate requests and, whereappropriate, the keypairs, are loaded into host-managed key rings for users ofPD/MQ protected queues. As in Scenario 1, only the certificates of the recipients ofmessages originating from z/OS and OS/390 must reside in the key ringassociated with the user ID of the PD/MQ data services daemon.1. Upload the CA certificate from your PKI provider, and import this certificate

into RACF as a CERTAUTH (certificate authority certificate).2. FTP the Certificate Authority certificate to a dataset. Then import it.

RACDCERT CERTAUTH ADD ('Tivoli.PKI.CA')WITHLABEL('TIVOLICA') TRUST

3. For the z/OS user ID KSMITH, a key pair (public and private key) and acertificate are generated. Download and export this certificate request andsubmit it to the non-host resident PKI provider to approve and fill thecertificate request. The key usage fields dataEncipherment, keyEncipherment,digitalSignature, and nonRepudiation, of the certificate must be set.RACDCERT ID(KSMITH) GENREQ(LABEL('Tivoli Certreq')) DSN('KSMITH.CERTREQ')

4. Once the certificate request has been filled, upload and import the certificate tothe key ring drq.pdmq.keyring, which is associated with the z/OS user ID ofKSMITH.RACDCERT ID(KSMITH) ADD('KSMITH.GRANTED.REQ') WITHLABEL('KSMITH TIVCERT')PASSWORD('PW') TRUST

RACDCERT ID(KSMITH) CONNECT(ID(KSMITH) LABEL('KSMITH TIVCERT')RING(drq.pdmq.keyring) DEFAULT KEYUSAGE(PERSONAL))

5. Export the certificate for Janet Jones from the appropriate GSKIT key databasein PKCS12 format, and upload the certificate to z/OS. Load the certificateimported to z/OS in the key ring associated with the user ID of the PD/MQdata services daemon.RACDCERT ID(ADMIN) ADD('jjones.cert') WITHLABEL('jjones') PASSWORD('pw') TRUST

RACDCERT ID(PDMQ) CONNECT(ID(ADMIN) LABEL('jjones') RING(drq.pdmq.keyring)USAGE(SITE))

Once your key rings have been populated, see “Mapping PKI Identities to PolicyDirector Users” on page 45 for the next steps.

If you are using a non-z/OS or non-OS/390 PKI provider, see the documentationfor that product for the specific commands and interfaces required to generatecertificates. Additional information for the non-z/OS and non-OS/390 platform canbe found in the Tivoli: Policy Director for MQSeries Administration Guide 3.7.1. This isthe book for the product that runs on Solaris, Windows NT, and AIX.

Importing Application or End-User Certificates for EncryptionPD/MQ for z/OS has a requirement for messages that originate on, that is, areenqueued (PUT) to, MQSeries queues that have a policy that enforces encryptionof messages. The requirement is that the certificate and private key associated with


the user or application certificate reside in the user’s SAF-managed key ring on thez/OS or OS/390 host. PD/MQ assumes the local z/OS identity of the sender so itcan access the private key in the protection of a message. The certificate for theuser can be imported from a Web browser key ring, for example.

The z/OS: SecureWay Security Server RACF Command Language Reference, OS/390:SecureWay Security Server RACF Command Language Reference, z/OS: SecureWaySecurity Server RACF Security Administrator’s Guide and OS/390: SecureWay SecurityServer RACF Security Administrator’s Guide provide detailed guidance and examples,which may aid in your understanding of key rings, certificates and the steps toregister certificates with RACF.

Mapping PKI Identities to Policy Director UsersPolicy Director Authorization Services uses a Lightweight Directory AccessProtocol (LDAP) directory server to store user and group information. Figure 11shows a typical installation of Policy Director user and group information in anLDAP directory.

PD Information(secUser)

c=us secAuthority=Default

o=org

cn=Users

User Object(inetorgperson) UUID Mapping

(secMap)

cn=Groups

UUID Mapping(secMap)

PD Information(secGroup)

Group Object(accessGroup)

Figure 11. Policy Director User and Group Entries in an LDAP Directory


The secMap objects store links between a Policy Director user entry in the LDAPdirectory and the representation of the Policy Director user in the Policy directorauthorization database. The mapping model is illustrated in Figure 12.

The authorization database represents users (and groups) as Unique UniversalIdentifiers (UUIDs). When a user is created using the Policy Director Web PortalManager or the pdadmin command, the user is created in LDAP and theappropriate secMap object, and a UUID is also created with a pointer back to theuser entry in LDAP.

PD/MQ extends the secMap object to link a user’s certificate to the user’s PolicyDirector user entry. The extension is done by adding an auxiliary object to thesecMap object. This auxiliary object has an LDAP object class of secPKIMap. Therelationship between secMap and secPKIMap is shown in Figure 13 on page 47.

objectClass: secMaptop

c=us

cn=jon

o=org

cn=jon

SecDN: cn=user1, o=org, c=ussecUUID: 1034….3e12

10a34….3e12 T[PDMQ]ED

Authorization Database

10a34….3e12 T[PDMQ]ED

Authorization Database

Figure 12. The secMap Object Maps Policy Director User Entries to Authorization DatabaseInformation


The secCertDN attribute in the secPKIMap object contains the DistinguishedName (DN) of the user’s PKI certificate. When PD/MQ receives a PKI identity in acertificate, it searches the secMap objects to find the one whose secCertDNattribute matches the DN of the certificate.

Creating the secPKIMap Object Class in LDAPThe secPKIMap object class can be created using the IBM SecureWay DirectoryManagement tool, which is provided on the CD-ROMs that accompany the IBMPolicy Director Authorization Services for z/OS. Alternately, the secPKIMap objectclass can be created using the ldapmodify command, passing as input thepdmq.ldif file found in the PD/MQ sample directory.

If you have previously installed Tivoli Policy Director for MQSeries, you shouldverify that the secPKIMap object class has been defined to your LDAP directoryserver.

You must have administrative access to the LDAP server to add the secPKIMapobject class. Figure 14 on page 48 through Figure 16 on page 49 show the sequenceof steps to create this object class using the IBM SecureWay Directory Managementtool.

The first step is to create secPKIMap as an auxiliary object class, with a superiorobject class of secMap.

Notes:

1. The OID 1.3.6.1.4.1.4228.4.1 must be specified when creating the secPKIMapobject class.

2. For z/OS and OS/390 LDAP users: If you intend to have your Policy Directoruser registry for your PD/MQ installation reside in your z/OS or OS/390LDAP server, the directions for updating the LDAP schema are slightly

secDN: cn=user1, o=org, c=ussecUUID:1034....3e12

secCertDN:

Auxiliary objectclass

objectClass: secMaptopsecPKIMap

objectClass: secMaptopsecPKIMap

secCertDN:cn=user1, c=ussecDN:cn=user1, o=org, c=ussecUUID:1034....3e12

Standard objectclass

ObjectClass: secMaptop

ObjectClass: secPKIMap

Figure 13. Extending the secMap Object with secPKIMap


different. To update the schema, use the sample supplied pdmq.ldif file, whichis found in the /usr/lpp/pdmq/doc directory. Use the following command:ldapmodify -D admin_dn -w admin_pw -f pdmq.ldif

After filling in this panel, select the required attributes tab at the top of the frame.

Figure 14. Creating the Object Class

Figure 15. Adding secAuthority and secCertSerialNumber as Optional Attributes


Adding secPKIMap Objects to Existing secMap ObjectsThis task can also be performed using the Directory Management Tool (DMT). Thesteps are shown in Figure 17 through Figure 19 on page 51.

First, open the tree of objects. Then highlight a particular secMap object to beupdated. This object should be one for which you want to define a mappingbetween the Policy Director DN and the DN contained in the user’s certificate.Then click the “Add auxiliary class” button (Figure 17).

Figure 16. Updating the secPKIMap Object with the Certificate Data for this Policy DirectorUser

Figure 17. Browsing the Tree of Existing secMap Objects


You can also find a particular object using the Search capability of DMT, using theDN of the Policy Director user as the search key for the secDN attribute in the treeof secMap objects. Highlight secPKIMap in the list of available auxiliary classes.

The next step is to specify the secCertDN as a required attribute of secPKIMap, asshown in Figure 19 on page 51. Select the optional attributes tab, at the top of theframe.

On the Optional Attributes frame, select from the available attributessecCertSerialNumber and secAuthority as optional attributes. Select the OKbutton at the bottom of the frame to commit the definition of the secPKIMapobject class.

Figure 18. Attaching a secPKIMap Object to an Existing secMap Object


Finally, edit the secMap object entry (Figure 16 on page 49), entering thesecCertDN that matches the DN of the certificate for this Policy Director user.Commit your changes by selecting the “OK” push button.

Defining and Attaching Policy TemplatesThe protected namespace configured in PD/MQ represents the protected queues,which are resources created by MQSeries. Policy templates can be defined andattached to these queues.

The Protected Object Policy (POP) is used to specify the quality of protectionrequired on messages flowing through these queues as well as the audit level. Inaddition, Policy Director ACL permission bits are also used to specify who can putmessages to and get messages from a queue.

Authorization policy templates can be defined and applied using Policy Director.See the Tivoli SecureWay: Policy Director Base Administration Guide 3.7.1 for furtherinformation on defining policy templates.

Specifying Authorization for PD/MQ OperationsPD/MQ relies upon the Policy Director Access Control Lists (ACLs) to specify thefollowing permissions on MQSeries queues:

E Represents authority to enqueue messages on a given queue object; itauthorizes an entity to call the MQPUT API on the queue.

D Represents authority to dequeue messages on a given queue object; itauthorizes an entity to call the MQGET API on the queue.

Figure 19. Creating the Attributes of the secPKIMap Object Class


These permissions are PD/MQ specific. They are prefaced by [PDMQ]E (forenqueue), [PDMQ]D (for dequeue), or [PDMQ]ED (for both) in the Web PortalManager and the pdadmin commands. ACLs can be placed on queues, queuemanagers, or on the /PDMQ/Queues object.

This example creates an ACL (pdmqacl) and specifies that user1 has enqueueauthority to /PDMQ/Queue/queue_manager_name/queue_name.pdadmin>acl create pdmqaclacl modify pdmqacl set user user1 [PDMQ]Eacl attach /PDMQ/Queue/queue_manager_name/queue_name pdmqacl

Specifying the PD/MQ Protected Object Policy (POP)Quality of protection (QoP) defines how messages are cryptographically protected.POP defines these QoP attributes:

privacy Represents PRIVACY PROTECTION on all messages using thisqueue.

integrity Represents INTEGRITY PROTECTION on all messages using thisqueue.

none Represents NO CRYPTOGRAPHIC PROTECTION on messagesassociated with this queue. Asserting this QoP does not, in anyway, circumvent authorization enforcement on queue operations.PD/MQ ACLs are still enforced. NO CRYPTOGRAPHICPROTECTION is appropriate for MQSeries queues in whichapplication messages do not require cryptographic protection.

If you do not want any cryptographic protection, explicitly specify this by selectinga POP of none. If a queue in the Protected Object Space does not have a POPspecified, all messages sent to that queue are integrity-protected by default.

Note: You may consider overriding this default by specifying a QoP of noneinitially so that you can stage PD/MQ across multiple applications before allof the administrative steps have been completed. As administrative actions,such as obtaining certificates, and populating key rings, are completed, youcan then test the desired QoP by using the Policy Director administrativetools to alter the POP’s QoP. See Tivoli SecureWay: Policy Director BaseAdministration Guide 3.7.1.

For POPs that specify privacy, you must list queue recipients as extendedattributes of the queue in the Protected Object Space. This information is needed soPD/MQ can find the proper encryption keys for the recipients. If the PD/MQconfiguration data does not have the correct recipient names listed, the intendedrecipients are not able to read the message (because they are not able to decrypt it),in spite of having the right permissions to read messages off the queue.

Successfully sending a message and having it received depends on:v The sender being authorized to put (enqueue) the message on the queue, and

being able to correctly protect the message, as specified in the QoP in theprotected object policy associated with the protected MQSeries queue.

v The recipient being authorized to receive (dequeue) the message, and PD/MQbeing able to correctly validate (and if necessary decrypt) the message. Thevalidation performed by PD/MQ depends on the quality of the messageprotection as specified in the protected object policy. For example, if the QoP inthe protected object policy indicates that the messages on a protected MQSeries


queue are integrity checked, then during the dequeue process, PD/MQ must beable to validate that the message was not altered in transit.

Additionally, the POP controls the auditing specifically performed by PD/MQ. Theaudit level may be:

all PD/MQ produces an audit record for all MQPUTs and MQGETs.

none PD/MQ does not produce audit records for either MQPUT or MQGEToperations.

PD/MQ uses the z/OS and OS/390 System Management Facilities (SMF) as therepository for audit records that it produces, as does Policy Director AuthorizationServices. See “Chapter 8. Auditing PD/MQ for z/OS and OS/390” on page 77, fora discussion of the record types produced by PD/MQ on z/OS and OS/390.

ACL Evaluation and Queue Name ResolutionPD/MQ evaluates ACLs based on the target queue name for any MQOPEN,MQPUT1, and MQGET operations. When an application specifies a queue managerand queue name combination on a call to the MQOPEN API, PD/MQ may resolvethe queue manager-queue name pair to the destination queue manager-queuename pair. This is controlled by the Qname-resolution attribute associated with the/PDMQ object in the protected object space.

If the Qname-resolution attribute is set to local, PD/MQ uses the given queuemanager-queue name pair. If the Qname-resolution attribute is set to remote,PD/MQ resolves the queue manager-queue name pair to the destination queuemanager-queue name pair.

Note: PD/MQ for z/OS and OS/390 does not support the Qname-resolutionattribute of remote. PD/MQ uses only the given queue manager-queuename pair.

A PD/MQ ScenarioThe use of PD/MQ authorization policy with MQSeries messages can be furtherexplained by a scenario. Note that the following scenario depicts the behaviorexhibited in this release. For example, a user John on host tarzan, is using thequeue manager TARZAN.QM, and Jane on host homer is using HOMER.QM asthe queue manager.

John uses the remote queue OUT.HOMER.QUEUE (for MQPUT) and local queueIN.HOMER.QUEUE (for MQGET) to communicate with homer. Jane uses remotequeue OUT.TARZAN.QUEUE (for MQPUT) and IN.TARZAN.QUEUE (forMQGET) to communicate with tarzan. Both users list each other as recipients fortheir messages.1. Create the following ACLs:

v acl-to-john

Jane PDMQ:E

John PDMQ:Dv acl-to-jane

Jane PDMQ:D

John PDMQ:E


2. Next, create POP of msg-encr with a QoP set to privacy. Update the extendedattribute Q-recipients to specify the DN of John as a recipient for the queuesOUT.TARZAN.QUEUE and IN.HOMER.QUEUE.

3. Attach the ACLs and POP as follows:v /PDMQ/Queue/HOMER.QM/IN.HOMER.QUEUE

acl-to-john

POP msg-encr

This gives Jane the permission to send messages to this queue and John theauthority to get messages from the queue. Attaching the POP of msg-encrensures that all messages sent to the queue will be encrypted. TheQ-recipients attribute lists for whom the messages will be encrypted.

v /PDMQ/Queue/TARZAN.QM/IN.TARZAN.QUEUE

acl-to-jane

POP none

This gives John the permission to send messages to this queue and Jane theauthority to get messages from the queue. Since there is no POP associatedwith the queue, messages are integrity-protected, and no audit records aregenerated.

In the first scenario, John sends a message to Jane on OUT.HOMER.QUEUE.PD/MQ resolves OUT.HOMER.QUEUE to IN.TARZAN.QUEUE.

The ACL permits John to write to the remote queue. John sends the messagewithout any privacy or integrity protection because the target queue for recipientJane does not require any cryptographic message protection on incoming messages.The quality of protection requirements are met. PD/MQ forwards the message toJane’s application. Jane can read John’s message.

Now, let us consider the case where Jane sends messages to John onOUT.TARZAN.QUEUE. PD/MQ resolves OUT.TARZAN.QUEUE toIN.HOMER.QUEUE.

Jane has permission to enqueue messages on the remote queue. PD/MQ does notforward an incoming message to John’s application unless it is privacy protected.This implies integrity too. On Jane’s end, PD/MQ digitally signs the message andalso sends Jane’s certificate along with the message. Because John mandatesconfidentiality on incoming messages, Jane’s message is encrypted before beingsent so that only John can read it (assuming of course that only John has beenmade the recipient). John must be listed in the recipient list in the extendedattributes.


Chapter 5. MQSeries and Application EnvironmentConsiderations

PD/MQ for z/OS and OS/390 does not require direct changes to an application’suse of MQSeries services. This section discusses a set of considerations, whichrelate to both MQSeries and the applications that you choose, to the additionalprotection that PD/MQ provides.

PD/MQ for z/OS and OS/390 Interaction with MQSeries AuthorizationMQSeries on z/OS makes extensive use of a SAF-compliant security manager, suchas RACF. RACF provides excellent control over the use of MQSeries services onthe local z/OS or OS/390 platform.

PD/MQ augments the protection provided by RACF by adding a “distributed”facet, in which access to queues and protection of the application messages isretained within a queue manager, and as the messages traverse your MQ“network.” This is true whether the message originates on another z/OS orOS/390 host instance, or from a non-z/OS or non-OS/390 queue manager. PD/MQcan consistently, across platforms, enforce access control and a quality of protectionassociated with your application’s messages as applications use MQSeries tofacilitate cross-platform, cross-application communication.

The authorization applied by PD/MQ for z/OS does not replace the authorizationthat MQSeries supplies using RACF, but rather enhances it. PD/MQ, as does theunderlying Policy Director Authorization Services, utilizes RACF to leverage thestoring of configuration information, and in the case of PD/MQ, it uses SAF-basedkey rings exclusively for the storage of certificates and keys.

Access to protected queues is first checked by PD/MQ, and if granted by PD/MQ,is then checked by the queue manager. Thus, MQSeries administrators assignpermissions to queues both through PD/MQ and MQSeries to ensure that aprotected queue can be accessed, with PD/MQ providing a consistency acrossoperating systems and platforms.

Managing MQSeries with respect to the definition of MQSeries resources andsecurity considerations are discussed in depth in MQSeries for OS/390 V5R2: SystemSetup Guide and MQSeries for OS/390 V5R2: System Administration Guide, which areavailable at http://www.ibm.com/software/ts/mqseries/library/manualsa/.

Dynamic Queues, Generated Names, and PD/MQThe model queue object defines a set of queue attributes that are used as a templatefor a dynamic queue. Dynamic queues are created by the queue manager when anapplication makes an open queue request specifying a queue that is a modelqueue. The dynamic queue that is created in this way is a local queue whoseattributes are those of the model queue.

From an MQSeries perspective, you can specify a name (in full) for the dynamicqueue, or the stem of a name (for example, ABC*) and let the queue manager adda unique part to this, or you can let the queue manager assign a complete uniquename for you. Dynamic queues can be of two types:


Temporary This type of queue is deleted when the queue isclosed, and does not survive a restart of a queuemanager. The queues can be used to storenonpersistant messages only.

Permanent This type of queue is not deleted when the queueis closed, unless the application programspecifically requests it to be deleted. The queuesurvives a restart of a queue manager, and can beused to store persistent and nonpersistantmessages.

From a security policy enforcement perspective, PD/MQ does not make adistinction between temporary or permanent dynamic queues. In general, fordynamic queues, PD/MQ uses the model queue name from which the dynamicqueue was created when retrieving policy from the Policy Director protected objectnamespace. (See also, “How PD/MQ Detects Dynamically-Generated Queues” onpage 57.) This is significant because:v For all dynamic queues created from a given model queue, if a data protection

policy of privacy has been specified, then the list of recipients must include allpossible recipients for all queues than can be created from the model queue thatis defined to Policy Director.

v For all dynamic queues created from a given model queue, PD/MQ usesauthorization information associated with the model queue in resolvingauthorization decisions. Therefore, the ACL associated with the model queuemust contain the complete set of authorized users that can accessapplication-created instances of that model queue.

Note: PD/MQ for z/OS does not provide protection, or data protection, for queuenames (including those for model queues) that begin with the reserved highlevel qualifier (HLQ) of SYSTEM.

Depending on the number of applications that are PD/MQ enabled and that usedynamic queues created from a given model queue, you may consider addingadditional model queues in order to subset the list of recipients. This isrecommended if you are enforcing a data protection policy of privacy and haveauthorized users that must be maintained for a given model queue.


Figure 20, illustrates a simplified request-reply application in which a clientapplication defines a dynamic queue and enqueues a message to a serverapplication specifying that the sever should respond to the client’s request on areply-to queue and reply-to queue manager. As discussed above, the policy for theclient’s dynamically-created queue is derived from the model queue from which itwas created.

From the server’s perspective, when the client’s message is dequeued from theserver’s queue and subsequently processed, PD/MQ keeps track of the modelqueue name that was used to create the client’s dynamic queue. This relationshipis maintained so that when the server replies through an MQPUT1 or MQOPEN,MQPUT, or MQCLOSE to the client, PD/MQ is able to apply consistent policy andquality of protection, which is obtained from the model queue name.

PD/MQ for z/OS and OS/390 retains these relationships for a period of time andchecks for unused entries. These mappings of dynamic queue to model queue havea system-level scope, which means that PD/MQ is able to enforce a consistentsecurity policy even if one application dequeues a client’s message, and relays themessage to another application, which then responds. The fixed period of time isapproximately one hour after a dynamic-to-model queue entry has been cached byPD/MQ on z/OS or OS/390. This time interval is important if you haveapplications that utilize dynamic queues and have a response-latency time greaterthan one hour. In this case, you should consider not using PD/MQ to protect themodel queues for these applications. Once the dynamic-to-model queue cacheentry has been purged, PD/MQ for z/OS is unable to associate the correct policyto the dynamic queue.

How PD/MQ Detects Dynamically-Generated QueuesPD/MQ intercepts a subset of the MQSeries programming services issued byPD/MQ-enabled applications. A dynamic queue is recognized during the

Application

A

MQPUT

PD/MQ MQSeries

Application

B

MQGET

Client Server

MQPUT1

MQSeriesPD/MQ

PD/MQ

PD/MQ

Client PUTsmessage withreply-to queuecreated in firststep

Client createsdynamic queuefor reply

Client GETsresponse fromdynamic queue

Server opensIts messagequeue andwaits formessages

Server issuesMGET to pull amessage offIts queue.Reply-to queueand queuemanagerspecified

Server processesmessage

Server issuesMQPUT1 of theresponse;specifies reply-toqueue and queuemanager

Dynamic Queue Model queue

YYYYXXXX

Figure 20. Request-Reply Application Example

Chapter 5. MQSeries and Application Environment Considerations 57

processing of an MQOPEN invocation when the queue name specified by theapplication differs from the actual queue name, as returned by MQSeries duringthe processing of the MQOPEN invocation, and a model queue name has beenspecified on the MQOPEN invocation.

If a dynamic queue is detected, then PD/MQ uses the model queue name whenobtaining policy, which determines the authorization and data protection policy. Inaddition, PD/MQ caches the relationship between the dynamically-generatedqueue name and the model queue. Subsequently enqueuing messages to thedynamic queue causes PD/MQ, during its processing of the application’s message,to include information so that the remote PD/MQ instance can enforce a consistentsecurity policy.

If your application uses dynamic queues, and fully specifies the queue name,which is therefore not changed by MQSeries during MQOPEN processing, thenyou must define the actual queue names that the application uses to the PolicyDirector protected object space. PD/MQ attempts to obtain policy from the actualapplication queue name, not the model queue.

Application Environments and Enabling for PD/MQThis release of PD/MQ for z/OS and OS/390 supports the following applicationenvironments:v z/OS and OS/390 UNIX System Services environmentv z/OS and OS/390 batch applicationsv CICS Transaction Server Version 1 Release 3 for z/OS or OS/390

Note that in the CICS environment, applications that use the CICS bridge are notsupported by PD/MQ for z/OS and OS/390.

Enabling Applications for PD/MQ in the UNIX System ServicesEnvironment

The z/OS and OS/390 UNIX System Services applications that run in the UNIXSystem Services shell environment and that use MQSeries can be protected byPD/MQ.

For example, assume that an application that uses MQSeries services is to beprotected by PD/MQ, after the appropriate administrative setup has beencompleted. The application environment requires a STEPLIB statement to invokethe PD/MQ interceptor logic before the MQSeries-supplied code. Assuming thePD/MQ interceptor resides in the cataloged dataset, DRQ.SDRQAUTH, thecommands that follow can be used to define the STEPLIB to invoke the PD/MQinterceptor.

In this example, display the contents of the STEPLIB shell environment variable towhich the shell responds that no steplibs are defined:$echo $STEPLIB

Export the STEPLIB DRQ.SDRQAUTH and verify that the shell environmentvariable has been set:$ export STEPLIB=DRQ.SDRQAUTH$ echo $STEPLIBDRQ.SDRQAUTH$


In addition to the STEPLIB, the application program must reside in anAPF-authorized library. If your application program resides in the HFS, your UNIXSystem Services administrator or security administrator can mark the HFS files thatthe application resides in, as APF-authorized using the extattr UNIX SystemServices command.

BPXBATCH is an MVS utility that you can use to run shell commands or shellscripts and to run executable files through the MVS batch environment. You caninvoke BPXBATCH:v In JCLv From the TSO/E READY promptv From TSO CLISTs and REXX execsv From a program

MQSeries applications that run in the BPXBATCH utility environment also musthave a STEPLIB statement added to the JCL so that the PDMQ interceptor logic isinvoked, instead of the normal MQSeries product libraries. Also, the BPXBATCHapplication program, if it does not reside in the HFS, must reside in anAPF-authorized dataset.

More information can be found in the z/OS and OS/390 libraries that giveguidance and customizing information for the UNIX System Services environment.The publications listed below provide both planning and usage information thatyou may find useful:v z/OS: UNIX System Services Planning

v z/OS: UNIX System Services Command Reference

v OS/390: UNIX System Services Planning

v OS/390: UNIX System Services Command Reference

In addition, the following MQSeries publications may assist in setup andadministration of MQSeries applications and application environments:v MQSeries for OS/390 V5R2: System Setup Guide


Enabling BATCH and BATCH-RRS Applications for PD/MQSimilar to UNIX System Services applications, applications that use either the batchMQSeries adapter or the Batch-RRS MQSeries adapter must:v Reside in an APF-authorized library, although the executable application code

does not have to be link edited AC=1.v Include a STEPLIB statement in the JCL that runs the application. This statement

must be prior to any MQSeries libraries to invoke the PD/MQ interceptor loadmodules.

Here is an example://STEPLIB DD DSN=thlq.DRQ.SDRQAUTH,DISP=SHR

Enabling CICS Transactions that Use the MQSeries-CICSAdapter for PD/MQ

CICS applications or transactions are not individually enabled for PD/MQ. Ratherall CICS transactions that run within the MQSeries-CICS adapter become PD/MQenabled because the MQSeries-CICS adapter manages the MQSeries connections.


This requires some additional and careful planning considerations, since thegranularity of PD/MQ enablement affects all transactions that utilize the MQSeriesCICS adapter.

Before proceeding, you must ensure that CICS transactions that use MQSeries havebeen reviewed so that youknow which users of the MQSeries messages arehost-based and which are not. This knowledge is important for planning thesecurity policy, and if privacy of the messages is used, in understanding andadministering the list of recipients for messages that originate on the z/OS orOS/390 platform.

Once the planning and administration has been completed, similar to the batch,batch-RRS, TSO/E and UNIX System Services environment, add a STEPLIBstatement to the JCL procedure used to start the MQSeries-CICS adapter. Be surethis statement is before any MQSeries libraries. Once the JCL has been modified,you must start or restart the MQSeries-CICS adapter.

For more information on the MQSeries-CICS adapter see:v MQSeries for OS/390 V5R2: System Setup Guide


MQSeries Limitations and Unsupported ConfigurationsPD/MQ for z/OS and OS/390 Version 3.7.1 does not support the followingMQSeries configuration options:v Channel conversion exitsv Cluster workload balance queuesv Use of Message Reference Header messages (MQRMH)v Protection for queue names that begin with the reserved high level qualifier

(HLQ) of SYSTEMv Earlier releases of MQSeries for OS/390. Releases prior to MQSeries 5.2 for

OS/390 are not supported. See “PD/MQ for z/OS and OS/390 InstallationPrerequisites” on page 7 for prerequisite product restrictions.

Limitations to Supported EnvironmentsThis initial release of PD/MQ for z/OS and OS/390 does not support thefollowing application execution environments:v The CICS bridgev The CICS mover

Once you start the PD/MQ daemon processes, if you inadvertently cancel them, allsubsequent MQCONN, MQOPEN, MQGET, MQPUT, and MQPUT1 operations willfail with a security authorization failure. If protected queues are being using by theMQSeries-CICS adapter, this requires the PD/MQ server and data services daemonprocesses to be started (or restarted) before the MQSeries-CICS adapter is restarted.These PD/MQ processes must be executing before applications can use MQSeriesservices that are intercepted and processed by PD/MQ. See “PD/MQPost-Installation Tasks” on page 8 for more information.


PD/MQ and Maximum Message SizesOne of the attributes an MQSeries administrator can set on a queue or queuemanager is the maximum message length that MQSeries accepts. ThisMaxMsgLength attribute indicates the longest (physical length) message that canbe put on a queue. Your MQSeries administrators can set a maximum messagelength, based on their knowledge of the applications using MQSeries in your shop.

Since PD/MQ increases the size of messages by adding security information to themessage, such as the certificate of the originator, and data that encapsulates theintended recipients for the message. Some of the security information that PD/MQadds is variable in length. For example, X.509 V3 digital certificates are not all thesame length; the subject distinguished name may differ between certificatesdepending on the naming hierarchy that an installation uses. The length of the CAdistinguished name may also vary, depending on which CA the installation selects.Depending on the number of recipients for a protected message, additionaloverhead is added for each recipient.

The variable length of the data used in the PD/MQ protection processing ofmessages means that only guidelines can be offered for the MQSeries administratorwhen establishing or revising the maximum message length attribute of PD/MQprotected queues or queue managers. The maximum message length for protectedMQSeries queues should take into consideration the maximum known applicationmessage length plus the overhead which PDMQ adds in its processing.

Depending on the “headroom” that the MQSeries administrator has set, it ispossible that a PD/MQ encapsulated message may exceed the MaxMsgLengthlimit and cause a message to be rejected with an MQSeries return code ofMQRC_MSG_TOO_BIG_FOR_Q or MQRC_MSG_TOO_BIG_FOR_Q_MGR. Toaddress this, MQSeries administrators should increase the value of MaxMsgLength.

The MQSeries administrator should increase the value of MaxMsgLength forqueues or queue managers that are subject to PD/MQ protection, based on thefollowing approximation. For a given message:New Message Size = 1280 + OML + (200 x NOR)

where OML is the original message length and NOR is the number of recipients.

Here is an example of how you might calculate this. Assume that:v The original message length is 8 bytes.v The number of recipients is 2.

This yields:New Message Size = 1280 + 8 + (200 X 2)New Message Size = 1688 bytes

From an MQSeries administrator’s perspective, knowing the maximum messagelength enqueued or dequeued from protected queues and the maximum number ofrecipients, enables the administrator to approximate the largest protected messagethat PD/MQ can enqueue or dequeue. This approximation can then be increasedto plan for message size growth, as applications change or additional recipients areadded.

This plan for growth is at the installation’s discretion, based on your knowledge ofthe applications, the frequency of change in terms of message content, and thenumbers of recipients of those messages. Based on these approximations, plus a


contingency factor, you should determine for a given queue or queue manager ifthe maximum message limit will be exceeded.


Chapter 6. Error Handling in PD/MQ for z/OS and OS/390

PD/MQ for z/OS routes any incorrect messages received to an error-handlingqueue. Incorrect messages are those with one or more of the following conditions:v Sender did not have the authority to write to the queue.v The sender’s certificate was not valid.v The message was sealed (encrypted) and PD/MQ was unable to decrypt the

message.v A policy mismatch occurred. For example, the sender used integrity instead of

the expected quality of protection of privacy, or used the wrong algorithm.v The message was sent without PD/MQ encapsulation from a host that did not

have PD/MQ installed or properly configured.

Note: PD/MQ does not issue any warnings if an application sends a message to aqueue using an expired certificate. However the recipient will be unable toretrieve the message from the queue, and the message will be placed on theerror queue.

A dead-letter queue (DLQ) is a holding queue for messages that cannot bedelivered to their destination queues. MQSeries recommends that every queuemanager in a network have an associated DLQ.

PD/MQ requires that you define an error queue that can be used for routingmessages that cannot be processed due to an error condition. If you do not definea custom error queue, PD/MQ will route messages that cannot be processed to thedead letter queue (DLQ) defined by the local queue manager.

All messages that cannot be processed by PD/MQ are prefixed with the MQSeriesdead-letter header structure, MQDLH. PD/MQ fills in the MQDLH header withthe following information:v Reason code field. The reason code field of the MQDLH structure contains a

reason code that identifies why the message is on the error queue you havedefined.

v Original destination queuev Original destination queue managerv Original message’s coded character set Id (CCSID)v Original format namev Original application typev Original application namev Date and time in GMT (Greenwich Mean Time)

You should have a routine that runs regularly to process messages on either theerror queue that you have defined or the MQSeries-supplied default dead-letterqueue called CSQUDLQH. A user-written rules table supplies instructions to theDLQ handler, for processing messages on the DLQ. That is, the DLQ handlermatches messages on the DLQ against entries in the rules table. When a DLQmessage matches an entry in the rules table, the DLQ handler performs the actionassociated with that entry. For more information on the processing provided by theMQSeries CSQUDLQH dead-letter-queue-handling utility, see the publicationMQSeries for OS/390 V5R2: System Administration Guide.


When PD/MQ sends a message to the error-handling queue, PD/MQ returns theMQCC_WARNING return code and the MQRC_SUPPRESSED_BY_EXIT reasoncode to the application.

PD/MQ will attempt to write the complete message to the error queue. Whendefining this error queue to MQSeries, be sure to take into consideration theguidelines discussed in “PD/MQ and Maximum Message Sizes” on page 61. IfPD/MQ is unable to write to the error queue, the message will be lost.


Chapter 7. Messages for PD/MQ for z/OS and OS/390

This chapter documents the PD/MQ messages.

PD/MQ ABEND CODES

Here are the codes that PD/MQ issues in the case of an abend.

Table 3. PD/MQ Abend Codes

201 PD/MQ unrecoverable error abend code

Reason Code Constants

1 Unable to obtain storage for common anchor block (CAB), an internal controlstructure used by PD/MQ

2 Unable to obtain storage for server anchor block (SAB)

3 Server not running in correct protect key

Any of these abend codes indicates that an internal error has occurred. Yourresponse should be to follow your local procedure for obtaining support.

DRQZD0001I Environment variable variable-name hasinvalid value - value. Using defaultvalue value.

Explanation: When the PD/MQ data services daemonwas started, an invalid value for one of theenvironment variables was encountered indrqdserv.envars. The daemon was started using thedefault value.

User Response: If the default value is not satisfactory,correct the environment variable value and restart thedaemon.

DRQZD0002I Data services initialization complete.

Explanation: Initialization of the data services daemonis complete.

User Response: None

DRQZD0003I Data services shutdown requested.

Explanation: An operator STOP command wasentered to shut down the data services daemon.

User Response: None

DRQZD0004I LOG option processed: option

Explanation: The Log option specified in the messagewas processed when the data services daemon wasstarted.

User Response: None

DRQZD0005I Incorrect LOG option specified.

Explanation: An operator MODIFY command wasentered with keyword LOG.

User Response: Correct the log option and restart theserver.

DRQZD0006I Unrecognized Data Services command:Specify LOG, DISPLAY, or STOP.

Explanation: An operator MODIFY command wasentered with an invalid keyword.

User Response: Enter the MODIFY commandspecifying LOG, DISPLAY, or STOP: FPDMQD,DISPLAY.

DRQZD0007E Insufficient storage available.

Explanation: The data services daemon is unable tostart due to insufficient storage.

User Response: Correct the command option andretry the request.

DRQZD0009I Tivoli Policy Director/MQ dataservices starting, level product-level.

Explanation: The data services daemon has started inresponse to an operator START command.

User Response: None


DRQZD0011I Data services address space could notbe made non-swappable: Error error-code

Explanation: An attempt to make the data servicesaddress space non-swappable has failed with theindicated sysevent transwap return code.

User Response: Use the return code to diagnose thesource of the error.

DRQZD0013I Data services detected an error duringinitialization: Error error-code, Reasonreason-code

Explanation: An error has occurred initializing thedata services daemon. The message indicates the errortext and reason code.

User Response: Use the reason code to determine thesource of the error.

DRQZD0014I Data services detected an error duringtermination: Error error-code, Reasonreason-code

Explanation: An error has occurred duringtermination of the data services daemon. The messageindicates the error text and reason code.

User Response: Use the reason code to determine thesource of the error.

DRQZD0015I Data services program call requestfailed: Error error-code

Explanation: The data services daemon hasunsuccessfully processed a client request with theindicated return code. The request has failed.

User Response: Additional messages may be issueddescribing the source of the error.

DRQZD0016I Data services runtime environmentfailed to initialize.

Explanation: The data services daemon hasunsuccessfully processed a client request with theindicated return code. The request has failed.

User Response: Additional messages may be issueddescribing the source of the error.

DRQZD0017I Data services already active.

Explanation: The data services daemon has not startedsince it is already active.

User Response: None

DRQZD0018I Data services initialized failed,program not APF authorized.

Explanation: The data services daemon has not startedbecause it is not APF authorized.

User Response: Verify that DRQ.SDRQLOAD is APFauthorized. If a STEPLIB is present in the data servicesJCL, verify that all libraries in the STEPLIBconcatenation are APF authorized.

DRQZD0020I Data services ARM registrationcomplete for element type elem-type,element name elem-name.

Explanation: The data services daemon hassuccessfully registered with ARM with the indicatedelement type and name.

User Response: None

DRQZD0021I Data services ARM restart in progressfor element type elem-type, element nameelem-name.

Explanation: The data services daemon is beingrestarted by ARM using the indicated element type andname.

User Response: None

DRQZD0022I Data services ARM registration failed:Error error-code, Reason reason-code

Explanation: The data services daemon attempted toregister with ARM with the indicated element type andname. The attempt failed with the indicated return andreason codes from the IXCARM macro.

User Response: None

DRQZD0023I Data services failed to format thedisplay message.

Explanation: An error occurred formatting a dataservices daemon error message. The message was notissued.

User Response: Follow your local procedures forcontacting IBM for support.

DRQZD0025I Data Services settings: setting-values

Explanation: In response to an operator displaycommand, the data services daemon shows the currentsettings. The values for message level and loggingsettings are shown. In addition, the number of currentthreads started and requests pending is displayed.

User Response: None


DRQZD0029E Unable to create security environmentfor user userid, reason reason-code:reason-text

Explanation: The data services daemon was unable toestablish a security environment using thepthread_security_np service for the indicated user ID.The reason code and reason text describe the error. Thecurrent request failed.

User Response: See the z/OS C/C++ Run-Time LibraryReference, SA22-7821, for the description of thepthread_security_np service and its error reason codes.Use the reason code to determine the source of theerror.

DRQZD0030I Unable to delete security environment,reason reason-code: reason-text

Explanation: The data services daemon was unable todelete a previously established security environmentusing the pthread_security_np service for the indicateduser ID. The reason code and reason text describe theerror.

User Response: See the z/OS C/C++ Run-Time LibraryReference, SA22-7821, for the description of thepthread_security_np service and its error reason codes.Use the reason code to determine the source of theerror.

DRQZD0031E Data services not started, product isnot enabled.

Explanation: The PD/MQ data services daemon hasattempted to register its invocation, but the registrationhas failed. The daemon was not initialized.

User Response: Check the ISFPRDxx member ofPARMLIB for a correct entry for PD/MQ.

DRQZD0032E Data services product deregistrationfailed, rc=return-code.

Explanation: Product deregistration serviceIFAEDDRG has failed with the indicated return code.

User Response: Use the return code to find the sourceof the error.

DRQZS0101E Internal error occurred in modulemodule, reason code reason-code.Additional information:additional-information

Explanation: An error occurred in PD/MQ or in asystem service required by PD/MQ.

User Response: Use the reason code and additionalinformation (if any) to determine the cause of the error.

The reason codes are:

104 The SVT for the server failed a validity check.

105 A call to the IFAEDREG service failed.

106 A call to the IFAEDDRG service failed.

130 The level was invalid for the name/tokenservice.

131 The persist indicator was invalid for thename/token service.

132 A name/token service call has terminated withan error.

143 The IXCARM ready service has failed.

144 A field being added to an SMF record exceedsthe length of the buffer or the maximumallowable length.

176 An error occurred during the AXSET service.

178 An error occurred establishing an ESTAE.

179 An error occurred deleting an ESTAE.

180 An error occurred during the ATTACH service.

182 An error occurred attempting to ENQ aresource.

184 An error occurred attempting to DEQ aresource.

185 The CIB contained an unexpected commandverb.

186 An error occurred during execution of theQEDIT service.

187 An error occurred creating a resourcetermination manager.

188 An error occurred deleting a resourcetermination manager.

189 An error occurred obtaining the current tasktoken.

192 An error occurred attempting to issue anETDES service.

211 TCB address not found in task managementtable.

303 A request level is not supported by the currentversion.

304 A logging audit code has been provided but isnot recognized as valid.

511 An invalid parameter value was detected by aroutine.

512 An invalid function code was detected by aroutine.

518 A control block name was missing or invalid

519 A control block length was missing or invalid.

530 An error occurred during execution of theSTIMERM service.

Chapter 7. Messages for PD/MQ for z/OS and OS/390 67

531 An error occurred during execution of theSTIMER service.

532 An error occurred during execution of theTTIMER service.

555 An error occurred in setting the CIB countusing QEDIT.

557 The LX system token contains an invalid LXvalue.

558 Unable to reserve a system LX.

559 Unable to create entry table.

560 Unable to connect entry table.

561 The ALESERV extracth service has failed.

576 Unable to insert a node in a linked list.

577 An error occurred during processing of aDETACH macro.

578 Unable to delete a node from a linked list.

583 Unexpected token passed to a parse actionroutine.

584 Unrecognized parse token.

DRQZS0106W SDUMP error occurred in modulemodule, return code return-code, reasoncode reason-code.

Explanation: An error in taking an SDUMP occurredin the indicated module with the indicated return andreason codes.

User Response: Use the return and reason codes todetermine the cause of the error.

DRQZS0112E

PDMQ abend codereason reason-codeModule module-nameoffset offsetlevel maintenance-levelPSW pswCAB cabcontents of registers

Explanation: PD/MQ abended with the user orsystem abend code abend code. User abend codes are indecimal; system abend codes are in hexadecimal.

User Response: The system programmer should seeTable 3 on page 65, “PDMQ Abend Codes, “ forinformation on the user abend codes, or theappropriate system codes manual for information onthe system abend codes.

DRQZS0116E Resource manager register failed,return code return-code.

Explanation: The server attempted to register with theresource manager CRGGRM. The attempt failed withthe indicated return code.

User Response: Use the return code to diagnose theproblem.

DRQZS0117E Resource manager unregister failed,return code return-code.

Explanation: The server attempted to unregister withthe resource manager CRQDRM. The attempt failedwith the indicated return code.


DRQZS0118E Resource manager set exit informationfailed, return code return-code.

Explanation: The server attempted to set an exit forthe resource manager CRGSEIF, which failed with theindicated return code.


DRQZS0119E SMF recording failed, SMFEWTMreturn code return-code.

Explanation: Writing of an SMF record failed.

User Response: Use the return code from theSMFEWTM macro to diagnose the problem.

DRQZS0137I SDUMP not taken, suppressed byDAE.

Explanation: PD/MQ attempted to take an SDUMP,but it has been suppressed by the Dump Analysis andElimination (DAE) component.

User Response: None

DRQZS0161E Delete current context failed, returncode return-code.

Explanation: The CTXRCC service attempted to deletethe current context, which failed with the indicatedreturn code shown in hex.


DRQZS0162E Retrieve current context failed, returncode return-code.

Explanation: The CTXRCC service attempted toretrieve the current context, which failed with theindicated return code shown in hex.



DRQZS0163E Express context interest failed, returncode return-code.

Explanation: The CTXEINT1 service attempted toexpress context interest, which failed with the indicatedreturn code.


DRQZS0164E Unable to build credentials for user oridentity, IRRSZC00 SAF return codereturn-code, major code major-code, minorminor-code.

Explanation: The attempt to obtain credentials for theuser specified in the message failed with the indicatedreturn code.

User Response: Use the SAF return code and AZNcodes from the IRRSZC00 service to diagnose theproblem.

DRQZS0165E Unable to delete credentials,IRRSZC00 SAF return code return-code,major code major-code, minor minor-code.

Explanation: The attempt to delete credentials for theuser specified in the message failed with the indicatedreturn code.

User Response: Use the SAF return code and AZNcodes from the IRRSZC00 service to diagnose theproblem.

DRQZS0166E Set context interest data failed, returncode return-code.

Explanation: The CTXSCID2 service attempted toreplace context interest data, which failed with theindicated return code.


DRQZS0167E IRRSZC00 failed, policy directorauthorization services not installed.

Explanation: Policy Director Authorization Services isrequired to invoke IRRSZC00.

User Response: Install and configure Policy DirectorAuthorization Services.

DRQZS0168E IRRSZA00 failed, policy directorauthorization services not installed.

Explanation: Policy Director Authorization Services isrequired to invoke IRRSZA00.

User Response: Install and configure Policy DirectorAuthorization Services.

DRQZS0170I ARM registration complete for elementtype element-type, element nameelement-name.

Explanation: The server has successfully registeredwith ARM with the indicated element type and name.

User Response: None required.

DRQZS0171E ARM registration failed for elementtype element-type, element nameelement-name , return code return-code,reason code reason-code.

Explanation: The server attempted to register withARM with the indicated element type and name. Theattempt failed with the indicated return and reasoncodes from the IXCARM macro.

User Response: Use the return and reason codes todiagnose the problem.

DRQZS0172E ARM deregistration failed, returncode return-code, reason code reason-code.

Explanation: The server has attempted to deregisterwith ARM, but the deregistration has failed with theindicated return and reason codes from the IXCARMmacro.


DRQZS0174E xxxx unable to load module module,return code return-code, reason codereason-code.

Explanation: PD/MQ was unable to load theindicated module.

User Response: See the return and reason codes forinformation about the problem.

DRQZS0175W xxxx unable to delete module module,return code return-code.

Explanation: PD/MQ was unable to delete theindicated module.

User Response: See the return and reason codes forinformation about the problem.

DRQZS0180I Task task-name, task-id is being restarteddue to abend.

Explanation: The indicated required task has abendedand restarted.

User Response: None


DRQZS0181I Task task-name, task-id cannot berestarted due to abend.

Explanation: The indicated task has abended butcannot be restarted. If the task is required for thePD/MQ server, the server is terminated.

User Response: Correct the problem indicated by theabend, or follow your local procedures for contactingIBM support.

DRQZS0182I Task task-name, task-id has beenrestarted.

Explanation: The indicated task has been successfullyrestarted.

User Response: None

DRQZS0190E IRRSZA00 service is required but notinstalled.

Explanation: The service to perform an access decisionfor a resource is not installed.

User Response: Install the Policy DirectorAuthorization Services product (program number5655-F95).

DRQZS0191E IRRSZC00 service is required but notinstalled.

Explanation: The service to obtain credentials for auser is not installed.

User Response: Install the Policy DirectorAuthorization Services product (program number5655-F95).

DRQZS0192E IRRSZA00 service failed, resourceresource-name, SAF return code rc, aznmajor code azn major code, azn minorcode azn minor code, operation operation.

Explanation: The aznAccess service failed. Theoperation was either E (Enqueue) or D (Dequeue).

User Response: Use the Policy Director AuthorizationServices (program number 5655-F95) documentation forIRRSZA00 to find the meaning of the azn codes andother information in the message to debug the problem.

DRQZS0193I Value ″encryption strength″ unrecognizedfor attribute queue-name, value ignored.

Explanation: The encryption strength value for thespecified queue is not recognized.

User Response: Check the Policy Director policy forthe encryption strength required for the queue.

DRQZS0194I Value ″remote″ for attributeQname-resolution unsupported, ″ local ″will be used.

Explanation: Remote queue resolution is notsupported.

User Response: None

DRQZS0201E Request rejected due to unauthorizedadapter environment, module namemodule-name.

Explanation: The request has been rejected becausethe MQSeries adapter is not authorized.

User Response: APF authorize the PDMQSDRQAUTH loadlib.

DRQZS0202E Request rejected, unable to connect toserver server-name.

Explanation: The request has been rejected becausethe server is not active.

User Response: Start the server.

DRQZS0203E Request rejected, unable to determineadapter type.

Explanation: The request has been rejected becausethe adapter type is not BATCH, CICS, or IMS.

User Response: Use a supported adapter type.

DRQZS0204E Request rejected, unsupported adaptertype, module name module-name.

Explanation: The request has been rejected becausethe adapter type is not supported.

User Response: Use one of the supported adapters:BATCH, BATCH/RRS, CICS, IMS.

DRQZS0205E Request rejected, unable to obtainqueue attributes, return code return-code,reason code reason-code.

Explanation: The query queue request to obtain thequeue attributes was rejected.

User Response: Use the MQSeries return and reasoncodes to diagnose the problem.

DRQZS0206E Request rejected, unable to obtainqueue manager attributes, return codereturn-code, reason code reason-code.

Explanation: The query queue manager request toobtain the queue manager attributes was rejected.



DRQZS0208I

Job (jobname) User (userid)Access not permittedIdentity:resource-nameOperation code:

(PDMQ)E(PDMQ)D(PDMQ)ED

Explanation: The user is not authorized to theresource. Meanings of the operation codes are:(PDMQ)E is enqueue, (PDMQ)D is dequeue, and(PDMQ)ED is both.

User Response: Use a resource to which the user isauthorized. Operation codes are defined during theinstallation of Policy Director.

DRQZS0209I Message for queue-name sent to errorqueue error-queue-name, reasonreason-code.

Explanation: An MQSeries message intended for thequeue indicated in the message could not be written soit was sent to the error queue named in the message.

User Response: Use the MQSeries reason code todiagnose the problem.

DRQZS0210E Message for queue-name not sent toerror queue error-queue-name, reasonreason-code, MQ return code return-code,reason reason-code.

Explanation: An MQSeries message intended for thequeue named in the message could not be sent, butneither was it sent to the error queue named in themessage.


DRQZS0211E Request rejected, data services servernot active.

Explanation: The request was rejected because thedata services server is not active.

User Response: Start the data services server.

DRQZS0212E Data conversion from CCSIDoriginating-system-CCSID toreceiving-system-CCSID failed, MQ returncode return code, reason reason code.

Explanation: Conversion of data in the message failed.

User Response: Use the CCSIDs to determine wherethe message originated. Use the return and reasoncodes to diagnose the problem.

DRQZS0213E Close failed for queue manager qmgr-name queue queue-name, MQ return codereturn code, reason reason code.

Explanation: The queue named in the message failedclose processing.


DRQZS0214E Data protection initialization failedprocessing object ″″object″″, return codereturn code, reason reason code. Additionalinformation: information.

Explanation: Initialization of the data areas needed fordata protection failed.

User Response: Refer to the files gskcms.h andgsktypes.h for the meaning of the return code. Thisadditional information may indicate the function thatfailed.

DRQZS0215E Data protection failed processingobject ″″object″″, return code return code,reason reason code. Additionalinformation: information.

Explanation: Encryption of the message data failed.


DRQZS0216E Data unprotection failed, processingobject ″″object″″, return code return-code,reason reason-code. Additionalinformation: information.

Explanation: Decryption of the message data failed.


DRQZS0217E Data conversion from CCSIDoriginating-system-CCSID toreceiving-system- CCSID using format″format″ failed, MQ return code returncode, reason reason code.

Explanation: Conversion of data using the specifiedformat failed.

User Response: Use the CCSIDs to determine wherethe message originated. Use the return and reasoncodes to diagnose the problem.


DRQZS0218E Access to queue queue-name denied,quality of protection is privacy but norecipients have been defined.

Explanation: No recipients have been defined for thequeue.

User Response: Define at least one recipient for thequeue in the Policy Director policy.

DRQZS0219E Message verification error from queuequeue name, message size of messagelength does not match original size oforiginal message length.

Explanation: Message was rejected during GETprocessing because the length of the message afterdecryption did not match the original message size.

User Response: Ensure that the PD/MQ sender iscompatible with the level of PD/MQ on z/OS.

DRQZS0220E Message verification error from queuequeue name, encryption strength notavailable.

Explanation: Message was rejected during GETprocessing because the encryption strength for thequeue is not available.


DRQZS0221E Message verification error from queuequeue name, message encryption strengthencryption strength not valid.

Explanation: Ensure that the PD/MQ sender iscompatible with the level of PD/MQ on z/OS.

User Response: Define a valid encryption strength forthe queue in Policy Director.

DRQZS0222E Message verification error from queuequeue name, message encryption strengthencryption strength of msg inconsistentwith quality of protection strength queueencryption strength.

Explanation: Message was rejected during GETprocessing because the encryption strength for themessage is not consistent with the encryption strengthof the queue.


DRQZS0223E Message verification error from queuequeue name, message size message lengthinconsistent with header size headerlength or original size original messagelength.

Explanation: This message is issued only for a zerolength message when the length of the message is notthe same as the length of the header or the originalmessage length of zero.


DRQZS0224E Message verification error from queuequeue name, message length of messagelength too small.

Explanation: Message was rejected during GETprocessing because the buffer is not large enough tocontain the PD/MQ message header.


DRQZS0225E Message verification error from queuequeue name, message header notacceptable.

Explanation: Message was rejected during GETprocessing because the “structure identifier” in theheader is invalid.


DRQZS0226E Message verification error from queuequeue name, header version notsupported.

Explanation: Message was rejected during GETprocessing because “Version major number” in theheader is invalid.


DRQZS0300I Modify command ignored due toerrors.

Explanation: The text of an operator MODIFY servercommand was not recognized.

User Response: Correct the command and retry therequest.

DRQZS0301I ″value″ was expected in commandposition position before ″keyword″.

Explanation: A value was missing in the indicatedposition in the command.



DRQZS0302I ″value″ was seen in command positionposition where one of the following wasexpected: valid-values.

Explanation: An invalid value was found at theindicated position in the command.

User Response: Correct the command using one ofthe listed values.

DRQZS0303I Modify command text missing,command ignored.

Explanation: The MODIFY command was enteredwithout required command text. The command isignored.


DRQZS0304I Modify parameter command accepted.

Explanation: A parameter on the MODIFY commandwas accepted for processing.

User Response: None required.

DRQZS0305E Abend abend-code occurred processingmodify command.

Explanation: An abend occurred in processing theMODIFY command. The command was not executed.

User Response: Use the abend code to diagnose theproblem.

DRQZS0306E Modify command command ignoreddue to authorization failure.

Explanation: A MODIFY command could not beprocessed because SAF checking has determined thatthe user is not authorized to issue the command.

User Response: Delete the command.

DRQZS0310I

QueuesJobname Jobid Useridjobname jobid useridAsid Adapt QoPasid adapter qopQMgr: q-manager-name Queue: q-nameModel: model-qnameThread: thread Handle: handleType: Queue-typeStrength: encryption-strengthSigAlg: signature algorithmErrorQ: error-queue-name

Explanation: Details about each open queue aredisplayed, in response to an operator command:jobname Job name that submitted the requestjobid Job ID that submitted the requestuserid User ID that submitted the requestasid Address space IDadapter Adapter typeqop Quality of protection of the queue

Note that the value for Type will be LOCAL, REMOTE,ALIAS, MODEL, or DYNAMIC.

User Response: None

DRQZS0311I No objects to display.

Explanation: A command to display informationabout the queue was issued, but there are no objects onthe queue.

User Response: None

DRQZS0312I

DisplayServer status: statusQueue objects: obj

Explanation: In response to an operator command,information about the status of the PD/MQ server isdisplayed.

User Response: None

DRQZS0313I Dynamic Queues QMgr: qmgr nameQueue: queue name Model: model queuename Jobname: jobname Jobid: jobid

Explanation: In response to an operator command,information about dynamic queues is displayed. If thekeyword ALL was used, jobname and jobid aredisplayed also.

User Response: None

DRQZS0488E Server not started due to errors instart parameters.

Explanation: One or more parameters in the serverstartup options for the PD/MQ server were not correct.

User Response: Correct the parameters and retry therequest.

DRQZS0491E ″value″ was expected in startparameter position position before″string″.

Explanation: PD/MQ encountered an error in aparameter on the START command.

User Response: Use the position and string values toidentify the parameter in error. Retry the START


command with the corrected parameter.

DRQZS0492E ″ value″ was seen in start parameterposition position where one of thefollowing was expected: list-of-values.

Explanation: PD/MQ encountered an error in aparameter on the START server command. The positionof the error in the command string is indicated byposition.

User Response: Retry the START command using oneof the valid values.

DRQZS0493E Abend abend-code occurred processingstart parameters.

Explanation: An abend occurred in processing theSTART command. The command was executed withany parameters that were processed prior to the abend.

User Response: Use the abend code to diagnose theproblem. You may want to use the MODIFY commandto reset server options.

DRQZS0501I SMF recording in effect for record typetype.

Explanation: The PD/MQ server was started withSMF recording of the type specified for records active.

User Response: None

DRQZS0502I SMF recording not in effect.

Explanation: The PD/MQ server was startedspecifying no SMF recording.

User Response: None

DRQZS0515E Initialization failed for serverserver-name.

Explanation: Initialization of the names server failedto complete. Messages describing the reason for thefailure will have been issued prior to this one.

User Response: Use the preceding error messages todetermine the cause of the initialization failure.

DRQZS0517E Server not started due to invalidexecution environment, possible missingPPT entry.

Explanation: The PD/MQ server was not startedbecause of a problem with the execution environment.The server is not running in the correct protect key.

User Response: Verify that a PPT entry has beendefined in your SCHEDxx member of PARMLIB forprogram DRQHCTL. See the PD/MQ ProgramDirectory for more information.

DRQZS0518E Server not started, product is notenabled.

Explanation: The PD/MQ server has attempted toregister its invocation, but the registration has failed.The server was not initialized.

User Response: Check the ISFPRDxx member ofPARMLIB for a correct entry for PD/MQ.

DRQZS0527E Server not started, START commandmust be used.

Explanation: An attempt was made to start thePD/MQ server through a batch job. The server must bestarted with the MVS START command.

User Response: Issue the MVS START command tostart the PD/MQ server.

DRQZS0528E Server not started, invalid operatingsystem level.

Explanation: The PD/MQ server requires the OS/390R10 or higher environment. The server was not started.

User Response: None.

DRQZS0538E Server already active.

Explanation: The START command was entered for aPD/MQ server that is already active. The commandwas ignored.

User Response: None

DRQZS0702I Debug mode is enabled.

Explanation: A MODIFY server command was issuedto enable debug mode or display debug setting.

User Response: None

DRQZS0703I Debug mode is disabled.

Explanation: A MODIFY server command was issuedto disable debug mode or display debug setting.

User Response: None

DRQZS0709I Trace is active.

Explanation: This message is issued in response to aMODIFY server command to display trace status.

User Response: None

DRQZS0710I Trace is inactive.

Explanation: This message is issued in response to aMODIFY server command to display trace status whentrace is inactive.

User Response: None


DRQZS0711I Trace is now active.

Explanation: A MODIFY server command was issuedto start trace.

User Response: None

DRQZS0714I Trace is now inactive.

Explanation: A MODIFY server command was issuedto stop trace.

User Response: None

DRQZS0715I Trace is already active.

Explanation: A server MODIFY command was issuedto start tracing, but trace was previously started. Thecommand is ignored.

User Response: None

DRQZS0717I Trace is already inactive.

Explanation: A server MODIFY command was issuedto stop tracing but trace was previously stopped. Thecommand is ignored.

User Response: None

DRQZS0724I Tivoli Policy Director for MQSerieslevel system level initialization complete.

Explanation: The PD/MQ server was successfullyinitialized.

User Response: None

DRQZS0725I Server shutdown in progress.

Explanation: The PD/MQ server is being shut downin response to a stop command.

User Response: None

DRQZS0736I Server shutdown proceeding.

Explanation: A STOP command has been issued toshutdown the PD/MQ server. The server is waiting forcompletion of outstanding work.

User Response: None

DRQZS0806E parameter value ″value″ is in error,invalid syntax specified.

Explanation: The value for the parameter containsinvalid syntax.

User Response: Correct the syntax.

DRQZS0807E parameter value ″value″ is too long,maximum length allowed is maximum.

Explanation: The value for the parameter is longerthan the maximum allowed length.

User Response: Correct the length of the value.

DRQZS0808E parameter value ″value″ is not numeric.

Explanation: The value for the parameter is notnumeric. It must be numeric.

User Response: Correct the value.

DRQZS0809E parameter value ″value″ is too small,minimum value allowed is minimum.

Explanation: The value for the parameter is smallerthan the minimum allowed value.


DRQZS0810E parameter value ″value″ is too large,maximum value allowed is maximum.

Explanation: The value for the parameter is largerthan the maximum allowed value.


DRQZS0811E parameter value ″value″ is invalid.

Explanation: The value for the parameter is invalid.


DRQZS0813I parameter value ″value″ contains invalidhexadecimal digits.

Explanation: The value for the parameter containscharacters that are not valid hexadecimal digits. Validhexadecimal digits are 0-9 and A-F.


DRQZS0814E parameter value ″value″ is too short,minimum length allowed is minimum.

Explanation: The value for the parameter is shorterthan the minimum allowed length.


DRQZS0837E parameter value contains numbercharacters, but it must be even.

Explanation: The value for the parameter is an oddnumber of characters. The value must be an evennumber of characters.

User Response: Correct the value to contain an evennumber of characters.


DRQZS0901E Binary conversion error occurred inissuing a message.

Explanation: A message containing a numeric valuecould not be issued.

User Response: Follow your local procedure to callIBM for service.

DRQZS0902E Insert of an invalid type wasencountered in a message.

Explanation: A message containing an invalid insertcould not be issued.


DRQZS0903E Invalid insert number wasencountered in a message.

Explanation: A message containing an invalid insertnumber could not be issued.


DRQZS0904E Message too long.

Explanation: A message could not be issued because itis too long to display.


DRQZS0905E Incorrect number of inserts passed fora message.

Explanation: A message could not be issued becausean incorrect number of inserts was used.


DRQZS0906E Message msgid not issued sincemessage table not loaded.

Explanation: The message table was not loadedtherefore the message could not be issued.


DRQZS0908E Message message-number lineline-number not found in message table.

Explanation: The message indicated in the messagewas not found in the message table.


DRQZS0910E Message build error, reason=reason code

Explanation: The message could not be built.

User Response: Use the reason to determine theproblem. Possible reasons are:

Number inserts mismatch - number of insertindicators in the message does not match thenumber of inserts specified in the messageinvocation.

Binary conversion error.

Hex conversion error.

Invalid insert type - type was not binary, hex, orcharacter.

Invalid insert number - insert was not numeric or isout of range.

Message too long.

DRQZS0999I Diag: diagnostic-data

Explanation: This message contains diagnosticinformation about a function being performed such asmodule name, return code, reason code. This messageis issued when the PD/MQ server is in debug mode.

User Response: None


Chapter 8. Auditing PD/MQ for z/OS and OS/390

Policy Director lets administrators specify what level of auditing is to be recordedfor access to a resource. The audit level is specified in the Protected Object Policy(POP), and can be set to all, none, permit, deny, error, or admin. PD/MQ forz/OS currently supports all or none. Setting any of the audit flags in the POPturns on auditing for that resource.

PD/MQ for z/OS and OS/390 uses the services of the MVS System ManagementFacilities (SMF) on z/OS or OS/390. Audit records produced by PD/MQ arecentralized in SMF across processes and applications that are PD/MQ-enabled.

By default, PD/MQ has a user-defined, SMF-type-180 record. You can change thisrecord type so that PD/MQ-produced audit records can be included in anapplication that you already may have that processes SMF records.

Since this is a user record number, during PD/MQ server initialization, you mayspecify the SMF record number that PD/MQ uses for auditing security-relevantevents. See “Customizing the PD/MQ Server Processes” on page 16 for adiscussion of the options that can be customized for the PD/MQ server processes.

The SMF record is defined using subtypes, with subtype 1 being a general auditingevent. The SMF record contains all data relevant to the request being processed,and is intended to be consistent with the information recorded by the non-hostversion of PD/MQ.

The SMF record is mapped by the DRQKSMF macro, which is found in the targetlibrary in SDRQMAC1. If you are writing data-reduction programs for SMF data,you may include this mapping macro to aid in the development and customizationof SMF post-processing routines. The data areas for this macro are in “Appendix.PD/MQ SMF Audit Records” on page 79.

In the SMF records produced by PD/MQ, the data is organized into sections. Therecord consists of:v A standard SMF headerv A header extension defined by PD/MQv A product sectionv And a data section

The product section of the SMF record is always present in the records producedby PD/MQ for z/OS. The data section varies based on subtype. For this release,one subtype is defined and hence a single data section.

The header extension contains the offsets and lengths of the product and datasections in the SMF record. The product section describes the PD/MQ product andz/OS and OS/390 releases.

The data section contains the data specific to the event being recorded. PD/MQgenerates log records as a result of MQOPEN, MQCLOSE, MQGET, MQPUT, andMQPUT1 operations processed by PD/MQ. Since the information recorded in thedata section of the SMF record varies based on the MQSeries operation beingprocessed, not all fields in the data section will be relevant.


When a field in the data section is not present, its length and offset are both zero.If you intend to write an SMF post-processing program, your application shouldcheck for a length of non-zero to determine when a specific data field is present inthe data section of the SMF record produced by PD/MQ.

The data section consists of a fixed part followed by a variable part. These partscontain items such as the MQSeries request being audited (for example, MQGET orMQPUT), the encryption strength, the signature algorithm, the MQSeries errorcode, and a list of recipients.

“Appendix. PD/MQ SMF Audit Records” on page 79 defines the format for theSMF audit records generated by PD/MQ. For additional information on SMF, see:v For the z/OS platform: z/OS: MVS System Management Facilities (SMF)

v For the OS/390 platform: OS/390: MVS System Management Facilities (SMF)


Appendix. PD/MQ SMF Audit Records

By default, PD/MQ writes SMF type 180 records. You may change this recordnumber to suit your needs so that PD/MQ audit records are processed byapplications or tools in your shop. PD/MQ supplies the macro DMQKSMF, whichprovides the mapping of the SMF records generated by PD/MQ.

The format for the PD/MQ generated SMF records is:

Table 4. PD/MQ-Generated SMF Records

Decimal Hex Name Length Format Description

0 0 SMFB4HDR 0 Binary PDMQ Audit Record --Standard SMF Header

0 0 SMFB4LEN 2 Binary Record length

2 2 SMFB4SEG 2 Binary Segment descriptor

4 4 SMFB4FLG SeeTable 5 onpage 81 forspecific flags.

4 Flag SMF flags

5 5 SMFB4RTY 1 Binary Record Type

6 6 SMFB4TME 4 Binary TOD record written

10 A SMFB4DTE 4 Packed Date record written inpacked decimal

14 E SMFB4SID 4 Character System ID

18 12 SMFB4SSI 4 Character Subsystem name

22 16 SMFB4STY 2 Binary Record subtype

24 18 SMFB4HDX 0 Binary Start of Header Extension

24 18 SMFB4NDB 2 Binary Number of doublets

26 1A SMFB4SRL 2 Binary Record Change Level

28 1C SMFB4RS1 16 Binary Reserved

44 2C SMFB4DBL 0 Binary Doublets

44 2C SMFB4PRS 4 Binary Offset to product section

48 30 SMFB4PRL 4 Binary Length of product section

52 34 SMFB4DSS 4 Binary Offset to data section

56 38 SMFB4DSL 4 Binary Length of data section

0 0 SMFB4PRO 0 Binary Start of Product Section

0 0 SMFB4VER 1 Binary Product Version

1 1 SMFB4REL 1 Binary Product Release

2 2 SMFB4MOD 1 Binary Product Modification Level

3 3 SMFB4RS2 1 Binary Reserved

4 4 SMFB4FMI 8 Character Product FMID


Table 4. PD/MQ-Generated SMF Records (continued)


12 C SMFB4MVS 34 Character Operating system stringname

46 2E SMFB4RS3 2 Character Reserved

48 30 SMFB4RS4 4 Binary Reserved

0 0 RB41SECT 0 Character Start of Subtype 1

0 0 RB41JBN 8 Character Job name

8 8 RB41USR 8 Character User identification (user ID)

16 10 RB41SYS 8 Character System name

24 18 RB41PLX 8 Character Sysplex name

32 20 RB41ACT 4 Character Action being performed

36 24 RB41RSN 4 Binary MQ-related reason code

40 28 RB41AUD 4 Binary Audit code

44 2C RB41DEC 4 Binary Access decision

48 30 RB41POP 1 Binary Protection algorithm

49 31 RB41SGA 1 Binary Signature algorithm

50 32 RB41ENC 1 Binary Encryption strength

51 33 RB41RS1 1 Binary Reserved

52 34 RB41OOB 4 Binary Offset to protected objectname

56 38 RB41OBL 4 Binary Length of protected objectname

60 3C RB41OQN 4 Binary Offset to queue name

64 40 RB41QNL 4 Binary Length of queue name

68 44 RB41OQM 4 Binary Offset to queue managername

72 48 RB41QML 4 Binary Length of queue managername

76 4C RB41OOP 4 Binary Offset to operation codes

80 50 RB41OPL 4 Binary Length of operation codes

84 54 RB41OID 4 Binary Offset to the sender’sidentity

88 58 RB41IDL 4 Binary Length of the sender’sidentity

92 5C RB41NRC 4 Binary Number of entries inrecipient list

96 60 RB41ORC 4 Binary Offset to the recipient list

100 64 RB41RCL 4 Binary Length of the recipient list

104 68 RB41OMS 4 Binary Offset to message ID

108 6C RB41MSL 4 Binary Length of message ID

112 70 RB41FMT 8 Character Format name

120 78 RB41RS2 16 Binary Reserved


Table 4. PD/MQ-Generated SMF Records (continued)


136 88 RB41END 0 Binary End of fixed part of theSMF Record

0 0 RB41RCLI 0 Binary Start of the Recipient List

0 0 RB41RCRL 0 Binary Start of recipient list entry

0 0 RB41RCRE 4 Binary Length of recipient listentry

4 4 RB41RCRP * Character Recipient list entry

Table 5. SMF Flags

Name Description

SMFB4FR0 1...... Reserved

SMFB4SUT .1...... Subtypes valid

SMFB4FR2 ..1..... Reserved

SMFB4V4 ...1.... MVS/SP V4

SMFB4ESA .....1... MVS/SP V3

SMFB4XA ......1.. MVS/SP V2

SMFB4VS2 ......1. VS2

SMFB4FR7 .......1 Reserved

In the following tables, the Label column indicates the name of the constant foundin the PD/MQ SMF audit record mapping macro DMQKSMF.

Table 6 shows the PD/MQ SMF Record version level for the standard SMF headersection. The field SMFB4SRL is set to this value:

Table 6. SMF Record Version Level

Label Value Description

SMFB4RL0 X’0000’ Current record version level. 0 indicates the first releaseof PD/MQ for z/OS and OS/390.

Table 7 shows PD/MQ MQSeries operation code constant values for data section,subtype 1. These values are associated with the field RB41ACT:

Table 7. MQSeries Operation Code Constants


RB41ACOP 1 MQOPEN operation being audited

RB41ACGT 2 MQGET operation being audited

RB41ACPT 3 MQPUT operation being audited

RB41ACP1 4 MQPUT1 operation being audited

RB41ACCL 5 MQCLOSE operation being audited


PD/MQ access decision codes reflect the access control decision from PolicyDirector Authorization Services. The field RB41DEC in the data section of thePD/MQ-generated audit record may take on one of these values:

Table 8. PD/MQ Access Decision Codes


RB41DCAG X’0002’ Access was granted by Policy Director AuthorizationServices

RB41DCAD X’0004’ Access was denied by Policy Director AuthorizationServices

PD/MQ signature algorithm codes reflect the algorithm that PD/MQ used toprocess the message being audited. The field RB41SGA in the data section of thePD/MQ-generated audit record may take on one of these values:

Table 9. PD/MQ Signature Algorithm Codes


RB41SGM2 1 Signature algorithm of MD2 was used in processing thisevent.

RB41SGM5 2 Signature algorithm of MD5 was used in processing thisevent.

RB41SGS1 3 Signature algorithm of SHA1 was used in processing thisevent.

PD/MQ encryption strength codes reflect the strength of the cryptographicalgorithm applied in the protection of the message being audited. The fieldRB41ENC in the data section of the PD/MQ-generated audit record may take onone of these values:

Table 10. PD/MQ Encryption Strength Codes


RB41ECST 1 Strong cryptography was used in the processing of thisaudited message.

RB41ECMD 2 Medium strength cryptography was used in theprocessing of this audited message.

RB41ECWK 3 Weak cryptography was used in the processing of thisaudited message.

PD/MQ protection operation codes reflect the quality of protection applied in theprocessing of this audited MQSeries message. The field RB41POP in the datasection of the PD/MQ-generated audit record may take on one of these values:

Table 11. PD/MQ Protection Operation Codes


RB41PONO 1 The quality of protection applied was NONE

RB41POIN 2 The quality of protection applied was INTEGRITY

RB41POPR 3 The quality of protection applied was PRIVACY

If PD/MQ encounters an error during the dequeuing of a message, it sets the auditcode field in the data section of the SMF record, which reflects the error that


PD/MQ encountered. The field RB41AUD in the data section of thePD/MQ-generated audit record may take on one of these values:

Table 12. PD/MQ Audit Codes


RB41AGQM 1 QoP mismatch.

RB41AGDE 2 PD/MQ encountered an error during the decryption ofthe message.

RB41AGSA 3 PD/MQ was unable to map the sender’s certificate to aPolicy Director user ID in order to validate that thesender was authorized to enqueue to this protectedqueue.

RB41AGHE 4 PD/MQ detected an error in the header that it prependsto an application message, or the header was not present.

RB41AGSM 5 PD/MQ detected a length mismatch between theprotected and unprotected message.

RB41AGEM 6 PD/MQ encountered an error in the decryption of amessage. The algorithm that the policy specified did notmatch the algorithm used to encrypt the message.

RB41AGCN 7 PD/MQ detected a conversion error (locale), during thedequeue processing of a message.

RB41AGER 8 PD/MQ was unable to dequeue the message from theprotected queue.


Bibliography

Most of the books cited in this publication are listed here, along with their order numbers for those thathave one. In some categories, separate lists are given for z/OS books and their OS/390 counterparts. Usethe books that are correct for your operating system. If only one book, or set of books, is given, it can beused for either z/OS or OS/390.

PD/MQThe first book is for PD/MQ on z/OS or OS/390.The second is for PD/MQ on AIX, Sun Solaris, orWindows NT.v Tivoli: Policy Director for MQSeries

Administration Guide 3.7.1, SC24-6041v Tivoli: Policy Director for MQSeries

Administration Reference Guide 3.8

Books for Installation on z/OSv z/OS: SMP/E Commands, SA22-7771v z/OS: SMP/E Messages, Codes, and Diagnosis,

GA22-7770v z/OS: SMP/E Reference, SA22-7772v z/OS: SMP/E User’s Guide, SA22-7773v z/OS: MVS Initialization and Tuning Reference,

SA22-7592

Books for Installation on OS/390v OS/390: SMP/E Commands, SC28-1805-06v OS/390: SMP/E Messages and Codes,

SC28-1738-07v OS/390: SMP/E Diagnosis Guide, SC28-1737-06v OS/390: SMP/E Reference, SC28-1806-06v OS/390: SMP/E User’s Guide, SC28-1740-06v OS/390: MVS Initialization and Tuning Reference,

SC28-1752-13

Policy Directorv Tivoli SecureWay: Policy Director Base for

Windows Installation Guide 3.7

v Tivoli SecureWay: Policy Director Base for SolarisInstallation Guide 3.7

v Tivoli SecureWay: Policy Director Base for AIXInstallation Guide 3.7

v Tivoli SecureWay: Policy Director BaseAdministration Guide 3.7.1

v Tivoli SecureWay: Policy Director Web PortalManager Administration Guide 3.8, GC32-0737-00

Policy Director AuthorizationServicesv IBM Policy Director Authorization Services for

z/OS and OS/390: Customization and Use,SC24-6040

MQSeriesv MQSeries for OS/390 V5R2: Concepts and

Planning Guide, GC34-5650-00v MQSeries for OS/390 V5R2: System Setup Guide,

SC34-5651-00v MQSeries for OS/390 V5R2: System

Administration Guide, SC34-5652-00

Security Server for z/OSUse these publications if you are running PD/MQon z/OS. A list of publications to use for PD/MQon OS/390 follows this list.

LDAPv z/OS: SecureWay Security Server LDAP Server

Administration and Use, SC24-5923v z/OS: SecureWay Security Server LDAP Client

Programming, SC24-5924

RACFv z/OS: SecureWay Security Server RACF Security

Administrator’s Guide, SA22-7683v z/OS: SecureWay Security Server RACF Callable

Services, SA22-7691v z/OS: SecureWay Security Server RACF Command

Language Reference, SA22-7687

Security Server for OS/390This is the list of publications for PD/MQ onOS/390.


LDAPv OS/390: SecureWay Security Server LDAP Server

Administration and Usage Guide, SC24-5861-06v OS/390: SecureWay Security Server LDAP Client

Application Development Guide and Reference,SC24-5878-02

RACFv OS/390: SecureWay Security Server RACF

Security Administrator’s Guide, SC28-1915-08v OS/390: SecureWay Security Server RACF Callable

Services, GC28-1921-08v OS/390: SecureWay Security Server RACF

Command Language Reference, SC28-1919-08

SMFv z/OS: MVS System Management Facilities (SMF),

SA22-7630v OS/390: MVS System Management Facilities

(SMF), GC28-1783-12

SSLv z/OS: System Secure Sockets Layer Programming,

SC24-5901v OS/390: System Secure Sockets Layer

Programming Guide and Reference, SC24-5877-03

UNIX System Servicesv z/OS: UNIX System Services Planning,

GA22-7800v z/OS: UNIX System Services Command Reference,

SA22-7802v OS/390: UNIX System Services Planning,

SC28-1890-11v OS/390: UNIX System Services Command

Reference, SC28-1892-11


Index

Aabend codes 65access control lists (ACLs) 53accessing publications online xiii

IBM z/OS and OS/390publications xiii

Tivoli publications xiiiACL evaluation and queue name

resolution 53adding MQSeries objects to Policy

Director 30adding secPKIMap objects 49administering PD/MQ 29application environment

considerations 55application environments

and enabling for PD/MQ 58limitations 60

applicationsenabling 5

attaching configuration information toprotected objects 32

audit records 79auditing PD/MQ 77authorization for PD/MQ operations 51

Ccertificates

for encryption 44how used by PD/MQ 38X.509 V3 40, 41

CICS transactions,enabling 59components of PD/MQ 2configuring PD/MQ 13

configuring a non-z/OS residentPKI 25

configuring Policy Director 26configuring the protected object

space 26customizing

data services daemon 17customizing server processes 16default OMVS segments 16defining PD/MQ processes 13joining a Policy Director secure

domain 26overview 13PD/MQ data services daemon 13summary of certificate-related

operations 24considerations for application

environments 55considerations for MQSeries 55contacting customer support xivconventions used in this guide xiicreating

Policy Director identities 36secPKIMap object class in LDAP 47X.509 V3 certificates 41

customer support xiv

Ddaemon messages 65data services daemon 17

for PD/MQ 13default OMVS segments 16defining

and attaching policy templates 51MQSeries resources 29PKI identities for applications 36

dependencies for PD/MQ 2detecting dynamic queues 57DRQKSMF macro 77dynamic queues 55

how PD/MQ detects 57

Eenabling applications 5

in BATCH and BATCH-RRS 59in UNIX System Services 58with MQSeries-CICS adapter 59

enabling PD/MQ 9updating the SCHEDxx member of

SYS1.PARMLIB 10environments

application 55BATCH and BATCH-RRS 59MQSeries-CICS adapter 59UNIX System Services 58

error handling in PD/MQ 63

Ggenerated names 55

Hhow certificates are used by PD/MQ 38how PD/MQ works 4

how applications are enabled 5how MQI works 6how queues work 4on z/OS and OS/390 4

Iimporting certificates for encryption 44installing PD/MQ for z/OS and

OS/390 7, 8post-installation tasks 8, 9prerequisites 7

LLDAP 3

creating the secPKIMap objectclass 47

Lightweight Directory Access Protocol(LDAP) 3

limitationsapplication environment 60MQSeries 60

Mmaking PD/MQ operational 9

updating the SCHEDxx member ofSYS1.PARMLIB 10

mappingPKI identities to Policy Director

users 45Policy Director users to z/OS user

IDs 37maximum message size 61message numbering 65Message Queue Interface (MQI) 6messages 65

for daemon 65for the server 67maximum size 61

MQI 6MQSeries

adding objects to Policy Director 30authorization 55defining resources 29limitations and unsupported

configurations 60MQSeries considerations 55MVS System Management Facilities

(SMF) 77

OOMVS segments 16online publications xiii

IBM xiiiTivoli xiii

ordering publications xiii

PPD/MQ

abend codes 65auditing 77certificates 38compatibility 2components and dependencies 2data services daemon 13interaction with MQSeries

authorization 55messages 65operations 51


PD/MQ (continued)server 13SMF audit records 79

PD/MQ for z/OS and OS/390installation 7prerequisites 7

PKI 3identities 36, 45non-z/OS-resident 25operations 42

Policy Director 3adding MQSeries objects 30identities 36protected objects 32secure domain 26users 45

Policy Director AuthorizationServices 26

policy templates 51POP 52post-installation tasks for PD/MQ 8preface xiprerequisite and related documents xiprerequisites for PD/MQ for z/OS and

OS/390 7protected object policy (POP) 52protected object space 26protected objects 32providing feedback about

publications xiiipublic key infrastructure (PKI) 3publications

for installation 8online xiiiordering xiiiproviding feedback xiii

Qqueues 4

dynamic 55, 57queue name resolution 53

Rrelated documents xi

Sscenarios

for defining PKI operations 42for PD/MQ 53

secPKIMap 47objects 49

secure domain 26server

messages 67server processes

customizing PD/MQ 16server processes, defining PD/MQ 13SMF 77SMF audit records 79specifying

PD/MQ protected object policy 52System Management Facilities (SMF) 77

Uunderstanding PD/MQ 1unsupported configurations 60

Wwhat this guide contains xiiwho should read this guide xi

XX.509 V3 certificates 40

creating 41


Program Number: 5698-PDM

Printed in the United States of Americaon recycled paper containing 10%recovered post-consumer fiber.

SC24-6041-00