Tivoli SecureWay Policy Director Base Administration Guidepublib.boulder.ibm.com/tividd/td/SW_30/GC32-0680-01/en... · 2002-11-09 · Tivoli SecureWay Policy Director Base Administration

Tivoli SecureWay Policy DirectorBaseAdministration GuideVersion 3.8

Tivoli SecureWay Policy DirectorBaseAdministration GuideVersion 3.8

Tivoli SecureWay Policy Director Base Administration Guide

Copyright Notice

© Copyright IBM Corporation 2001. All rights reserved. May only be used pursuant to a TivoliSystems Software License Agreement, an IBM Software License Agreement, or Addendum for TivoliProducts to IBM Customer or License Agreement. No part of this publication may be reproduced,transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in anyform or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise,without prior written permission of IBM Corporation. IBM Corporation grants you limited permissionto make hardcopy or other reproductions of any machine-readable documentation for your own use,provided that each such reproduction shall carry the IBM Corporation copyright notice. No other rightsunder 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 thisdocument are hereby disclaimed, including the warranties of merchantability and fitness for aparticular purpose.

U.S. Government Users Restricted Rights—Use, duplication or disclosure restricted by GSA ADPSchedule Contract with IBM Corporation.

Trademarks

IBM, the IBM logo, Tivoli, the Tivoli logo, AIX, Policy Director, and SecureWay are trademarks orregistered trademarks of International Business Machines Corporation or Tivoli Systems Inc. in theUnited States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation inthe United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the UnitedStates, other countries, or both.

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

References in this publication to Tivoli Systems or IBM products, programs, or services do not implythat they will be available in all countries in which Tivoli Systems or IBM operates. Any reference tothese products, programs, or services is not intended to imply that only Tivoli Systems or IBMproducts, programs, or services can be used. Subject to valid intellectual property or other legallyprotectable right of Tivoli Systems or IBM, any functionally equivalent product, program, or servicecan be used instead of the referenced product, program, or service. The evaluation and verification ofoperation in conjunction with other products, except those expressly designated by Tivoli Systems orIBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patentapplications covering subject matter in this document. The furnishing of this document does not giveyou any license to these patents. You can send license inquiries, in writing, to the IBM Director ofLicensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A.

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiWho Should Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

What This Guide Contains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Typeface Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Related Policy Director Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Accessing Online Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Ordering Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Providing Feedback about Product Documentation . . . . . . . . . . . . . . . . . . . xvii

Contacting Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Chapter 1. Policy Director Overview. . . . . . . . . . . . . . . . . . . . . . 1Securing the Enterprise Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Network Security Technologies and Definitions . . . . . . . . . . . . . . . . . . . 2

Network Security — Common Concerns . . . . . . . . . . . . . . . . . . . . . . . . 4

Introducing Policy Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Policy Director — Core Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Quality of (Data) Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Accountability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Centralized Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Policy Director Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Web Portal Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

pdadmin Command Line Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

iiiTivoli SecureWay Policy Director Base Administration Guide

WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Authorization API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Administration API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Policy Director Authorization Server . . . . . . . . . . . . . . . . . . . . . . . . . . 13

IBM Global Security Kit (GSKit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Understanding Authorization: Conceptual Model . . . . . . . . . . . . . . . . . . . . . 13

The Benefits of a Standard Authorization Service. . . . . . . . . . . . . . . . . 15

Introducing the Policy Director Authorization Service . . . . . . . . . . . . . 16

The Policy Director Authorization Service . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Authorization Service Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Replication for Scalability and Performance . . . . . . . . . . . . . . . . . . . . . 21

Implementing a Network Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Defining the Network Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . 23

The Protected Object Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Defining and Applying ACL and POP Policies . . . . . . . . . . . . . . . . . . . 25

Policy Administration: The Web Portal Manager . . . . . . . . . . . . . . . . . 27

The Authorization Process: Step-by-Step . . . . . . . . . . . . . . . . . . . . . . . 28

The Policy Director Authorization API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Using the Authorization API: Two Examples . . . . . . . . . . . . . . . . . . . . 31

Authorization API: Remote Cache Mode . . . . . . . . . . . . . . . . . . . . . . . 32

Authorization API: Local Cache Mode. . . . . . . . . . . . . . . . . . . . . . . . . 34

External Authorization Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Extending the Authorization Service . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Imposing Conditions on Resource Requests . . . . . . . . . . . . . . . . . . . . . 36

The Authorization Evaluation Process . . . . . . . . . . . . . . . . . . . . . . . . . 36

Implementing an External Authorization Service . . . . . . . . . . . . . . . . . 40

Deployment Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Chapter 2. Managing the Protected Object Space. . . . . . 43

iv Version 3.8

Understanding the Protected Object Space . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Elements of the Protected Object Space . . . . . . . . . . . . . . . . . . . . . . . . 44

Protected Object Space Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

User-defined Object Space for Third-Party Applications . . . . . . . . . . . . 48

Defining a Database Object Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Creating a New User-defined Container Object . . . . . . . . . . . . . . . . . . 49

Creating and Deleting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Chapter 3. Using Access Control Policies . . . . . . . . . . . . . . 53Introducing the ACL Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

ACL Policy Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Creating and Naming ACL Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

ACL Entry Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Type Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

ID Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Permissions (Actions) Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Default Policy Director Permissions (Actions) . . . . . . . . . . . . . . . . . . . 59

How the Authorization Service Uses ACL Policies . . . . . . . . . . . . . . . . . . . . 60

Performing Operations on an Object . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Requirements for Custom Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 61

Custom Action Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Evaluating an ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Evaluating Authenticated Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Evaluating Unauthenticated Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Example ACL Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Sparse ACL Model: ACL Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Understanding the Sparse ACL Model . . . . . . . . . . . . . . . . . . . . . . . . . 65

The Default Root ACL Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Traverse Permission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

vTivoli SecureWay Policy Director Base Administration Guide

Resolving an Access Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Applying ACL Policies to Different Object Types . . . . . . . . . . . . . . . . 69

ACL Policy Inheritance Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Guidelines for a Secure Object Space . . . . . . . . . . . . . . . . . . . . . . . . . 70

Creating Extended ACL Actions and Action Groups . . . . . . . . . . . . . . . . . . . 71

Creating a New Action Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Creating New Actions in an Action Group . . . . . . . . . . . . . . . . . . . . . . 73

Entering Custom Actions into ACL Entries . . . . . . . . . . . . . . . . . . . . . 74

ACL Policies and the Protected Object Space . . . . . . . . . . . . . . . . . . . . . . . 75

Root ( / ) Container Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

The Traverse Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

WebSEAL Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

/WebSEAL/<host> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

/WebSEAL/<host>/<file> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

WebSEAL Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Management Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

/Management/ACL Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

/Management/Action Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

/Management/POP Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

/Management/Server Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

/Management/Config Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

/Management/Policy Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

/Management/Replica Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

/Management/Users Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

/Management/Groups Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

/Management/GSO Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Object and Object Space Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Default Administration ACL Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Default Root ACL Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

vi Version 3.8

Default /WebSEAL ACL Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Default /Management ACL Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Default /Replica ACL Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Default /Config ACL Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Default /GSO ACL Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Default /Policy ACL Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Chapter 4. Using Protected Object Policies . . . . . . . . . . . . 91Introducing Protected Object Policies (POP) . . . . . . . . . . . . . . . . . . . . . . . . 91

POP Policy Notes:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Creating and Deleting Protected Object Policies . . . . . . . . . . . . . . . . . . 93

Applying POP Attributes to Protected Objects . . . . . . . . . . . . . . . . . . . 94

Configuring the POP Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Warning Mode Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Audit Level Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Time-of-Day Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Quality of Protection Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

IP Endpoint Authentication Method Attribute . . . . . . . . . . . . . . . . . . . . 98

Chapter 5. Delegating Administration Tasks . . . . . . . . . . . . 99Delegating Object Space Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Structuring the Object Space for Management Delegation. . . . . . . . . . 100

Default Administration Users and Groups. . . . . . . . . . . . . . . . . . . . . . 101

Creating Administration Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Example Administration ACL Templates . . . . . . . . . . . . . . . . . . . . . . 104

Example: Management Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Delegating Group Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Creating Group Container Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Creating Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

ACL Policies Affecting Group Management . . . . . . . . . . . . . . . . . . . . 110

viiTivoli SecureWay Policy Director Base Administration Guide

ACL Policies Affecting User Management . . . . . . . . . . . . . . . . . . . . . 112

Managing Delegated Administration Policy . . . . . . . . . . . . . . . . . . . . . . . . 114

Chapter 6. Managing the Policy Director Servers . . . . . 119Introducing the Policy Director Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Server Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Introducing Server Administration Tools. . . . . . . . . . . . . . . . . . . . . . . 122

Server Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

UNIX: Stopping / Starting Policy Director Servers . . . . . . . . . . . . . . . . . . . 124

Stop the Policy Director Servers Using the pd_start Utility. . . . . . . . . 125

Start the Policy Director Servers Using the pd_start Utility. . . . . . . . . 125

Restart the Policy Director Servers Using the pd_start Utility . . . . . . . 125

Start Individual Servers Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Displaying Server Status Using the pd_start Utility . . . . . . . . . . . . . . 126

Windows: Stopping / Starting Policy Director Servers . . . . . . . . . . . . . . . . 126

Using the Services Control Panel to Stop / Start Servers . . . . . . . . . . 126

Automating Server Startup at Boot Time . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Authorization Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Management Server (pdmgrd) Administration. . . . . . . . . . . . . . . . . . . . . . . 128

Replicating the Authorization Database . . . . . . . . . . . . . . . . . . . . . . . 128

Setting the Number of Update Notifier Threads . . . . . . . . . . . . . . . . . 130

Setting the Notification Delay Time . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Chapter 7. Using the LDAP Registry . . . . . . . . . . . . . . . . . . . 133LDAP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

LDAP: A Protocol for Directory Services. . . . . . . . . . . . . . . . . . . . . . 134

LDAP Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

The LDAP Information Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

LDAP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

viii Version 3.8

LDAP Fail-over Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

The Master-Slave Replication Model . . . . . . . . . . . . . . . . . . . . . . . . . 139

Policy Director Fail-over Capability for LDAP Servers. . . . . . . . . . . . 140

Master Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Replica Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Setting Preference Values for Replica LDAP Servers . . . . . . . . . . . . . 142

Server Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Applying Policy Director ACLs to New LDAP Suffixes . . . . . . . . . . . . . . . 144

Procedures for IBM SecureWay Directory Server . . . . . . . . . . . . . . . . 145

Procedures for iPlanet Directory Server . . . . . . . . . . . . . . . . . . . . . . . 149

Chapter 8. Logging and Auditing Server Activity . . . . . 153Introduction to Logging and Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Log Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Audit Trail Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Documentation Convention: <install-path> . . . . . . . . . . . . . . . . . . . . . 154

Policy Director Server Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Enabling and Disabling Policy Director Server Log Files . . . . . . . . . . 155

Example: ivmgrd.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Serviceability Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Directing Messages to Standard Output . . . . . . . . . . . . . . . . . . . . . . . 157

Policy Director Audit Trail Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Enabling and Disabling Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Specifying the Log File Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Specifying Audit File Rollover Thresholds . . . . . . . . . . . . . . . . . . . . . 159

Specifying the Frequency for Flushing Audit File Buffers. . . . . . . . . . 160

Specifying Audit Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Audit Trail File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Status Attribute of the Outcome Field . . . . . . . . . . . . . . . . . . . . . . . . 163

ixTivoli SecureWay Policy Director Base Administration Guide

Resource Attribute of the Target Field . . . . . . . . . . . . . . . . . . . . . . . . 163

Audit Trail File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Authorization Audit Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Authentication Audit Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

WebSEAL Audit Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Management Audit Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Appendix A. pdadmin Command Reference. . . . . . . . . . . 173Introducing the pdadmin Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Starting the pdadmin Utility (login command) . . . . . . . . . . . . . . . . . . 174

Help Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Exiting the pdadmin Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Special Characters Disallowed for GSO Commands . . . . . . . . . . . . . . 176

Limitations When Naming GSO Resources . . . . . . . . . . . . . . . . . . . . 176

ACL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Managing ACL Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Managing Extended Attributes for ACLs . . . . . . . . . . . . . . . . . . . . . . 179

Action Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Creating Custom ACL Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Creating Extended ACL Actions and Action Groups . . . . . . . . . . . . . . 181

Object Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Managing a Custom Objectspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Managing Protected Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Managing Extended Attributes for Protected Objects . . . . . . . . . . . . . 185

Protected Object Policy (POP) Commands . . . . . . . . . . . . . . . . . . . . . . . . . 186

Managing Protected Object Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Managing Extended Attributes for Protected Object Policies . . . . . . . . 188

Server Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Technical Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

x Version 3.8

Administration Information Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

User Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Group Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Resource Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Managing Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Managing Resource Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Managing Resource Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Policy Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Managing Login Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Managing Password Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Appendix B. ivmgrd.conf Reference . . . . . . . . . . . . . . . . . . . 215

Appendix C. ivacld.conf Reference . . . . . . . . . . . . . . . . . . . . 219

Appendix D. ldap.conf Reference . . . . . . . . . . . . . . . . . . . . . . 225

Appendix E. pd.conf Reference . . . . . . . . . . . . . . . . . . . . . . . . 227

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

xiTivoli SecureWay Policy Director Base Administration Guide

xii Version 3.8

Preface

Welcome to the Tivoli SecureWay Policy Director BaseAdministration Guide.

Policy Director is a complete authorization solution for corporateWeb, client/server, MQ, and existing legacy applications. PolicyDirector authorization allows an organization to securely control useraccess to protected information and resources. You use PolicyDirector in conjunction with standard Internet-based applications tobuild highly secure and well-managed network-based applications.

This administration guide provides a comprehensive set ofprocedures and reference information for managing Policy Directorservers and resources. This guide also provides you with valuablebackground and concept information for the wide range of PolicyDirector functionality.

Who Should Read This GuideThe target audience for this guide includes:

¶ Security administrators

¶ System installation and deployment administrators

¶ Network system administrators

¶ IT architects

¶ Application developers

What This Guide Contains¶ Chapter 1: Policy Director Overview

This chapter introduces you to important Policy Directorconcepts and functionality such as: Policy Director coretechnologies and components, the authorization service model,and implementing a security policy.

¶ Chapter 2: Managing the Protected Object Space

xiiiTivoli SecureWay Policy Director Base Administration Guide

This chapter discusses how Policy Director uses a virtualrepresentation of resources in a protected object space. Twotypes of object spaces are supported: flat file and database.

¶ Chapter 3: Using Access Control Policies

This chapter is a complete reference to access control list (ACL)policies.

¶ Chapter 4: Using Protected Object Policies

This chapter is a complete reference to protected object policies(POP).

¶ Chapter 5: Delegating Administration Tasks

This chapter explains how Policy Director supports delegatedmanagement of the object space and group management.

¶ Chapter 6: Managing the Policy Director Servers

This chapter is a technical reference to managing andcustomizing the operation of the Policy Director servers.

¶ Chapter 7: Using the LDAP Registry

This chapter introduces the LDAP protocol / directory andprovides detailed information on LDAP fail-over configuration.

¶ Chapter 8: Logging and Auditing Server Activity

This chapter provides a complete reference to the PolicyDirector logging and auditing capabilities.

¶ Appendix A: pdadmin Command Reference

¶ Appendix B: ivmgrd.conf Reference

¶ Appendix C: ivacld.conf Reference

¶ Appendix D: ldap.conf Reference

¶ Appendix E: pd.conf Reference

xiv Version 3.8

Typeface ConventionsThis guide uses several typeface conventions for special terms andactions. These conventions have the following meaning:

Bold Command names and options, keywords, and otherinformation that you must use literally appear in bold.

Italics Variables, command arguments, and values you mustprovide appear in italics. Titles of publications and specialwords or phrases that are emphasized also appear initalics.

Monospace Code examples, command lines, screen output, and systemmessages appear in monospace font.

Related Policy Director DocumentsThe following table summarizes some of the available PolicyDirector documentation, located on the Tivoli SecureWay PolicyDirector support site:

Tivoli SecureWay Policy Director Technical Documents

Installation Guides

Tivoli SecureWay Policy Director Base Installation Guide

Tivoli SecureWay Policy Director WebSEAL Installation Guide

Administration Guides

Tivoli SecureWay Policy Director Base Administration Guide (thisdocument)

Tivoli SecureWay Policy Director WebSEAL Administration Guide

Tivoli SecureWay Policy Director Plug-in for Edge Server AdministrationGuide

Tivoli SecureWay Policy Director Web Portal Manager AdministrationGuide

Developer References

Tivoli SecureWay Policy Director Authorization ADK DeveloperReference

Tivoli SecureWay Policy Director Authorization API Java WrappersDeveloper Reference

xvTivoli SecureWay Policy Director Base Administration Guide

Tivoli SecureWay Policy Director Technical Documents

Tivoli SecureWay Policy Director Administration API DeveloperReference

Tivoli SecureWay Policy Director WebSEAL Developer Reference

Supplemental Documentation

Tivoli SecureWay Policy Director Release Notes

Tivoli SecureWay Policy Director Performance Tuning Guide

Tivoli SecureWay Policy Director Capacity Planning Guide

Accessing Online DocumentationThe Tivoli Customer Support Web site(http://www.tivoli.com/support/) provides links to the followingdocumentation information:

¶ Technical information, including release notes, installation andconfiguration guides, administration guides, and developerreferences.

¶ Frequently Asked Questions (FAQs)

¶ Software download information

You can find the Customer Support Handbook (a guide to supportservices) at: http://www.tivoli.com/support/getting/.

You can access the index of online Tivoli publications athttp://www.tivoli.com/support/documents/. Click on Master Indexto find product-specific support pages.

You can locate Policy Director technical documentation, by productversion, at:https://www.tivoli.com/secure/support/Prodman/html/AB.html#Security

The documentation for some products is available in PDF andHTML formats. Translated documents are also available for someproducts.

xvi Version 3.8

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

Resellers should refer tohttp://www.tivoli.com/support/smb/index.html for moreinformation about obtaining Tivoli technical documentation andsupport.

Business Partners should refer to “Ordering Documentation” on pagexvii for more information about obtaining Tivoli technicaldocumentation.

Ordering DocumentationOrder Tivoli documentation online athttp://www.tivoli.com/support/Prodman/html/pub_order.html orby calling one of the following telephone numbers:

¶ U.S. customers: (800) 879-2755

¶ Canadian customers: (800) 426-4968

Providing Feedback about Product DocumentationWe are very interested in hearing about your experience with Tivoliproducts and documentation, and we welcome your suggestions forimprovements. If you have comments or suggestions about ourproducts and documentation, contact us in one of the followingways:

¶ Send e-mail to [email protected].

¶ Fill out our customer feedback survey athttp://www.tivoli.com/support/survey/.

Contacting Customer SupportThe Tivoli Customer Support Handbook at:

http://www.tivoli.com/support/handbook/

xviiTivoli SecureWay Policy Director Base Administration Guide

http://www.tivoli.com/support/Prodman/html/pub_order.html


http://www.tivoli.com/support/survey/


provides information about all aspects of Tivoli Customer Support,including the following:

¶ Registration and eligibility

¶ How to contact support, depending on the severity of yourproblem

¶ Telephone numbers and e-mail addresses, depending on thecountry you are in

¶ What information you should gather before contacting support

xviii Version 3.8

Policy Director Overview

Policy Director is a complete authorization solution for corporateWeb, client/server, Policy Director for Operating Systems (PDOS),Policy Director for MQ Series (PDMQ), and legacy (pre-existing)applications. Policy Director authorization allows an organization tosecurely control user access to protected information and resources.By providing a centralized, flexible, and scalable access controlsolution, Policy Director allows you to build highly secure andwell-managed network-based applications and e-businessinfrastructure.

Topic Index:

¶ “Securing the Enterprise Network” on page 2

¶ “Policy Director — Core Technologies” on page 6

¶ “Policy Director Components” on page 9

¶ “Understanding Authorization: Conceptual Model” on page 13

¶ “The Policy Director Authorization Service” on page 17

¶ “Implementing a Network Security Policy” on page 23

¶ “The Policy Director Authorization API” on page 30

¶ “External Authorization Capability” on page 35

1

1Tivoli SecureWay Policy Director Base Administration Guide

1.P

olicy

Directo

rO

verview

Securing the Enterprise NetworkMany organizations now value the public Internet and privateintranets as effective and vital mediums for global communication.Electronic commerce, or e-business, has rapidly become an essentialcomponent of many business marketing strategies. Educationalinstitutions rely on the Internet for long-distance learning. On-lineservices allow individuals to send electronic mail and to tap theWeb’s vast encyclopedia of resources. Traditional applications, suchas TELNET and POP3, still prevail as important network services.

Businesses are realizing that they can use Internet technologies toenhance supply chain relationships, facilitate collaboration withbusiness partners, and provide increased customerconnectivity—provided they can expose corporate resources with ahigh degree of security. Businesses want to use the Internet as aglobal commercial and distribution vehicle, but have been hinderedby the lack of proven security policy mechanisms and managementsystems.

Policy Director is an information policy management solution thatprovides organizations with centralized network securityservices—where you can consistently implement and maintaincorporate security policy.

Policy Director provides the three primary requirements for balancedsecurity solution:

¶ Provides a variety of solutions for creating a highly securenetwork environment

¶ Provides convenient and intuitive management tools for securecentralized administration

¶ Provides security mechanisms that do not hinder permitted clientactivity on the network

Network Security Technologies and DefinitionsThe following network security services and concepts are importantto the discussion of Policy Director throughout this document:

2 Version 3.8

¶ Secure Domain — the group of users, systems, and resourcesthat share common services and usually function with a commonpurpose

¶ Access Control List (ACL) policies — the Policy Directorsecurity mechanism that provides users and groups thepermissions to perform specific operations, or actions, onprotected resources

¶ Authentication — the process of identifying any individualattempting to login to a secure domain

¶ Authorization — the process (performed by the AuthorizationService) of determining whether an individual has the right toperform an operation on a protected resource

¶ Credentials — detailed information, acquired duringauthentication, describing the user, group associations (if any),and other security-related identity attributes

¶ Encryption — the translation of electronic data into secret codethat protects the data from being examined by unauthorizedparties. Encryption facilitates the security condition known asprivacy.

¶ Integrity — the condition that electronic data is unmodifiedbetween the time it was sent and the time it was received

¶ Protected Object Policy (POP) — the Policy Director securitymechanism that dictates special conditions for accessing aprotected resource after a successful ACL policy check

¶ Protected Object Space — the virtual object representation ofactual system resources that is used for applying ACL and POPpolicies and used by the Authorization Service

¶ Registry — the datastore (such as LDAP) that maintains theaccount information for users and groups that are allowed toparticipate in the secure domain

¶ Scalability — the ability of a network system to respond toincreasing numbers of users who access resources


1.P

olicy

Directo

rO

verview

¶ Quality of Protection — the level of data security, determinedby a combination of authentication, integrity, and privacyconditions

Network Security — Common ConcernsBoth the world-wide public Internet and company-private intranetsconnect to heterogeneous computer systems, applications, andnetworks. This mixture of dissimilar hardware and software usuallyimpacts a network in the following ways:

¶ No centralized control of security for applications

¶ No unified resource location naming convention

¶ No common support for high availability of applications

¶ No common support for scalable growth

New business models require organizations to expose theirinformation resources to a previously unthought of degree. Thesebusinesses need to know that they can securely control access tothose resources.

Managing policy and users across distributed networks has provendifficult for Information Technology (IT) managers, especially sinceindividual application and system vendors implement authorizationin their own proprietary fashion.

Companies realize that developing new authorization services foreach enterprise application is an expensive process that leads to adifficult-to-manage infrastructure. A centralized authorization servicethat is accessed by developers via a standardized API could greatlyspeed time to market and reduce total-cost-of-ownership.

A centralized network security management system needs to fulfillrequirements that include:

¶ Co-exist with and/or leverage existing firewall and authenticatorarchitectures

¶ Integrate or co-exist with network and application managementframeworks

4 Version 3.8

¶ Be application-independent

Introducing Policy DirectorPolicy Director is a complete authorization and network securitypolicy management solution that provides unsurpassed end-to-endprotection of resources over geographically dispersed intranets andextranets.

In addition to its state-of-the-art security policy management feature,Policy Director supports authentication, authorization, data security,and resource management capabilities. You use Policy Director inconjunction with standard Internet-based applications to build highlysecure and well-managed intranets.

At its core, Policy Director provides:

¶ Authentication framework

Policy Director provides a wide range of built-in authenticatorsand supports external authenticators.

¶ Authorization framework

The Policy Authorization Service, accessed via a standardAuthorization API, provides permit and deny decisions on accessrequests for native Policy Director servers and third-partyapplications.

With Policy Director, businesses can now securely manage access toprivate internal network-based resources and leverage the publicInternet’s broad connectivity and ease of use. Policy Director, incombination with a corporate firewall system, can fully protect theEnterprise intranet from unauthorized access and intrusion.

The Authorization Service API StandardAuthorization services are a critical part of an application’s securityarchitecture. After a user passes the authentication process,authorization services proceed to enforce the business policy bydetermining what services and information the user can access.


1.P

olicy

Directo

rO

verview

For example, a user accessing a Web-based retirement fund would beable to view personal account information after an authorizationserver verifies the identity, credentials, and privilege attributes of thatuser.

The standards-based Authorization API allows applications to makecalls to the centralized Authorization Service, thus eliminating thenecessity for developers to write authorization code for each newapplication.

The Authorization API allows businesses to standardize allapplications on a trusted authorization framework. With theAuthorization API, businesses can provide more control over accessto resources on their networks.

Policy Director — Core TechnologiesThe Policy Director network security management solution providesand supports the following core technologies:

¶ Authentication

¶ Authorization

¶ Quality of Protection

¶ Scalability

¶ Accountability

¶ Centralized Management

AuthenticationAuthentication is the first step a client must take when making arequest for a resource from a network protected by Policy Director.The authentication process is usually dependent on the specificrequirements of the service-providing application. Policy Directorallows a highly flexible approach to authentication through the useof the Authorization API.

6 Version 3.8

Policy Director Base provides built-in support of user name andpassword authentication through the Authorization API. Developerscan build any custom authentication mechanism that uses theAuthorization API.

Authorization¶ Policy Director Authorization Service

¶ ACL and POP policies for fine-grained access control

¶ Standards-based Authorization API

¶ External authorization service capability

Quality of (Data) ProtectionQuality of Protection is the degree to which Policy Director protectsany information transmitted between client and server. Quality ofProtection is determined by the combined effect of encryptionstandards and modification-detection algorithms.

Quality of Protection levels include:

¶ Standard TCP communication (no protection)

¶ Data integrity – protects messages (data stream) from beingmodified during network communication

¶ Data privacy – protects messages from being modified orinspected during network communication

Supported Encryption StandardsPolicy Director supports the following encryption ciphers over SSL:

¶ 40-bit RC2

¶ 128-bit RC2

¶ 40-bit RC4

¶ 128-bit RC4

¶ 40-bit DES

¶ 56-bit DES

¶ 168-bit triple DES


1.P

olicy

Directo

rO

verview

Secure CommunicationPolicy Director supports the data integrity and data privacy providedby the Secure Socket Layer communication protocol.

The Secure Socket Layer (SSL) handshake protocol was developedby Netscape Communications Corporation to provide security andprivacy over the Internet. SSL works by using public key forauthentication and secret key to encrypt data that is transferred overthe SSL connection.

Policy Director supports SSL versions 2 and 3.

ScalabilityScalability is the ability to respond to increasing numbers of userswho access resources in the secure domain. Policy Director uses thefollowing techniques to provide scalability:

¶ Replication of services

v Authentication services

v Authorization services

v Security policies

v Data encryption services

v Auditing services

¶ Front-end replicated servers (WebSEAL)

v Mirrored resources for high availability

v Load balancing client requests

¶ Back-end replicated servers (WebSEAL)

v Back-end servers can be WebSEAL or third-party applicationservers

v Mirrored resources (unified object space) for high availability

v Additional content and resources

v Load balancing of incoming requests through junctions

8 Version 3.8

¶ Optimized performance by allowing the off-loading ofauthentication and authorization services to separate servers

¶ Scaled deployment of services without increasing managementoverhead

AccountabilityPolicy Director provides a number of logging and auditingcapabilities. There are log files that capture any error and warningmessages generated by Policy Director servers. There are also audittrail files that monitor Policy Director server activity.

Log files:¶ Policy Director server log files

¶ Serviceability messages

¶ Standard HTTP log files

Audit trail files:¶ Policy Director server audit trail files

Centralized Management¶ Web Portal Manager

¶ pdadmin command line utility

Policy Director ComponentsPolicy Director includes software for both client and server systems.Policy Director is supported on UNIX (including Solaris, AIX,HP-UX, and Linux) and Windows NT /2000 operating systemplatforms.


1.P

olicy

Directo

rO

verview

Web Portal ManagerThe Web Portal Manager is a Web-based graphical application usedto manage security policy for the Policy Director secure domain. TheWeb Portal Manager provides management and administration ofusers, groups, roles, permissions, policies, and application accessprovisioning.

The Web Portal Manager also includes a rich set of delegatedmanagement services that enables a business to delegate useradministration, group and role administration, securityadministration, and application access provisioning to participants(sub-domains) in the business system. These sub-domains can furtherdelegate management and administration to trusted sub-domainsunder their control, thereby supporting multi-level delegation andmanagement hierarchy based on roles.

Web Portal Managerand

pdadmin Command Line Utility

Policy Director Server System

� Security Server (authentication)� User Registry (LDAP)� Authorization Service (access control)� Management Server (pdmgrd)� WebSEAL (webseald)� Authorization Server (pdacld)� Authorization API� Administration API� IBM Global Security Kit (SSL implementation)

Operating System

Server

SSL-enabledBrowser

Client

Operating System

Figure 1. Policy Director Components

10 Version 3.8

pdadmin Command Line UtilityThe pdadmin command line utility provides a means for performingall Policy Director administration tasks. The Web Portal Managerprovides a limited range of these administration tasks.

Security ServerThe Security Server is the LDAP server that provides authenticationservices and maintains a centralized registry database which containsaccount entries for all valid users who participate in the securedomain.

The Security Server performs two important roles:

¶ Defines the groups and organizations to which the user belongsand the roles the user can assume. This information is stored ina centralized registry database. The Authorization Serviceconsiders this information when making authorization decisions.

¶ Provides authentication services for all login attempts.

The Security Server can replicate the registry database throughoutthe secure domain to prevent a single point of failure. The SecurityServer is responsible for updating all replica databases whenever achange to the master registry occurs.

Management ServerThe Management Server (pdmgrd) maintains the masterauthorization policy database for the secure domain. It is alsoresponsible for updating all authorization database replicasthroughout the secure domain. The Management Server alsomaintains location information about the other Policy Directorservers in the secure domain.

WebSEALWebSEAL (webseald) is a resource security manager that providesfine-grained HTTP and HTTPS access control.

WebSEAL is a high performance, multi-threaded Web server thataccepts HTTP and HTTPS requests. WebSEAL manages access


1.P

olicy

Directo

rO

verview

control for such resources as: URLs, URL-based regular expressions,CGI programs, HTML files, Java servlets, and Java class files.

WebSEAL, as a junction server, secures and manages third-partyWeb servers through WebSEAL junction technology. WebSEALjunctions allow you to attach additional server file systems to theWeb space and view the resources as a single, unified object space.

WebSEAL can be used to provide single sign-on capabilities forWeb-based resources. The user can authenticate to WebSEAL viastandard SSL. WebSEAL then impersonates the user using HTTPbasic and digest authentication. WebSEAL can also pass the user’sidentity as a CGI variable.

Authorization APIThe Policy Director Application Development Kit (ADK) includes anAuthorization API that lets developers build Policy Director securityand authorization directly into corporate applications. TheAuthorization API provides direct access to the AuthorizationService, which means developers no longer need to writeauthorization code for each application.

The Authorization API reduces application development time andcost. Because all network security is centrally managed by PolicyDirector, the total cost of ownership and likelihood of securitybreaches are both significantly reduced.

The technology underlying the Authorization API has been acceptedfor fast-track standardization by unanimous vote of the SecurityWorking Group of the Open Group.

Administration APIThe Administration API provides a complete set of functions for thepdadmin utility. The functions allow third-party applications toprogrammatically administer Policy Director objects, includingACLs,actions, objects, POPs, servers, users, groups, and policies.

12 Version 3.8

Policy Director Authorization ServerIn remote cache authorization mode, applications use the functioncalls provided by the Authorization API to communicate to theAuthorization Server (pdacld). The Authorization Server maintains areplica of the authorization policy database and functions as theauthorization decision-making evaluator.

The API forwards an authorization decision request to theAuthorization Server. The Authorization Server returns arecommendation based on security policy. The server can also writean audit record containing the details of the authorization request.

IBM Global Security Kit (GSKit)Policy Director uses the IBM Global Security Kit (GSKit)implementation of the SSL protocol. Administrators manage X.509certificates using the GSKit iKeyman utility.

Understanding Authorization: Conceptual ModelWhen servers enforce security in a secure domain, each client mustprovide proof of its identity. In turn, security policy determineswhether that client is permitted to perform an operation on arequested resource. Because access to every resource in a securedomain is controlled by a server, the server’s demands forauthentication and authorization can provide comprehensive networksecurity.

In security systems, authorization is distinct from authentication.Authorization determines whether an authenticated client has theright to perform an operation on a specific resource in a securedomain. Authentication ensures that the individual is who he or sheclaims to be, but says nothing about the rights to perform operationson a protected resource.

In the Policy Director authorization model, authorization policy isimplemented independently of the mechanism used for userauthentication. Users can authenticate their identity using eitherpublic/private key, secret key, or customer-defined mechanisms.


1.P

olicy

Directo

rO

verview

Part of the authentication process involves the acquisition of acredential that describes the identity of the client. Authorizationdecisions made by an authorization service are based on usercredentials.

The resources in a secure domain receive a level of protection asdictated by the security policy for the domain. The security policydefines the legitimate participants of the secure domain and thedegree of protection surrounding each resource requiring protection.

The basic components of the authorization process include:

¶ A resource manager responsible for implementing the requestedoperation when authorization is granted

A component of the resource manager is a policy enforcer thatdirects the request to the authorization service for processing.

¶ An authorization service that performs the decision-makingaction on the request

Traditional applications bundle the policy enforcer and resourcemanager into one process. Examples of this structure include PolicyDirector WebSEAL and third-party applications.

ResourceManager

AuthenticatedClient

AuthorizationCheck

Yes / No

Request forResource

AuthorizationService

PolicyEnforcer

Resources

ApplicationServer

Figure 2. General Authorization Model

14 Version 3.8

The independent functionality of these authorization componentsallows much flexibility in the design of the security enforcementstrategy.

For example, such independence allows the security administrator tocontrol:

¶ Where the processes are located

¶ Who writes the code for the processes

¶ How the processes perform their tasks

The Benefits of a Standard Authorization ServiceAuthorization in most systems, both legacy and new, is tightlycoupled to individual applications. Companies typically buildapplications over time to serve their business needs. Many of theseapplications require some specific form of authorization.

The result is often a wide variety of applications with differingauthorization implementations. These proprietary authorizationimplementations require separate administration, are difficult tointegrate, and result in higher costs of ownership.

A distributed authorization service can provide these independentapplications with a standard authorization decision-makingmechanism. Benefits of such a standard authorization service wouldinclude:

¶ Reduced cost of developing and managing access to applications

¶ Reduced total cost of ownership and management of separateauthorization systems

¶ Leverage of existing security infrastructure

¶ Allow new businesses to open more securely

¶ Enable newer and different kinds of applications

¶ Allow shorter development cycles

¶ Share information securely


1.P

olicy

Directo

rO

verview

Introducing the Policy Director Authorization ServicePolicy Director integrates into existing legacy and emerginginfrastructures and provides secure, centralized policy managementcapability. The Policy Director Authorization Service—together withresource managers (such as WebSEAL)—provides a standardauthorization mechanism for business network systems.

Existing applications can take advantage of the AuthorizationService. Authorization policy is based on user or group roles and canbe applied to network servers, individual transactions or databaserequests, specific Web-based information, management activities, anduser-defined objects.

The Authorization API (See “The Policy Director Authorization API”on page 30) allows existing applications to make calls to the

Authorization Service which in turn makes decisions based on thecorporate security policy.

The Policy Director Authorization Service is also extensible and canbe configured to call on other authorization services for additionalprocessing using the External Authorization Service plug-in interface.

Policy Director Authorization Service BenefitsThe Authorization Service provides the following benefits:

¶ The service is application independent

¶ The service uses a standard authorization coding style that islanguage independent (the Authorization API)

¶ The service is centrally managed and therefore easy toadminister — the addition of a new employee, for example,requires modifying the privilege database in one central location,rather than across multiple systems

¶ The service addresses the application of security services in aheterogeneous cross-platform environment

¶ The service integrates existing non-Policy Director authorizationsystems through an external authorization service capability

16 Version 3.8

¶ The service has a scalable and flexible architecture that can beeasily integrated with existing infrastructure

¶ The service enables multi-tiered authorization — a credentialspacket can be passed through the multiple layers of anapplication process or transaction

¶ The service uses a common and effective auditing model

¶ The service is independent of any authentication mechanism

The Policy Director Authorization ServiceThe Policy Director Authorization Service is responsible for theauthorization decision-making process that helps to enforce anetwork security policy. Authorization decisions made by theAuthorization Service result in the approval or denial of clientrequests to perform operations on protected resources in the securedomain.

ComponentsThe Authorization Service is made up of three basic components:

¶ Master authorization policy database

¶ Management Server

¶ The authorization decision-making evaluator

Master Authorization Policy DatabaseThe master authorization policy database contains the security policyinformation for all resources in the secure domain. The database alsocontains all necessary credential information associated with theparticipants of the secure domain.

You use the Web Portal Manager to enter and modify the contents ofthis database.

Management Server (pdmgrd)The Management Server maintains the master authorization policydatabase, replicates this policy information throughout the securedomain, and updates the database replicas whenever a change ismade to the master.


1.P

olicy

Directo

rO

verview

The Management Server also maintains location information aboutthe other Policy Director and non-Policy Director servers operatingin the secure domain.

Note: There must be only one instance of the Management Server inany secure domain.

Authorization EvaluatorThe authorization evaluator is the decision-making process thatdetermines a client’s ability to access a protected resource based onthe security policy. The evaluator makes its recommendation to theresource manager which, in turn, responds accordingly.

Registry database replication parameters are configurable for eachevaluator.

The following figure illustrates the main components of theAuthorization Service:

18 Version 3.8

Authorization Service InterfacesThe Authorization Service has two interfaces where interaction takesplace:

¶ Management interface — The security administrator managesthe security policy of the network by using the Web PortalManager (and/or the pdadmin utility) to apply policy rules(templates) on network resources and register the credentials ofparticipants in the secure domain.

The Web Portal Manager applies this security policy data to themaster authorization policy database via the Management Server.

This interface is complex and involves detailed knowledge of theobject space, policy templates, and credentials.

Authorization Service

ManagementServer

(pdmgrd)Master

AuthorizationPolicy

AuthorizationEvaluator

ResourceManager

ReplicaAuthorization

Policy

Figure 3. Authorization Service Components


1.P

olicy

Directo

rO

verview

¶ Authorization API — The Authorization API passes requestsfor authorization decisions from the resource manager to theauthorization evaluator which then passes back arecommendation. The Tivoli SecureWay Policy DirectorAuthorization ADK Developer Reference contains the details ofthis API.


ManagementServer

(pdmgrd)Master

AuthorizationPolicy


AuthAPI

ResourceManager

Web PortalManager


Policy

ManagementInterface

Figure 4. Authorization Service: Interfaces

20 Version 3.8

Replication for Scalability and PerformanceAuthorization Service components can be replicated to increaseavailability in a heavy-demand environment.

You can configure the master authorization policy database,containing policy rules and credential information, to automaticallyreplicate. Applications that call the Authorization Service have twooptions for referencing this database information:

¶ The application — when configured to work seamlessly with theauthorization evaluator — uses a local cache of the database

The database is replicated for each application that uses theAuthorization Service in local cache mode.

¶ The application uses a shared replica cached by the remoteAuthorization Server component

The database is replicated for each instance of the AuthorizationServer. Many applications can access a single AuthorizationServer.

Update notification from the Management Server (whenever achange has been made to the master authorization policy database)triggers the caching process to update all replicas.


1.P

olicy

Directo

rO

verview

Performance Notes¶ In addition to update notifications direct from the Management

Server, the application servers also check the version of themaster authorization policy database every few minutes to ensurethey have not missed an update notification.

If an update notification fails to reach a server, a log entry iscreated. In both cases a retry mechanism also ensures the updatehappens in the future.

¶ The cached authorization policy information results in highsystem performance. For example, when WebSEAL does anauthorization check, it checks the policy template in its owncached version of the database. WebSEAL does not have toaccess the network to obtain this information from the masterdatabase. The result is very fast response times (performance)for authorization checks.

¶ Individual authorization results are not cached by the callingapplication server.


Policy


Policy


ManagementServer

(pdmgrd)Master

AuthorizationPolicy

Web PortalManager


AuthAPI

ResourceManager


Policy

Figure 5. Replicated Authorization Service Components

22 Version 3.8

Implementing a Network Security PolicyThe security policy for a secure domain is determined by controllinguser and group participation in the domain and applying rules,known as access control list (ACL) policies and protected objectpolicies (POP), to resources requiring protection. The AuthorizationService enforces these policies by matching a user’s credentials withthe permissions in the policy assigned to the requested resource. Theresulting recommendation is passed to the resource manager whichcompletes the response to the original request.

Defining the Network Security PolicyThe Authorization Service uses a central database that lists allresources in the secure domain and the ACL and POP policiesassigned to each resource. This master authorization policy databaseand the user registry (containing user and group accounts) are thekey components that help define a network security policy.

In summary, a network security policy controls:

1. Users and groups allowed to participate in the secure domain

The user registry maintains this information.

2. The level of protection on all objects in the secure domain

The master authorization policy database maintains thisinformation.

The Protected Object SpaceThe protected object space is a hierarchical portrayal of resourcesbelonging to a secure domain. The objects that appear in thehierarchical object space represent the actual network resources.

¶ System resource — the actual physical file or application.

¶ Protected object — the logical representation of an actualsystem resource used by the Authorization Service, the WebPortal Manager, and other Policy Director management utilities.

Policy templates can be attached to objects in the object space toprovide protection of the resource. The Authorization Service makesauthorization decisions based these templates.


1.P

olicy

Directo

rO

verview

The following object space categories are used by Policy Director:

¶ Web objects

These objects represent anything that can be addressed by anHTTP URL. This includes static Web pages and dynamic URLsthat are converted to database queries or some other type ofapplication.

¶ Policy Director management objects

These objects represent the management activities that can beperformed via the Web Portal Manager. The objects represent thetasks necessary to define users and set security policy. PolicyDirector supports delegation of management activities and canrestrict an administrator’s ability to set security policy to asubset of the object space.

¶ User-defined objects

These objects represent customer-defined tasks or networkresources protected by applications using the AuthorizationService via the Authorization API.

ManagementObjects

WebObjects

User-DefinedObjects

Figure 6. Policy Director Protected Object Space

24 Version 3.8

Defining and Applying ACL and POP PoliciesSecurity administrators protect system resources by defining rules,known as ACL and POP policies, and applying these policies to theobject representations of those resources in the object space.

The Authorization Service performs authorization decisions based onthe policies applied to these objects. When a requested operation ona protected object is permitted, the application responsible for theresource implements this operation.

One policy can dictate the protection parameters of many objects.Any change to the rule will affect all objects to which the templateis attached.

Explicit and Inherited PolicyPolicy can be explicitly applied or inherited. The Policy Directorprotected object space supports inheritance of ACL and POP policyattributes. This is an important consideration for the securityadministrator who manages the object space. The administrator onlyneeds to apply explicit policies at points in the hierarchy where therules must change.

Examples of types of policy include:

¶ Hard-coded rules

ManagementObjects

WebObjects

User-DefinedObjects

Explicit RuleInherited

Rule

Figure 7. Explicit and Inherited Policies


1.P

olicy

Directo

rO

verview

¶ External authorization capability

¶ Special secure labeling

¶ Access control lists (ACLs)

The Access Control List (ACL)An access control list policy, or ACL policy, is the set of controls(permissions) that specifies the conditions necessary to performcertain operations on that resource. ACL policy definitions areimportant components of the security policy established for thesecure domain. ACL policies, like all policies, are used to stamp anorganization’s security standards onto the resources represented inthe protected object space.

An ACL policy specifically controls:

1. What operations can be performed on the resource

2. Who can perform these operations

An ACL policy is made up of one or more entries that include userand group designations and their specific permissions or rights.

user peter ---------T---rx

group engineering ---------T---rx

user michael ---------T---rx

unauthenticated ---------------

ACL(containing multiple

entries)

Figure 8. ACL Policy

26 Version 3.8

Protected Object Policies (POP)ACL policies provide the Authorization Service with information tomake a “yes” or “no” answer on a request to access a protectedobject and perform some operation on that object.

POP policies contain additional conditions on the request that arepassed back to Policy Director Base and the Resource Manager(such as WebSEAL) along with the “yes” ACL policy decision fromthe Authorization Service. It is the responsibility of Policy Directorand the Resource Manager to enforce the POP conditions.

The following tables list the available attributes for a POP:

Enforced by Policy Director Base

POP Attribute Description

Name Name of the policy. This becomes the<pop-name> in the pdadmin pop commands.

Description Descriptive text for the policy. This appears inthe pop show command.

Warning Mode Provides administrators a means to test ACLand POP policies.

Audit Level Specifies type of auditing: all, none, successfulaccess, denied access, errors.

Time-of-Day Access Day and time restrictions for successful accessto the protected object.

Enforced by Resource Manager (such as WebSEAL)

POP Attribute Description

Quality of Protection Specifies degree of data protection: none,integrity, privacy.

IP EndpointAuthentication MethodPolicy

Specifies authentication requirements foraccess from members of external networks.

Policy Administration: The Web Portal ManagerThe Web Portal Manager is a Web-based graphical application usedto manage security policy in a Policy Director secure domain. The


1.P

olicy

Directo

rO

verview

pdadmin command line utility provides the same administrationcapabilities as the Web Portal Manager, plus many commands notsupported by the Web Portal Manager.

From the Web Portal Manager (or pdadmin), you can manage theuser registry, the master authorization policy database, and the PolicyDirector servers. You can also add and delete users / groups andapply ACL and POP policies to network objects.

The Authorization Process: Step-by-StepThe following diagram illustrates the complete authorization process:

SecurityServer

Web PortalManager

Windows NT

Workstation

MasterAuthorization

Policy

UserRegistry

ManagementServer

Apply policies on theprotected object space

Create, modify, anddelete user and group

accounts

Figure 9. Web Portal Manager: Administration of the Security Policy

28 Version 3.8

1. An authenticated client request for a resource is directed to theresource manager server and intercepted by the policy enforcerprocess.

The resource manager can be WebSEAL (for HTTP, HTTPSaccess) or a third-party application.

2. The policy enforcer process uses the Authorization API (See“The Policy Director Authorization API” on page 30) to call theAuthorization Service for an authorization decision.

3. The Authorization Service performs an authorization check onthe resource, represented as an object in the protected objectspace. Base POP policies are checked first. Next the ACL policyattached to the object is checked against the client’s credentials.Then, POP policies enforced by the resource manager arechecked.

4. The decision to accept or deny the request is returned as arecommendation to the resource manager (via the policyenforcer).

Client


Secure Domain

AuthorizationPolicy

Protected ObjectSpace

2. Request forAuthorization

(AuthAPI)

5. AuthorizedOperation

1. Request

6. Response

3. AuthorizationCheck

4. AuthorizationDecision(AuthAPI)

Resources

/

ResourceManager

PolicyEnforcer

Figure 10. The Policy Director Authorization Process


1.P

olicy

Directo

rO

verview

5. If the request is finally approved, the resource manager passesthe request on to the application responsible for the resource.

6. The client receives the results of the requested operation.

The Policy Director Authorization APIThe Policy Director Authorization Application ProgrammingInterface (API) allows Policy Director applications and third-partyapplications to query the Authorization Service to make authorizationdecisions.

The Authorization API is the interface between the resource manager(requesting the authorization check) and the Authorization Serviceitself. The Authorization API allows the policy-enforcing applicationto ask for an authorization decision, but shields the application fromthe complexities of the actual decision-making process.

The Authorization API provides a standard programming model forcoding authorization requests and decisions. The Authorization APIlets you make standardized calls to the centrally managedAuthorization Service from any legacy or newly developedapplication.

The Authorization API can be used in one of two modes:

¶ Remote Cache Mode

In this mode, the API is initialized to call the (remote)Authorization Server (pdacld) to perform authorization decisionson behalf of the application. The Authorization Server maintainsits own cache of the replica authorization policy database. Thismode is recommended for handling authorization requests fromapplication clients.

(See “Authorization API: Remote Cache Mode” on page 32)

¶ Local Cache Mode

In this mode, the API is initialized to download and maintain alocal replica of the authorization database for the application.Local cache mode provides better performance because theapplication performs all authorization decisions locally instead of

30 Version 3.8

across a network. However, the overhead of database replicationand the security implications of using this mode make it bestsuited for use by trusted application servers, such as WebSEAL.

(See “Authorization API: Local Cache Mode” on page 34)

One of the primary values and benefits of the Authorization API isits ability to shield the user from the complexities of theAuthorization Service mechanism itself. Issues of management,storage, caching, replication, credential formats, and authenticationmethods are all hidden behind the Authorization API.

The Authorization API also works independently from the underlyingsecurity infrastructure, the credential format, and the evaluatingmechanism. The Authorization API makes it possible to request anauthorization check and get a simple “yes” or “no” recommendationin return. The details of the authorization check mechanism areinvisible to the user.

Using the Authorization API: Two ExamplesThird-party applications can use the Authorization API to performaccess control on very specific and specialized processes.

Example 1:

A graphical user interface can be designed to dynamically show taskbuttons as active or inactive, according to the results of theauthorization check.

Example 2:

Another use of the Authorization API is demonstrated in thefollowing figure, illustrating a request for a CGI transaction by aWeb application.

The lowest level of authorization, illustrated in Figure A, involves an“all-or-nothing” access control on the URL. This coarse-grained levelof authorization only determines if the client can run the CGIprogram. If access is allowed to the CGI application, no furthercontrol is available to resources manipulated by the CGI application.


1.P

olicy

Directo

rO

verview

In Figure B, access controls have been set on resources that the CGIprogram manipulates. The Web application is configured to use theAuthorization API. Now the CGI program can call the AuthorizationService to make authorization decisions on the resources itmanipulates — based on the identity of the requesting client.

Authorization API: Remote Cache ModeIn remote cache mode, applications use the function calls providedby the Authorization API to communicate to the (remote)Authorization Server (pdacld). The Authorization Server functions asthe authorization decision-making evaluator and maintains its ownreplica authorization policy database.

WebSEAL

Client

WebApplication

ObjectsManipulated

by CGI


WebSEAL

Client

WebApplication

ObjectsManipulated

by CGI


Figure A

Figure B

Fine-grainedAuthorized

AccessRequest

Response

Request

Response

Coarse-grainedAccess

API

Function Call

Figure 11. Example Use of the Authorization API

32 Version 3.8

The Authorization Server makes the decision and returns arecommendation to the application via the API. The server can alsowrite an audit record containing the details of the authorizationdecision request.

There must be an Authorization Server running somewhere in thesecure domain. The Authorization Server can reside on the samemachine as the application, or on another machine. You can alsoinstall the Authorization Server on more than one machine in asecure domain to allow for high availability. The Authorization APIwill transparently fail-over when a particular Authorization Serverfails.

AuthAPI


ManagementServer

(pdmgrd)Master

AuthorizationPolicy


AuthAPI

Third-PartyApplication


Policy

AuthenticatedClient

Resources

pdacld

Figure 12. Authorization API: Remote Cache Mode


1.P

olicy

Directo

rO

verview

Authorization API: Local Cache ModeIn local cache mode, the API downloads and maintains a replica ofthe authorization policy database on the application’s local filesystem. It performs all authorization decisions in-memory, whichresults in higher performance and better reliability.

You must manually register any application using the AuthorizationAPI in local cache mode with the Authorization Service. TheManagement Server must know the location of any local cache modeAuthorization API application so it can update the replicaauthorization policy database associated with it.

The local replica is persistent across invocations of the application.When the API starts in replica mode, it checks for any updates to themaster authorization policy database that might have occurred sincethe local replica was built.

34 Version 3.8

External Authorization CapabilityIn some situations, the standard Policy Director policyimplementations—Access Control Lists and Protected ObjectPolicies—may not be able to express all the authorization rulesrequired by an organization’s security policy. Policy Directorprovides optional external authorization capability to accommodateany additional authorization requirements.

The External Authorization Service allows you to impose additionalauthorization controls and conditions that are dictated by a separate(external) authorization service module.


ManagementServer

(pdmgrd)Master

AuthorizationPolicy


AuthAPI

WebSEALor

Third-Party


Policy

AuthenticatedClient

Resources

Figure 13. Authorization API: Local Cache Mode


1.P

olicy

Directo

rO

verview

Extending the Authorization ServiceExternal authorization capability is automatically built into thePolicy Director Authorization Service. If you configure an ExternalAuthorization Service, the Policy Director Authorization Servicesimply incorporates the access decision paths into its evaluationprocess.

Applications that use the Authorization Service—such as WebSEALand any application using the Authorization API—benefit from theadditional, but seamless, contribution of a configured ExternalAuthorization Service. Any addition to the security policy throughthe use of an External Authorization Service is transparent to theseapplications and requires no change to the applications.

The External Authorization Service architecture allows the fullintegration of an organization’s existing security service. An ExternalAuthorization Service preserves a company’s initial investment insecurity mechanisms by allowing legacy servers to be incorporatedinto the Policy Director authorization decision-making process.

Imposing Conditions on Resource RequestsAn External Authorization Service can be used to impose morespecific conditions or system-specific side effects on a successful orunsuccessful access attempt.

Examples of such conditions include:

¶ Cause an external auditing mechanism to record the successfulor unsuccessful access attempt

¶ Actively monitor the access attempt and cause an alert or alarmwhenever unacceptable behavior is detected

¶ Billing / micro-payment transactions

¶ Impose access quotas on a protected resource

The Authorization Evaluation ProcessAn authorization decision that incorporates an external authorizationserver takes place in the following manner:

36 Version 3.8

1. If a trigger condition is met during the course of an accessdecision, the External Authorization Services that have beenconfigured for that condition are each called in turn to evaluatetheir own external authorization constraints.

Invocation of the External Authorization Service occursregardless of whether or not the necessary permission is grantedto the user by the Policy Director Authorization Service.

2. Each External Authorization Service returns a decision ofpermitted, denied, or indifferent.

When “indifferent” is returned, the External AuthorizationService has determined that its functionality is not required forthe decision process and that it will not participate.

3. Each External Authorization Service decision is weightedaccording to the level of importance that its decision carries inthe process.

The weighting of individual External Authorization Services isconfigured when the service plug-in is loaded.

4. All authorization decision results are summed and combined withthe decision made by the Policy Director Authorization Service.The resulting decision is returned to the caller.

ExampleThe following figure illustrates an authorization decision involving aWebSEAL server and an External Authorization Service.


1.P

olicy

Directo

rO

verview

In this example, the purpose of the External Authorization Service isto impose a quota restriction on how often the photo-quality printerresource can be accessed.

The service implementation imposes a limit on the number of jobsubmissions that any one person can make to this printer in oneweek. An External Authorization Service trigger condition has beenattached to the photo printer resource so that the ExternalAuthorization Service is invoked anytime that the photo printer isaccessed.

The External Authorization Service has been loaded with the defaultdecision weighting of 101, which overrides any decision made bythe Policy Director Authorization Service, should it need to do so.

1. The WebSEAL Server receives a request from a client for accessto an online photo printing resource. The client is a member of

Client


Third-PartyResource Manager

Secure Domain

AuthorizationPolicy

Protected ObjectSpace

2. Request forAuthorization

7. Denied Access

1. Request

8. Response:"Denied"

3. AuthorizationCheck

(allowed +100)

6. Combined AuthorizationDecision (denied -1)

Resources

/

ExternalAuthorization

Service

5. External AuthorizationResult (denied -101)

4. ExternalAuthorization

Check

Authzn API

Figure 14. External Authorization Service with WebSEAL

38 Version 3.8

the appropriate group GraphicArtists and so is normallypermitted to submit jobs to the printer.

2. The WebSEAL Server first consults the Policy DirectorAuthorization Service to determine whether the requesting userhas permission to submit jobs to the printer.

3. The Policy Director Authorization Service checks the accesspermissions on the target requested object and compares thesewith the capabilities of the requesting user:group GraphicArtists rx

In the ACL on the printer resource, the “x” permission grants anyuser in the GraphicArtists group access to the resource.Therefore, the Policy Director Authorization Service grants theuser permission to submit the job.

4. Since the photo printer resource is being accessed and anExternal Authorization Service trigger condition was attached tothis object, a request is also made to the External AuthorizationService configured for that trigger condition.

The External Authorization Service receives all of the AccessDecision Information (ADI) that was passed in with the originalaccess decision check by WebSEAL.

5. The External Authorization Service consults the record ofprevious accesses made by this user. If the requesting user hasnot exceeded their quota for the week, it returns an accessdecision of “indifferent”.

The implication is that the External Authorization Service isindifferent to the request and has no intention of participating inthe access decision because its conditions for denying accesshave not been met.

However, if the user has exceeded their quota, then the ExternalAuthorization Service returns a decision of “access denied”.

For this example, it is assumed that the requester has exceededtheir quota and that the External Authorization Service detectsthis and returns an “access denied” decision.


1.P

olicy

Directo

rO

verview

6. The Policy Director Authorization Service receives the “accessdenied” result from the External Authorization Service. It thentakes this decision and weights it with the default ExternalAuthorization Service weighting value of 101.

The results of the External Authorization Service decision andthe decision made by the Policy Director Authorization Serviceare combined. The result is “access denied” because the result ofthe External Authorization Service (-101) outweighs that of thePD Authorization Service (100).

7. The WebSEAL Server rejects the job submission to the photoprinter resource.

8. The WebSEAL Server returns a response to the caller to indicatethat the job was rejected.

Implementing an External Authorization ServiceTwo general steps are required to set up an External AuthorizationService:

1. Write an External Authorization Service plug-in module with anauthorization interface that can be referenced during authorizationdecisions.

2. Register the External Authorization Service with Policy Directorso that Policy Director authorization clients can load the plug-inservice at initialization time.

Registering the service sets a trigger condition for the invocation ofthe External Authorization Service. When the trigger condition isencountered during an authorization check, the ExternalAuthorization Service interface is invoked to make an additionalauthorization decision.

Refer to the Tivoli SecureWay Policy Director Authorization APIDeveloper Reference for advanced details on implementing anExternal Authorization Service.

Deployment StrategiesPolicy Director allows you to implement an External AuthorizationService in several ways:

40 Version 3.8

¶ Any number of external authorization servers can be added toyour secure domain to perform a variety of authorizationevaluations. Each External Authorization Service is loaded intothe individual local-mode Authorization API client application.Applications that can load External Authorization Servicesinclude WebSEAL (webseald), the Authorization Server(PDAcld), other Policy Director servers, and any authorizationapplications written by the customer.

¶ Remote-mode authorization API clients, which make requests tothe Authorization Server for authorization decisions,automatically make use of any External Authorization Servicethat are loaded by the Authorization Server.

¶ More than one External Authorization Service can be called forany single trigger condition. In this case, the results of eachExternal Authorization Service is weighted accordingly and thenthe results are combined with the result of the Policy DirectorAuthorization Service.

¶ Trigger conditions can be placed upon objects, using a ProtectedObject Policy (POP) trigger, such that any request to an object,regardless of the operation that is being requested, triggers a callto the External Authorization Services that are configured for thetrigger.

¶ Trigger conditions can also be placed upon the operationsrequested by a user. For example an External AuthorizationService can be triggered specifically when a user requests awrite operation to a protected resource, but not for any otheroperation. It is then possible to develop sets of operations forwhich one or more External Authorization Services incombination are triggered according the set of operationsrequested.

¶ The External Authorization Services are implemented asdynamically loadable library (DLL) modules. This greatlysimplifies the task of External Authorization Servicedevelopment. There is no requirement to make remote requeststo the External Authorization Service and the overhead ofmaking the call is equivalent to the overhead of a function call.


1.P

olicy

Directo

rO

verview

¶ The combination of the Authorization API and an ExternalAuthorization Service provides a highly extensible and flexiblesolution for implementing complex security policy.

42 Version 3.8

Managing the Protected ObjectSpace

A Policy Director secure domain contains physical resources thatusually need some level of protection. Resources can include files,directories, and printer services. Policy Director uses a virtualrepresentation of these resources called the protected object space.

Resources can be protected by attaching ACL and POP policies tothe object representations of these resources. This chapter discussesthe protected object space and how you can create extensions to theobject space to support custom application requirements.

Topic Index:

¶ “Understanding the Protected Object Space” on page 43

¶ “Defining a Database Object Space” on page 48

Understanding the Protected Object SpaceA Policy Director secure domain contains physical resources thatneed some level of access protection. Resources can include files,directories, network ports, applications, and printer services.

The Policy Director security model depends on ACL and POPpolicies to provide fine-grained protection for these resources. Acorporate security policy is implemented by the strategicallyapplying custom ACL and POP policies to those resources requiring

2


2.M

anag

ing

the

Pro

tectedO

bject

Sp

ace

protection. The Policy Director Authorization Service makesdecisions to permit or deny access to resources based on usercredentials and the specific permissions and conditions set in theACL and POP policies.

In order to apply ACL and POP policies and allow the AuthorizationService to perform its security checks, Policy Director uses a virtualobject representation of secure domain resources called the protectedobject space.

As a Policy Director security administrator, you use the Web PortalManager or the pdadmin utility to attach ACL and POP policies tothe logical objects in the object space.

Elements of the Protected Object SpaceThe Policy Director protected object space is the logical andhierarchical portrayal of resources belonging to a secure domain.Objects that appear in the hierarchical object space represent actualphysical network resources.

¶ System Resource – the actual physical file, network service, orapplication

¶ Protected Object – the logical representation of an actualsystem resource used by the Authorization Service, the WebPortal Manager, and other Policy Director management utilities

The protected object space uses two types of objects:

¶ Container objects

Container objects are structural designations that allow you toorganize the object space hierarchically into distinct functionalregions. Container objects contain resource objects.

¶ Resource objects

Resource objects are the representations of actual networkresources (such as services, files, and programs) in your securedomain.

44 Version 3.8

container objects

resource objects

Figure 15. Policy Director Protected Object Space


2.M

anag

ing

the

Pro

tectedO

bject

Sp

ace

Protected Object Space HierarchyThe structural top, or start, of the protected object space is the rootcontainer object. The symbol for root is the forward nslash ( / ).

The following object space categories follow the root object:

¶ Web objects ( /WebSEAL container)

The WebSEAL container object is the root of the logical Webspace of the secure domain. All HTTP operations are authorizedagainst some object in this sub-tree.

Web objects represent anything that can be addressed by a URL.This includes static Web pages and dynamic URLs that areconverted to database queries or some other type of applicationinvocation by a Web-to-application gateway.

¶ Policy Director management objects ( /Managementcontainer)

The Management container object is the root of the logical spacecontrolling all Policy Director management operations.Management objects represent the services required to defineusers and groups, and set security policy. These tasks can beperformed using the Web Portal Manager or the pdadmin utility.

Sub-divisions of the /Management region include:

v User management (/Users)

v Group management (/Groups)

v GSO management (/GSO)

v Server management (/Server)

v ACL policy (/ACL)

v POP policy (/POP)

v Configuration authorization control (/Config)

v Third-party authorization control (/Action)

v Authorization database replication control (/Replica)

46 Version 3.8

Policy Director supports delegation of certain managementactivities and can restrict an administrator’s ability to set securitypolicy to a subset of the object space.

¶ User-defined objects

These objects represent customer-defined tasks or networkresources protected by third-party applications that use theAuthorization API to make calls to the Policy DirectorAuthorization Service.

WebSEAL Management

/ (root)

server1 server2

Web Objects

Action

Server Replica

User-Defined

ManagementObjects

User-DefinedObjects

Users

Groups

POP

GSO

Config

ACL

Figure 16. Regions of the Policy Director Protected Object Space


2.M

anag

ing

the

Pro

tectedO

bject

Sp

ace

User-defined Object Space for Third-PartyApplications

Policy Director can provide authorization services to any third-partyapplication object defined by the protected object space.

A region of the object space needs to be defined for each applicationthat is using Policy Director. WebSEAL, for example, has its ownobject space (/WebSEAL). Policy Director stores managementobjects in the /Management object space.

These object spaces appear in a pdadmin objectspace listcommand:pdadmin> objectspace list

/WebSEAL/Management

Policy Director and third-party applications make calls to theAuthorization Service through the Authorization API. Two necessarysteps are required to integrate a third-party application with theAuthorization Service:

¶ Describe the third-party application object space

¶ Apply permissions on any objects requiring protection

Optional “user-defined object” containers are regions of the protectedobject space where you can create objects for third-party application.Before you can add new objects, you must define a new object spacecontainer.

Defining a Database Object SpacePolicy Director allows you to extend its authorization services toobjects belonging to a user-defined third-party object space. Twonecessary steps are required to integrate a third-party object spacewith Policy Director:

¶ Describe the third-party application’s object space to PolicyDirector

¶ Apply ACL and POP policies to any objects requiring protection

48 Version 3.8

The pdadmin objectspace commands allow you to easily createuser-defined object space regions and manage the objects containedin these spaces. User-defined object spaces created with thesecommands are dynamic because they can be updated while PolicyDirector is running.

Creating a New User-defined Container ObjectUse the pdadmin objectspace and object commands to manageuser-defined object spaces. The objectspace command creates acontainer type object.

Note: The default Policy Director object spaces (/WebSEAL and/Management) cannot be controlled with the pdadminobjectspace commands.

Syntax:pdadmin> objectspace create <name> <description> <type>

The object space name must begin with a forward slash (/).

The description appears in the Web Portal Manager.

The type can be one of the following categories:

Object Types

0 – unknown1 – secure domain2 – file3 – executable program4 – directory5 – junction6 – WebSEAL server7 – unused8 – unused

9 – HTTP server10 – non-existent object11 – container object12 – leaf object13 – port14 – application container object15 – application leaf object16 – management object17 – unused

The type category is only used by the Web Portal Manager todisplay an appropriate icon with the object.


2.M

anag

ing

the

Pro

tectedO

bject

Sp

ace

When creating an object, a type must be specified. You can select anappropriate category, or use type 0 for “unknown”.

For example:pdadmin> objectspace create /Test-Space “New Object Space” 14pdadmin> objectspace list

/WebSEAL/Management/Management/Users/Management/Groups/Test-Space

Administration Notes:¶ It is best to create a separate object space for each third-party

application.

¶ You must define the new object space before you can addobjects.

¶ The root of the object space—created at the same time theobject space is defined—automatically has theispolicyattachable attribute set.

Creating and Deleting ObjectsOnce an object space has been created, you can populate it withobjects.

Use the pdadmin objects commands to manage user-definedobjects.pdadmin> object create <name> <description> <type>ispolicyattachable {yes|no}

An object has the following fields:

Argument Description

Name This is the fully qualified location of the object inthe object space, beginning with an existing objectspace name.

Description The text description of the object.

50 Version 3.8


Type The type of the object to be created. Used by theWeb Portal Manager to display an appropriateicon.

ispolicyattachable Indicates if a POP policy can be attached to theobject. If set to “no”, the object inherits policyfrom above. Used to force child objects to use thesame policy as the parent.

For example:pdadmin> object create /Test-Space/folder1 “Folder 1” 14ispolicyattachable yes

pdadmin> object list /Test-Spacefolder1

pdadmin> object show /Test-Space/folder1Name: /Test-Space/folder1

Description: Folder 1Type: (Application Container Object) : 14Is Policy Attachable: yes

pdadmin> object create /Test-Space/folder2 “Folder 2” 14ispolicyattachable no

pdadmin> object listandshow /Test-SpaceName: folder1

Description: Folder 1Type: (Application Container Object) : 14Is Policy Attachable: yes

Name: folder2Description: Folder 2Type: (Application Container Object) : 14Is Policy Attachable: no

pdadmin> object delete /Test-Space/folder1pdadmin> object list /Test-Space

folder2


2.M

anag

ing

the

Pro

tectedO

bject

Sp

ace

Administration Notes:¶ Child objects are not moved when you change the name of a

parent object. Child objects can therefore be left without parentobjects. You must move all child objects when you change thename of a parent object.

¶ If the ispolicyattachable field is left out in the pdadmin objectcreate command, the utility assumes that you intended to use theobjectspace create command. An objectspace is created ratherthan an object.

52 Version 3.8

Using Access Control Policies

Policy Director uses a virtual representation of the resources in thesecure domain—called the protected object space. Resources can beprotected by defining special security policies (rules) and attachingthese policies to the object representation of this resource in theprotected object space.

The policy type that defines who has access to an object, and whatoperations can be performed on the object, is known as an accesscontrol list policy or ACL policy. ACL policies are used to helpstamp an organization’s security policy onto the resources belongingto the secure domain.

Topic Index:

¶ “Introducing the ACL Policy” on page 54

¶ “ACL Entry Syntax” on page 56

¶ “How the Authorization Service Uses ACL Policies” on page 60

¶ “Evaluating an ACL” on page 63

¶ “Sparse ACL Model: ACL Inheritance” on page 64

¶ “Creating Extended ACL Actions and Action Groups” on page71

¶ “ACL Policies and the Protected Object Space” on page 75

¶ “WebSEAL Permissions” on page 76

¶ “Management Permissions” on page 77

3


3.U

sing

Access

Co

ntro

lP

olicies

¶ “Object and Object Space Permissions” on page 87

¶ “Default Administration ACL Policies” on page 87

Introducing the ACL PolicyAn access control list policy (ACL) is a method used by PolicyDirector to provide fine-grained protection to resources in the securedomain.

An ACL policy is a set of rules, or permissions, that specify theconditions necessary to perform an operation on a protected object.An ACL policy identifies the operations permitted on a protectedobject and lists the identities (users and groups) who can performthose operations.

¶ User and group identities are defined in the Policy Directorregistry

¶ The protected object space and ACL policies are defined in themaster authorization database

Each ACL policy has a unique name, or label. Each ACL policy canbe applied to one or more objects.

An ACL policy consists of one or more entries that include user andgroup designations and their specific permissions.

ACL Policy EntriesAn ACL policy consists of one or more entries describing:

¶ The names of users and groups whose access to the object isexplicitly controlled

¶ The specific operations permitted to each user, group, or role

¶ The specific operations permitted to the special any-other andunauthenticated user categories

A user represents any authenticated Policy Director identity.Typically, users represent network users or application servers.

54 Version 3.8

A group is a collection of one or more users. A networkadministrator can use group ACL entries to easily assign the samepermissions to multiple users. New users to the secure domain gainaccess to objects by becoming members of appropriate groups. Thiseliminates the need to create new ACL entries for every new user.Groups can represent organizational divisions or departments withina secure domain. Groups are also useful in defining roles orfunctional associations.

Users and groups are collectively referred to as entities.

User and group entries in ACLs are actually stored using auniversally unique identifier (UUID). The UUID provides extrasecurity in the case where a user or group is deleted from thedomain and then recreated with the same name. For example, eventhough a new user has the same name as the deleted user, PolicyDirector allocates a new UUID to this user. Since the UUID is new,any existing ACLs that reference the old user name will not grantany rights to the new user. Stale UUIDs in ACLs (from deleted usersand groups) are silently removed by the Policy Director ManagementServer (pdmgrd).

You use the pdadmin utility or the Web Portal Manager to create,modify, and delete ACL entries.

user peter ---------T---rx

group engineering ---------T---rx

user michael ---------T---rx

unauthenticated ---------------

ACL(containing multiple

entries)

Figure 17. Access Control List for a Web Page Object


3.U

sing

Access

Co

ntro

lP

olicies

Creating and Naming ACL PoliciesYou can use the Web Portal Manager, or the pdadmin acl createcommand, to create a unique ACL policy and save it with a name.You can then apply security policy by attaching the ACL to objectsin the protected object space.

The ACL becomes a single source policy (like a formula or recipe)containing the specific entries that provide the correct level ofprotection for all objects associated with it. If the security policyrequirements change, you only edit the single ACL. The newsecurity definition is instantly implemented for all objects affectedby that ACL.

ACL Entry SyntaxAn ACL entry contains either two or three attributes, depending onthe ACL entry type, and appears in the following format:

¶ Type – the entity category (user or group) for which the ACLwas created

¶ ID (Identity) – the unique identifier (name) of the entity

The ID attribute is not required for the any-other andunauthenticated ACL entry types

¶ Permissions (or actions) – the set of operations permitted onthe object by this user or group

ACL Entry user adam ---------T---r-

Type ID Permissions

Figure 18. ACL Entry Attributes

56 Version 3.8

Most permissions dictate the client’s ability to perform a specificoperation on the resource.

In the above example, the user adam (type = user, ID = adam) haspermission to read (view) the object protected by this ACL policy.The “r” permission allows the read operation. The “T” permissionenforces the traverse rule.

Type AttributeAn ACL entry type identifies the user, group, or special entity for aspecific ACL entry. There are four ACL entry types:

Type Description

user Sets permissions for a specific user in the secure domain. The usermust be a member of the secure domain with an account in theregistry. The user entry type requires a user name (ID). The entryformat is: user ID permissions

For example:

user anthony -------T-----r-

group Sets permissions for all members of a specific group in the securedomain. The group entry type requires a group name (ID). The entryformat is: group ID permissions

For example:

group engineering -------T-----r-

any-other(also known asany-authenticated)

Sets permissions for all authenticated users. No ID designation isrequired. The entry format is: any-other permissions

For example:

any-other -------T-----r-


3.U

sing

Access

Co

ntro

lP

olicies

Type Description

unauthenticated Sets permissions for those users who have not been authenticated bythe Security Server. No ID designation is required. The entry formatis: unauthenticated permissions

For example:

unauthenticated -------T-----r-

This ACL entry is a mask (a bit-wise “and ” operation) against theany-other ACL entry to determine the permission set. A permissionfor unauthenticated is granted only if the permission also appearsin the any-other entry. For example, the following unauthenticatedACL entry:

unauthenticated -------------rw

masked against this any-other ACL entry:

any-other -------T-----r-

results in these permissions:

-------------r- (read only).

ID AttributeThe ACL entry ID is the unique identifier, or name, for a user orgroup entry type. IDs must represent valid users and /or groupscreated for the secure domain and stored in the registry database.

Examples:user michael

user anthony

group engineering

group documentation

group accounting

Note: The ID attribute is not used for the any-other andunauthenticated ACL entry types.

58 Version 3.8

Permissions (Actions) AttributeEach ACL entry contains a set of permissions (or actions) thatdescribe the specific operations permitted on the object by the useror group

ACL policies control protected resources in the following ways:

¶ A user’s ability to perform operations on protected objects

¶ An administrator’s ability to change access control rules on theobject and any sub-objects

¶ Policy Director’s ability to delegate user’s credentials

Note: ACL permissions are context-sensitive — the behavior ofcertain permissions varies according to the region of theprotected object space in which they are applied. Forexample, the m permission has a different meaning on aWebSEAL object than on a Management object.

Default Policy Director Permissions (Actions)Policy Director defines seventeen default permissions (actions). TheWeb Portal Manager divides these permissions into three categories:

Base Generic WebSEALa A b B c g N t T W d m s v l r x

Action Bit Description Category

a Attach Base

A Add Base

b Browse Base

B Bypass Time-of-Day Base

c Control Base

d Delete Generic

g Delegation Base

l List Directory WebSEAL

m Modify Generic

N Create Base


3.U

sing

Access

Co

ntro

lP

olicies

Action Bit Description Category

r Read WebSEAL

s Server Administration Generic

t Trace Base

T Traverse Base

v View Generic

W Password Base

x Execute WebSEAL

Policy Director provides the capability to define many moreadditional permissions (actions) for use by third-party applications.See “Creating Extended ACL Actions and Action Groups” onpage 71.

How the Authorization Service Uses ACL PoliciesPolicy Director relies on ACL policies to specify the conditionsnecessary to perform an operation on a protected object.

When an ACL is attached to an object, entries in the ACL specifywhat operations are allowed on this object and who may performthose operations.

Policy Director uses a default set of permissions that cover a widerange of operations. Permissions are represented by single printableASCII characters (a-z, A-Z). Each permission is displayed (bypdadmin or the Web Portal Manager) with a label describing theoperation it governs. In addition, the Web Portal Manager groups theACLs according to their use in a particular part of the object space(such as WebSEAL) or their use across the entire object space (Base,Generic).

Performing Operations on an ObjectApplication software typically contains one or more operations thatare performed on protected objects. Policy Director requires theseapplications to make calls into the Authorization Service before therequested operation is allowed to progress. This call is made via the

60 Version 3.8

Authorization API for both Policy Director services (for example,WebSEAL) and third-party applications.

The Authorization Service uses the information contained in theACL to make a simple “yes” or “no” response to the question:“Does this user (group) have the ‘r’ permission (for example) to‘view’ the requested object?”

It is important to note that the Authorization Service knows nothingabout the operation requiring the “r” permission. All it cares about isthe presence, or not, of the “r” permission in the ACL entry of therequesting user or group.

This is actually a very powerful feature of the Authorization Service.The Service is completely independent of the operations beingrequested. This is why it is easy to extend the benefits of theAuthorization Service to third-party applications.

Requirements for Custom PermissionsThe entire repertoire of eighteen default Policy Director permissions(actions) is available to third-party applications. If a third-partyapplication makes use of a default Policy Director permission, theassociated operation should very closely match that of the actualoperation normally performed by Policy Director. For example, “r”should only be used by an operation that requires a read-only accessto a protected object.

Note: Of course, a third-party application can use a default PolicyDirector permission for a completely unrelatedoperation—because the Authorization Service does not knowor care about the operation. However, this situation wouldcause difficulty for an administrator who would have todistinguish between two dissimilar uses of the samepermission.

If a third-party application uses an operation that is not wellrepresented by any the default permissions, Policy Director allowsyou to define a new permission (action) that can be used by thisapplication and recognized by the Authorization Service.


3.U

sing

Access

Co

ntro

lP

olicies

See “Creating Extended ACL Actions and Action Groups” onpage 71 .

Custom Action ExampleIn this example, there is a requirement to protect certain printerdevice from unauthorized use. A third-party print spooling service iswritten with the Authorization API so that it can call theAuthorization Service to perform ACL checks on requests made tothe printer.

The standard Policy Director permissions do not include an obviouspermission for protecting printers. However, the printer can beprotected by a newly created permission (“p” in this example).

An ACL policy is attached to the printer object. If a user requeststhe use of the protected printer, that user must have an ACL entrycontaining the “p” permission. The Authorization Service returns afavorable response if the “p” permission is present and the printingoperation proceeds. If the Authorization Service finds no existence ofan “p” permission for that user, the printing operation is not allowedto proceed.

PrintSpoolerService


Printer ACL

AuthznPolicy

Database

API

user michael p

Can I use thisprinter?

"YES"

Figure 19. Custom Print Spooler Action

62 Version 3.8

Evaluating an ACLPolicy Director follows a specific evaluation process to determinethe permissions granted to a particular user by an ACL. When youunderstand this process, you can determine how best to keepunwanted users from gaining access to resoiurces .

Evaluating Authenticated RequestsPolicy Director evaluates an authenticated user request in thefollowing order:

1. Match the user ID with the ACL’s user entries. The permissionsgranted are those in the matching entry.

Successful match: evaluation stops here. Unsuccessful match:continue to the next step.

2. Determine the group(s) to which the user belongs and match withthe ACL’s group entries:

If more than one group entry is matched, the resultingpermissions are a logical “or” (most permissive) of thepermissions granted by each matching entry.


3. Grant the permissions of the any-other entry (if it exists).


4. An implicit any-other entity exists when there is no any-otherACL entry. This implicit entry grants no permissions.

Successful match: no permissions granted. End of evaluationprocess.

Evaluating Unauthenticated RequestsPolicy Director evaluates an unauthenticated user by granting thepermissions from the ACL’s unauthenticated entry.

The unauthenticated entry is a mask (a bitwise “and” operation)against the any-other entry when permissions are determined. A


3.U

sing

Access

Co

ntro

lP

olicies

permission for unauthenticated is granted only if the permissionalso appears in the any-other entry.

Since unauthenticated depends on any-other, it makes little sensefor an ACL to contain unauthenticated without any-other. If anACL does contain unauthenticated without any-other, the defaultresponse is to grant no permissions to unauthenticated.

Example ACL EntriesYou set permissions for specific users and groups by specifying theappropriate ACL entry type. In the following example, the groupdocumentation has full access privileges:group documentation --bcg--Tdmsv--lrx

You can restrict access to other authenticated users in the securedomain (not belonging to the documentation group) by using theany-other entry type:any-other -------T-------rx

You can further restrict access to the unauthenticated entry type forusers who are not members of the secure domain.unauthenticated -------T-------r-

Note: Without an unauthenticated ACL entry, unauthenticated userscannot access any secure documents within the securedomain.

Sparse ACL Model: ACL InheritanceTo secure network resources in a protected object space, each objectmust be protected by an access control list (ACL) policy.

You can assign an ACL policy to an object in one of two ways:

¶ Attach an explicit ACL policy on the object.

¶ Allow the object to inherit its ACL policy from a precedingcontainer object in the hierarchy.

64 Version 3.8

Adopting an inherited ACL scheme can greatly reduce theadministration tasks for a secure domain. This section discusses theconcepts of inherited, or sparse ACLs.

Understanding the Sparse ACL ModelThe power of ACL inheritance is based on the following principle:any object without an explicitly attached ACL policy inherits thepolicy of its nearest container object with an explicitly set ACL. Inother words, all objects without explicitly attached ACLs inheritACLs from container objects with explicitly attached ACLs. Aparticular chain of inheritance is broken when you attach an explicitACL on an object.

ACL inheritance simplifies the task of setting and maintaining accesscontrols on a large protected object space. In a typical object space,you only need to attach a few ACLs at key locations to secure theentire object space — hence, a sparse ACL model.

A typical object space begins with a single explicit ACL attached tothe root container object. The root ACL must always exist and cannever be removed. Normally, this is an ACL with very littlerestriction. All objects located in the object space below inherit thisACL.

When a region or sub-tree in the object space requires differentaccess control restrictions, you attach an explicit ACL at the root ofthat sub-tree. This interrupts the flow of inherited ACLs from theprimary object space root to that sub-tree. A new chain ofinheritance begins from this newly created explicit ACL.

The Default Root ACL PolicyPolicy Director checks inheritance beginning with the root of theprotected object space. If you do not explicitly set ACLs on anyother objects in the tree, the entire tree inherits this root ACL.

There is always an explicit ACL policy set at the root of theprotected object space. An administrator can replace this ACL withanother ACL containing different entries and permission settings. Butthe root ACL can never be completely removed.


3.U

sing

Access

Co

ntro

lP

olicies

The root ACL policy is explicitly set during the initial PolicyDirector installation and configuration.

Core entries for the default root ACL — default-root — include:Group iv-admin TcmdbvaAny-other TUnauthenticated T

Traverse PermissionPolicy Director access control depends on two conditions.

1. The ACL that controls the requested object must containappropriate access permissions for the requesting user.

2. The requested object must be accessible to the requesting user.

Accessibility to protected objects is controlled by the traverse (T)permission.

The traverse permission is only applied to container objects in theprotected object space. The traverse permission specifies that a user,group, any-other, or unauthenticated identified in the ACL entry haspermission to pass through this container object in order to gainaccess to a protected resource object below in the hierarchy.

A protected object is accessible to a requester if the requesterpossess the traverse permission on each ACL attached to containerobjects above the requested resource on the path towards root andincluding root.

The following example illustrates how the traverse permissionworks. Within the ACME Corporation, there is an Engineeringcontainer object (directory), which also contains a TechPubscontainer object (sub-directory). User kate, a member of the Salesdepartment, requires traverse to the Engineering/TechPubsdirectory to review a release note file. The administrator providestraverse for any-other at the root. The administrator providestraverse for group sales on the Engineering directory. TheTechPubs directory inherits the ACL from the Engineeringdirectory. Although Kate has no other permissions in these twodirectories, she can pass (traverse) through these directories in order

66 Version 3.8

to access the release_note file. Because this file has readpermission for user kate, she can view the file.

You can easily restrict access to the hierarchy below a givencontainer object — without resetting individual permissions on theseobjects. Simply remove the traverse permission from the appropriateACL entry. Removing traverse permission on a directory objectprotects all objects lower in the hierarchy, even if those objectscontain other less restrictive ACLs.

For example, if group sales did not have the traverse permission onthe Engineering directory, Kate could not access the release notefile, even though she has read permission for the file.

Resolving an Access RequestInheritance begins with the root ACL and impacts all objects in theobject space until it reaches an object with an explicit ACL. At thispoint, a new chain of inheritance begins.

Engineering/Sales/

TechPubs/

release_note

group sales -------T---------

(ACL inherited)

user kate ---------------r-

ACME Corporation

root

any-authenticated -------T---------

Figure 20. Traverse Permission


3.U

sing

Access

Co

ntro

lP

olicies

Objects below an explicitly set ACL inherit the new access controls.If you delete an explicit ACL, access control for all objects revertsback to the nearest directory or container object with an explicitlyset ACL.

When a user tries to access a secure object (such as a Webdocument), Policy Director checks whether the user has thepermissions to access the object. It does this by checking everyobject along the object hierarchy for the proper inherited orexplicitly set permissions.

A user is denied access to an object if any directory or containerobject in the hierarchy above does not include the traversepermission for that user. Access is also denied if the target objectdoes not contain sufficient permissions to perform the requestedoperation.

In order to succeed an access check, the requestor must have both:

1. Permission to traverse the path to the requested object.

2. Appropriate permissions on the requested object.

The following example illustrates the process of resolving whether auser can read (view) an object:/acme/engineering/project_Y/current/report.html

Policy Director checks:

1. Traverse permission on the explicitly set root ACL (/).

2. Traverse permission on any explicit ACLs attached to thedirectories: acme,engineering, project_Y, and current.

3. Read permission on the file itself (report.html).

The user is denied access if the user fails the access check at any ofthese points along the object hierarchy.

68 Version 3.8

Applying ACL Policies to Different Object TypesPermissions for a variety of operations can be set in an ACL policy.Only a subset of these possible operations may be relevant for aspecific object to which the ACL is attached.

The reason for this behavior is related to the two features of PolicyDirector that are designed to make administration easier:

¶ ACL policies

¶ ACL inheritance

ACL policies allow you to attach the same ACL definition tomultiple objects in the protected object space. The ACL definitionconsists of enough entries to meet the requirements of all objects towhich the ACL will be applied; however, each individual object mayonly be affected by a few of the entries.

In the ACL inheritance model, any object without an attachedexplicit ACL policy will “inherit” the policy definitions from thenearest ACL applied to an object above it in the hierarchy.

In summary, an ACL policy has to describe the necessarypermissions for all object types that it will be applied to — and notjust the object that it is attached to.

ACL Policy Inheritance ExampleThe following figure illustrates the impact of a mixture of inheritedand explicit ACLs in a corporate object space.

A corporate object space has a general security policy set at the rootobject. Root is followed by the /WebSEAL container object andindividually controlled departmental sub-trees.

In this example, the sales group is given ownership of theirdepartmental sub-tree. Note that the ACL on this sub-tree no longeracknowledges the unauthenticated or any-other entry types.


3.U

sing

Access

Co

ntro

lP

olicies

The Year-to-Date sales file (ytd.html) has an explicit ACL thatgrants read permission to members of the sales-vp group (who arealso members of the sales group).

Note: This ACL scheme need not be changed with the addition orsubtraction of users within the secure domain. New users aresimply added to the appropriate group(s). Likewise, users canbe removed from those groups.

Guidelines for a Secure Object Space¶ Set high-level security policy on container objects at the top of

the object space. Set exceptions to this policy with explicit ACLon objects lower in the hierarchy.

¶ Arrange your protected object space so that most objects areprotected by inherited, rather than explicit, ACLs.

staff.html manager.htmltele.html president.html

products.htmlclientA.html ytd.htmlsales.html

WebSEAL Server( www.acme.com/ )

Departments/

group iv-admin -abc---Tdm----lrxgroup ivmgrd-servers -------T------l--group webseal-servers -a--g--Tdm----lrxunauthenticated -----------------any_authenticated -------T-------r-

Sales/

Note: Group "sales" includes membersof group "sales-vp".

Personnel/

Production/ Inventory/

group iv-admin -abc---Tdm----lrxgroup ivmgrd-servers -------T------l--group webseal-servers -a--g--Tdm----lrxgroup sales -------T------lrx

group iv-admin -abc---Tdm----lrxgroup ivmgrd-servers -------T------l--group webseal-servers -a--g--Tdm----lrxgroup sales-vp -------T-------r-

Figure 21. ACL Inheritance Example

70 Version 3.8

Inherited ACLs simplify the maintenance of your tree becausethey reduce the number of ACLs you must maintain. This lowermaintenance reduces the risk of an error which couldcompromise your network.

¶ Position new objects in the tree where they inherit theappropriate permissions.

Arrange your object tree into a set of sub-trees, where eachsub-tree is governed by a specific access policy. You determinethe access policy for an entire sub-tree by setting an explicitACL at the root of the sub-tree.

¶ Create a core set of ACL policies and re-use these ACLswherever necessary.

Since an ACL policy is a single source definition, anymodifications to the policy will impact all objects associatedwith this ACL.

¶ Control user access through the use of groups.

It is possible for an ACL to consist of only group entries. Accessto an object by individual users can be efficiently controlled byadding users to or removing users from these groups.

Creating Extended ACL Actions and Action GroupsIn this section, the word “action” has the same meaning as the word“permissions,” used in previous sections.

Every Policy Director permission is defined as an action. Seventeenactions are pre-defined for immediate functionality (see “DefaultPolicy Director Permissions (Actions)” on page 59). You can alsodefine new actions for use by third-party applications.

This section describes how to define action groups that serve ascontainers for an expanded set of custom actions:

¶ Each action group is capable of holding up to 32 action bits.

¶ An action bit is made up of a letter: a-z, A-Z.

¶ Each action bit character can only be used once within an actiongroup


3.U

sing

Access

Co

ntro

lP

olicies

¶ You can re-use the same action bit in other action groups.

¶ The default Policy Director actions are stored in an initialpre-defined action group called “primary”

Policy Director supports a total of 32 action groups (including theprimary action group) for a total of 1024 individual actions

a A b B c g N T W

...

32

primary action group

Bits set for:group sales abNT

Figure 22. Primary Action Group

a A b B c g N T W

...

32

multiple action groups

Figure 23. Multiple Action Groups

72 Version 3.8

Creating a New Action GroupUse the pdadmin action group create command to create a newaction group:pdadmin> action group create test-grouppdadmin> action group list

primarytest-group

pdadmin> action group delete test-grouppdadmin> action group list

primary

The default primary action group always appears in a group listingand cannot be deleted.

You must have an entry in an ACL on the /Management/ACL objectwith the modify (m) permission to create action groups and thedelete (d) permission to delete action groups.

Creating New Actions in an Action GroupUse the pdadmin action create command to create a new actionwithin an action group:pdadmin> action create <action-name> <action-label> <action-type><action-group-name>

action-name Letter representing the action (permission).

action-label Descriptive label for this action. Appears in apdadmin action list command and the Web PortalManager.

action-type Action category (used by Web Portal Manager togroup common action bits together). Defaultcategories include Base, Generic, and WebSEAL.

action-group-name Action group where this new action belongs. If thisargument is not specified, the action is assigned tothe “primary” action group.

For example:


3.U

sing

Access

Co

ntro

lP

olicies

pdadmin> action create P Test-Action Special test-grouppdadmin> action list test-group

P Test-Action Specialpdadmin> action delete P test-grouppdadmin> action list test-grouppdadmin>

Entering Custom Actions into ACL EntriesAs discussed in “ACL Entry Syntax” on page 56, ACL entriescontain an entry type, a type ID (for user and group types), and theset of permitted action bits.

You must use a special syntax to identify custom action bitsbelonging to action groups other than the “primary” action group.Action strings that represent the action bits from multiple actiongroups are presented in the following format:<action>...<action>[<action-group>]<action>...<action>,,,

For example:

abgTr[groupA]Pq[groupB]Rsy[groupC]ab

¶ The first set of action bits (abgTr) represent permissions fromthe “primary” (Policy Director default) action group.

¶ Action group A contains actions P and q.

¶ Action Group B contains actions R, s, and y.

¶ Action group C contains actions a and b.

¶ Note that action group C contains action bits that use the sameletters as action bits in the “primary” group.

Because the action bits are associated with a specific actiongroup (C), the “a” and “b” action bits have unique identities andcan represent very different permissions from the “a” and “b”action bits in the “primary” action group.

ExampleShow Action Groupspdadmin>pdadmin> action group list

primarytest-group

74 Version 3.8

List Actions in Action Group “test-group”pdadmin> action list test-group

P Test-Action SpecialS Test-Action2 Special

List ACL Policiespdadmin> acl list

default-websealdefault-roottestdefault-replicadefault-management

Show Details of ACL “test”pdadmin> acl show test

ACL Name: testDescription:Entries:

User sec_master TcmdbvaGroup ivmgrd-servers TlAny-other r

Add ACL Entry for User Kate Containing Actions from ActionGroups “primary” and “test-group”pdadmin> acl modify test set user kathy brT[test-group]PSpdadmin> acl show test

ACL Name: testDescription:Entries:User sec_master TcmdbvaGroup ivmgrd-servers TlAny-other rUser kathy Tbr[test-group]PS

ACL Policies and the Protected Object SpaceContainer objects represent specific regions of the protected objectspace and serve two important security functions:

1. You can use the container object’s ACL to define high levelpolicy for all sub-objects within the region when no otherexplicit ACLs are applied.


3.U

sing

Access

Co

ntro

lP

olicies

2. You can quickly deny access to all objects in a region byremoving the traverse permission from the container object’sACL.

Root ( / ) Container ObjectThe following security considerations apply for the Root object:

¶ The root object begins the chain of ACL inheritance for theentire protected object space

¶ If you do not apply any other explicit ACLs, the root objectdefines (through inheritance) the security policy for the entireobject space

¶ Traverse permission is required for access to any object belowroot

The Traverse PermissionThe Traverse permission is a generic permission that appliesthroughout the protected object space:

Operation Description

T traverse When applied to a container object, allows therequester to hierarchically pass through thecontainer object on the way to the requestedresource object. It does not allow any other typeof access to the container object. Traverse is notrequired on the requested resource object itself.

WebSEAL PermissionsThe following security considerations apply for the /WebSEALcontainer in the protected object space:

¶ The WebSEAL object begins the chain of ACL inheritance forthe WebSEAL region of the object space

¶ If you do not apply any other explicit ACLs, this object defines(through inheritance) the security policy for the entire Web space

¶ The traverse permission is required for access to this object andany object below this point

76 Version 3.8

/WebSEAL/<host>This subtree contains the Web space of a particular WebSEALserver. The following security considerations apply for this object:

¶ The traverse permission is required for access to any objectbelow this point

¶ If you do not apply any other explicit ACLs, this object defines(through inheritance) the security policy for the entire objectspace on this machine

/WebSEAL/<host>/<file>This is the resource object checked for HTTP access. Thepermissions checked depend on the operation being requested.

WebSEAL PermissionsThe following table describes the permissions applicable for theWebSEAL region of the object space:


r read View the Web object

x execute Run the CGI program.

d delete Remove the Web object from the Web space.

m modify PUT an HTTP object. (Place - publish - anHTTP object in the WebSEAL object space.)

l list Required by Management Server to generate adirectory auto-list of the Web space.

g delegation Assigns trust to a WebSEAL server to act onbehalf of a client, and pass that request to ajunctioned WebSEAL server.

Management PermissionsThe Management region of the protected object space containsseveral sub-management container objects that require specific setsof permissions:

¶ “/Management/ACL Permissions” on page 78


3.U

sing

Access

Co

ntro

lP

olicies

¶ “/Management/Action Permissions” on page 80

¶ “/Management/POP Permissions” on page 81

¶ “/Management/Server Permissions” on page 82

¶ “/Management/Config Permissions” on page 82

¶ “/Management/Policy Permissions” on page 83

¶ “/Management/Replica Permissions” on page 83

¶ “/Management/Users Permissions” on page 84

¶ “/Management/Groups Permissions” on page 85

¶ “/Management/GSO Permissions” on page 86

The following security considerations apply for the /Managementregion of the protected object space:

¶ The Management object begins the chain of ACL inheritance forthe entire Management region of the object space.

¶ If you do not apply any other explicit ACLs, this object defines(through inheritance) the security policy for the entireManagement object space.

¶ The traverse permission is required for access to /Management.

/Management/ACL PermissionsThis object allows administration users to perform high-level ACLmanagement tasks that can impact the security policy for the securedomain.


a attach Attach ACL policies to objects; remove ACLpolicies from objects.

acl attachacl detach

c control Ownership of the ACL policy; allowed to create,delete and modify entries for this ACL.

acl modify

78 Version 3.8


d delete Delete an existing ACL policy. The ACL entryfor this user must also contain the control (c)permission.

acl delete

m modify Create a new ACL policy.

acl create

v view List and find view ACLs; show ACL details. Thispermission must be in an entry of an ACLattached to /Management/ACL.

acl findacl listacl show

You must create ACL administrator entries in the default ACL policyfor the /Management/ACL object. The administrator’s ACL entry cancontain any of the above permissions. These permissions give theadministrator powers to create new ACL policies, attach ACLs toobjects, and delete ACL policies.

An ACL administrator cannot modify an existing ACL unless there isan entry in that ACL for the administrator containing the control (c)permission. Only the owner of an ACL can modify its entries.

Note that the creator of a new ACL policy (m on/Management/ACL) becomes the first entry in that ACL—with theTcmdbsvaBlNWA permissions set by default.

For example, if sec_master is an administrator entry in thedefault-management ACL, with m permission, sec_master cancreate a new ACL policy. User sec_master becomes the first entry inthe new ACL, with TcmdbsvaBlNWA permissions.

The control permission (c) gives sec_master ownership of the ACLand allows sec_master to modify the ACL. User sec_master couldthen grant administration permissions to other user entries in thatACL.


3.U

sing

Access

Co

ntro

lP

olicies

Ownership of the default-management ACL itself is given to bothuser sec_master and group iv-admin by default.

The Control Permission (c)The control permission is a powerful permission that gives youownership of an ACL policy. Control allows you to modify theentries in the ACL. This means you have the power to create entries,delete entries, grant permissions, and take away permissions.

The administrator who wants to delete this ACL from the list ofACL policies must have an entry in that ACL and must have thecontrol permission set in that entry.

The control permission allows you to grant administration powers toanother user, such as the ability to attach (a) that ACL to objects.You must use the control permission with great care because of itspowerful ownership properties.

The control permission is only important in the /Management/ACLspace.

/Management/Action PermissionsThis object allows administration users to manage custom actionsand action groups. Action tasks and associated permissions include:


d delete Delete an existing action or action group.

action deleteaction group delete

m modify Create a new action or action group.

action createaction group create

action listaction group list

do not require special permissions.

80 Version 3.8

Policy Director provides authorization services to applications.Applications that are part of the Policy Director family include, forexample, WebSEAL (for Web applications) and PDMQ (formessaging applications).

Third-party applications can make calls to the Authorization Servicethrough the Authorization API. Two necessary steps required tointegrate a third-party application with the Authorization Serviceinclude:

¶ Define the application’s object space

¶ Apply permissions on objects (resources) needing protection

The administrator of a third-party application object space can usethe pdadmin utility to define new permissions and actions. Theadministrator must have the m and d Management/Actionpermissions to create and delete these permissions/actions.

/Management/POP PermissionsThis object allows administration users to manage protected objectpolicies. All permissions must appear in entries for ACLs on/Management/POP. Action tasks and associated permissions include:


a attach Attach a POP to an object.

pop attachpop detach

d delete Delete a POP.

pop delete

m modify Create POPs and modify POP attributes.

pop createpop modify

v view Find and list POPs and show POP details.

pop findpop listpop show

B Bypass TOD An administration permission that overrides thetime-of-day POP attribute on an object.


3.U

sing

Access

Co

ntro

lP

olicies

/Management/Server PermissionsThe /Management/Server container object of the protected objectspace allows administrators to perform server management tasks(when appropriate permissions are set).

Server management controls are used to determine if a user haspermission to create, modify, or delete a server definition. Serverdefinitions contain information that allows other Policy Directorservers, particularly the Management Server (pdmgrd), to locate andcommunicate with that server.

A server definition is created for a particular Resource Manager(such as WebSEAL) or Authorization Server (pdacld) as part of theinstallation process. The definition for a server is also deleted whenthe server is uninstalled.


s server Replicate authorization database.

server replicate

v view List registered servers and display serverproperties.

server listserver show

t trace Enable dynamic trace or statistics administration.

server task <server-name> traceserver task <server-name> stats

/Management/Config PermissionsThe /Management/Config container object of the protected objectspace allows administrators to perform configuration managementtasks (when appropriate permissions are set).

The creation and deletion of server definitions happensautomatically—the installation administrator does not have toperform any special steps to create a definition. However, theadministrator must be granted modify (m) permission on the/Management/Config object in order to create the definition duringinstallation.

82 Version 3.8

In addition, the administrator must have delete (d) permission on the/Management/Config object in order to delete the definition duringuninstallation.


m modify Configuration into a secure domain.

svrsslcfg -configsvrsslcfg -modify

d delete Unconfiguration.

srvsslcfg -unconfig

/Management/Policy PermissionsThe /Management/Policy container object of the protected objectspace allows administrators to authorize the policy get and policyset commands (when appropriate permissions are set).


v view Required for policy get operations.

m modify Required for policy set operations..

/Management/Replica PermissionsThe /Management/Replica container object of the protected objectspace controls the replication of the authorization database.High-level controls on this object affect the operation of theManagement Server and the Security Manager(s) in the securedomain.

Replica management controls are used to determine what processesare allowed to read or update the master authorization policydatabase in order for replication to take place properly.

Controls and associated permissions include:


v view Read the master authorization database.

m modify Authorize modification of the replica database(s).


3.U

sing

Access

Co

ntro

lP

olicies

All Policy Director servers which maintain a local replica of theauthorization database — this includes all resource managers andauthorization servers — must be granted view (v) permission on the/Management/Replica object. The replication process requires thatthese processes be allowed to view and access entries out of themaster authorization policy database. The Policy Director installationautomatically grants read permission to any server requiring accessto the authorization policy database.

Policy Director currently does not use the modify (m) permission.The only way to modify the master policy authorization database isthrough the Web Portal Manager or the pdadmin utility. These toolsare subject to other finer-grained checks. The modify permission isintended to be used in the future when it is possible to replicate theManagement Server.

/Management/Users PermissionsThis object allows administration users to manage user accounts.Action tasks and associated permissions include:


d delete Delete a user account.

user delete

m modify Modify user account details.

user modify authentication-mechanismuser modify account-validuser modify gsouseruser modify description

N create Create a new user and optionally assign that userto a group. Import group data from the userregistry.

user createuser import

v view List user accounts and show user account details.

user listuser list-dnuser list-gsouseruser showuser show-dnuser show-groups

84 Version 3.8


W password Reset and validate a user password.

user modify passworduser modify password-valid

The W permission allows password resets and is appropriate to giveto helpdesk administrators so they can assist users who haveforgotten their passwords. This permission allows an administrator toreset the forgotten password and then use the user modifypassword-valid command to set a value of “no”. This action allowsthe user to log and then forces the user to immediately apply a newpassword.

Access granted by the /Management/Users object overrides anyaccess restrictions imposed by “delegated administration” policyACLs under /Management/Groups/<group-name>.

/Management/Groups PermissionsThis object allows administration users to manage groups and groupmembership. Action tasks and associated permissions include:


d delete Delete a group.

group delete

m modify Modify group descriptions. Remove a usermember of a group.

group modify descriptiongroup modify remove

N create Create a new group. Import group data from theuser registry.

group creategroup import

v view List groups and show group details.

group listgroup list-dngroup showgroup show-dngroup show-members


3.U

sing

Access

Co

ntro

lP

olicies


A add Add an existing user to a group.

group modify add

The A bit is required on your entry in the ACL on a group to allowyou to add existing users to your group. You use the user createcommand (which requires N permission) to create new users and,optionally, place them in an existing group.

The capability of adding existing users to your group is powerfulbecause the owner of a group has control over all user members ofthe group. If you, as the owner of the group, also have delete (d)permission, you can delete this user from the entire secure domain.

/Management/GSO PermissionsThe /Management/GSO container object of the protected objectspace allows administrators to perform GSO management tasks(when appropriate permissions are set).


m modify rsrcgroup modifyrsrccred modify

v view rsrc listrsrcgroup listrsrccred listrsrc showrsrcgroup showrsrccred show

N create rsrc creatersrcgroup creatersrccred create(all the above commands also require m)

d delete rsrc deletersrcgroup deletersrccred delete(all the above commands also require m)

86 Version 3.8

Object and Object Space PermissionsThese commands allows administration users to manage new objectsand object spaces. Action tasks and associated permissions include:


b browse objectspace listobjectspace writefileobject listobject listandshow(additionally requires v)

d delete objectspace deleteobject deleteobject modify set name(additionally requires m)

m modify objectspace createobjectspace readfileobject createobject modify

v view object listandshow(additionally requires b)object show

Default Administration ACL PoliciesThe following default administration ACL policies are suggestedstarting points for securing specific regions of the secure domain.

You can add entries for users, groups, any-other (any-authenticated),and unauthenticated to provide a broader range of control and bettermeet the requirements of your protected object space.

Note the user(s) and group(s) in each ACL that contain the control(c) permission. Users and groups with the control permission “own”the ACL and have the power to modify the ACL entries.

Default Root ACL PolicyCore entries for the default root ACL, default-root, include:Group iv-admin TcmdbvaAny-other TUnauthenticated T


3.U

sing

Access

Co

ntro

lP

olicies

The root ACL is very basic — everyone can traverse the objectspace, but cannot perform any other actions. Typically, you wouldnot need to change this. However, one useful function of the rootACL is to quickly deny access to the entire object space for anindividual user or group.

Consider the following entry in the root ACL:user john -----------------

The consequence of this entry (no permissions) is that user johncannot even traverse the root container object. This user cannot gainaccess at all to the protected object space — regardless of anypermissions granted lower down in the tree.

You can apply this same approach to the WebSEAL object space.For example, if you take away the traverse permission from aparticular user at the /WebSEAL container objects, that user cannotgain entry to the WebSEAL object space at all — regardless of anypermissions granted on objects within those regions.

Default /WebSEAL ACL PolicyCore entries for the WebSEAL ACL, default-webseal, include:Group iv-admin TcmdbsvarxlGroup webseal-servers TgmdbsrxlUser sec_master TcmdbsvarxlAny-other TrxUnauthenticated T

At installation, this default ACL is attached to the /WebSEALcontainer object in the object space.

The group, webseal-servers, contains an entry for each WebSEALserver in the secure domain. The default permissions allow theservers to respond to browser requests.

The traverse permission allows expansion of the Web space asrepresented in the Web Portal Manager. The list permission allowsthe Web Portal Manager to display the contents of the Web space.

88 Version 3.8

Default /Management ACL PolicyCore entries for the Management ACL, default-management,include:Group iv-admin TcmdbsvatNWAGroup ivmgrd-servers TsAny-other Tv

At installation, this ACL is attached to the /Management containerobject in the object space.

Default /Replica ACL PolicyCore entries for the Replica management ACL, default-replica,include:Group iv-admin TcbvaGroup ivmgrd-servers mGroup secmgrd-servers mdvGroup ivacld-servers mdv

Default /Config ACL PolicyCore entries for the Config management ACL, default-config,include:Group iv-admin TcmdbsvaNAny-other TvUnauthenticated Tv

Default /GSO ACL PolicyCore entries for the GSO management ACL, default-gso, include:Group iv-admin TcmdbvaNAny-other TvUnauthenticated Tv

Default /Policy ACL PolicyCore entries for the Policy management ACL, default-policy,include:Group iv-admin TcmdbvaNAny-other TvUnauthenticated Tv


3.U

sing

Access

Co

ntro

lP

olicies

90 Version 3.8

Using Protected Object Policies

The Policy Director Authorization Service makes decisions onrequests for access to protected objects in the secure domain. Thedecision can be based on two types of policies:

¶ Access control list (ACL) policies

¶ Protected object polices (POP)

The purpose of a POP is to impose additional conditions on theoperation permitted by the ACL policy.

Examples of access conditions can include:

¶ Writing a report record to the auditing service

¶ Restricting access to a specific time period

This chapter discusses how protected object policies are configuredand applied to objects.

Topic Index:

¶ “Introducing Protected Object Policies (POP)” on page 91

¶ “Configuring the POP Attributes” on page 95

Introducing Protected Object Policies (POP)ACL policies provide the Authorization Service with information tomake a “yes” or “no” answer on a request to access a protectedobject and perform some operation on that object.

4


4.U

sing

Pro

tectedO

bject

Po

licies

POP policies contain additional conditions on the request that arepassed back to the Resource Manager (such as WebSEAL) alongwith the “yes” ACL policy decision from the Authorization Service.It is the responsibility of the Resource Manager to enforce the POPconditions.

The following table lists the available attributes for a Policy DirectorPOP:

Enforced by Policy Director Base

POP Attribute Description pdadmin pop Commands

Name Name of the policy. Thisbecomes the <pop-name> inthe pdadmin pop commands.

createdelete

Description Descriptive text for the policy.This appears in the pop showcommand.

modify set description

Warning Mode Provides administrators ameans to test ACL and POPpolicies.

modify set warning

Audit Level Specifies type of auditing: all,none, successful access, deniedaccess, errors.

modify set audit-level

Time-of-DayAccess

Day and time restrictions forsuccessful access to theprotected object.

modify set tod-access

Extendedattributes

Specifies supplemental datafields.

modify set attributemodify delete attributelist attributeshow attribute



Quality ofProtection

Specifies degree of dataprotection: none, integrity,privacy.

modify set qop

92 Version 3.8



IP EndpointAuthenticationMethod Policy

Specifies authenticationrequirements for access frommembers of external networks.

modify set ipauth addmodify set ipauth removemodify set ipauth anyotherw

POP Policy Notes:¶ The time-of-day access and the IP endpoint authentication

method access place restrictions on the access to the object.

¶ Audit level and quality of protection inform the AuthorizationService that extra services are required when permitting accessto the object.

¶ Warning mode provides a way to test ACL and POP policiesbefore they are made active.

Note: The quality of protection and auditing rules specified by theP, I, and A permission bits in previous versions of PolicyDirector are now specified in POP policies.

Creating and Deleting Protected Object PoliciesProtected Object Policies (POP) operate in a similar way to ACLpolicies—you create and configure a POP and then attach the POP toobjects in the protected object space.

POP policies are inherited in the same way as ACL policies. BothPOP policies and ACL policies are placed in the master authorizationdatabase which is controlled by the Management Server.

Create and List a POP Policypdadmin> pop create <pop-name>

For example:pdadmin> pop create testpdadmin> pop list

test

The new POP policy contains the following default settings:


4.U

sing

Pro

tectedO

bject

Po

licies

pdadmin> pop show testProtected object policy: testDescription:Warning: noAudit level: noneQuality of protection: noneTime of day access: sun, mon, tue, wed, thu, fri, sat:

anytime:localIP Endpoint Authentication Method Policy

Any Other Network 0

Delete a POP Policypdadmin> pop delete <pop-name>

For example:pdadmin> pop delete testpdadmin> pop listpdadmin>

Modify and Show a POP Descriptionpdadmin> pop modify <pop-name> set description <description>

Note: Always enclose the description with double quotation markswhen you use more than one word.

For example:pdadmin> pop modify test set description “Test POP”pdadmin> pop show test

Protected object policy: testDescription: Test POPWarning: noAudit level: noneQuality of protection: noneTime of day access: sun, mon, tue, wed, thu, fri, sat:

anytime:localIP Endpoint Authentication Method Policy

Any Other Network 0

Applying POP Attributes to Protected ObjectsPOP policies are applied to objects in the same manner as ACLpolicies.

94 Version 3.8

Attach a POP Policy to an ObjectThe syntax for attaching a POP policy to an object is:pdadmin> pop attach <object-name> <pop-name>

For example:pdadmin> pop attach /WebSEAL/serverA/index.html test

Find Where a POP Policy is Attachedpdadmin> pop find test

/WebSEAL/serverA/index.html

Delete a POP PolicyThe syntax for detaching a POP policy from an object is:pdadmin> pop detach <object-name>

For example:pdadmin> pop detach /WebSEAL/serverA/index.html

Configuring the POP Attributes¶ Warning Mode Attribute

¶ Audit Level Attribute

¶ Time-of-Day Attribute

¶ Quality of Protection Attribute

¶ IP Endpoint Authentication Method Attribute

Warning Mode AttributeThe purpose of the warning attribute is to allow a securityadministrator to debug or troubleshoot the accuracy of theauthorization policy set on the protected object space.

When you set the warning attribute to “yes”, any action is possibleby any user on the object where the POP is attached. Any access toan object is permitted even if the ACL policy attached to the objectis set to deny this access.


4.U

sing

Pro

tectedO

bject

Po

licies

Audit records are generated that capture the results of all ACLpolicies with warning mode set throughout the object space. Theaudit log shows the outcome of an authorization decision as it wouldhave been made if the warning attribute has been set to “no”. Theadministrator can, therefore, determine if policy is set and enforcedcorrectly.pdadmin> pop modify <pop-name> set warning {yes|no}

For example:pdadmin> pop modify test set warning yes

Audit Level AttributeThe audit level POP attribute is the replacement for the “A” ACLpermission bit that activated auditing in previous versions of PolicyDirector. The POP audit level has the expanded ability to specify alevel of auditing.

For example, if auditing is set to record unsuccessful events, you canuse the results to detect an unusual number of failed access attemptson a particular resource.

Auditing records are written in a standard XML format that allowseasy parsing to extract whatever information is required.

See “Audit Trail Files” on page 154.pdadmin> pop modify <pop-name> set audit-level{all|none|<audit-level-list>

Audit-Level-List

Value Description

permit Audit all requests on a protected object that result insuccessful access.

deny Audit all requests on a protected object that result indenial of access.

error Audit all internally generated error messages resultingfrom a denial of access to the protected object.

96 Version 3.8

You can apply any combination of these three values. Use a commaas a separator character when you specify more than one value.

For example:pdadmin> pop modify test set audit-level permit,deny

Time-of-Day AttributeThe time-of-day (TOD) POP attribute allows you to place specificday and time conditions on the access to a protected object. Thistype of condition might be useful to limit access to information thatregularly requires periods of inactivity for modification and updates.

There is an ACL policy permission bit (“B”) that overrides thetime-of-day conditions on an object. This permission should only beused by a high level administrator who needs full access of theprotected object space all the time.pop modify <pop-name> set tod-access <time-of-day-string>

The time-of-day-string argument includes a day-range and atime-range and uses the following format:<{anyday|weekday|<day-list>}>:<{anytime|<time-spec>-<time-spec>}>[:{utc|local}]

The day-list variable can be any combination of the following:mon,tue,wed,thu,fri,sat,sun

The time-spec range variable must be expressed (using 24 hourtime) as:hhmm-hhmm

For example:0700-1945

The optional time zone for the server (not the client) is local bydefault.

For example:pdadmin> pop modify test set tod-access mon,tue,fri:1315-1730


4.U

sing

Pro

tectedO

bject

Po

licies

Quality of Protection AttributeThe quality of protection POP attribute allows you to specify toWebSEAL what level of data protection is required when performingan operation on an object.

Refer to the Tivoli SecureWay Policy Director WebSEALAdministration Guide for detailed information about this POPattribute.

IP Endpoint Authentication Method AttributeThe IP endpoint authentication method POP attribute allows you toconfigure authentication strength policy (step-up) and network-basedauthentication policy.

Refer to the Tivoli SecureWay Policy Director WebSEALAdministration Guide for detailed information about this POPattribute.

98 Version 3.8

Delegating Administration Tasks

Policy Director allows high-level administrators to delegateresponsibilities for managing the secure domain to lower-leveladministrators. This capability is vital to successfully managing verylarge domains composed of numerous departments, and thereforecontain high numbers of groups, users, and resources.

Policy Director supports two types of delegated administration:

¶ Delegated management of resources in sub-regions of the objectspace

Administration capabilities are restricted to a portion of theobject space.

¶ Delegated management of groups and users

Administration capabilities are restricted to a portion of the userpopulation.

Topic Index:

¶ “Delegating Object Space Management” on page 100

¶ “Delegating Group Management” on page 106

¶ “Managing Delegated Administration Policy” on page 114

5


5.D

elegatin

gA

dm

inistratio

nTasks

Delegating Object Space ManagementThe distribution of administration responsibilities within a securedomain is called management delegation. The need for managementdelegation generally arises from the growing demands of a large sitecontaining many distinct departmental or resource divisions.

Typically, a large object space can be organized into regionsrepresenting these departments or divisions. Each distinct region ofthe domain is usually better organized and maintained by a managerwho is more familiar with the issues and needs of that branch.

In a Policy Director secure domain, the sec_master account forLDAP is initially the only account with administration permission.As sec_master, you can create management accounts and assign tothese accounts appropriate controls for specific regions of the objectspace.

Structuring the Object Space for ManagementDelegation

Structure your object space to contain distinct regions, or branches,where sub-management responsibilities—specific to that branch—canbe carried out.

In the example below, both the Engineering and Publications regionsof the object space require separate management control. Control ofthese regions begins with the root of each region and extends to allobjects below.

100 Version 3.8

Default Administration Users and GroupsAt installation, Policy Director provides several importantadministration groups. By default, these users and groups are givenspecial permissions to control and manage all operations in thesecure domain. (This default security policy is defined by the ACLscreated during installation.)

The following sections detail the specific roles assigned to each ofthese users and groups at installation time. The administrator cancustomize these privileges at a later time to accommodate changingmanagement policies.

user sec_master (LDAP)This user represents the administrator of the secure domain who isgranted complete rights for all operations within the secure domain.

This policy can be modified as the object space grows by delegatingmanagement permissions to other users and possibly revoking certain(or all) permissions from sec_master.

Object Space

/WebSEAL

Engineering Server

Publications

Marketing Server

Resources

Figure 24. Structuring the Object Space for Management Delegation


5.D

elegatin

gA

dm

inistratio

nTasks

group iv-adminThis group represents the administrator group. Like sec_master, allmembers of this group are considered administrators of the securedomain by the default policy. All default ACLs grant usersec_master and group iv-admin exactly the same permissions.

You can easily place users into an administration role by addingthem to the iv-admin group. The danger with this procedure is thatonce a user becomes a member of this group (with the defaultACLs), that user has full rights to do everything on any object in theentire namespace.

The default policy for this group can be changed by delegatingmanagement permissions to other users and revoking some or allmanagement permissions from group iv-admin.

group ivmgrd-serversThis group contains the Management Server. Policy Director requiresthat exactly one Management Server exists in the secure domain.Therefore, this group only contains that one entry.

Since most management requests made by the console are executedvia the Management Server to the target server, the ManagementServer must have permission to perform the request at the targetserver. For this reason, this group is granted server administrationpermission (s) in the default management ACL, and list (l)permission throughout the Web space.

group webseal-serversThis group contains all the WebSEAL servers in the secure domain.The default WebSEAL ACL grants these servers the complete set ofHTTP-specific permissions and the delegation permission. Thispolicy allows all WebSEAL servers to junction to all otherWebSEAL servers. A modification of this policy could grant thesepermissions on a server-by-server basis.

102 Version 3.8

Creating Administration UsersYou can create administration accounts with varying degrees ofresponsibility. Responsibility is delegated to administrators throughstrategically place administration ACLs. The following list illustratespossible administration roles:

¶ ACL administration responsibilities

The ACL administrator can control all, or part, of a protectedobject namespace region, depending on where the administrationACL is placed. The administrator’s ACL entry could contain theb, a, and T permissions, plus any other permissions appropriatefor operations on objects in that region.

The administrator can use the Management Console to attach (a)ACLs to objects in the designated namespace using the existingset of ACL templates. This administrator does not havepermissions to create, modify, or delete ACL templates.

¶ ACL policy responsibilities

The ACL policy administrator should be responsible forcontrolling the creation and modification of all ACL templatesused in the secure domain. The ACL policy administrator shouldbe granted d, b, m, and v permission on the /Management or/Management/ACL object.

This ACL policy administrator can create new ACL templates(m). As the creator of a new template, the administratorbecomes, by default, the first entry in the new ACL template,with abcT permissions. The control permission (c) effectivelygives the administrator ownership of the ACL, and therefore theability to modify the ACL.

As owner of the ACL, the administrator is able to use the delete(d) permission (granted in the management ACL) to remove theACL from the list of templates. You cannot delete an ACLtemplate unless you are the owner of that ACL.

¶ Server management responsibilities

This administrator is granted d, m, s, and v permissions on the/Management/Server object. This administrator can performoperations affecting the Policy Director servers.


5.D

elegatin

gA

dm

inistratio

nTasks

¶ Authorization Action responsibilities

This administrator is granted d and m permissions on the/Management/Action object. This administrator can create ordelete all permissions created for third-party applications.

Example Administration ACL TemplatesThe following example illustrates how a user gains administrationrights.

¶ The following ACL on /WebSEAL gives administration rights touser adam:

user sec_master abcTdmlrxgroup iv-admin abcTdmlrxgroup webseal-servers gTdmlrxgroup ivmgrd-servers Tluser adam abcTdmlrxany-other Trxunauthenticated Trx

Example: Management DelegationA large object space might require many administration users tomanage a variety of sub-branches. In this scenario, the ACLs for thedirectories on the path to each of these branches must contain entriesfor each account, with traverse permission. For a site with manyadministration users, these ACLs could contain a long list of entriesrepresenting all these administration accounts.

The following technique resolves the problem of numerous ACLentries for administrators:

1. Create an administration group account.

2. Add all new administration users to this group.

3. Add this group as an ACL entry (with traverse) to the directoriesleading to each sub-branch requiring management delegation.

4. At each branch root ACL, add the appropriate administration userentry (with b, c, T, plus other appropriate permissions).

104 Version 3.8

5. The administrator can now remove the administration group ACLentry (and any other entry) from the root.

Now only that user has control over the root and all objectsbelow.

In the example below, the group iv-admin contains alladministration users. User pub-manager is a member of this groupand therefore, has the necessary traverse permission required tonavigate to the Publications directory.

The Publications directory includes the user pub-manager entryin its ACL. Since pub-manager is the delegated administrator ofthis branch (with the appropriate permissions), pub-manager canremove the iv-admin group account (and any other ACL entries)from the Publications ACL to gain total control over that branchof the Web space.

/WebSEAL/server

/Resources

/Marketing

group iv-admin --b----T---------...user pub-manager -abc---Tdm----lrx

/Publications

user sec_master -abc---Tdm----lrxgroup iv-admin --b----T---------

user sec_master -abc---Tdm----lrxgroup iv-admin --b----T---------

= explicit ACL

= inherited ACL

Figure 25. Management Delegation Example


5.D

elegatin

gA

dm

inistratio

nTasks

Delegating Group ManagementPolicy Director allows high-level administrators to delegateresponsibilities for managing the secure domain to lower-leveladministrators. This capability is vital to successful management ofvery large domains composed of numerous departments that containhigh numbers of groups, users, and resources.

In order to manage a large or complex set of users, you can delegatethe management of specific groups of users to lower-leveladministrators. When an administrator is given policy managementcontrol of a group, that administrator has policy management controlover the user members of that group.

Delegated group management defines:

¶ Who has administration responsibility for a specific group (andthe user members of that group)

¶ The level of group and user control given to this administrator

In this discussion, the term “administrator” refers to theresponsibilities and controls granted to an otherwise typical user. Anadministrator of delegated duties is a normal user with additionalpowers to perform certain management tasks.

Setting up delegated group management requires the followingconditions:

1. Determine a logical and practical hierarchy of the users and usertypes who are members of the secure domain

2. Create group container objects that reflect this hierarchy

3. Create appropriate groups within these container objects

4. Strategically attach ACL policies that include theadministrator-user entry

5. Assign, to this administrator-user entry, the specific permissionsneeded to perform the required tasks

106 Version 3.8

Creating Group Container ObjectsBy default, the /Management region of the Policy Director objectspace has a Groups container object that you can use to organize thehierarchy of groups in your secure domain.

Container objects are structural designations that allow you toorganize the object space into distinct and hierarchical functionalregions. Group container objects allow you to define distinctcategories of group types. You create actual groups within eachspecific group container object.

Use the pdadmin object create command to create a new groupcontainer object:pdadmin> object create <obj-name> <description> <type>ispolicyattachable {yes|no}


obj-name Full path and name of the new group container object.Path must begin with /Management/Groups.

description Any text string describing the object. This informationappears in the object show command.

type The type argument identifies the specific graphical iconassociated with this object and displayed by theManagement Console. Types range from 0-16 (see tablebelow). Type 14 is appropriate for container objects.

ispolicyattachable

Determines whether you can attach an ACL policy tothis object.


5.D

elegatin

gA

dm

inistratio

nTasks

Object Types

0 – unknown1 – secure domain2 – file3 – executable program4 – directory5 – junction6 – WebSEAL server7 – unused8 – unused

9 – HTTP server10 – non-existent object11 – container object12 – leaf object13 – port14 – application container object15 – application leaf object16 – management object17 – unused

For example:pdadmin> object create /Management/Groups/Travel “TravelContainer Object” 10 ispolicyattachable yes

You can also use the pdadmin group create command to create agroup container object. See “Creating Groups” on page 109.

–

–

+

/Management

/Management/Groups

/Management/Groups/Travel

Figure 26. Group Container Object

108 Version 3.8

Creating GroupsUse the pdadmin group create command to create a new groupand, optionally, place this group in a group container object. If thecontainer object does not currently exist, it is automatically created:pdadmin> group create <group-name> <dn> <cn> [group-container]


group-name Name of the new group object.

dn Distinguished Name for the new group.

cn Common Name for the new group.

group-container Relative path name for the group container objectwhere this new group should be located. If no groupcontainer object is specified, the group is placedunder /Management /Groups.

¶ All new group container objects that you create appear under thedefault /Management/Groups container. To create a container atanother sub-level, use a relative path name for thegroup-container argument.

¶ The group create command does not allow you to create agroup container object without a group.

¶ To add a new group to the object space, the administrator musthave create permission (N) on the ACL governing the associatedgroup container object.

If no group container object is specified, the administrator ACLentry (with the create permission) must be specified in the ACLgoverning the /Management/Groups container.

At installation, a single default ACL (default-management)—attached to /Management—defines thepermissions on all groups and group containers. You must addappropriate explicit ACLs to customize this control.

¶ You can add multiple groups to a single group container.

The ACL on the group container object controls (throughinheritance) all groups that reside under the container object. Thecontainer object and its groups are now the domain of theadministrator with the delegated responsibilities.


5.D

elegatin

gA

dm

inistratio

nTasks

¶ The placement of a new group in the object space is fixed oncreation.

Once a group is created, you can only move its position bydeleting the group from the object space (but not LDAP) andthen import the group to a new location (users in the group willbe maintained).

For example:pdadmin> group create group1 “cn=travel,c=us” Group1 Travel

pdadmin> group create group2 “cn=travel,c=us” Group2 Travel

ACL Policies Affecting Group ManagementAuthorization to control a group of users is obtained by attaching anappropriate ACL to the group object or group container object.

The ACL, constructed and attached by a higher-level administrator,should contain the appropriate permissions for the actions that mustbe performed by the delegated administrator of that group (orgroups).

–

–

–

/Management

/Management/Groups

/Management/Groups/Travel

+ /Management/Groups/Travel/group1

+ /Management/Groups/Travel/group2

Figure 27. Creating New Groups under a Specific Group Container

110 Version 3.8

If the group resides under the /Management /Groups section of theobject space, the ACL must be attached to /Management/Groups orthe group itself.

If the group resides under a group container object, the ACL must beattached to the group container object or the group itself. If youattach the ACL to the /Management/Groups container object, theACL would impact all other group container objects located belowin the object space.

The ACL that is attached to one of these locations (or inherited fromabove) determines:¶ Who controls the group object and the users in the group¶ What actions can be performed on the group and its users

For example, in Figure 27 on page 110, an ACL on/Management/Groups/Travel defines permissions to control bothgroup1 and group2.

The following operations and ACL permissions are appropriate forgroup management:

Operation Permission

create (a new group) import (group data from theuser registry)

N (create)

delete (a group) d (delete)

show (group details) v (view)

modify (group description) m (modify)

add (an existing user to a group) A (add)

remove (a user member of the group) A (add)

You can use the appropriate pdadmin utility commands, or theManagement Console, to perform these operations.

Notes:¶ The create (N) permission must reside in an ACL that is attached

to /Management/Groups or on a group container object.


5.D

elegatin

gA

dm

inistratio

nTasks

¶ All other permissions listed can reside in an ACL attached to/Management/Groups, a group container object, or the groupobject itself.

¶ The add (A) permission is powerful because it allows you to addany existing user to your group.

If an outside user is placed into a group, the administrator ofthat group now has control of that user (and may share controlof the user with administrators of other groups where that user isa member).

This permission is best granted only to high-level administratorswho are responsible for user and group organization andcorporate policy.

ACL Policies Affecting User ManagementThe group administrator can perform an action on a user if they havethe appropriate permission defined on any of the groups where thatuser is a member.

The following operations and ACL permissions are appropriate foruser management:

Operation Permission

create (a new user within the specified group)import (user data from the user registry)

N (create)

delete (a user) d (delete)

show (user details) v (view)

modify (user description) m (modify)

account valid m (modify)

reset password W (password)

password-valid W (password)

You can use the appropriate pdadmin utility commands, or theManagement Console, to perform these operations.

112 Version 3.8

Notes:¶ The create (N) permission (in the group ACL or group container

ACL) allows you to create or import a user and enter that userinto the group you control.user create user1 “cn=user1,c=us” user1 user1 adcde group1

user import user2 “cn=user2,c=us” group1

¶ You can also create a user without designating a group. In thiscase, however, the create (N) permission must reside in an ACLon the /Management/Users container object.

The ACL attached to /Management/Users defines the permissionsfor all users (whether they are members of a group or not).

¶ A group administrator can perform an operation on a user if thatadministrator has the appropriate permission defined in anygroup where that user is a member.

¶ If a user is not a member of any group, an administrator musthave appropriate permissions in an ACL on /Management/Usersto perform operations on that user.

¶ The password (W) permission is appropriate for helpdeskoperators who must assist users who have lost their passwords.

The operator can reset the lost password to some known value,and then set user modify password-valid (pdadmin) to “no”.This action would force the user to change the password at thenext login.

¶ The view (v) permission is used to control the output of userlist, user list-dn, user show groups, group list, and grouplist-dn commands. The view permission is used to filter theoutput of these commands. If the user does not have viewpermission on a group or user that is being returned by thecommand, that group or user is filtered from the outout.


5.D

elegatin

gA

dm

inistratio

nTasks

Managing Delegated Administration PolicyThe previous two sections described separately how to delegateadministration of security policy for protecting resources in yoursecure domain and also how to delegate management of the userswho access those resources. These two individual aspects ofdelegated administration often need to be combined to establish acomplete delegated administation security policy.

Great care, however, must be taken when doing this. In particular,you must be careful which permissions you grant in combinationwith each other.

For example the “A” permission should never be granted togetherwith the “m” or “W” permissions except to the most powerful andtrusted administrators (and maybe not at all). The consequence ofgranting both “A” and “W” to an administrator is that theadministrator can add any user to the group for which they havethese permissions and then change that user’s password. Any usercan be chosen, including a more senior administrator or evensec_master. In this way, a malicious administrator could gain fullaccess to the system by logging on as that senior user.

The consequence of granting the “A” and “m” permissions togetherare similar except that an administrator with both of thesepermissions can only use this combination to disable any account.

When defining a complete delegated administration policy, theseconstraints imply a certain structure and use to your user groups.

You must establish groups that you use to delegate user managementtasks—such as creating new users, deleting users and resetting users’passwords. Administrators that perform user administration tasksshould have the “N”, “d”, “m”, “W”, and “v” permissions to create,delete, modify (disable or change description), reset or invalidatepasswords, and view users they are responsible for managing. Thesegroups are used only for delegating user management and should notbe used for protecting other resources in the secure domain.

114 Version 3.8

You must also establish groups that you use to delegate managementof security policy for protected resources within the secure domain.Administrators controlling security policy for these groups shouldhave the “A” and “v” permissions but none of the “N”, “d”, “m” or“W″ permissions. These groups are used to control access to the realresources that need protecting.

Example:

Suppose you have a Web space accessible to the internet withresources that should be:

¶ publicly accessible

¶ accessible only to customers and employees

¶ accessible only to employees

The space can be structured as:/WebSEAL/

www.company_xyz.com/customers/sales/

An ACL at the root of www.company_xyz.com’s Web space allowspublic access to everything in the Web space. An ACL at customersallows access to customers and sales people and another ACL atsales allows access only to sales people. These ACLs might looklike:public-access

user sec_master -abc---Tdm----lrxany-other -------T------lrxunauthenticated -------T------lrx

customer-accessuser sec_master -abc---Tdm----lrxgroup customers -------T------lrxgroup sales -------T------lrxany-other -----------------unauthenticated -----------------

sales-accessuser sec_master -abc---Tdm----lrxgroup sales -------T------lrxany-other -----------------unauthenticated -----------------


5.D

elegatin

gA

dm

inistratio

nTasks

These ACLs would be attached respectively at:/WebSEAL/www.compan_xyz.com/WebSEAL/www.company_xyz.com/customers/WebSEAL/www.company_xyz.com/sales

Suppose you have the following delegated user administration policy.Sales people (members of the “sales” group) are allowed to createnew accounts for customers and grant them access to the customersportion of the Web space. Only administrators (members of the“sales-admin” group) are allowed to manage accounts for new salespeople.

The following group structure implements this policy:/Management/

Groups/sales <- ACL sales-adminsales-users <- ACL sales-users-admincustomers <- ACL customers-admincustomers-users <- ACL customers-users-admin

The sales-admin ACL is used to administer membership of the salesgroup which, in turn, is used to control access to thesales-people-only portion of the Web space.. The only permisionrequired is for the “sales-admin” group to be able to add and removeusers from this group. The view (v) permission is also useful toadministrators to allow them to view the group membership and theusers in the group.sales-admin

group super-admin Tabcgroup admin TAv

The sales-users-admin ACL. by attachment to the sales-users group,controls who can manage users who are members of the sales-usersgroup (this is the “sales-admin” group again).sales-users-admin

group super-admin Tabcgroup admin TNWdmv

Similarly the customers-admin ACL is used to administermembership of the customers group which, in turn, is used tocontrol access to the customers-only portion of the Web space.

116 Version 3.8

customers-admingroup super-admin Tabcgroup sales TAv

The customers-users-admin ACL, by attachment to thecustomers-users group, controls who can manage the members ofthe customers-users group (this the sales group again). We alsoallow members of the “sales-admin” group to manage customers.customers-users-admin

group super-admin Tabcgroup sales TNWdmvgroup admin TNWdmv

Notice in each ACL, a super-admin group entry i granted attach,browse, and control permission. Members of the super-admin groupare responsible for administering these ACLs.


5.D

elegatin

gA

dm

inistratio

nTasks

118 Version 3.8

Managing the Policy DirectorServers

This chapter provides detailed information for performing generaladministration and configuration tasks on the Policy Director servers.The configuration files that support each server are also discussed.

Topic Index:

¶ “Introducing the Policy Director Servers” on page 119

¶ “UNIX: Stopping / Starting Policy Director Servers” on page124

¶ “Windows: Stopping / Starting Policy Director Servers” on page126

¶ “Automating Server Startup at Boot Time” on page 127

¶ “Management Server (pdmgrd) Administration” on page 128

Introducing the Policy Director ServersPolicy Director consists of the following server processes (daemons):

¶ Management Server (pdmgrd)

¶ Authorization Server (pdacld)

¶ WebSEAL (webseald)

These servers are automatically configured and enabled duringproduct installation.

6


6.M

anag

ing

the

Po

licyD

irector

Servers

The Management Server (pdmgrd) manages the master authorization(ACL) database and maintains location information about otherPolicy Director servers in a secure domain. The Management Servertypically requires very little administration or configuration.

The Authorization Server (pdacld) allows third-party applications tomake authorization calls (via the Authorization API) to the PolicyDirector security service. The Authorization Server typically requiresvery little administration or configuration.

WebSEAL (webseald) is a high performance, multi-threaded Webserver that applies fine-grained security policy to the protected Webobject space. WebSEAL can provide single sign-on solutions andincorporate back-end Web application server resources into itssecurity policy.

Server DependenciesImportant Policy Director server dependencies include the following:

¶ There can be only one instance of the Management Server andthe master authorization (ACL) database in any secure domain

¶ The Management Server replicates the authorization database toall other Policy Director servers in the secure domain

¶ Each resource manager (for example, WebSEAL and theAuthorization Server) applies access control policy based oninformation from the replicated authorization database

120 Version 3.8

Web PortalManager

ReplicaAuthzn

Database

MasterAuthorization

Database

UserRegistry

Management Server(pdmgrd)

WebSEAL(webseald)

Authzn Server(pdacld)

ReplicaAuthzn

Database

Figure 28. Policy Director Server Components


6.M

anag

ing

the

Po

licyD

irector

Servers

Introducing Server Administration ToolsThe following interfaces are available for performing certainadministration tasks:

¶ Web Portal Manager

¶ pdadmin utility

¶ pd_start utility

¶ Windows NT Services Control Panel

Use the Management Console’s graphical user interface (GUI) toaccomplish most server administration tasks. For specific advancedtasks not covered by the Management Console, use one of the otherutilities.

The pdadmin, and the UNIX startup scripts provide command lineinterfaces. Command line expressions are useful when automatingserver administration tasks within shell scripts.

The Web Portal Manager and pdadmin can all be used remotely orlocally. The startup scripts must be administered locally.

When troubleshooting, the command line utilities can provide statusinformation and control of individual servers.

The Web Portal Manager¶ Refer to the Tivoli SecureWay Policy Director Web Portal

Manager for Windows Administration Guide

The pdadmin UtilityPolicy Director provides the pdadmin command line utility toperform most server tasks. Use pdadmin to:

¶ Perform all administration tasks available though theManagement Console

¶ Perform all administration tasks not available though theManagement Console

¶ See “pdadmin Command Reference” on page 173.

122 Version 3.8

pd_start UtilityAdministrators can use the pd_start utility to manually stop, start,restart servers, and to display server status:

Windows NT Services Control PanelUse the Services Control Panel to:

¶ Stop a server

¶ Start a server

¶ Pause (suspend) a server

¶ Continue (resume) a paused server

¶ List configured servers

Server Configuration FilesYou can use the server configuration files to customize the operationof each Policy Director server:

Server Name ConfigurationFile

Configuration File Location

ManagementServer(pdmgrd)

ivmgrd.conf UNIX: <install-path>/etc/ivmgrd.confWindows: <install-path>\etc\ivmgrd.conf

AuthorizationServer(pdacld)

ivacld.conf UNIX: <install-path>/etc/ivacld.confWindows: <install-path>\etc\ivacld.conf

WebSEAL(webseald)

webseald.conf UNIX: /opt/pdweb/etc/webseald.confWindows:C:\Program Files\Tivoli\PDWeb\etc\webseald.conf

Policy Director Base program files are installed in the following rootdirectory:

UNIX: /opt/PolicyDirector/Windows: C:\Program Files\Tivoli\Policy Director\


6.M

anag

ing

the

Po

licyD

irector

Servers

This guide uses the <install-path> variable to represent this rootdirectory. All relative path names expressed in the Policy Directorconfiguration files are relative to this root directory.

Configuration files are ASCII text-based and can be edited using acommon text editor. The configuration files contain parameter entriesin the following format:parameter=value

The initial installation of Policy Director establishes default valuesfor most parameters. Some parameters are static and never change;others can be modified to customize server functionality andperformance.

Note: After editing a configuration file, you must stop and restartthe Policy Director server before the changes will take effect.

Each file contains sections, or stanzas, containing one or moreparameters for a particular configuration category. The stanza labelsappear within brackets [stanza-name].

For example, the [ssl] stanza in ivmgrd.conf defines the SSLconfiguration settings for the Management Server. The stanza [ldap]defines configuration required by the Management Server tocommunicate with the LDAP registry server.

The files contain comments that explain the use of each parameter.

If you find that you must change any configuration settings,carefully edit the files to ensure their integrity.

UNIX: Stopping / Starting Policy Director ServersServer processes are normally enabled and disabled throughautomated scripts that run at system startup and shutdown.

In a UNIX environment, you can also use the pd_start script tomanually start and stop the server processes. This technique is usefulwhen you need to customize an installation or when you need to

124 Version 3.8

perform troubleshooting tasks. You can only run scripts on the localmachine. Use the Web Portal Manager to stop and start serversremotely.

The general syntax for pd_start is:# pd_start {start|restart|stop|status}

You can run the pd_start utility from any directory. The scriptresides in the following directory:/opt/PolicyDirector/bin/

Stop the Policy Director Servers Using the pd_startUtility

Use the pd_start utility to stop all Policy Director servers on aparticular machine in the correct order:# pd_start stop

This script waits until all servers have stopped before returning theprompt.

Start the Policy Director Servers Using the pd_startUtility

Use the pd_start utility to start all Policy Director servers notcurrently running on a particular machine:# pd_start start

This script waits until all servers have started before returning theprompt.

Restart the Policy Director Servers Using the pd_startUtility

Use the pd_start utility to stop all Policy Director servers on aparticular machine and then restart the servers:# pd_start restart

This script waits until all servers have started before returning theprompt.


6.M

anag

ing

the

Po

licyD

irector

Servers

Start Individual Servers ManuallyYou can manually start the servers individually by executing theserver directly. The server initializes itself, and if successful,daemonizes itself.

You must perform the startup commands as an administration user,such as root.

Start the Policy Director servers in the following order:

1. Management Server (pdmgrd):# <install-path>/bin/pdmgrd

2. Authorization Server (pdacld):# <install-path>/bin/pdacld

Displaying Server Status Using the pd_start UtilityUse the pd_start command to display server status:# pd_start statusPolicy Director Servers:Server Enabled Runningpdmgrd yes yeswebseald no nopdacld yes no

Windows: Stopping / Starting Policy Director ServersUse the Windows NT Services Control Panel to start and stop theserver processes manually. This can be useful when customizing aninstallation or when troubleshooting. Administrative privileges arerequired to use this utility.

You can start and stop the Policy Director servers all at once orindividually. The servers generally must be stopped and started in thecorrect order.

Using the Services Control Panel to Stop / StartServers

The AutoStart Service automatically starts each of the PolicyDirector servers whenever the Startup configuration is set to“Automatic”. After the servers start, the AutoStart Service exits.

126 Version 3.8

You can also use the Services Control Panel to manually start andstop the individual servers:

1. Open the Windows Control Panel.

2. Double-click the Services icon.

The Services dialog box appears.

3. From the list box, select the Policy Director servers according tothe sequence indicated in Steps 4 and 5.

4. Stop the Policy Director servers in the following order:

¶ Authorization Server


5. Start the Policy Director servers in the following order:


¶ Authorization Server

6. Click the appropriate control option button (Start, Stop, Startup)from the right-hand side of the box.

7. To prevent automatic starting of a Policy Director server by theAutoStart Service, use the “Startup...” option button to set thatserver to Disabled.

Automating Server Startup at Boot TimeParameters for automating server startup are located in the [pdrte]stanza of the pd.conf configuration file.

Management ServerWhen the PDMgr package is installed, the Management Serverdaemon (pdmgrd) automatically starts after each system reboot:[pdrte]boot-start-ivmgrd = yes

To prevent automatic pdmgrd startup, set:boot-start-ivmgrd = no


6.M

anag

ing

the

Po

licyD

irector

Servers

Note: Each secure domain must contain only one ManagementServer. Do not install and run pdmgrd on more than oneserver per secure domain.

Authorization ServerWhen the PDAcld package is installed, the Authorization Serverdaemon automatically starts after each system reboot:[pdrte]boot-start-ivacld = yes

To prevent automatic pdacld startup, set:boot-start-ivacld = no

Management Server (pdmgrd) AdministrationThe Management Server manages the master authorization policydatabase and maintains location information about other PolicyDirector servers in the secure domain. The Management Servertypically requires very little administration or configuration. Thissection describes configuration tasks available to the administrator.

¶ “Replicating the Authorization Database” on page 128

¶ “Setting the Number of Update Notifier Threads” on page 130

¶ “Setting the Notification Delay Time” on page 131

Replicating the Authorization DatabaseA Policy Director administrator can make security policy changes tothe secure domain at any time. A primary responsibility of theManagement Server is to make the necessary adjustments to themaster authorization database to reflect these changes.

When the Management Server makes a change to the masterauthorization database, it can send out notification of this change toall authorization servers (with replica databases). The authorizationservers must then request a database update from the masterauthorization database.

Note: Additionally, client servers can check for database updates bypolling the Management Server at regular intervals. Polling

128 Version 3.8

configuration for a WebSEAL client, for example, isexplained in the Tivoli SecureWay Policy Director WebSEALAdministration Guide.

Policy Director allows you to configure update notifications from theManagement Server to be an automatic process or a manuallycontrolled task. The auto-database-update-notify parameter islocated in the [ivmgrd] stanza of the ivmgrd.conf configurationfile. By default, the parameter is set to “yes” (update notification isautomatically performed by the Management Server):[ivmgrd]auto-database-update-notify = yes

This automatic setting is appropriate for environments wheredatabase changes are few and infrequent. When you configureupdate notification to be automatic, you must also correctlyconfigure the max-notifier-threads and notifier-wait-timeparameters. See “Setting the Number of Update Notifier Threads” onpage 130 and “Setting the Notification Delay Time” on page 131.

When you configure update notification to be manual, manualapplication of the pdadmin server replicate command controls thisevent.[ivmgrd]auto-database-update-notify = no

This manual setting is appropriate for environments where databasemodifications occur frequently and involve substantial changes. Insome cases several database modifications can generate many updatenotifications which soon become obsolete because of the continuingchanges to the master database. These obsolete notifications causeunnecessary network traffic.

The manual control of update notification allows you to complete theprocess of modifying the master authorization database before updatenotifications are sent out to authorization servers with databasereplicas.


6.M

anag

ing

the

Po

licyD

irector

Servers

In manual mode, update notification uses the notifier thread pool (asit does in automatic mode). Therefore, the manual mode setting isaffected by the max-notifier-threads parameter setting. See “Settingthe Number of Update Notifier Threads” on page 130.

Using the pdadmin server replicate CommandWhen you configure update notification to be manual, manualapplication of the pdadmin server replicate command controls thisevent. The command has the following syntax:pdadmin> server replicate [-server <server-name>]

If the optional server-name argument is specified, only that server isnotified of changes to the master authorization database. A responseis returned indicating the success or failure of the notification andthe replication.

If the server-name argument is not specified, all configuredauthorization servers receive update notifications. A successfulresponse only indicates that the Management Server has begunsending out update notifications. The response does not indicatesuccess or failure of the actual notification and replication processes.

The authorization required to execute this command is “s” on the/Management/Server object.

Setting the Number of Update Notifier ThreadsThe Management Server is responsible for synchronizing all databasereplicas in the secure domain. When a change is made to the masterdatabase, notification threads do the work of announcing this changeto all replicas. Each replica then has the responsibility to downloadthe new information from the master.

The Management Server configuration file, ivmgrd.conf, contains aparameter for setting the maximum number of update notifierthreads. This pool of threads allows simultaneous (parallel)notification.

For example, to concurrently notify 30 replicas of a database change,the thread pool should be set to at least 30. If there are more than 30

130 Version 3.8

replicas, another round of notifications occurs (in this example, 30 ata time). All replicas are guaranteed to be notified, regardless of thevalue of this parameter.

The performance goal of the update notifier threads value is toannounce a database change as quickly as possible. Generally thevalue should be set to equal the number of existing replicas. Thisresults in the performance advantage of a single pool of threadsquickly accomplishing the notification task to all replicas at once.

The default event notifier thread pool is set as:[ivmgrd]max-notifier-threads = 10

See also “Setting the Notification Delay Time”.

Setting the Notification Delay TimeWhen the Management Server is instructed to make a change to themaster authorization database, it waits for a default period of timebefore sending out notifications to database replicas. The defaulttime delay is set at 15 seconds. This time delay is reset with eachsubsequent change to the database.

The purpose of the time delay is to prevent the Management Serverfrom sending individual replica notifications for each of a series ofdatabase changes. The time delay helps to ensure optimalperformance of the Policy Director system.

This performance feature is particularly important for environmentswhere batch changes are made to the authorization database. It is notefficient for policy changes to be sent to database replicas until allchanges have been made.

You can override this default notification time delay by changing thenotifier-wait-time parameter value (in seconds), located in the[ivmgrd] stanza of the ivmgrd.conf configuration file. For example:[ivmgrd]notifier-wait-time = 20

By default, the value is set to 15 seconds.


6.M

anag

ing

the

Po

licyD

irector

Servers

132 Version 3.8

Using the LDAP Registry

LDAP is a protocol that runs over TCP/IP. The LDAP protocolstandard includes low-level network protocol definitions plus datarepresentation and handling functionality. A directory that isaccessible through LDAP is commonly referred to as an LDAPdirectory.

The default installation of Policy Director uses the LDAP directoryto store user information. IBM’s implementation of LDAP is knownas IBM SecureWay Directory. iPlanet’s implementation of LDAP isknown as iPlanet Directory Server. This chapter discussesconfiguration features of the Policy Director LDAP registry.

Topic Index:

¶ “LDAP Overview” on page 133

¶ “LDAP Fail-over Configuration” on page 139

¶ “Applying Policy Director ACLs to New LDAP Suffixes” onpage 144

LDAP OverviewIn 1988, the CCITT (Consultative International Telephonique etTelegraphique, which is now ITU-T, InternationalTelecommunications Union -Telecommunication StandardizationSector) created a standard for directory services known as X.500.

7


7.U

sing

the

LD

AP

Reg

istry

The X.500 directory service soon became ISO standard 9594 (DataCommunications Network Directory, RecommendationsX.500-X.521) in 1990.

The ISO set of standards is still commonly referred to as X.500.X.500 defines a directory that can be universally used for largeamounts of data. Today, X.500 directories are used by nationaltelephone organizations for large, online telephone directories.

To access an X.500 directory, a client uses the Directory AccessProtocol (DAP) that was defined along with the X.500 standard.Unfortunately, DAP is a rather complex protocol that cannot beeasily supported on thin clients, such as desktop computers.

X.500 was therefore limited to powerful computers and large-scaleimplementations. The requirement to access centralized directoriesfrom slim clients, however, became important to support the obviouscost-effectiveness of centralized directories.

Work performed at the University of Michigan and at NetscapeCommunications Corporation led to a simplified version of DAP,called the Lightweight Directory Access Protocol (LDAP). LDAPsupports most of the features of DAP, but lacks some of the complexand seldom used functions. The LDAP implementation is relativelysimple and can be used by desktop applications.

LDAP: A Protocol for Directory ServicesLDAP is a protocol that runs over TCP/IP. The LDAP protocolstandard includes low-level network protocol definitions plus datarepresentation and handling functionality. A directory that isaccessible through LDAP is commonly referred to as an LDAPdirectory.

Note: The LDAP standard does not define how the data is stored inthe directory.

134 Version 3.8

Initially, LDAP was designed to allow thin clients to access anX.500 directory through a gateway server that did translationbetween LDAP and DAP.

Soon, directories were developed that could handle the LDAPprotocol natively rather than performing a translation between LDAPand DAP.

The IBM implementation of an LDAP directory is the SecureWayDirectory, which is available on AIX, Windows NT, Sun Solaris,OS/400, and OS/390.

An LDAP directory can use any storage implementation for thedirectory data. While most implementations use flat file databases,the IBM SecureWay Directory uses the high-performance,highly-scalable DB2 relational database as its storageimplementation.

LDAPClient Directory

LDAPGatewayServer

X.500Server

TCP

LDAP

OSI

DAP

Figure 29. LDAP Access to X.500

LDAPClient Directory

LDAPServer

TCP

LDAP

Figure 30. Stand-alone LDAP Server


7.U

sing

the

LD

AP

Reg

istry

LDAP DirectoriesMost directories store information similar to the structure of aprinted phone book. The entries are usually organized in ahierarchical way that allows efficient and flexible management andsearching.

LDAP directories are much more powerful and are not limited toname, phone number, and address entries. In fact, an LDAP directorycan store (and subsequently retrieve) almost any kind of data. Thetype of data that can be stored in an LDAP directory is defined bythe directory schema, which can be extended and adapted to meetyour requirements.

The task of defining a directory schema and the hierarchicaldirectory information tree can be compared to the design of arelational database. Thorough analysis of application requirements,corporate standards, and data definitions is necessary to design adirectory schema and the directory information tree (DIT).

LDAP server products, such as the IBM SecureWay Directory,provide a comprehensive schema that can be used, unlessrequirements dictate specific modifications.

IBM supports current and evolving standards and proposals for datadefinitions by actively participating in the standards process and byimplementing the results in the IBM SecureWay Directory. The mostimportant standards body for LDAP is the Internet Engineering TaskForce (IETF), where representatives of IBM and other key industryleaders actively support these activities.

Every organization uses directories. For example, most modernoperating systems, such as UNIX or Windows 9x/NT, store useraccount information either locally or on departmental servers.Network operating systems, such as NetWare (Novell), also requireuser databases. Departments can maintain a local employee database,while at the corporate level, there are large human resourcedatabases. In addition, operating systems store large amounts of dataabout system configuration and other network resources, such asprinters and servers.

136 Version 3.8

Information is often stored across multiple locations, makingadministration and maintenance unnecessarily difficult. A majorreason why LDAP has quickly gathered so much interest is thepotential for a single, standards based directory for distributedinformation.

The LDAP Information ModelThe LDAP information model is based on a subset of the X.500information model. Data in an LDAP directory is stored in entriesthat contain attributes. Attributes are typed in the form:type = value

where the type is defined by an object identifier (OID), and thevalue has a defined syntax. Attributes can be single-valued (forexample, a person can only have one date-of-birth) or multi-valued(a person can have multiple phone numbers).

Each entry in an LDAP directory has a unique distinguished name(DN). The directory schema defines rules for DNs and whatattributes an entry must contain. To organize the information storedin directory entries, the schema defines object classes. An objectclass consists of mandatory and optional attributes.

Object classes can be inherited from other object classes, whichprovides a method for easy extensibility (for example, new objectclasses can be defined by just adding new attributes to existingobject classes).

LDAP Features

ScalabilityLDAP directories, particularly when they are backed up by arelational database as in the IBM SecureWay Directory, are highlyscalable. Large directories with millions of entries are possible withexcellent performance.

Due to the common standard base, another scalability factor is theeasy step-up possibility to more powerful hardware and software.LDAP does not rely on a specific operating system and isvendor-independent.


7.U

sing

the

LD

AP

Reg

istry

AvailabilityLDAP supports replication and splitting of namespaces. Replicationallows multiple LDAP servers to store the same directory contents.Clients benefit from these additional servers available whenever onefails.

Splitting allows sections of the whole directory to be stored ondifferent servers at different locations. This not only increasesavailability (no single point of failure) but also offers an easy wayfor distributed management.

SecurityLDAP supports security features that prevent unauthorized access todata. Secure communication protocols, such as SSL andauthentication mechanisms, along with access control lists (ACL)policies for data entries, guarantee a maximum level of security.

ManageabilityCurrent versions of LDAP, such as the IBM SecureWay Directory,provide a graphical user interface for both system administration anddirectory data administration. Dynamically extensible schema allowsyou to extend the directory schema without interrupting the service.

StandardizationThe LDAP protocol—and many related client/server capabilities,application programming interfaces (APIs), and data definitions—aredefined by either official standards or corresponding RFCs (Requestfor Comments).

Lightweight Directory Access Protocol (v3), RFC 2251, for example,defines the basic LDAP protocol. Other features, that are widelyaccepted and implemented, are defined in Internet drafts. Much ofthis work is done by the IETF (Internet Engineering Task Force) andthe DMTF (Distributed Management Task Force).

138 Version 3.8

LDAP Fail-over ConfigurationThe Lightweight Directory Access Protocol (LDAP) defines astandard method for accessing and updating information in adirectory. Directories are usually accessed using the client/servermodel of communication. Any server that implements the LDAPprotocol is an LDAP directory server.

Policy Director supports the use of LDAP for its user registry. IBM’simplementation of LDAP is known as IBM SecureWay Directory.iPlanet’s implementation of LDAP is known as iPlanet DirectoryServer.

The LDAP distributed architecture supports scalable directoryservices with server replication capabilities. Server replicationimproves the availability of a directory service. IBM SecureWayDirectory replication is based on a master-slave model. iPlanetDirectory Server replication is based on a supplier/consumer model.Policy Director still treats this as a master/slave relationship.

The combination of a master server and multiple replicated servershelps ensure that directory data is always available when needed. Ifany server fails, the directory service continues to be available fromanother replicated server. Policy Director supports this replicationcapability.

The Master-Slave Replication ModelReplication involves two types of directories: master and replica.LDAP refers to the master as master server and to the replica asreplica server. For a particular directory structure, there is one masterserver (the read-write server). All updates are made on the masterserver and these updates are subsequently propagated to the replicaservers. Each replica server database contains an exact copy of themaster server’s directory data.

Changes to the directory can be made only to the master server,which is always used for write operations to the directory. Either themaster or the replicas can be used for read operations. When the


7.U

sing

the

LD

AP

Reg

istry

original master server is out of service for an extended period oftime, a replica server can be promoted as a master server to allowwrite operations to the directory.

Policy Director Fail-over Capability for LDAP ServersPolicy Director connects to the LDAP master server when it startsup. If the LDAP master server is down for any reason, the PolicyDirector server must be able to connect to an available LDAP replicaserver for any read operations.

Many operations, especially those from regular users, are readoperations. These include such operations as user authentication andsign-on to back-end junctioned Web servers. After properconfiguration, Policy Director will fail-over to a replica server whenit cannot connect to the master server.

You can find the configuration parameters for LDAP fail-over in the[ldap] stanza of the ldap.conf configuration file:

UNIX: /opt/PolicyDirector/etc/ldap.confWindows: <install-path>\etc\ldap.conf

Master Server ConfigurationIBM SecureWay Directory (LDAP) supports the existence of a singleread-write master LDAP server. iPlanet Directory Server supportsmultiple read-write LDAP servers. Policy Director treats the iPlanet“supplier” server as the master server for configuration purposes.

The active configuration lines in the ldap.conf file represent theparameters and values for this master LDAP server. You determinethese values during Policy Director configuration. For example:[ldap]enabled = yeshost = outbackport = 389ssl-port = 636max-search-size = 2048

140 Version 3.8

Parameter Description

enabled Policy Director uses an LDAP user registry. Valuesare “yes” and “no”.

host The network name of the machine where the LDAPmaster server is located.

port The TCP listening port of the LDAP master server.

ssl-port The SSL listening port of the LDAP master server.

max-search-size The Policy Director limit for an LDAP client searchof database items - such as a request for theManagement Console to list users from the LDAPdatabase.

If you make a change to the LDAP database, such as adding a newuser account through the Management Console, Policy Directoralways uses the read-write (master) LDAP server.

Replica Server ConfigurationIBM SecureWay Directory (LDAP) supports the existence of one ormore read-only replica LDAP servers. iPlanet Directory Server(LDAP) supports the existence of one or more read-only replicaLDAP servers referred to as “consumers”.

You must add lines to the [ldap] stanza that identify any replicaservers available to Policy Director. Use the following syntax foreach replica:replica = <ldap-server>,<port>,<type>,<preference>


ldap-server The network name of the LDAP replica server.

port The port this server listens on. Generally, use 389 or636.

type The functionality of the replica server - either“read-only” or “read-write”. Normally, use“read-only”. A “read-write” type would represent amaster server.


7.U

sing

the

LD

AP

Reg

istry


preference A number from 1 - 10. The server with the highestpreference value is chosen for LDAP connections.See “Setting Preference Values for Replica LDAPServers”.

Example:replica = replica1.ldap.tivoli.com,389,readonly,5replica = replica2.ldap.tivoli.com,389,readonly,5

Changes to the ldap.conf file do not take effect until you restartPolicy Director.

Setting Preference Values for Replica LDAP ServersEach replica LDAP server must have a preference value (1-10) thatdetermines its priority for selection as:

¶ The primary read-only access server, or

¶ A backup read-only server during a fail-over

The higher the number, the higher the priority. If the primaryread-only server fails for any reason, the server with the next highestpreference value is used. If two or more servers have the samepreference value, a least-busy load balancing algorithm determineswhich one is selected.

Remember that the master LDAP server can function as both aread-only and a read-write server. For read-only access, the masterserver has a hard-coded default preference setting of 5. This allowsyou to set replica servers at values higher or lower than the masterto obtain the required performance. For example, with appropriatepreference settings, you could prevent the master server fromhandling everyday read operations.

You can set hierarchical preference values to allow access to a singleLDAP server (with fail-over to the other servers), or set equalpreferences for all servers and allow load balancing to dictate serverselection.

142 Version 3.8

The following table illustrates some possible preference scenarios.“M” refers to the master (read-only/read-write) LDAP server; “R1,R2, R3” refer to the replica (readonly) LDAP servers.

M R1 R2 R3 Fail-over Preference

5 5 5 5 All servers have the same preferencevalues. Load balancing determines whichserver is selected for each access operation.

5 6 6 6 The three replica servers have the samepreference value. This value is higher thanthe master server value. Load balancingdetermines server selection among the threereplicas. The master is only used if all threereplica servers become unavailable.

5 6 7 8 Server 3 (with the highest preference value)becomes the primary server. If server3 fails,server 2 becomes the primary serverbecause it has the next highest preferencevalue.

Preference values only affect read-only access to the LDAP database.Policy Director always uses the master (read-write) server when youneed to make a change to the LDAP database.

Also note that some Policy Director daemons (such as theManagement Server) override the preference settings in theirconfiguration files to indicate that the read-write server is preferred.This is because those daemons usually make update operationswhich should go to the master LDAP server.

Server PollingIf an LDAP server does fail, Policy Director continuously polls theserver to check for its return to active duty. The poll time is 10seconds.


7.U

sing

the

LD

AP

Reg

istry

Applying Policy Director ACLs to New LDAP Suffixes

Note: The following information applies to both IBM SecureWayDirectory Server and iPlanet Directory Server.

When an LDAP administrator adds LDAP suffixes after the initialconfiguration of Policy Director, the administrator must apply theappropriate Access Control Lists (ACLs) to allow Policy Director tomanage users and groups defined in these new suffixes.

For IBM SecureWay Directory, use the Directory Management Toolto apply ACLs. For Netscape LDAP server, use the iPlanet Console5.0.

Use the appropriate LDAP administration interface to apply thefollowing ACLs to every new Policy Director suffix:

LDAP Group Access Control

cn=SecurityGroup,secAuthority=Default

¶ full access

cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default

¶ read

¶ search

¶ compare

cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default

¶ read

¶ search

¶ compare

These controls apply when the administrator has selected LDAP forthe Policy Director user registry and a new LDAP suffix has beencreated after Policy Director is initially configured. It is assumed thatyou are the Policy Director administrator and are familiar with both

144 Version 3.8

Policy Director and LDAP. It is further assumed that, asadministrator, you have the proper authority to update the LDAPDirectory Information Tree.

When Policy Director is configured, it attempts to apply appropriateACLs to every LDAP suffix that exists at that time in the LDAPserver. This access control allows Policy Director to create andmanage user and group information within these LDAP suffixes.

However, if a suffix is created after Policy Director has beenconfigured, and Policy Director must later be able to create andmanage user and group information within this new suffix, then theappropriate access controls need to be applied manually. Withoutthese access controls, Policy Director does not have the appropriateLDAP permission to create and manage user and group informationspecified to be within this new suffix.

To apply the appropriate access controls to the newly created LDAPsuffix, perform the following steps for either the IBM SecureWayDirectory or the iPlanet Directory Server, depending on the LDAPserver type being used.

Note that the procedures assume that the newly created suffix iscalled “o=neworg,c=us”. You should substitute the actual newlycreated suffix for this value in the following descriptions.

Procedures for IBM SecureWay Directory ServerThe following steps describe how to apply the appropriate PolicyDirector access controls to the newly created suffix for the IBMSecureWay Directory Server.

1. Start the LDAP Directory Management Tool (DMT) with one ofthe following comamnds:

On Windows: Start -> Programs -> IBM SecureWayDirectory -> Directory Management Tool

On UNIX:# /usr/bin/dmt

2. The following warning may appear:Warning: Entry o=neworg,c=us does not contain any data.


7.U

sing

the

LD

AP

Reg

istry

Dismiss the warning. In step 7, you will need to remember ifyou’ve seen this warning.

3. Click the Add Server button in the left pane. The Add Serverwindow appears.

4. Enter these values for each of the following fields:

Field Value Comment

Server Name: ldap://<hostname> For example,ibm007.ibm.com

Port: 389 389 is the default port

User DN: cn=root DN of the LDAPadministrator

User Password: abc123 Password of the LDAPadministrator

5. Click OK. The Directory Management Tool page appears.

6. Verify the server name in the upper part of the left frame. Forexample, ldap://ibm007.ibm.com:389

7. From the tree structure on the left, select Directory Tree ->Browse Tree. The following warning might appear:Warning: Entry o=neworg,c=us does not contain any data.

8. Skip to step 9 on page 147 if you have not seen the followingmessage:Warning: Entry o=neworg,c=us does not contain any data.

If you have seen this message, you must create an entry for thesuffix. Access control cannot be applied to the suffix until anentry exists. Follow these steps to create an entry:

a. Click the Add button in right pane. The Add an LDAPEntry dialog box is displayed.

b. Set the entry type to Organization. Set the parent DN toc=us. Set the entry DN to o=neworg. Click OK. The entrypage for organization is displayed within the Add an LDAPdialog box.

146 Version 3.8

c. Enter the organization name (neworg) in the Attributessection at the o: label.

d. Click Add. The Browse Directory Tree page is displayed.

9. Click Directory Tree -> Refresh Tree in the left pane.

10. Highlight the newly created suffix in the Browse Tree pane onthe right.

11. Click the ACL button in the right pane. The current accesscontrol list settings for the suffix are displayed in the Edit anLDAP ACL window.

12. In the Subject area of the Edit an LDAP ACL window, enter thefollowing Distinguished Name:cn=SecurityGroup,secAuthority=Default

Check the group type and click Add.

13. When the window is displayed, make the following selections:

¶ In the DN entry box, select Descendant directory treeentries inherit from this entry.

¶ In the Rights box, for Add child and Delete entry, selectGrant.

¶ In the Security class box, for each security class (Normal,Sensitive, and Critical), select Grant for each permission(Read, Write, Search, and Compare).

Click OK.

14. Highlight the newly created suffix in the Browse Tree pane onthe right.

15. Click the ACL button in the right pane. Verify that thecn=SecurityGroup,secAuthority=Default group is listed andthe settings for the group are correct. Group names are notcase-sensitive.

16. In the subject area of the Edit an LDAP ACL window, enter thefollowing Distinguished Name:cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default


7.U

sing

the

LD

AP

Reg

istry

Select the group Type and click Add.



¶ In the Rights box, for Add child and Delete entry, selectUnspecified.

¶ In the Security class box, for the Normal security class,select Grant for the Read, Search and Comparepermissions.

¶ In the Security class box, for the Normal security class,select Unspecified for the Write permissions.

¶ In the Security class box, for the Sensitive and Criticalsecurity classes, select Unspecified for all permissions.

Click OK.

18. Highlight the newly created suffix in the Browse Tree pane onthe right. Click the ACL button in the right pane. Verify thatthe cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default group islisted and the settings for the group are correct. Group namesare not case-sensitive.

19. In the Subject area of the Edit an LDAP ACL window, enter thefollowing Distinguished Name:cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default

Select the group Type and click Add.



¶ In the Rights box, select Unspecified for Add child andDelete entry.

¶ In the Security class box, for the Normal security class,select Grant for the Read, Search, and Comparepermissions.

148 Version 3.8

¶ In the Security class box, for the Normal security class,select Unspecified for the Write permission.

¶ In the Security class box, for the Sensitive and Criticalsecurity classes, select Unspecified for each permission(Read, Write, Search, and Compare).

Click OK.

21. Click Exit to close the Directory Management Tool.

Procedures for iPlanet Directory ServerNote that these procedures describe the creation of ACLs for suffixesusing the iPlanet Console 5.0.

1. Start the iPlanet Console 5.0 with one of the followingcommands:

¶ On UNIX systems, enter the following from the iPlanetDirectory server install directory:# ./startconsole

¶ On Windows systems, click: Start -> Programs -> iPlanetServer Products -> iPlanet Console 5.0

2. Enter the User ID for the LDAP administrator. This will usuallybe cn=Directory Manager. Enter the password and theAdministration URL. Click OK.

3. Select the Domain to be used by Policy Director.

4. Expand the server name and Server Group.

5. Select the entry labeled Directory Server. Configurationinformation about the iPlanet Directory server is displayed.

6. Click the Open button. The iPlanet Directory server is accessed.

7. Click the Directory tab. If the newly created suffix is displayedin the left pane, skip to step 8 on page 150.

If the newly created suffix does not appear in the left pane, youmust create an entry for the new suffix before applying accesscontrols to the suffix. Follow these steps to create the entry:


7.U

sing

the

LD

AP

Reg

istry

a. Highlight the name of the server at the top of the directorytree. Click Object -> New Root Object. A list of rootsuffixes is displayed.

b. Select o=neworg,c=us from the list of root suffixes. TheNew Object selection window is displayed.

c. In the New Object selection window, scroll down and selectOrganization as the new object entry type.

d. Click OK. The Property Editor window is displayed.

e. Fill in the Organization field as neworg and click OK.

Note: These instructions assume an example suffix. Createthe entry type and name which corresponds to youractual suffix.

f. Click View -> Refresh. The new suffix entry will appear inthe left pane.

8. Highlight the neworg entry in the left pane. Click Object ->Set Access Permissions. The Manage Access Control foro=neworg,c=us window is displayed.

9. Click New to display the Edit ACI for o=neworg, c=us window.

10. Specify the ACI name as SECURITY GROUP - ALLOW ALL.

11. Highlight the All Users name and click Remove.

12. Click Edit Manually. The Edit ACI for o=neworg,c=us windowis displayed.

13. Replace the default ACI text with the following:(target="ldap:///o=neworg,c=us")(targetattr="*")(version 3.0; acl "SECURITY GROUP - ALLOW ALL";allow (all)groupdn = "ldap:///cn=SecurityGroup,secAuthority=Default";)

Click Check Syntax to ensure that you have entered the textcorrectly. Correct any errors until the syntax passes the check.

14. Click OK. The Manage Access Control for o=neworg,c=uswindow is displayed.

150 Version 3.8

15. Click New. Specify the ACI name asPD Servers GROUP - ALLOW READ



18. Replace the default ACI text with the following:(target="ldap:///o=neworg,c=us")(targetattr="*")(version 3.0; acl "SECURITY GROUP - ALLOW READ";allow(read, search, compare)groupdn = "ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default";)



20. Click New. Specify the ACI name as PD Remote ACL UsersGROUP -ALLOW READ.



23. Replace the default ACI text with the following:(target="ldap:///o=neworg,c=us")(targetattr="*")(version 3.0; acl "SECURITY GROUP - ALLOW READ";allow (read, search, compare)groupdn = "ldap:///cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default";)



25. Click New. Specify the ACI name as PD Deny-Others1.



7.U

sing

the

LD

AP

Reg

istry


28. Replace the default ACI text with the following:(targetfilter="(|(objectclass=secUser)(objectclass=secGroup))")(version 3.0; acl "PD Deny-Others"; deny(all)groupdn != "ldap:///cn=SecurityGroup,secAuthority=Default ||ldap:///cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default ||ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default";)



30. Click New. Specify the ACI name as PD Deny-Others2.



33. Replace the default ACI text with the following:(targetfilter="(|(objectclass=secPolicyData)(objectclass=secPolicy))")(version 3.0; acl "PD Deny-Others"; deny(all)groupdn != "ldap:///cn=SecurityGroup,secAuthority=Default ||ldap:///cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default ||ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default";)



35. Click OK to close the Manage Access Control foro=neworg,c=us window.

36. Click Console -> Exit to exit the console.

152 Version 3.8

Logging and Auditing ServerActivity

Policy Director provides a number of logging and auditingcapabilities. Log files can capture any error and warning messagesgenerated by Policy Director servers. Audit trail files can captureauthorization, authentication, management, and HTTP eventsoccurring on the Policy Director servers.

Topic Index:

¶ “Introduction to Logging and Auditing” on page 153

¶ “Policy Director Server Log Files” on page 155

¶ “Serviceability Messages” on page 156

¶ “Policy Director Audit Trail Files” on page 158

¶ “Audit Trail File Format” on page 161

¶ “Audit Trail File Contents” on page 164

Introduction to Logging and AuditingThe contents of log and audit trail files can be a useful source ofinformation when monitoring and troubleshooting the activity ofPolicy Director servers.

Log FilesLog files are used by the Policy Director servers to store warningand error messages. All log files are in ASCII format.

8


8.L

og

gin

gan

dA

ud

iting

Server

Activity

Policy Director provides the following log files:

1. Policy Director server log files

See “Policy Director Server Log Files” on page 155.

2. Serviceability messages

See “Serviceability Messages” on page 156.

Audit Trail FilesAudit trail files are used by the Policy Director servers to storerecords of server activity. The output of a specific server event iscalled a record. An audit trail is a collection of multiple records thatdocument the server activity. All Policy Director audit trail files arein ASCII format.

Policy Director audit trail files record events for the followingservers:




See “Policy Director Audit Trail Files” on page 158.

See “Audit Trail File Format” on page 161.

See “Audit Trail File Contents” on page 164.

Documentation Convention: <install-path>The <install-path> variable used throughout this chapter has thefollowing interpretations, according to operating system platform:

UNIX: /opt/PolicyDirector/Windows: \Program Files\Tivoli\Policy Director

This pathname is fixed in UNIX and cannot be modified.

The Windows platform allows you to define <install-path> duringthe installation of the Policy Director software.

154 Version 3.8

Policy Director Server Log FilesEach Policy Director server dynamically generates warning and errormessages that are directed to standard error and then redirected tospecific log files.

Server Log File Location


(Parameters in ivmgrd.conf configuration file.)UNIX:log-file=/var/PolicyDirector/log/pdmgrd.logWindows:log-file=<install-path>\log\pdmgrd.log

Authorization Server(pdacld)

(Parameters in ivacld.conf configuration file.)UNIX:log-file=/var/PolicyDirector/log/pdacld.logWindows:log-file=<install-path>\log\pdacld.log

WebSEAL(webseald)

(Parameters in webseald.conf configuration file.)UNIX:log-file=/var/PolicyDirector/log/webseald.logWindows:log-file=<install-path>\log\webseald.log

Enabling and Disabling Policy Director Server LogFiles

Logging is enabled when there is a log file defined in theconfiguration file for the specific server.

Example: ivmgrd.log2001-08-18-20:03:26.231+00:00I----- 0x1354A0A0 pdmgrd NOTICE ivcgeneral ivmgrd.cpp 720 0x00000001Open database2001-08-18-20:03:26.232+00:00I----- 0x1354A0A0 pdmgrd NOTICE ivcgeneral ivmgrd.cpp 727 0x00000001Creating database2001-08-18-20:03:26.312+00:00I----- 0x1354A0A0 pdmgrd NOTICE ivcgeneral ivmgrd.cpp 749 0x00000001Initialize client notifier2001-08-18-20:03:26.315+00:00I----- 0x1354A0A0 pdmgrd NOTICE ivc


8.L

og

gin

gan

dA

ud

iting

Server

Activity

general ivmgrd.cpp 760 0x00000001Initialize local object cache2001-08-18-20:03:26.728+00:00I----- 0x1354A0A0 pdmgrd NOTICE ivcgeneral ivmgrd.cpp 825 0x00000001Initialize authorization manager2001-08-18-20:03:29.278+00:00I----- 0x1354A0A0 pdmgrd NOTICE ivcgeneral ivmgrd.cpp 833 0x00000001Initialize client authorization2001-08-18-20:03:31.341+00:00I----- 0x1354A0A0 pdmgrd NOTICE ivcgeneral ivmgrd.cpp 863 0x00000001Initialize server manager2001-08-18-20:03:31.345+00:00I----- 0x1354A0A0 pdmgrd NOTICE ivcgeneral ivmgrd.cpp 872 0x00000001Initialize command handlercpp 937 0x000000012.799+00:00I----- 0x1354A0A0 pdmgrd NOTICE ivcgeneral ivmgrd.Server readypp 528 0x0000001335.377+00:00I----- 0x10652105 pdmgrd NOTICE basmts mtsserver.cThe server is listening on port 7135.

Serviceability MessagesServiceability messages are controlled by the routing file:

UNIX: /opt/PolicyDirector/etc/routingWindows: <install-path>\etc\routing

Entries in this configuration file determine the type of informationthat will be logged. The routing file includes the following defaultentries:

UNIX:FATAL:STDOUT:-;FILE:/var/PolicyDirector/log/fatal.logERROR:STDOUT:-;FILE:/var/PolicyDirector/log/error.logWARNING:STDOUT:-;FILE:/var/PolicyDirector/log/warning.logNOTICE:FILE.10.100:/var/PolicyDirector/log/notice.log

Windows:

156 Version 3.8

FATAL:STDERR:-;FILE:%PDDIR%/log/fatal.logERROR:STDERR:-;FILE:%PDDIR%/log/error.logWARNING:STDERR:-;FILE:%PDDIR%/log/warning.logNOTICE:FILE.10.100:%PDDIR%/log/notice.log

Directing Messages to Standard OutputWarning and error messages (including NOTICE messages) arenormally redirected to the appropriate log files.

To direct these messages to standard output (terminal), use the-foreground command option when starting a server. This optionwill cause the server to run in the foreground (that is, the server willnot daemonize itself), and warning and error messages will bewritten to standard output.

For example, to start the Management Server in debug mode, use thefollowing command:# /opt/PolicyDirector/bin/pdmgrd -foreground

You can also use the UNIX tee command to capture the serveroutput to a single file.

The following example illustrates starting the Management Server inthis mode:# pdmgrd -foreground 2>&1 | tee /tmp/ivmgrd.log

Debug Notes1. When you have completed gathering server activity information,

be sure to restore the routing file to its normal condition.Remove the NOTICE entry. NOTICE generates a large amountof information which can rapidly accumulate.

2. You can use Ctrl + c to interrupt a server process started indebug mode. The server process will shutdown correctly andexit.


8.L

og

gin

gan

dA

ud

iting

Server

Activity

Policy Director Audit Trail FilesAuditing is defined as the collection of data about system activitiesthat affect the secure operation of the Policy Director authorizationprocess. Each Policy Director server can capture audit eventswhenever any security related auditable activity occurs.

Audit events are saved as audit records that document the specificactivity of that server. Each audited activity is referred to as an auditevent. A collection of audit event records stored in a file is referredto as an audit trail.

Each Policy Director server maintains its own audit trail file. ThePolicy Director servers include:




¶ User-developed applications using Authorization ADK (Refer tothe Tivoli SecureWay Policy Director Authorization ADKDeveloper Reference)

Parameters for configuring Policy Director server audit trail files arelocated in the [aznapi-configuration] stanza of each of the<server-name>.conf files.

Server server-name Configuration File

Management Server pdmgrd ivmgrd.conf

Authorization Server pdacld ivacld.conf

WebSEAL webseald webseald.conf

Enabling and Disabling AuditingAudit trail recording is enabled on a server-by-server basis by settingthe logaudit value in the [aznapi-configuration] stanza of theconfiguration file for the specific server.

By default auditing is disabled:

158 Version 3.8

[aznapi-configuration]logaudit = no

A value of “yes” will enable auditing for that server. For example:[aznapi-configuration]logaudit = yes

Specifying the Log File LocationBy default the audit trail file for each server is called audit.log andis held in the specific server’s log directory. The auditlog parameterin each server’s configuration file specifies the location of the audittrail file:

Server Log File Location


UNIX: auditlog=/var/PolicyDirector/audit/pdmgrd.logWindows: auditlog=C:\pd\audit\pdmgrd.log

Authorization Server(pdacld)

UNIX: auditlog=/var/PolicyDirector/audit/pdacld.logWindows: auditlog=C:\pd\audit\pdacld.log

Specifying Audit File Rollover ThresholdsThe logsize parameter specifies the maximum size to which each ofthe audit trail files may grow and has the following default value (inbytes):[aznapi-configuration]logsize = 2000000

When an audit trail file reaches the specified value—known as itsrollover threshold—the existing file is backed up to a file of thesame name with an appended current date and timestamp. A newaudit trail file is then started.

The various possible logsize values are interpreted as follows:

¶ If the logsize value is less than zero (< 0), then a new audit trailfile is created with each invocation of the auditing process andevery 24 hours from that instance.

¶ If the logsize value is equal to zero (= 0), then no rollovers areperformed and the audit trail file grows indefinitely. If an audittrail file already exists, new data is appended to it.


8.L

og

gin

gan

dA

ud

iting

Server

Activity

¶ If the logsize value is greater than zero (> 0), then a rollover isperformed when an audit trail file reaches the configuredthreshold value. If an audit trail file already exists at startup,new data is appended to it.

Specifying the Frequency for Flushing Audit FileBuffers

Audit trail files are written to buffered data streams. If you aremonitoring the audit trail files in real time, you may want to alterthe frequency with which the server forces a flush of the audit trailfile buffers.

By default, audit trail files are flushed every 20 seconds:[aznapi-configuration]logflush = 20

If you specify a negative value, a flush will be forced after everyrecord is written.

Specifying Audit EventsAudit events are categorized by the server functionality thatgenerates them. Some functionality is common across PolicyDirector servers while other functionality is server-specific. Eachtype of server functionality is associated with an audit tag:

Audit Tag Server Functionality

authn Credential acquisition authentication auditing

azn Authorization event auditing.

mgmt Management command auditing

http Webseal HTTP request auditing

You can configure each Policy Director server to selectively captureaudit events on a category by category basis. For example thefollowing configuration will capture only authentication events anddisable the capture all other events, including overriding anyauthorization auditing enabled in POP settings.[aznapi-configuration]auditcfg = authn

160 Version 3.8

The following settings enable WebSEAL HTTP request andauthorization auditing, but disable all other audit categories for theWebSEAL server:[aznapi-configuration]auditcfg = httpauditcfg = authn

By default, when auditing is enabled for a process with noconfigured audit tags, all auditable events will be captured.

The following table indicates the auditing events (indicated by theaudit tag) that can be captured for each specific Policy Directorserver.

Audit Tag webseald pdmgrd pdacld authadk

authn X X X X

azn X X X X

mgmt X

http X

Audit Trail File FormatAudit events are captured in the audit trail in a standard format usingXML-style tags. Although XML is only an intermediary step todelivering a presentation view of the data, the XML file is in ASCIIformat and can be read directly or passed to other external parsingengines for further analysis.

An entire audit trail does not represent a single XML document.Each audit event within the file is written as an isolated XML datablock. Each data block conforms to the rules of standard XMLsyntax.

As an audit administrator, you are expected to select and extractevents according to your own criteria. This may include reformattingeach event by applying an appropriate DTD (Document Type


8.L

og

gin

gan

dA

ud

iting

Server

Activity

definition) or schema for the analysis tool you are using. The DTDis an intermediate format that provides a description of the data thatcan be captured.

A suggested DTD is shown below.<!ELEMENT event (date, outcome, originator, accessor, target, data*)><!ATTLIST event

rev CDATA "1.1"link CDATA #IMPLIED >

<!ELEMENT date (#PCDATA)><!ELEMENT outcome (#PCDATA)><!ATTLIST outcome

status CDATA #IMPLIED><!ELEMENT originator (component, event, location)><!ATTLIST originator

blade CDATA #REQUIRED><!ELEMENT component rev CDATA “1.0”><!ELEMENT action (#PCDATA)><!ELEMENT location (#PCDATA)><!ELEMENT accessor (principal*)><!ATTLIST accessor

name CDATA #REQUIRED><!ELEMENT principal (#PCDATA)><!ATTLIST principal

auth CDATA #REQUIRED><!ELEMENT target (object, process?, azn?)><!ATTLIST target

resource CDATA #REQUIRED><!ELEMENT object (#PCDATA)><!ELEMENT process (pid, rid, eid, uid, gid)><!ATTLIST process

architecture (unix | nt) 'unix'><!ELEMENT pid #PCDATA><!ELEMENT rid #PCDATA><!ELEMENT eid #PCDATA><!ELEMENT uid #PCDATA><!ELEMENT gid #PCDATA><!ELEMENT azn (perm, result, qualifier)><!ELEMENT perm #PCDATA><!ELEMENT result #PCDATA><!ELEMENT qualifier #PCDATA><!ELEMENT data #PCDATA><!ATTLIST data

tag CDATA #REQUIRED>

162 Version 3.8

Because Policy Director auditing uses a standard record format, notall fields are relevant to every event recorded. Generally each eventcaptures the result of an action that a principal attempts on a targetobject.

Information about the action, the principal’s credentials, the targetobject, and the outcome are captured in a common format header ofthe audit record. Fields that are not relevant for a particular eventmay contain some default value. Additional event-specificinformation may also be recorded in a free format data area at theend of the record.

Decoding the meaning of certain data values in the records mayrequire an advanced knowledge of the Policy Director code andarchitecture.

Status Attribute of the Outcome FieldThe outcome field always includes a Policy Director status codeand an outcome value. The possible outcome values include:0 = SUCCESS1 = FAILURE2 = PENDING3 = UNKNOWN

You can use the pdadmin errtext command to provide interpretationfor the policy Director status code (412668954 in the followingexample).<outcome status=”412668954”>1</outcome>

Resource Attribute of the Target FieldThe resource attribute of the target field represents a broadcategorization of the target object:0 = AUTHORISATION1 = PROCESS2 = TCB3 = CREDENTIAL5 = GENERAL


8.L

og

gin

gan

dA

ud

iting

Server

Activity

Audit Trail File Contents

Authorization Audit RecordsAuthorization is the primary function of the Policy Director servers.Authorization audit records can be captured when a target object inthe Policy Director authorization policy database (protected objectspace) has a POP policy attached to it that enables auditfunctionality.

See “Using Protected Object Policies” on page 91.

You can configure auditing for a particular server by adding “azn” tothe audit configuration list in the [aznapi-configuration] stanza ofthe server’s configuration file:[aznapi-configuration]auditcfg = azn

The following record is a sample audit record for the followingevent:pdadmin> pop modify pop1 set audit-level all

<event rev="1.1"><date>2001-08-05-16:25:08.341+00:00I-----</date><outcome status="0">0</outcome><originator blade="pdmgrd"><component rev=”1.1”>mgmt</component><action>13702</action><location>phaedrus</location></originator><accessor name=""><principal auth="IV_LDAP_V3.0">sec_master</principal></accessor><target resource="5"><object></object></target><data>“13702”“pop1”“pop1”“false”“15”“0”“““0”“0”“0”“127”“1”

164 Version 3.8

“0”“0”“0”</data></event>

Authentication Audit RecordsAuthentication of a principal is performed externally to PolicyDirector during credential acquisition. Audit records can be capturedby Policy Director to record the success or failure of suchauthentication attempts.

You can configure auditing of authentication attempts by adding“authn” to the audit configuration list in the [aznapi-configuration]stanza of the server’s configuration file:[aznapi-configuration]auditcfg = authn

The following is a sample authentication event logged fromWebSEAL for an unauthenticated user.<event rev="1.1"><date>2001-08-05-23:04:26.630+00:00I-----</date><outcome status="0">0</outcome><originator blade="webseald"><component>authn</component><event rev="1">0</event><location>location not specified</location></originator><accessor name="unknown"><principal auth="invalid"></principal></accessor><target resource="5"><object></object></target><data></data></event>

WebSEAL Audit RecordsWeb server activity can be optionally recorded in the audit trail filein addition to, or in place of, the standard HHTP Common Logformat files described in the Tivoli SecureWay Policy DirectorWebSEAL Administration Guide.


8.L

og

gin

gan

dA

ud

iting

Server

Activity

You can configure auditing of WebSEAL activity by adding “http” tothe audit configuration list in the [aznapi-configuration] stanza ofthe WebSEAL server’s configuration file (webseald.conf):[aznapi-configuration]auditcfg = http

The following is a sample HTTP access audit record:<event rev="1.1"><date>2001-08-05-23:04:26.931+00:00I-----</date><outcome status="412668954">1</outcome><originator blade="webseald"><component>http</component><event rev="1">2</event><location>146.84.251.70</location></originator><accessor name="user not specified"><principal auth="IV_DCE_V3.0">cell_admin</principal></accessor><target resource="5"><object>/pics/pd30.gif</object></target><data></data></event>

Management Audit RecordsThe responsibilities of the Management Server include maintainingthe master authorization policy database. This database includes thedescription of the protected object space for the secure domain, ACLand POP policies, and where ACLs and POPs are attached toobjects.

You can configure auditing of the Management Server activity byadding “mgmt” to the audit configuration list in the[aznapi-configuration] stanza of the Management Server’sconfiguration file (ivmgrd.conf):[aznapi-configuration]auditcfg = mgmt

The following is a sample event record of the following pdadmincommand:pdadmin> pop modify pop1 set audit-level all<event rev="1.1"><date>2001-08-05-23:01:37.078+00:00I-----</date><outcome status="0">0</outcome><originator blade="ivmgrd"><component>mgmt</component>

166 Version 3.8

<event rev="1">3702</event><location>location not specified</location></originator><accessor name="user not specified"><principal auth="IV_DCE_V3.0">cell_admin</principal></accessor><target resource="5"><object></object></target><data>"2019""1002""pop1""0"""</data></event>

Event Field ID Codes for Management CommandsThe audit records for management commands contains an event IDcode that identifies one of the Policy Director management(pdadmin) commands. Command arguments are listed in the datasection of the event record in their internal format.

Note that commands which do not result in an effective change ofstate of the database (such as list and show) are never captured.

ACL Management Commands

ACL_LIST 13000

ACL_GET 13001

ACL_SET 13002

ACL_DELETE 13003

ACL_FIND 13005

ACTION_LIST 13006

ACTION_SET 13007

ACTION_DELETE 13008

ACTION_GROUPLIST 13009

ACTION_GROUPCREATE 13010

ACTION_GROUPDELETE 13011

ACTION_LISTGROUP 13012

ACTION_CREATEGROUP 13013


8.L

og

gin

gan

dA

ud

iting

Server

Activity

ACTION_DELETEGROUP 13014

Object Management Commands

OBJSPC_CREATE 13103

OBJSPC_DELETE 13104

OBJSPC_LIST 13105

OBJ_CREATE 13106

OBJ_DELETE 13107

OBJ_MOD_SET_NAME 13110

OBJ_MOD_SET_DESC 13111

OBJ_MOD_SET_TYPE 13112

OBJ_MOD_SET_ISLF 13113

OBJ_MOD_SET_ISPOL 13114

OBJ_MOD_SET_ATTR 13115

OBJ_MOD_DEL_ATTR 13116

OBJ_MOD_DEL_ATTRVAL 13117

OBJ_SHOW_ATTR 13118

OBJ_LIST_ATTR 13119

ACL_ATTACH 13120

ACL_DETACH 13121

ACL_MOD_SET_ATTR 13123

ACL_MOD_DEL_ATTR 13124

ACL_MOD_DEL_ATTRVAL 13125

ACL_SHOW_ATTR 13126

ACL_LIST_ATTR 13127

POP_MOD_SET_ATTR 13128

POP_MOD_DEL_ATTR 13129

POP_MOD_DEL_ATTRVAL 13130

POP_SHOW_ATTR 13131

POP_LIST_ATTR 13132

OBJ_SHOW_ATTRS 13133

ACL_SHOW_ATTRS 13134

POP_SHOW_ATTRS 13135

168 Version 3.8

OBJ_SHOW 13136

OBJ_LIST 13137

OBJ_LISTANDSHOW 13138

Server Management Commands

SERVER_GET 13200

SERVER_LIST 13203

SERVER_PERFORMTASK 13204

SERVER_GETTASKLIST 13205

SERVER_REPLICATE 13206

Admin, User, and Group Management Commands

ADMIN_SHOWCONF 13400

USER_CREATE 13401

USER_IMPORT 13402

USER_MODDESC 13403

USER_MODPWD 13404

USER_MODAUTHMECH 13405

USER_MODACCVALID 13406

USER_MODPWDVALID 13407

USER_DELETE 13408

USER_SHOWGROUPS 13409

USER_SHOW 13410

USER_SHOWDN 13411

USER_LIST 13412

USER_LISTDN 13413

GROUP_CREATE 13414

GROUP_IMPORT 13415

GROUP_MODDESC 13416

GROUP_MODADD 13417

GROUP_MODREMOVE 13418

GROUP_DELETE 13419

GROUP_SHOW 13420

GROUP_SHOWDN 13421


8.L

og

gin

gan

dA

ud

iting

Server

Activity

GROUP_LIST 13422

GROUP_LISTDN 13423

GROUP_SHOWMEMB 13424

USER_MODGSOUSER 13425

USER_SET 13426

GROUP_SET 13427

13500 -> 13599 are used by GSO

GSO_RESOURCE_CREATE 13500

GSO_RESOURCE_DELETE 13501

GSO_RESOURCE_LIST 13502

GSO_RESOURCE_SHOW 13503

GSO Resource Credential Commands

GSO_RESOURCE_CRED_CREATE 13504

GSO_RESOURCE_CRED_DELETE 13505

GSO_RESOURCE_CRED_MODIFY 13506

GSO_RESOURCE_CRED_LIST 13507

GSO_RESOURCE_CRED_SHOW 13508

GSO Resource Group Commands

GSO_RESOURCE_GROUP_CREATE 13509

GSO_RESOURCE_GROUP_DELETE 13510

GSO_RESOURCE_GROUP_ADD 13511

GSO_RESOURCE_GROUP_REMOVE 13512

GSO_RESOURCE_GROUP_LIST 13513

GSO_RESOURCE_GROUP_SHOW 13514

Policy Commands

POLICY_SET_MAX_LOGIN_FAILURES 13600

POLICY_GET_MAX_LOGIN_FAILURES 13601

POLICY_SET_DISABLE_TIME_INTERVAL 13602

POLICY_GET_DISABLE_TIME_INTERVAL 13603

POLICY_SET_MAX_ACCOUNT_AGE 13604

POLICY_GET_MAX_ACCOUNT_AGE 13605

POLICY_SET_ACCOUNT_EXPIRY_DATE 13606

170 Version 3.8

POLICY_GET_ACCOUNT_EXPIRY_DATE 13607

POLICY_SET_MAX_INACTIVITY_TIME 13608

POLICY_GET_MAX_INACTIVITY_TIME 13609

POLICY_GET_ACCOUNT_CREATION_DATE 13610

POLICY_GET_LAST_LOGIN_ATTEMPT_DATE 13611

POLICY_SET_MAX_PASSWORD_AGE 13612

POLICY_GET_MAX_PASSWORD_AGE 13613

POLICY_SET_MIN_PASSWORD_AGE 13614

POLICY_GET_MIN_PASSWORD_AGE 13615

POLICY_SET_MAX_PASSWORD_REPEATED_CHARS 13616

POLICY_GET_MAX_PASSWORD_REPEATED_CHARS 13617

POLICY_SET_MIN_PASSWORD_ALPHAS 13618

POLICY_GET_MIN_PASSWORD_ALPHAS 13619

POLICY_SET_MIN_PASSWORD_NON_ALPHAS 13620

POLICY_GET_MIN_PASSWORD_NON_ALPHAS 13621

POLICY_SET_MIN_PASSWORD_DIFFERENT_CHARS 13622

POLICY_GET_MIN_PASSWORD_DIFFERENT_CHARS 13623

POLICY_SET_PASSWORD_SPACES 13624

POLICY_GET_PASSWORD_SPACES 13625

POLICY_SET_MIN_PASSWORD_LENGTH 13626

POLICY_GET_MIN_PASSWORD_LENGTH 13627

POLICY_SET_MIN_PASSWORD_REUSE_TIME 13628

POLICY_GET_MIN_PASSWORD_REUSE_TIME 13629

POLICY_GET_PASSWORD_FAILURES 13630

POLICY_GET_LAST_PASSWORD_CHANGE_DATE 13631

POLICY_SET_NUMBER_WARN_DAYS 13632

POLICY_GET_NUMBER_WARN_DAYS 13633

POLICY_SET_PASSWORD_REUSE_NUM 13634

POLICY_GET_PASSWORD_REUSE_NUM 13635

POLICY_SET_TOD_ACCESS 13636

POLICY_GET_TOD_ACCESS 13637

POP Commands


8.L

og

gin

gan

dA

ud

iting

Server

Activity

POP_CREATE 13700

POP_DELETE 13701

POP_MODIFY 13702

POP_SHOW 13703

POP_LIST 13704

POP_ATTACH 13705

POP_DETACH 13706

POP_FIND 13707

Configuration Commands 13800 -> 13899

CFG_CONFIG 13800

CFG_UNCONFIG 13801

CFG_REBNEWCERT 13802

CFG_CHGPORT 13803

172 Version 3.8

pdadmin Command Reference

The pdadmin utility is a command-line tool that you can use toperform most Policy Director administration tasks. The Web PortalManager provides many of these same commands through itsgraphical user interface.

Topic Index:

¶ “Introducing the pdadmin Utility” on page 174

¶ “ACL Commands” on page 176

¶ “Action Commands” on page 180

¶ “Object Commands” on page 182

¶ “Protected Object Policy (POP) Commands” on page 186

¶ “Server Commands” on page 189

¶ “Administration Information Command” on page 190

¶ “User Management Commands” on page 191

¶ “Group Management Commands” on page 198

¶ “Resource Management Commands” on page 202

¶ “Policy Management Commands” on page 209

A


A.

pd

adm

inC

om

man

dR

eference

Introducing the pdadmin UtilityThe pdadmin utility is a command-line tool that you can use toperform most Policy Director administration tasks. TheWeb PortalManager duplicates many pdadmin commands. However, pdadminprovides several advanced management functions that are notavailable through the Web Portal Manager.

You can automate certain management functions by writing scriptsthat use pdadmin. The communication between the pdadmin utilityand the Management Server (pdmgrd) is secured over SSL. Theutility is installed as part of the PDRTE package.

Starting the pdadmin Utility (login command)¶ Interactive Mode

¶ Single Command Line Mode

¶ Multiple Command Execution

Interactive ModeTo start pdadmin in interactive mode, you must enter the pdadmincommand followed by a login command with username(administrator) and password options and arguments. The admin-usermust be a registered user in an LDAP registry.

UNIX:# pdadmin# login –a <admin-user> –p <password>pdadmin>

Windows:MSDOS> pdadminMSDOS> login –a <admin-user> –p <password>pdadmin>

At the pdadmin prompt, enter appropriate commands, options, andarguments. Refer to the command reference tables in this appendix.

174 Version 3.8

Single Command Line ModeYou can execute a single pdadmin command from the operatinsystem command prompt:

UNIX:# pdadmin [–a <admin-user>] [–p <password>] [command]

Windows:MSDOS> pdadmin [–a <admin-user>] [–p <password>] [command]

¶ If you specify the admin-user (–a) and password (–p), you willbe logged in as that user.

¶ If you do not specify the admin-user (–a), you will be logged inas an unauthenticated user.

¶ If you specify the admin-user (–a), but do not specify apassword (–p), you will be prompted for a password.

The optional command argument allows you to run one-timecommands. For example, the user “test” will be created if you typefollowing command.pdadmin –a sec_master –p pwd user create testcn=test,ou=austin,o=ibm,c=us test test test1234

Multiple Command ExecutionYou can create a special file that contains multiple pdadmincommands that together perform a complete task or series of tasks.The pdadmin utility accepts a filename argument that identifies thelocation of such a file.

UNIX:# pdadmin [–a <admin-user>] [–p <password>] <file-pathname>

Windows:MSDOS> pdadmin [–a <admin-user>] [–p <password>] <file-pathname>

Help InformationFor a list of available commands by category, enter:pdadmin> help <category>


A.

pd

adm

inC

om

man

dR

eference

Command categories include: acl, action, object, server, rsrc,rsrccred, rsrcgroup, admin, login, user, group, policy, pop, errtext.

For information on specific command syntax, enter:pdadmin> help <command>

Exiting the pdadmin UtilityTo exit pdadmin and return to the command prompt, enter the exitor quit command. For example:pdadmin> exit

Special Characters Disallowed for GSO CommandsYou cannot use the following characters to create a GSO user name,GSO resource name, or GSO resource group name:!”#&()*+,;:<>=@\|

Although it is possible to use most of these characters for otherLDAP-related Policy Director data (such as the CN, DN, and SN ofa user), these characters have special meaning in LDAP DN syntaxand filters. Before using any of these characters in Policy Directoruser and group names, consult the documentation for your LDAPserver to determine the effect of special characters in LDAP.

Limitations When Naming GSO ResourcesUse double quotation marks around any resource or resourcecredential name that contains a blank space.

ACL CommandsThe following pdadmin acl commands allow you to create ACLpolicies and extended attributes.

¶ Managing ACL Policy

¶ Managing Extended Attributes for ACLs

Managing ACL Policy

Command Description

acl attach <object-name> <acl-name>

176 Version 3.8

Command Description

Attaches an ACL policy to an object. Replaces whateverACL is already associated with the object.

acl create <acl-name>

Creates a new ACL policy in the ACL database. Notethat this command does not create the specific ACLentries.

acl delete <acl-name>

Deletes an ACL policy from the ACL database.

acl detach <object-name>

Detaches the current ACL policy from the indicatedobject. Note that this command does not delete the ACLpolicy from the ACL database.

acl find <acl-name>

Finds and lists all objects that have the indicated ACLpolicy attached.

acl list

Lists all ACL policies in the ACL database.

acl modify <acl-name> description <description>

Equivalent to the acl modify set description command.

acl modify <acl-name> remove any-other

Allows you to remove the any-other ACL entry fromthe indicated ACL policy definition.

acl modify <acl-name> remove group <group-name>

Allows you to remove an existing group ACL entryfrom the indicated ACL policy definition.

acl modify <acl-name> remove unauthenticated

Allows you to remove the unauthenticated ACL entryfrom the indicated ACL policy definition.

acl modify <acl-name> remove user <username>

Allows you to remove an existing user ACL entry fromthe indicated ACL policy definition.

acl modify <acl-name> set any-other <perms>


A.

pd

adm

inC

om

man

dR

eference

Command Description

Allows you to create and/or edit the any-other ACLentry in the indicated ACL policy definition. Example:

pdadmin> acl modify pubs set any-other r

acl modify <acl-name> set description <description>

Allows you to create and/or edit the description fieldassociated with the indicated ACL policy.

acl modify <acl-name> set group <group-name> <perms>

Allows you to create and/or edit a group ACL entry inthe indicated ACL policy definition. Example:

pdadmin> acl modify pubs set group sales Tr

acl modify <acl-name> set unauthenticated <perms>

Allows you to create and/or edit the unauthenticatedACL entry in the indicated ACL policy definition.Example:

pdadmin> acl modify docs set unauthenticated r

acl modify <acl-name> set user <username> <perms>

Allows you to create and/or edit a user ACL entry inthe indicated ACL policy definition. Example:

pdadmin> acl modify pubs set user peter Tr

acl show <acl-name>

Lists the complete set of entries that make up thedefinition of the indicated ACL policy.

178 Version 3.8

Managing Extended Attributes for ACLs

Command Description

acl list <acl-name> attribute

Lists all extended attributes associated with the ACLpolicy.

acl modify <acl-name> delete attribute <attr-name>

Removes the extended attribute and all its values fromthe ACL policy.

acl modify <acl-name> delete attribute <attr-name> <attr-value>

Removes the specified value from the extended attributeassociated with the ACL policy.

acl modify <acl-name> set attribute <attr-name> <attr-value>

Adds an extended attribute and its value to an existingACL. Use this same command to add additional valuesto the same extended attribute.

acl show <acl-name> attribute <attr-name>

Displays the values of the specified extended attributeassociated with the ACL policy.


A.

pd

adm

inC

om

man

dR

eference

Action CommandsThe following pdadmin action commands are used to defineadditional authorization actions (ACL permissions) and actiongroups.

¶ Creating Custom ACL Actions

¶ Creating Extended ACL Actions and Action Groups

Creating Custom ACL Actions

Command Description

action create <action-name> <action-label> <action-type>

Defines a new Policy Director authorization action(permission). Creates a new permission characterrepresenting this action on the Management Console.The action-name argument designates the newsingle-character permission. The action-labelargument provides the label for the new checkboxthat will appear in the Management Console. Theaction-type argument designates an organizationalcategory (type) where this permission appears in theManagement Console display (ACLs tab). Example:

pdadmin> action create k time Ext-Authzn

action delete <action-name>

Deletes an existing authorization action (permission)created by the action create command. Example:

pdadmin> action delete k

action list

Lists all existing ACL actions (permissions)in thefollowing format:action-name action-labelaction-typeExample:

r read WebSEAL...

180 Version 3.8

Creating Extended ACL Actions and Action Groups

Command Description

action create <action-name> <action-label> <action-type><action-group-name>

Create a new ACL action definition for the specifiedaction group.

action delete <action-name> <action-group-name>

Delet an ACL action definition from the specifiedaction group.

action group list

List all Acl action group names.

action group create <action-group-name>

Create a new ACL action group.

action group delete <action-group-name>

Delete an ACL action group.

action list <action-group-name>

List all ACL action definitions for the specified actiongroup.


A.

pd

adm

inC

om

man

dR

eference

Object CommandsThe pdadmin objectand objectspace commands allow the creationof additional object spaces containing protected objects used bythird-party applications.

¶ Managing a Custom Objectspace

¶ Managing Protected Objects

¶ Managing Extended Attributes for Protected Objects

Managing a Custom Objectspace

Command Description

objectspace create <objectspace-name> <description> <type>

Creates a new protected object space under whichprotected objects can be placed.

objectspace delete <objectspace-name>

Deletes an existing protected object space and allassociated protected objects.

objectspace list

Lists all protected object spaces.

Managing Protected Objects

Command Description

object create <obj-name> <description> <type> ispolicyattachable{yes|no}

182 Version 3.8

Command Description

Creates a new protected object. The obj-name argumentis the name for the object being created. This namemust be unique. The description argument is any textstring describing the object. This information appears inthe object show command. The type argumentidentifies the specific graphical icon associated with thisobject and displayed by the Management Console.Types range from 0-13. For example, types 10 or 13 areappropriate for container objects. Theispolicyattachable argument determines whether youcan attach an ACL policy to this object. For example,see “Creating Group Container Objects” on page 107.

object delete <obj-name>

Deletes a protected object.

object list <obj-name>

new- Lists any child objects grouped under the specifiedprotected object. old - Lists the objects grouped underthe indicated directory and displays the name of anyACL associated with each object. Note that thiscommand does not expand the tree beyond thisdirectory.

object listandshow <obj-name>

Lists any child objects grouped under the specifiedprotected object and displays all values associated witheach of those objects.

object modify <obj-name> set name <new-obj-name>

Renames the protected object or protected object space.

object modify <obj-name> set description <description>

Changes the description of the protected object orprotected object space.

object modify <obj-name> set type <type>

Changes the type of the protected object or protectedobject space.

object modify <obj-name> set ispolicyattachable {yes|no}

Changes whether the protected object is allowed to havea protected object policy (POP) attached.


A.

pd

adm

inC

om

man

dR

eference

Command Description

object show <obj-name>

new- Shows all values associated with a protectedobject. old - Displays the object name and the name ofany ACL associated with it. If there is no associatedACL, the phrase “No ACL” appears.

184 Version 3.8

Managing Extended Attributes for Protected Objects

Command Description

object list <obj-name> attribute

Lists all the extended attributes associated with theprotected object.

object modify <obj-name> delete attribute <attr-name>

Removes the specified extended attribute and all itsvalues from the specified protected object.

object modify <obj-name> delete attribute <attr-name> <attr-value>

Removes the specified value from the extended attributeassociated with the specified protected object.

object modify <obj-name> set attribute <attr-name> <attr-value>

Adds the extended attribute and its value to a protectedobject.

object show <obj-name> attribute <attr-name>

Displays the values of the specified extended attributeassociated with the protected object.


A.

pd

adm

inC

om

man

dR

eference

Protected Object Policy (POP) CommandsThe pdadmin pop commands allow the creation of protected objectpolicies and extended attributes for protected object policies.

¶ Managing Protected Object Policies

¶ Managing Extended Attributes for Protected Object Policies

Managing Protected Object Policies

Command Description

pop attach <object-name> <pop-name>

Attach a protected object policy to a protected object.

pop create <pop-name>

Create a proptected object policy.

pop delete <pop-name>

Delete a protected object policy.

pop detach <object-name>

Detach a protected object policy from the protectedobject.

pop find <pop-name>

Find and list all protected objects that have protectedobject policies attached.

pop list

List all protected object policies that have been created.

pop modify <pop-name> set audit-level {all|none|<audit-level-list>}

Modify the protected object policy audit level. Theaudit-level-list can be a comma seperated list selectedfrom the following: permit, deny, error, admin.

pop modify <pop-name> set description <description>

Modify the protected object policy description.

pop modify <pop-name> set ipauth add <network> <netmask><auth_level>

Modify the protected object policy IP-authenticationaccess.

pop modify <pop-name> set ipauth anyothernw <auth_level>

186 Version 3.8

Command Description


pop modify <pop-name> set ipauth remove <network> <netmask>


pop modify <pop-name> set qop {none|integrity|privacy}

Modify the protected object policy quality of protectionlevel.

pop modify <pop-name> set tod-access <time-of-day-string>

Modify the protected object policy time of day access.The time-of-day-string argument has the followingformat: <{anyday|weekday|<day-list>}>:<{anytime|<time-spec>-<time-spec>}> [:{utc|local}] Theday-list variable can be mon, tue, wed, thu, fri, sat, orsun. The time-spec range variable must be expressed as:hhmm For example: 0700-1945 The optional time zoneis local by default.

pop modify <pop-name> set warning {on|off}

Modify the protected object policy warning indicator.

pop show <pop-name>

Show details of the protected object policy.


A.

pd

adm

inC

om

man

dR

eference

Managing Extended Attributes for Protected ObjectPolicies

Command Description

pop list <pop-name> attribute

Lists all extended attributes associated with a POP.

pop modify <pop-name> delete attribute <attr-name>

Removes the specified extended attribute and all itsvalues from the specified POP.

pop modify <pop-name> delete attribute <attr-name> <attr-value>

Removes the specified value from the extended attributeassociated with the specified POP.

pop modify <pop-name> set attribute <attr-name> <attr-value>

Adds the extended attribute and its value to a POP.

pop show <pop-name> attribute <attr-name>

Show details of specific POP attribute.

188 Version 3.8

Server CommandsThe following pdadmin server commands are appropriate forperforming management tasks on the Policy Director servers.

The server-name argument is expressed as the actual machine nameand the Policy Director component used by this command. ThePolicy Director component can be a Base server (such as pdmgrd orpdacld), a Policy Director resource manager (such as webseald), oran external application server::<policy-director-component>-<machine-name>

For example, if the machine name is cruz and the Policy Directorcomponent is WebSEAL, the server-name is:webseald-cruz

Command Description

server list

Lists all registered servers. Use the server name formatdisplayed by this command for any <server-name>arguments.

server listtasks <server-name>

Retrieves the list of tasks (commands) available forthis server.

server replicate [–server <server-name>]

server show <server-name>

Displays the specified server’s properties.

server task <server-name> <command>

Sends the specified command to the specified server.

Technical NotesNote that the server-name argument must be entered in the exactformat as displayed in the output of the pdadmin server listcommand.


A.

pd

adm

inC

om

man

dR

eference

The server-name argument is the full expression of the actualmachine name and the Policy Director component used by thiscommand (such as WebSEAL).<policy-director-component>-<machine-name>

For example, if the machine name is cruz and the Policy Directorcomponent is WebSEAL, the server-name is:webseald-cruz

Use the server list command to verify server-name expressions:pdadmin> server listwebseald-cruz

To display the properties of the WebSEAL server on the machinecruz, enter:pdadmin> server show webseald-cruzwebseald-cruz

Description: webseald/cruzHostname: cruzPrincipal: webseald/cruzPort: 7234Listening for authorization database update notifications: yesAZN Administration Services:

webseal-admin-svcazn_admin_svc_trace

Administration Information CommandThe following administration command displays information aboutthe server.

Command Description

admin show configuration

190 Version 3.8

Command Description

Displays current server configuration information, suchas:

¶ whether the user registry is contained in LDAP

¶ whether GSO is enabled or not

Example:

pdadmin> admin show configuration

would produce output similar to:

LDAP: TRUESECAUTHORITY: DefaultGSO: TRUE

User Management CommandsThe following pdadmin user commands controls user entries in theLDAP registry.

A user is a registered participant of the Policy Director securedomain. A GSO user is a Policy Director user that additionally hasthe authority to work with Web resources, such as a Web server.

Command Description

user create [–gsouser] [–no-password-policy] <username> <dn> <cn><sn> <password> [group-name]


A.

pd

adm

inC

om

man

dR

eference

Command Description

Creates a new Policy Director user (secUser) account inthe LDAP user registry. The distinguished name (DN)must be known before you can create a new useraccount.

When the optional -gsouser argument is specified, theuser is also made a GSO user (gsoUser).

The username argument is the name for the user beingcreated. This name must be unique.

The dn argument is the LDAP distinguished nameassigned to the user being created. Example:

“cn=Diana Lucas,ou=Austin,o=Wesley Inc,c=US”

The DN must be unique.

The cn argument is the common name assigned to theuser being created. Example:

Diana Lucas

The sn argument is the surname of the user beingcreated. Example:

Lucas

The password argument is the password you set for thisnew user. Passwords must adhere to the passwordpolicies set by the Policy Director administrator:Example:

mypasswd

The optional group-name argument assigns the user toan initial group. continued...

192 Version 3.8

Command Description

Example (entered as one line):

pdadmin> user create –gsouser dlucas “cn=DianaLucas,ou=Austin,o=Wesley Inc,c=US” “DianaLucas” Lucas mypasswd

To make the user account valid, you must manuallyactivate this user by modifying the user information. Tochange the information, you must set the account-validflag to “yes”. To add a description about a user, youmust use the modify user command to change the useraccount information.

user import [–gsouser] <username> <dn> [group-name]

Copies the information about a user from the LDAPdirectory. This command enables an existing user(whose DN already exists in the LDAP database) to beupdated with Policy Director information so that theuser can participate in the secure domain. The optionalgroup-name argument assigns the user to an initialgroup. Example (entered as one line):

pdadmin> user import –gsouser mlucaser “cn=MikeLucaser,ou=Austin,o=Wesley Inc,c=US”

user modify <username> description <description>

Adds a description that provides information that makesit easier for the administrator to identify this user.Example (entered as one line):

pdadmin> user modify dlucas description “DianaLucas, Credit Dept HCUS”

user modify <username> password <password>

Changes the password of the user from the currentpassword to a new password. There is no passwordconfirmation step for this operation. Example:

pdadmin> user modify dlucas password newpasswd

user modify <username> authentication-mechanism <mechanism>


A.

pd

adm

inC

om

man

dR

eference

Command Description

Changes the mechanism used for authentication. If noDN is specified, the first occurrence of the username isthe user account that is changed. Example (entered asone line):

pdadmin> user modify dlucasauthentication-mechanism Default:LDAP

user modify <username> account-valid {yes|no}

Specifies whether an account is active or inactive. Toactivate the account, select “yes”; to deactivate theaccount, select “no”. Example:

pdadmin> user modify dlucas account-valid yes

user modify <username> password-valid {yes|no}

Specifies whether a password is active or inactive.Setting this value to “no” forces the user to change thepassword at the next login attempt. Example:

pdadmin> user modify dlucas password-valid no

user modify <username> gsouser {yes|no}

Specifies whether the Policy Director user specified isalso a GSO user. To add the user as a GSO user, select“yes”; to remove the user as a GSO user, select “no”.Example:

pdadmin> user modify dlucas gsouser no

user delete <username>

Deletes an existing user account from the LDAP userregistry. Deleting a Policy Director user account deletesthe GSO user account information from the LDAPregistry also. Example:

pdadmin> user delete dlucas

Any resource credentials associated with a user accountare automatically removed at the same time the useraccount is deleted.

user show <username>

194 Version 3.8

Command Description

Displays the user account information for the userspecified. Example:

pdadmin> user show dlucas

Would produce information similar to:

Login ID: dlucasLDAP dn: cn=Diana Lucas,ou=Austin,o=Wesley Inc,c=USLDAP cn: Diana LucasLDAP sn: LucasDescription: Diana Lucas, Credit Dept HCUSIS SecUser: trueIS GSO user: falseAccount valid: truePassword valid: trueAuthentication mechanism: Default:LDAP

user show-dn <dn>

Provides additional information about the user whenyou specify the distinguished name (DN).


pdadmin> user show-dn “cn=DianaLucas,ou=Austin,o=Wesley Inc,c=US”

Would produce a list similar to:

Login ID: dlucasLDAP dn: cn=Diana Lucas,ou=Austin,o=WesleyInc,c=USLDAP cn: Diana LucasLDAP sn: LucasDescription: Diana Lucas, Credit Dept HCUSIS SecUser: trueIS GSO user: falseAccount valid: truePassword valid: trueAuthentication mechanism: Default:LDAP

user show-groups <username>


A.

pd

adm

inC

om

man

dR

eference

Command Description

Displays the groups of which the specified user is amember. Example:

pdadmin> user show-groups dlucas


salescreditengineering

user list <pattern> <max-return>

Generates a list of all configured user accounts, listedby user names, for the pattern you specify. The listdisplays in the order the user accounts were created.The pattern argument allows you to specify a patternfor the principal name. The pattern can include amixture of wildcards and string constants, and is casesensitive (for example, *luca*). The max-returnargument limits how many entries are found andreturned for a single request (for example, 2). Note thatthe number returned is also governed by the LDAPserver configuration (which specifies the maximumnumber of rersults that can be returned as part of asearch operation). The actual maximum returned entriesis the minimum of <max-return> and the configuredvalue in the LDAP server. Example:

pdadmin> user list *luca* 2


dlucasmlucaser

user list-dn <pattern> <max-return>

196 Version 3.8

Command Description

If only a portion of the distinguished name is known,generates a list of all configured user accounts, listed bydistinguished names. The list displays in the order theuser names were created. See user list command abovefor details on the command arguments. The patternargument allows you to specify a pattern for thecommon name (CN) portion of the user’s distinguishedname (excluding the “cn=” component). Example:

pdadmin> user list-dn *luca* 2


cn=Diana Lucas,ou=Austin,o=Wesley, Inc,c=UScn=Mike Lucaser,ou=Austin,o=Wesley, Inc,c=US

user list-gsouser <pattern> <max-return>

Generates a list of only the GSO users, listed bydistinguished names. The list displays in the order theGSO users were created. See user list command abovefor details on the command arguments. Example:

pdadmin> user list-gsouser *luca* 2


cn=Diana Lucas,ou=Austin,o=Wesley, Inc,c=UScn=Mike Lucaser,ou=Austin,o=Wesley, Inc,c=US


A.

pd

adm

inC

om

man

dR

eference

Group Management CommandsThe following pdadmin group commands control group entries inthe LDAP directory registry.

A group is a set of Policy Director user accounts that have similarattributes. Groups allow you to use a group name in an accesscontrol list (ACL) instead of listing all users individually.

Command Description

group create <groupname> <dn> <cn> [group-container-object]

Creates a new Policy Director group (ISSecGroup) inthe LDAP user registry. The groupname argument isthe name for the group being created. This name mustbe unique. The dn argument is the LDAP distinguishedname assigned to the access group being created.Example:

“cn=credit,ou=Austin,o=Wesley Inc,c=US”)

The cn argument is the common name assigned to thegroup. Example:

Credit

The optional group-container-object argument assignsthe group to the specified group container object. If youdo not use this argument, the group by default is placedin the object space under /Management/Groups.Example (entered as one line):

pdadmin> group create credit“cn=credit,ou=Austin,o=Wesley Inc,c=US” Credit

group import <groupname> <dn> [group-container-object]

198 Version 3.8

Command Description

Imports the information about an existing LDAPregistry group to create a Policy Director group. Thegroup must already exist in the LDAP registry beforeyou can import the information and create a PolicyDirector group. The name of the group being createdmust be unique in the object space. If no groupcontainer object is specified, the group is placed under/Management/Groups. Example (entered as one line):

pdadmin> group import engineering“cn=engineering,ou=Austin,o=Wesley Inc,c=US”

group modify <groupname> description <description>

Adds a description for the specified group that makes itmore easily identifiable by the IntraVers administrator.Example (entered as one line):

pdadmin> group modify credit description"Credit, Dept HCUS"

group modify <groupname> add <username>

Adds a new user to the specified group. Example:

pdadmin> group modify engineering add dlucas

group modify <groupname> remove <username>

Deletes an existing user from the specified group.Example:

pdadmin> group modify engineering remove dlucas

group delete <groupname>

Deletes an existing group and any entries associatedwith the group. Example:

pdadmin> group delete engineering

group show <groupname>


A.

pd

adm

inC

om

man

dR

eference

Command Description

Displays the details about a specified group. Example:

pdadmin> group show credit

Would display information similar to:

Group ID: creditLDAP dn: cn=credit,ou=Austin,o=Wesley Inc,c=USDescription: Credit, Dept HCUSLDAP cn: creditIs SecGroup: true

group show-dn <dn>

Provides the group name for the distinguished namespecified. Example (entered as one line):

pdadmin> group show-dncn=credit,ou=Austin,o=Wesley Inc,c=US

Would show information similar to the following:

Group ID: creditLDAP dn: cn=credit,ou=Austin,o=Wesley Inc,c=USDescription: Credit, Dept HCUSLDAP cn: creditIs SecGroup: true

group show-members <groupname>

Displays the members of the group specified, listed bydistinguished names. Example:

pdadmin> group show-members credit


dlucasmlucaser

group list <pattern> <max-return>

200 Version 3.8

Command Description

Generates a list of all configured groups whose namesmatch the specified pattern, listed by group names. Thepattern argument allows you to specify a pattern for thegroup name. The pattern can include a mixture ofwildcards and string constants, and is case sensitive (forexample, *austin*). The max-return argument limitshow many entries are found and returned for a singlerequest (for example, 2). Note that the number returnedis also governed by the LDAP server configuration(which specifies the maximum number of rersults thatcan be returned as part of a search operation). Theactual maximum returned entries is the minimum of<max-return> and the configured value in the LDAPserver. Example:

pdadmin> group list *a* 2

Would produce the following group information:

salesmarketing

group list-dn <pattern> <max-return>

If a portion of the distinguished name is known,generates a list of all configured groups, listed bydistinguished names for the pattern specified. See grouplist command above for details on the commandarguments. The pattern argument allows you to specifya pattern for the common name (CN) portion of thegroup’s distinguished name (excluding the “cn=”component). Example:

pdadmin> group list-dn *t* 2


cn=credit,ou=Austin,o=Wesley Inc,c=US salescn=marketing,ou=Boston,o=Austin Sale,c=US marketing


A.

pd

adm

inC

om

man

dR

eference

Resource Management CommandsThe following pdadmin commands control resource-relatedinformation.

Resource-related information includes:

¶ Managing Resources

¶ Managing Resource Groups

¶ Managing Resource Credentials

Managing ResourcesThe following pdadmin rsrc commands allow you to managedifferent resources, such as Web servers for GSO users.

A resource is a Web server. The –T identifier in a WebSEALjunction definition identifies the Web server.

A pdadmin rsrc command identifies the name of the Web resource.

Command Description

rsrc create <resource-name> [–desc <description>]

Creates and names a Web server as a resource. Theresource-name argument is the name given to the Webresource to identify it. Example:

engwebs01

The description argument is an optional description thatcan be added to more easily identify this resource to theadministrator. Any optional parameter must be precededwith a dash ( – ). Descriptions containing a space mustbe enclosed in double quotes marks (“). Example(entered as one line):

pdadmin> rsrc create engwebs01 –desc“Engineering Web server – Room 4807”

rsrc delete <resource-name>

202 Version 3.8

Command Description

Deletes the named resource, including the descriptioninformation. The resource must exist or an error isdisplayed. Example:

pdadmin> rsrc delete engwebs01

rsrc list

Displays the names of all Web resources defined in theLDAP directory, listed by resource name. Example:

pdadmin> rsrc list

Provides information similar to:

engwebs01engwebs02engwebs03

rsrc show <resource-name>

Displays the Web resource information for the resourcenamed. The resource must exist or an error messagedisplays. Example:

pdadmin> rsrc show engwebs01


Web Resource Name: engwebs01Description: Engineering Web server - Room 4807

Managing Resource GroupsThe following pdadmin rsrcgroup commands allow you to managedifferent resource group-related attributes.

A resource group refers to a group of Web servers, where all theservers in the group have the same sets of user IDs (userids) andpassword. You can create a single resource credential for all theresources in the resource group. Policy Director uses a singleresource credential for a resource group instead of a resourcecredential for each resource in the resource group.

Command Description

rsrcgroup create <resource-group-name> [–desc <description>]


A.

pd

adm

inC

om

man

dR

eference

Command Description

Creates and names a Web resource group. Theresource-group-name argument is the name of theresource group. The description argument is an optionaldescription that can be added to identify this resourcegroup. The optional –desc parameter must be precededwith a dash ( – ). Descriptions that have spaces need tobe enclosed in double quotes. Example (entered as oneline):

pdadmin> rsrcgroup create webs4807 –desc“Web servers, Room 4807”

rsrcgroup delete <resource-group-name>

Deletes the named resource group, including anydescription information. The resource group must exist.Example:

pdadmin> rsrcgroup delete webs4807

rsrcgroup modify <resource-group-name> add rsrcname<resource-name>

Adds a Web resource to an existing resource group. Theresource group must exist. Example (entered as oneline):

pdadmin> rsrcgroup modify webs4807 addrsrcname engwebs02

rsrcgroup modify <resource-group-name> remove rsrcname<resource-name>

Deletes a Web resource name from an existing resourcegroup. Example (entered as one line):

pdadmin> rsrcgroup modify webs4807 removersrcname engwebs02

rsrcgroup list

Displays the names of all Web resource groups definedto the LDAP directory. Information following “list” isignored. Example:

pdadmin> rsrcgroup list


webs4807websbld3

204 Version 3.8

Command Description

rsrcgroup show <resource-group-name>

Displays the Web resource group information for thespecified resource group. The resource group must existor an error message displays. Example:

pdadmin> rsrcgroup show webs4807


Resource Group Name: webs4807Description: Web servers, Room 4807Resource Members:engwebs01engwebs02engwebs03

Managing Resource CredentialsThe following pdadmin rsrccred commands allow you to managedifferent resource credential-related attributes.

A resource credential provides a user identification and passwordfor a GSO user-specific resource, such as a Web server or a group ofWeb servers.

You can only specify “web″ or “group″ as types of resource whenusing the pdadmin rsrccred commands.

Note: The resource, or resource group, must exist before you canapply the resource credential commands to it.


A.

pd

adm

inC

om

man

dR

eference

Command Description

rsrccred create <resource-name> rsrcuser <resource-userid> rsrcpwd<resource-password> rsrctype {web|group} user <username>

Creates and names a resource credential. Both the userand the resource (or resource group) must already existin order to create the resource credential,. If the user,resource, or resource group does not exist or is notspecified, an error message is displayed. The types ofresource include only “web” or “group” resources whenreferring to resource credential management commands.The resource-name argument is the name given to theresource when the resource was created. Example:

engwebs01)

The resource-userid argument is the unique useridentification (userid) for the user at the Web server.Example:

4807ws01

The resource-password argument is the password for auser at the Web server. Example:

rsrpwd

The username argument is the name of the user forwhom the resource credential information applies.Example:

dlucas


pdadmin> rsrccred create engwebs01 rsrcuser4807ws01 rsrcpwd rsrpwd rsrctype web userdlucas

rsrccred modify <resource-name> rsrctype {web|group} set [–rsrcuser<resource-userid>] [–rsrcpwd <resource-password>] user <username>

206 Version 3.8

Command Description

Changes the user ID and password resource credentialinformation for the named resource. To change or resetthe resource userid of the user or password information,these optional commands must be preceded by a dash (– ). Before the resource credential information can bechanged, the resource or resource group, and the usermust already exist. The type of resource you specifymust match the resource type assigned when it was firstcreated, such as “web” or “group”. Example (entered asone line):

pdadmin> rsrccred modify engwebs01 rsrctypegroup set –rsrcuser 4807ws01 –rsrcpwd newrsrpwuser dlucas

rsrccred delete <resource-name> rsrctype {web|group} user<username>

Deletes only the resource credential information for anexisting user. The type of resource must match theresource type assigned when the resource was firstcreated, such as “web” or “group”. Example (entered asone line):

pdadmin> rsrccred delete engwebs01 rsrctypegroup user dlucas

rsrccred list user <username>

Displays the names of all defined resources and theirtype for the specified user. Example:

pdadmin> rsrccred list user dlucas


Resource name: engwebs01Resource Type: groupResource name: engwebs02Resource Type: web

rsrccred show <resource-name> rsrctype {web|group} user <username>


A.

pd

adm

inC

om

man

dR

eference

Command Description

Displays the resource credential information for aspecified user. The resource credential and the user mustboth exist or an error message displays. Example(entered as one line):

pdadmin> rsrccred show webs4807 rsrctypegroup user dlucas


Resource Name: engwebs01Resource Type: groupResource User Id: dlucas

208 Version 3.8

Policy Management CommandsThe pdadmin policy commands are a set of management commandsthat set specific LDAP user and group account rules and conditions.

You can manage the following policy attributes:

¶ Managing Login Policies

¶ Managing Password Policies

A policy defines the set of constraints placed on LDAP useraccounts and passwords in order to improve the overall security ofthe system. These constraints can be imposed generally (globallyacross every user in the system) or specifically (only to a specifieduser).

If the user has a specific policy applied, this specific policy takesprecedence over any general policy that also might be defined. Theprecedence applies, regardless of whether the specific policy is moreor less restrictive than the general policy.

Managing Login PoliciesThe following pdadmin policy commands allow you to managelogin-related policies.

Use the login-related policy management commands to create newlogin policies or copy existing login policies. In addition, you candisplay information about a user account’s login policy.

For login-related policies, Policy Director defines relative time as:

DDD-hh:mm:ss

and defines absolute time as:

YYYY-MM-DD-hh:mm:ss


A.

pd

adm

inC

om

man

dR

eference

when referring to Registry Policy management commands.

Command Description

policy set account-expiry-date [unlimited <absolute-time>] [–user<username>]

policy get account-expiry-date [–user <username>]

Manages the policy controlling the absolute date andtime an individual user account is to expire. Can also beused to specify when all user accounts are to expire atthe same time. Example 1 (entered as one line):

pdadmin> policy set account-expiry-date1999-12-30-23:30:00 –user dlucas

Example 2:

pdadmin> policy get account-expiry-date –userdlucas

policy set disable-time-interval {<number>|unset|disable} [-user<username>]

policy get disable-time-interval [-user <username>]

Manages the penalty policy controlling the time periodan account should be disabled if the maximum numberof failed login attempts is reached. As the administrator,you can apply this penalty policy to a specific user orapply the policy globally to all users listed in the LDAPregistry. The default setting is 180.

policy set max-login-failures {<number>|unset} [-user <username>]

policy get max-login-failures [-user <username>]

Manages the policy controlling the maximum number offailed login attempts allowed before a penalty isimposed. This command depends on a penalty set in thepolicy set disable-time-interval command. As theadministrator, you can apply this policy to a specificuser or apply the policy globally to all users listed inthe LDAP registry. The default setting is 10.

policy set tod-access {<time-of-day-string>|unset} [–user <username>]

policy get tod-access [–user <username>]

210 Version 3.8

Command Description

Specify the day and time a user (or all users) can log in.The time-of-day-string argument has the followingformat:

<{anyday|weekday|<day-list>}>:<{anytime|<time-spec>-<time-spec>}>[:{utc|local}]

The day-list variable can be mon, tue, wed, thu, fri, sat,or sun. The time-spec range variables must be expressedas: hhmm For example: 0700-1945 The optional timezone is local by default. (Note: utc=GMT)


A.

pd

adm

inC

om

man

dR

eference

Managing Password PoliciesThe following pdadmin policy commands allow you to managedifferent password-related policy attributes.

For password-related policies, Policy Director defines relative timeas:

DDD-hh:mm:ss

when referring to policy management commands.

Command Description

policy set max-password-age {unset|<relative-time>} [–user<username>]

policy get max-password-age [–user <username>]

Manages the policy controlling the maximum timebefore a password expires and must be changed. Thetime specified can be unlimited or a “relative” timeexpressed in days, hours, and minutes. As theadministrator, you can specify a specific user name orapply the policy globally to all users listed in theregistry. The relative-time argument is the maximumtime, expressed in days, hours, and minutes in thisformat: DDD-hh:mm:ss Example 1 (entered as oneline):

pdadmin> policy set max-password-age031-08:30:00 –user dlucas

Example 2:

pdadmin> policy get max-password-age –userdlucas

policy set max-password-repeated-chars {<number>|unset} [-user<username>]

policy get max-password-repeated-chars [-user <username>]

Manages the policy controlling the maximum numberof repeated characters allowed in a password. As theadministrator, you can apply this policy to a specificuser or apply the policy globally to all users listed inthe default registry. The default setting is 2.

212 Version 3.8

Command Description

policy set min-password-alphas {<number>|unset} [-user <username>]

policy get min-password-alphas [-user <username>]

Manages the policy controlling the minimum numberof alphabetic characters allowed in a password. As theadministrator, you can apply this policy to a specificuser or apply the policy globally to all users listed inthe default registry. The default setting is 4.

policy set min-password-length {<number>|unset} [-user <username>]

policy get min-password-length [-user <username>]

Manages the policy controlling the minimum length ofa password. As the administrator, you can apply thispolicy to a specific user or apply the policy globally toall users listed in the default registry. The defaultsetting is 8.

policy set min-password-non-alphas {<number>|unset} [-user<username>]

policy get min-password-non-alphas [-user <username>]

Manages the policy controlling minimum number ofnon-alphabetic (numeric) characters allowed in apassword. As the administrator, you can apply thispolicy to a specific user or apply the policy globally toall users listed in the default registry. The defaultsetting is 1.

policy set password-spaces {yes|no|unset} [-user <username>]

policy get password-spaces [-user <username>]

Manages the policy controlling whether a passwordcan contain spaces. As the administrator, you canapply this policy to a specific user or apply the policyglobally to all users listed in the default registry. Thedefault setting is unset.


A.

pd

adm

inC

om

man

dR

eference

214 Version 3.8

ivmgrd.conf Reference

ivmgrd.conf configuration file for the Policy Director ManagementServer (pdmgrd).

Stanzas:

¶ [ivmgrd]

¶ [ldap]

¶ [ssl]

¶ [authentication-mechanisms]

¶ [object-spaces]

¶ [aznapi-configuration]

¶ [aznapi-entitlement-services]

¶ [aznapi-pac-services]

¶ [aznapi-cred-modification-services]

¶ [aznapi-external-authzn-services]

¶ [delegated-admin]


[ivmrgd] stanza

unix-user UNIX user account for this server.

unix-group UNIX group account for this server.

database-path Location of master authorization database.

B


B.

ivmg

rd.co

nf

Referen

ce


tcp-req-port TCP listening port for incoming requests.

max-notifier-threads Maximum number of event notifier threads.

auto-database-update-notify

Enable automatic or manual updatenotification for authorization databasereplicas.

notifier-wait-time Time (in seconds) the authorization policydatabase is idle before notification is sent toreplicas.

pid-file Location of PID file.

log-file Location of log file.

ca-cert-download-enabled Allow clients to download the root CAcertificate.

[ldap] stanza

ldap-server-config Location of the ldap.conf configuration file.

prefer-readwrite-server Enable and disable the choice for the clientto query the read/write LDAP server beforequerying any replica read-only serversconfigured in the domain.

bind-dn The LDAP user DN used when binding tothe LDAP server.

bind-pwd The LDAP user password.

ssl-enabled Enable and disable SSL communication withthe LDAP server.

ssl-keyfile Location of SSL key file used to handlecertificates used in LDAP communication.

ssl-keyfile-dn Certificate label in the SSL key file.

ssl-keyfile-pwd SSL key file password.

auth-using-compare Choose whether ldap_compare() is usedinstead of the ldap_bind() call to authenticateLDAP users.

[ssl] stanza

ssl-keyfile Location of the SSL key file.

ssl-keyfile-pwd Password used to protect private keys in thekey file.

216 Version 3.8


ssl-keyfile-stash Location of SSL password stashfile.

ssl-keyfile-label Label of key to use other than the default.

ssl-v3-timeout Session timeout for SSL v3 connections.

ssl-listening-port TCP port to listen on for incoming MTSrequests.

ssl-io-inactivity-timeout The duration (in seconds) that an SSLconnection waits for a response before timingout

ssl-maximum-worker-threads

Maximum number of threads created by theserver to handle incoming requests.

ssl-pwd-life SSL password lifetime - in days.

ssl-cert-life SSL certificate lifetime - in days.

ssl-auto-refresh Enable and disable automatic refresh of theSSL certificate and the key database filepassword. If enabled, the certificate andpassword are regeneated when either is nearexpiration.

[authentication-mechanisms] stanza

passwd-uraf Library to use for authentication.

cert-uraf Library to use for authentication.

passwd-ldap Library to use for authentication.

cert-ldap Library to use for authentication.

[aznapi-configuration] stanza

logsize Log file rollover threshold for audit logs.

logflush Frequency for flushing log file buffers foraudit logs.

logaudit Enable and disable auditing.

auditlog Location of audit trail file.

auditcfg = azn Capture authorization events.

auditcfg = authn Capture authentication events.

auditcfg = mgmt Capture authentication events.

[aznapi-entitlement-services] stanza


B.

ivmg

rd.co

nf

Referen

ce


[aznapi-pac-services] stanza

[aznapi-cred-modification-services] stanza

[aznapi-external-authzn-services] stanza

[delegated-admin] stanza

authorize-group-list Enable and disable authorization checks onthe group list and group list-dn commands.

218 Version 3.8

ivacld.conf Reference

ivacld.conf configuration file for the Policy Director AuthorizationServer (pdacld).

Stanzas:

¶ [ivacld]

¶ [ldap]

¶ [ssl]

¶ [manager]

¶ [authentication-mechanisms]

¶ [aznapi-configuration]

¶ [aznapi-entitlement-services]

¶ [aznapi-pac-services]

¶ [aznapi-cred-modification-services]

¶ [aznapi-admin-services]


[ivacld] stanza

tcp-req-port TCP listening port for incomingrequests.

pid-file Location of PID file.

log-file Location of log file.

C


C.

ivacld.co

nf

Referen

ce


unix-user UNIX user account for this server.

unix-group UNIX group account for this server.

permit-unauth-remote-caller Specifies whether Authorization APIclients should be authorized by theAuthorization Server before theirrequests are processed.

[ldap] stanza

enabled Enable and disable LDAP user registrysupport.

host LDAP server host name.

port The IP port used when binding to theLDAP server.

bind-dn The LDAP user DN used whenbinding to the LDAP server.

bind-pwd The LDAP user password.

cache-enabled Enable and disable LDAP client-sidecaching to improve performance forsimilar LDAP queries.

prefer-readwrite-server Enable and disable the choice for theclient to query the read/write LDAPserver before querying any replicaread-only servers configured in thedomain.

ssl-enabled Enable and disable SSLcommunication with the LDAP server.

ssl-keyfile Location of SSL key file used tohandle certificates used in LDAPcommunication.

ssl-keyfile-dn Certificate label in the SSL key file.

ssl-keyfile-pwd SSL key file password.

max-search-size Maximum search buffer size returnedfrom the LDAP server in entries.

ssl-port SSL port to listen on for LDAPcommunication.

220 Version 3.8


auth-using-compare Choose whether ldap_compare() isused instead of the ldap_bind() call toauthenticate LDAP users.

ldap-replica Define the LDAP user registry replicasin the domain.

[ssl] stanza

ssl-keyfile Location of the SSL keyfile.

ssl-keyfile-pwd Password used to protect private keysin the key file.

ssl-keyfile-stash Location of SSL password stashfile.

ssl-keyfile-label Label of key to use other than thedefault.

ssl-v3-timeout Session timeout for SSL v3connections.

ssl-listening-port TCP port to listen on for incomingMTS requests.

ssl-io-inactivity-timeout The duration (in seconds) that an SSLconnection waits for a response beforetiming out

ssl-maximum-worker-threads Maximum number of threads createdby the server to handle incomingrequests.


ssl-cert-life SSL certificate lifetime - in days.

ssl-auto-refresh Enable and disable automatic refreshof the SSL certificate and the keydatabase file password. If enabled, thecertificate and password areregeneated when either is nearexpiration.

ssl-authn-type Authentication type.

[manager] stanza

manager-host Host name of the MTS server.

master-port TCP port on which the server islistening for requests.


C.

ivacld.co

nf

Referen

ce


master-dn The expected Distinguished Name ofthe certificate presented by the MTSserver.

[authentication-mechanisms] stanza

passwd-uraf Library to use for authentication.

cert-uraf Library to use for authentication.

passwd-ldap Library to use for authentication.

cert-ldap Library to use for authentication.

[aznapi-configuration] stanza

logsize Log file rollover threshold for auditlogs.

logflush Frequency for flushing log file buffersfor audit logs.

logaudit Enable and disable auditing.

auditlog Location of the local client’s audit trailfile.

auditcfg = azn Capture authorization events.

auditcfg = authn Capture authentication events.

db-file The location of the pdacld databasecache file.

cache-refresh-interval The interval between checks forupdates to the master authorizationserver.

permission-info-returned

max-handle-groups Maximum number of handle groups toallocate.

listen-flags Enable and disable the receiving ofpolicy cache update notifications.

[aznapi-entitlement-services] stanza

Defines authorization API services.

[aznapi-pac-services] stanza

222 Version 3.8


AZN_V37CRED_SVC A service to convert between PolicyDirector 3.7 credentials and PolicyDirector 3.8 credentials. Allowssupport of remote authorizationrequests from Policy Director 3.7authorization API applications.

[aznapi-cred-modification-services] stanza

AZN_MOD_SVC_RAD_2AB A credential modification service thatallows groups to be dynamicallyappended to an existing credential.This action can give the owner of thecredential additional authorizationcapability.

[aznapi-admin-services] stanza

AZN_ADMIN_SVC_TRACE Enable and disable (using pdadmin)trace administration for anauthorization API application.


C.

ivacld.co

nf

Referen

ce

224 Version 3.8

ldap.conf Reference

ldap.conf configuration file

Stanzas:

¶ [ldap]


[ldap] stanza

enabled Policy Director uses an LDAP user registry. Values are“yes” and “no”.

host The network name of the machine where the LDAPmaster server is located.

port The TCP listening port of the LDAP master server.

ssl-port The SSL listening port of the LDAP master server.

max-search-size The Policy Director limit for an LDAP client search ofdatabase items - such as a request for the ManagementConsole to list users from the LDAP database.

replica Replica LDAP server entry.

D


D.

ldap

.con

fR

eference

226 Version 3.8

pd.conf Reference

pd.conf configuration file

Stanzas:

¶ [pdrte]

¶ [ssl]

¶ [manager]

¶ [ldap-ext-cred-tags]


[pdrte] stanza

configured Indicates whether the PDRTE packagehas been configured.

user-reg-type User registry type. (Currently onlyLDAP is supported.)

user-reg-server User registry server name.

user-reg-host User registry host name.

user-reg-hostport User registry server port number.

boot-start-ivmgrd Start the Management Server (pdmgrd)at system boot.

boot-start-ivacld Start the Authorization Server (pdacld)at system boot.

[ssl] stanza

E


E.

pd

.con

fR

eference


ssl-keyfile Location on the local system of theSSL key file.

ssl-keyfile-pwd Key file password.

ssl-keyfile-stash Location of the SSL passwordstashfile.

ssl-keyfile-label Name of certificate to use other thanthe default.

ssl-v3-timeout Session ID timeout for SSL v3connections.


ssl-io-inactivity-timeout The duration (in seconds) that an SSLconnection waits for a response beforetiming out.

ssl-auto-refresh Enable or disable automatic refresh ofthe key database certificates andpasswords.

[manager] stanza

master-host Host name of the MTS server.

master-port TCP port number on which the serveris listening for requests.

replica Authorization server replicas.

[ldap-ext-cred-tags] stanza

<credential-field-name> =<ldap-inetOrgPerson-field>

Mechanism to add extended attributesto the Policy Director credential fromexisting fields in the inetOrgPersonLDAP object class.

228 Version 3.8

Index

Aaccess control list (ACL) 3, 26accountability 9ACL 3, 26

apply to new LDAP suffixes 144control permission 80create 56custom permissions 61custom permissions example 62default administration policies 87default root 87entries 54entry syntax 56evaluation 63extended action groups 71extended actions 71ID attribute 58inheritance 64management permissions 77operations on an object 60permissions attribute 59resolving request 67traverse 66, 76type attribute 57WebSEAL permissions 76

ACL permissions 59ACL policies, defining 25action

enter into ACL entries 74action, create new 73action group, create new 73actions 59administration API 12administration policies (default) 87any-other 57, 63audit event 158audit trail 158audit trail files 154, 158auditcfg 160

auditingoverview 153

auditlog 159authentication 3, 6authorization 3, 7, 13authorization API 12, 30authorization API standard 5authorization database, replicate 128authorization evaluator 18authorization model 13authorization policy database 17authorization process 28authorization server 13, 119authorization service 14, 16, 17

authorization API 20benefits 16management interface 19

auto-database-update-notify 129

Bboot-start-ivacld 128boot-start-ivmgrd 127

Ccentralized management 9configuration files 123container object 44

management 46user-defined 47WebSEAL 46

control permission 80credentials 3


Ind

ex

Ddefault administration policies 87default config ACL 89default GSO ACL 89default management ACL 89default Policy ACL 89default replica ACL 89default root ACL 65, 87default WebSEAL ACL 88delegated administration

administration users and groups 101creating groups 109group ACL permissions 111group and user management 106group container objects 107managing policy 114object space management 100user ACL permissions 112

Eencryption 3

supported standards 7evaluating an ACL 63event field ID codes 167explicit ACL 64explicit ACL policy 25extended action groups 71extended actions 71external authorization service 35

Ffail-over configuration 139field ID codes 167

Ggroup 55group container objects 107GSKit 13

IIBM Global Security Kit (GSKit) 13IBM SecureWay Directory 139inheritance 64inherited ACL 64inherited ACL policy 25integrity 3iPlanet 139iv-admin group 102ivmgrd.log

example 155ivmgrd-servers group 102

LLDAP

fail-over configuration 139overview 133suffixes, new 144

ldap.conf 140LDAP fail-over

preference values 142local cache mode 30, 34log files 153

enable, disable 155logaudit 158logflush 160logging

overview 153logsize 159

230 Version 3.8

Mmanagement/ACL permissions 78management/Action permissions 80management/Config permissions 82management/Groups permissions 85management/GSO permissions 86management objects 24management/Policy permissions 83management/POP permissions 81management/Replica permissions 83management server 11, 17, 119management/Server permissions 82management/Users permissions 84master authorization policy database 17max-notifier-threads 129, 131

Nnotification delay time 131notifier-wait-time 129, 131

Oobject permissions 87object space, user-defined 48

creating new 49object space permissions 87object types 49, 108objects, create and delete 50

Ppd_start 122, 124pdacld 120pdacld.log 155pdadmin 11, 122pdadmin server replicate 130pdmgrd 17, 120pdmgrd.log 155

permissions 59custom 61custom, example 62

Policy Directoradministration API 12authorization API 12authorization server 13authorization service 16, 17components 9core technologies 6IBM Global Security Kit (GSKit) 13introducing 5management server 11pdadmin 11securing enterprise networks 2security server 11security technologies and definitions 2Web Portal Manager 10WebSEAL 11

policy enforcer 14POP 3, 27, 91

apply to objects 94configure attributes 95create 93

POP attributeaudit level 96IP endpoint authentication 98quality of protection 98time of day 97warning mode 95

POP policies, defining 25preference values (LDAP fail-over) 142protected object 23, 44protected object policies 27protected object policy (POP) 3, 91

apply to objects 94configure attributes 95create 93

protected object space 3, 23, 43guidelines 70management objects 24protected object 23system resource 23user-defined objects 24web objects 24


Ind

ex

Qquality of protection 4, 7

Rregistry 3remote cache mode 30, 32replica 141replicate authorization database 128replication 21resolving ACL request 67resource manager 14resource object 44rollover threshold 159root ACL (default) 65, 87

Sscalability 3, 8, 21sec_master user 101secure domain 3securing enterprise networks 2security

common concerns 4implementing policy 23

security server 11security technologies and definitions 2server

automating startup 127server log files 155server replicate 130server status 126servers, start and stop 124serviceability messages 156sparce ACL model 64start and stop server 124status, server 126system resource 23, 44

Ttraverse 76traverse permission 66, 76

Uunauthenticated 58, 63update notifier threads 130user 54user-defined object space 48

creating new 49user-defined objects 24

Wweb objects 24Web Portal Manager 10, 27, 122WebSEAL 11, 119webseal-servers group 102webseald 120webseald.log 155

232 Version 3.8

Printed in the United States of Americaon recycled paper containing 10%recovered post-consumer fiber.

GC32-0680-01